TRS-80 Model 4p movie streaming from floppies | Hacker News Reader

TRS-80 Model 4p movie streaming from floppies

youtube.com

146 pointsrocky113837 comments

Woo, nostalgia! My father's TRS-80 Model 4P was "my" first computer back in the mid- to late-1980s, and I spent more time on it than an elementary school kid probably should've. (Every time a new issue of Family Computing showed up in our mailbox, I'd grab it and flip through it to see if whatever games were in that issue had TRS-80 Model III or 4 versions...)

The "P" in "Model 4P" stood for "portable" — it was a modified Model 4 that was shrunk down to something roughly the size of a sewing machine. It had a handle on the back. Tandy's advertisements proudly proclaimed that it fit in overhead bins on airplanes. I feel sorry for anyone who actually tried that.

As far as specs, the 4P had a 4 MHz Z-80, a minimum of 64 kB of RAM, one or two single-sided double-density (SSDD) 5.25" floppy drives, and an 80x24 text mode. There was an optional 640x200 monochrome graphics card, but it doesn't look like this demo is using that. (I'd bet it's using the graphics characters in the Model 4's 80x24 text mode — faster and less data to deal with.) If I'm remembering correctly, the SSDD disks held ~180 kB, so there's less than half a megabyte of data in play for this demo. I'm kind of amazed at the sound in this demo — I'd never heard the speaker in my 4P ever make any noises other than simple beeps.

Semi-related trivia: The "best" word processor for the Model 4, SuperSCRIPSIT, was laid out on its program disk in such a way that the drive head's stepper motor played something that almost sounded like a song when it was loading itself off of the disk. Even ~30 years later, I can still hear SuperSCRIPSIT's loading sound in my head...

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.

Seeing this on a 4mhz machine with such low specs makes me wonder what sort of impractical demos might be possible on modern equipment that harbingers of things to come 20-30 years. Can anyone think of anything off the top of their heads?

The fun part of demos these days tends to be making everything small or real time. Playing back a fullscreen video is impressive for old enough hardware, for recent hardware it's trivial and then it can display literally anything you care to prerender.

I remember Kevin Kelly writing a blog post (that I can't find now) where he speculated that 30 years from now someone will come up with a clever way to get strong AI running on today's hardware.

Maybe we get true 3d screens in the future.

Then todays equivalent would be to hook up 5 external monitors, take the backing off, and running a movie through them to get 3d.

To clarify. Make the screens semi transparent, then look through all 5 from the front.

The demo scene back in those days, and before, was nothing short of astounding.

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.

my nostalgia moment, I was taught COBOL on these machines back in 86. I remember them well as it led to my buying my first PC, a Tandy SX. Having used original IBM PCs at my parents home I was so impressed by "Tandy Color" and sound. One thing led to another and Turbo Pascal and Turbo C entered by programming life... and a Model 50 with old school gray scale screens that still looked amazing.

Which makes it all so sad having read that eulogy to Radio Shack here a few days ago.

Out of all things, hot swapping those floppies blows my mind the most.

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.

What happens if you miss the swap window?

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

Next up, a Lego Mindstorm floppy swapper robot.

Crazy thing is that it would have far more smarts than the computer playing the movie.

and now i wonder how hard it would be to build a monochrome display using Mindstorm.

How about a mechanical display built using mindstorm robots and individual blocks as pixels? I bet you could get at least 1 frame a minute.

Whats the name of those mechanical notice boards that they used to have on train stations? I guess a mechanism like that pr pixel could perhaps be a option.

The number of synchronized mindstorm bricks and motors needed would likely be a nightmare though.

Did you use some kind of look-ahead caching going on in the video? In the full screen vid it comes out OK, but I noticed that in the sound demo you recorded it seemed like sometimes the video would struggle to keep up, and fall back to more and more of the picture being just text noise.

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.

Awesome. I love seen stuff done with the old Tandy machines; I grew up with a Color Computer 3, and I've seen that thing do some amazing things but rarely much done with the Model 1-4.

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

Really nice work!

The Model 4p must have had a better disk controller and software than my Model 1. The Model 1 used a Western Digital 1771 controller that required a pause between writing a disk command and reading the status. A few NOPs would do, but early versions of TRSDOS missed the pause out, causing frequent crashes.

I never did movies on it, but in 1980 managed to get it to record a few seconds of recognisable speech using the I/O line in the cassette port. Filled the massive 48k memory in no time.

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.

Neat. One of the hack ideas that I never got around to implementing was back in 2000 at the uni, when we had a bunch of 386SX's running in text mode as email terminals: pipe a video (e.g. a TV stream) through aalib on a fast server, and stream the resulting ASCII sequence, cleverly compressed, to the terminals. The tricky part would be to cope with latency well enough to avoid jerky playback (telnet wouldn't cut it).

I'd seriously watch tv shows on this kind of screens. I'm even searching for old monochrome LCDs for a uber minimal retro laptop (think Grid Compass https://www.google.fr/search?q=grid+compass&tbm=isch).

Thanks !

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.

I have a weird fetish for non realistic renderings, to the extreme (libcaca, terminal dithering), the more constraints the better.

My current obsession is finding a way to filter an image to display using the sharp MZ-series character set: http://www.sharpmz.org/mz-700/codetable.htm Very interesting symbol table for its time. Japanese so, it's like they always wanted emoji.

I know almost nothing, my desire came from reading this http://www.a1k0n.net/2011/07/20/donut-math.html . In case that helps you.

3d rendering on ascii terminal, if you can, build and run the source ( http://www.a1k0n.net/2006/09/15/obfuscated-c-donut.html ), it's always pretty to see running.

That's awesome! I fondly remember my BASIC programming class on the TRS-80, playing Telengard, and inserting 4 letter words into Tank Battle using the hex editor. Not to mention my favorite Doctor and favorite episodes (Key to Time).

Spectacular. I remember a friend's older brother wrote a speech synthesizer for the machine.

I still have our old Model 4P, and it's functional (as well as our Model 1, and my Model 100).

I hacked the crap out of those machines; they taught me programming. Assembly language routines in string space, anyone? VARPTR FTW.

"4p"? There are clearly more than 4 horizontal lines.

I thought the same. There are actually 48 lines. I think 4p is the model number.

It's a TRS-80 Model 4P, rather than 4 lines of horizontal resolution. Fourth version, and P means portable (in the loosest sense of the term). The actual video would be 16 characters high by 64 characters wide.

Very nice. Wondering was this a stock Model 4 or did it have any expansion to allow it to pull this off? Impressive that the floppies could keep up. Was it reading/displaying the floppies in real time or would it push the full floppy to memory and start when the previous stream was empty?

BTW: Love the choice of video. Very cool.

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.

I thought that I was going to see a hacked TRS-80 steam a 4K movie.

Reply on news.ycombinator.com