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 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
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.
The number of synchronized mindstorm bricks and motors needed would likely be a nightmare though.
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.
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.
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've done some other Model III demos. Here's a good starter page for them: