gp2000

The partial workaround for negative G problems is a nice little story: https://en.wikipedia.org/wiki/Miss_Shilling%27s_orifice

I worked on the gcc back-end for TAOS. One requirement was a special output format called a "tool" which was like a single subroutine shared library. It was specified with the standard "-f" gcc extension syntax: "-ftaos-tool".

I heard about the name change to "Elate" second hand. "taos" had to change to "elate" everywhere -- even the options.

The naming may or may not have sucked, but it definitely did blow having to tell the compiler to "-felate-tool".

I think because they were earlier machines the audience for the Model I/III/4 line is smaller. And no doubt many were sold to business which lessens the nostalgia.

I've done some other Model III demos. Here's a good starter page for them:

http://members.shaw.ca/gp2000/breakthrough.html

Yes. Conceptually the program is two threads. One reads from the floppy into a ring buffer and the other reads from the buffer and drives the audio and video. A few tracks are read to prime the buffer before the display thread runs in earnest.

The glitches you see are when a byte is dropped when reading a disk track. This causes the display to shift by a column and the interleaved audio data is displayed as graphics. And, conversely, one of the graphics columns is played as audio causing the screeching.

Some runs work better than others. The byte drops could be due to slight motor speed variance. Or just down to luck -- a few of the disk operations incur wait states as does writing to video memory. These times vary depending on exactly when they occur so it could just be down to luck. The code works in fixed 128 cycle steps with a few cycles reserved for wait state issues but apparently not enough to ensure correct operation.

And what about when the screen completely fills with garbage? I've no idea. Maybe the track didn't write correctly. Or maybe the drive misses a bit. Shifting the graphics and audio data stream by a bit would surely scramble the graphics. The audio should be mostly OK save for getting random noise every 8th bit.

I think the 4p has a Western Digital 1773 controller. I don't know if it is much better beyond supporting double density. My code does wait on status checks after writing commands. Maybe that's not necessary, but I haven't done floppy drive programming before this so I followed the example code closely.

Doing some speech recording back in the day -- heady stuff! I've always wondered how Big Five (and other) TRS-80 games managed to get reasonable voice output considering they are 1 bit/sample at 5 KHz.

Takes me back, remembering how proud we were that our "baby" computers could speak. And now? Well, let's just say that I wish the "tab is producing audio" icon on Chrome tabs functioned as a mute button.

Completely stock. The floppy drives can crank out a byte every 32 microseconds giving a theoretical maximum of 30.5 KB/second. Then you lose some to seeking and other overhead. A full screen is 1 KB so 30 FPS is within reach (I'm only doing 25). Actually, a graphics screen of 128 x 48 can be encoded in 768 bytes. Finding time to do the unpacking is the tricky part.

The floppy reading and and video/audio display are completely interleaved. The program works in 32 microsecond steps with 13.5 microseconds dedicated to reading the disk and 18.5 microseconds spent on graphics and audio update. These two conceptional threads communicate via a 32 KB ring buffer.

You can hear the disk seek a few times before the display starts as it builds up some buffer. I imagine a graphics display could be managed at a coarser level of interleaving at the expense of floppy bandwidth. Audio, however, needs constant servicing to work at all.

You recall the disk capacity correctly -- 40 tracks, 18 sectors/track, 256 bytes/sector. However, uses track-at-a-time reads to squeeze 200 KB onto each disk.

Track reads are a bit of a devil's bargain as certain data patterns cannot be written and other data patterns cannot be read. It still means more data though there is some possibility that conventional sectors with tight inter-sector gaps could do the job.

With 320 x 200 resolution on the Grid Compass you might be able to use conventional techniques to convert from color to monochrome.

At the 112 x 48 resolution I used, dither with or without error diffusion lost most of the image. Well, it would have looked fine standing back 6 feet or two metres or so, but what's the point if it looks bad at normal viewing disance?

I experimented with edge detection and GIMP filters like Posterize and Cartoonify reasoning they would tend to bring out the rough shapes in the image. I ended up doing some of it with Posterize and most with Cartoonify. The result is acceptable enough, but I do think the "tunnel" effects could be made to look a lot closer to the original.

The program will try to read from the drive and pop up an error message. Or crash; the error checking isn't super robust.

It would mean starting over at a minimum. The program isn't very user friendly, either. So for goodness sake don't lose concentration in the middle of a movie.

Edit: s/loose/lose/ - my typo nemesis

It wasn't quite hot swapping as only one floppy can be active at a time. Still, even with a whole 7.76 seconds I was worried I would crack under the pressure.

Good analysis. It actually uses the 64 x 16 text mode which has semigraphics yielding a 128 x 48 display. I only use 112 x 48 due to floppy disk bandwidth limits. I'm thinking of trying the 40 x 24 text mode. The 80 x 96 resolution would be a little nicer despite having two difference sizes of pixels. Or go the full 160 x 96 but that would require data compression of the video.

The hires adapter card has pretty serious write bandwidth limitations though there are possibilities if you're willing to put up with severe screen hashing.

It is pretty surprising how good 31250 Hz 1 bit audio can sound. As long as you set your expectations reasonably. "Was recognizable and didn't make my ears bleed too much" is about right.

Google of the past has severe doubts about Google of the present:

...we expect that advertising funded search engines will be inherently biased towards the advertisers and away from the needs of the consumers.

They were forced to change the name as they had lost the rights to use it: http://en.wikipedia.org/wiki/The_Source_(retailer)

Briefly: international Radio Shack stores were put under control of InterTan, a Tandy spinoff. When Circuit City bought InterTan, Tandy cancelled the licensing agreement to the Radio Shack name.

Not architecturally, but Federico Faggin and Masatoshi Shima were the key people on the 4004 and 8080 before leaving to form Zilog and build the Z-80. The Z-80 had to have DAA (decimal adjust) to be compatible with the 8080. Possibly the 8080 had DAA to compare well against the 6800. If that's the case, then we must ask where the 6800 got the idea. Could be from minicomputers or even mainframes, but from what I've read the early microcomputer designers had no pretense of making processors to compete anywhere near the high end. Instead their sights were set more along the line of embedded systems. Desktop calculators fit into that and Shima himself designed desktop calculators and helped specify the 4004 before he came to Intel. Thus my speculation that the impetus could have come from that direction.

Would love any and all analysis, but most interesting to me would be instruction details and especially the undocumented side effects. I'd also like to see comparison with the 8080 and how Zilog improved/changed the design.

I'd guess this goes back to the 4004 which was designed for a desktop calculator. Easy BCD really helps those applications so they must have had that in mind as a target market. There's not much point in using BCD once reasonable amounts of RAM and ROM are available.