3 ms·

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 min

by gp2000 12y ago

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

digi_owl 12y ago
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.
- Igglyboo 12y ago
  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.
  - digi_owl 12y ago
    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.
jarcane 12y ago
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.
- gp2000 12y ago
  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.
  - jarcane 12y ago
    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.
    - gp2000 12y ago
      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 http://members.shaw.ca/gp2000/breakthrough.html
Starwatcher2001 12y ago
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.
- gp2000 12y ago
  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.

by gp2000 12y ago

digi_owl 12y ago

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.

Igglyboo 12y ago
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.
- digi_owl 12y ago
  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.

jarcane 12y ago

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.

gp2000 12y ago
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.
- jarcane 12y ago
  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.
  - gp2000 12y ago
    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 http://members.shaw.ca/gp2000/breakthrough.html

Starwatcher2001 12y ago

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.

gp2000 12y ago
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.