How Fast Can We Load From Tape?
HTML-код
- Опубликовано: 24 июл 2024
- If we suddenly had a perfectly-reliable cassette tape, how fast could we possibly load data from it? This is a question I started pondering a while ago. To answer it, I had to do look into how data is stored on tape and how exactly we load it. Along the way, we'll find several limits and assumptions we have to work around on our quest for the fastest-possible loading.
Support Noel's Retro Lab on Patreon: / noelsretrolab
You can also support Noel's Retro Lab on RUclips by joining this channel:
/ @noelsretrolab
Chapters:
00:00 Intro
00:54 Cassette audio
02:05 Audio data encoding
03:03 Measurements from tape
05:44 TZX
08:28 Loading code
12:41 Arduino issues
19:01 Cassette port issues
21:41 Alternate port
24:25 Conclusion
Links:
Noel's Retro Lab web site noelsretrolab.com
TZX Format k1.spdns.de/Develop/Projects/z...
TZXDuino Reloaded github.com/arananet/TzxDuino-...
Maxduino Firmware github.com/rcmolina/MaxDuino_...
Hyperloader and CDT Scripts github.com/llopis/HyperLoader
Music tracks:
Funky Stars by McKlain mcklain.bandcamp.com/track/fu...
Battro OST by McKlain mcklain.bandcamp.com/track/ba...
More awesome music by McKlain: www.mcklain.com
🛠 Tools I use ➤ noelsretrolab.com/tools.html
Connect with Noel's Retro Lab:
Discord ➤ / discord
Facebook ➤ / noelsretrolab
Twitter ➤ / noelsretrolab
Instagram ➤ / noelsretrolab
Mailing list ➤ noelsretrolab.com 
Наука
(turns cassette tape into an NVMe)
Noel: «We can go faster»
At this rate, that Amstrad is going to travel through time. Great work!
Over the last year, this has become my favourite channel, but this video is even better than usual! Absolutely fantastic stuff, Noel. So informative, so enjoyable to watch. Just brilliant. And 100% agree about Head Over Heels. We spent literally days playing it as kids, but only as an adult have I come to appreciate it as programming masterpiece. Cramming so much game into so little memory is a work of technical genius that staggers me to this day.
So happy to hear that! Thank you very much! I put a lot of work into this video, so I'm glad it paid off. And yes, HoH was fantastic. I don't think I ever finished it all the way, but I sure made lots of maps along the way 😃
@@NoelsRetroLab Continuación for this video? Is interesting how we can modify the computer to load from tape at the max fastest speed posible.
IF we had this kind of speed back in the day we could have saved so much time.... possibly get our chores done? NAH! We'd just play more games! 😂
in a way slow loading times helped make you choose better .. but esp. on atari 8 bit :/ super slow.
Faster loading times actually means you will do less chores. Back in the day load times were so long you could start a game then go take out the trash and it still wouldn't be finished when you come back. If load times were shortened you'd be forced to do fewer chores, there would be no choice!
"...and I will see you next time!"
Noel channeling his inner GreatScott!!
I love the way GS says it, it sounds so happy and enthusiastic.
I fondly remember writing my first spectrum tape fast loader at 11 years old. It could only save/load at twice the speed but for me it was an incredible achievement. It's a shame I really don't have the same level of interaction with my computer hardware today.
Another brilliant video from Noe's Retro Lab. It is clear that you invested much time in researching, experimenting and in producing the video. To see such an effort is awe-inspiring, and in such an esoteric topic makes it even better. In addition, you do come across well on the camera if I can say that without sounding weird. You are rather photogenic, and your commentary is oddly pleasing to listen to. Every detail of your content is top-notch. Picking a favourite channel is like picking a favourite kid, but yours is definitely a strong contender for the top spot.
My guess is that pause happens when the Arduino needs to fetch a block from the SD card. At faster speeds its probably spending more and more time in the routine that fetches data. You could use a different CMD to stream a byte at a time or use DMA to transfer blocks and use ping pong buffers for playback.
Since this is just a proof of concept, the file contents could probably just be put into flash. He said it's 16KB. As long as the arduino code isn't too big, it'll fit.
Yeah, have written some code for reading/saving data to sd cards, it suprisingly slow and not every card is the same. Generally most sdcard libraries will default to an "ok" transfer method for a read or some even single byte reads which adds upto a LOT of overhead when your thinking about a 16kB of data. Also DMA on an atmega328p?
> _or use DMA to transfer blocks and use ping pong buffers for playback._
As a low-level bare-metal software engineer who's done exactly this sort of stuff, this is what I also would advise. Always have a DMA channel fetching well ahead of where you are reading, so much so that any sudden latency is masked and can be recovered from. And keep in mind that what you call a ping-pong buffer or what I'd call a double-buffer is really just a two-slot ring buffer. Sometimes a longer ring buffer is useful, though for most tasks it's just unnecessary overengineering. It depends on your DMA transfer setup overhead, your worst-case latency, and some other factors. One of those feel-things-out-to-be-sure-of-the-solution problems.
@Never Mind I wonder if it's possible to go into a slightly more extreme direction and skip using a Filesystem altogether, and instead just save the file you want to play as a raw bitstream in a predefined location on the SD Card itself.
The arduino could skip a lot of the FAT processing and instead just read the blocks directly, probably reducing latency a fair bit.
If you get the timings just right, one might even consider starting the output-routine from within the AVR interrupt!
Or, well, just using a modern uC such as an STM32 with true DMA.
I would just add a 32-64 KB SRAM chip as a buffer. Read the data from the SD card into the SRAM chip and no more interruptions.
Like others have said, since I discovered your channel a couple months ago it has quickly risen to the top of my anticipated video list. Never had an Amstrad (I'm in the US) but I find the research, diagnostics, and mods you have been doing fascinating.
Thank you so much Joshua! I'm really glad I can create something you enjoy, even without previous Amstrad "attachments" 😃 Cheers!
On the C64, I once built a custom speed loader using the parallel port and encoding the data on the cassette analog rather than digital. It worked, but only useful in the scene at that point as we already had 286 with hard drives.
now this is a celebration video! congrats
i love the way you research on these projects, trial and error, the fact that you don't hide mistakes, and you're also not afraid of voicing your opinions when you can back em up. without the need of being whiny.
keep'em coming!
Happy 100th! This episode was super fascinating, I've always wondered about those early baud rate recordings and how they work. The part where you made it load through the parallel port was gold!
Glad you enjoyed it! I'm looking forward to continuing with it and seeing how much faster it can really go.
This video popped up in my recommendations recently, and I'm so glad it did. This was a really cool deep dive!
Mod: I was watching most of yours videos this evening, and really enjoyed them! You should have a lot more subscribers :)
Welcome aboard! Really glad you liked them! 👍
Love this channel and these sort of videos in particular. The stubborn refusal to give up and to keep going further down the rabbit hole so the computer doesn't defeat you is awesome and of course what all of us users of these old machines had to do back in the day!
Congrats on Ep 100 man!! Well done!
Thank you!! It was a fun milestone! 😃
Back when I used a ZX81, I found you could make it reliably load more or less at fast forward speed by jamming the pinch wheel from WH Smith own brand C15 (nasty, rattly, and cheap) and it didn't seem to be affected by the tape increasing speed as it ran out.
Nice! It must have a very adaptable loader and be recorded really slow. But in any case, the ZX81 had so little memory, it wasn't as much of a big deal as trying to load 64KB or even 128KB!
Always a pleasure to watch.
The three check for a bit (or 5 in some systems) is also very common in hardware implementations, i.e. UARTs accept a bit as one or zero when the input has been in the same state for 3 (or more) sampling clock pulses. It makes the sampling more robust against frequency mismatches.
Congratulations Noel! All the best to your brilliant channel!!
Congrats on video#100. My mind is blown away at how knowledgeable you are, not just at electronics, but understanding of coding and everything else in between. Fantastic video Noel, keep up the good work. Rebranding looks great too. Will check out the merchandise. Love your channel. All the best, Alan.
Thank you so much Alan! Glad you enjoyed the video and the slight rebranding 👍
That was amazing. It really makes me want to look at older equipment and see what sort of fun things can be done.
Congrats on the 100 anniversary! This video was really interesting! Thanks!
I wanted to start a whole comment about that they usually pulse width encoding and not FSK, and then you are explaining the timer loops to detect the pulse width.
This is the first time I see content that's really in depth with some nice assembly. Thank you!
A lot of impressive technical deep dive in this one Noel, really enjoyed the watch! Thank you :)
Wow, very cool. I love the idea of using the 'parallel' port as a sort of serial port :)
Congratulations on the 100th video, hope this is just the introduction to a long career. I do not want to elaborate a posh post with a list of positive adjectives here, but yours is by far my most appreciated 8-bit channel. Every time I realise there is a new episode, just keep it in my mind to watch at the end of the day. I normally watch your episodes (as this one) a couple of times (and even more times in the parts where you get deep in the more interesting explanations). So nice you made some merch and, when my situation gets better, will Patreon & "merch addict" Noel's Retrolab. Love the solution where you skip the opamps and jump directly to the chip: I was shouting this idea at the screen when you came up with it :-)))
Wow, that was really well researched. Great job!
Thank you! Glad you enjoyed it. And that was your Amstrad again, serving as a guinea pig in case you hadn't noticed 😃
Absolutely excellent episode !
Wow! 100! Congrats to you. You're still in my Top 2.
Whoo-hoo! 😃👍
This will be nice to see an update in the near future. Good work 👏
Another excellent video Noel! Congratulations on episode 100, who'd have thought a humble Amstrad CPC could outpace an Arduino! Here's to many more episodes.
Congratulations on the 100th episode, I wish you a lot of success on this channel. Nice new intro. Greetings!
Excellent video. A very interesting topic, well researched, and clearly presented. Well done. Looking forward to the follow up.
You really did your homework for this one. Excellent work Sir!
Thank you so much! Doing my part to get to buy an Amstrad one day 😃
@@NoelsRetroLab I’ve been looking
Happy 100th episode Noel! This was a very fun episode. I do not load software by tape but enjoyed watching your experiment regardless.
Glad you enjoyed it! Thank you!
Really enjoyed this one.... not sure how I stumbled on your channel. Your presentation of technical data made me feel smarter :D Great Content.
Really glad to hear that. Welcome aboard! 👍
Wow, this answered some questions that were buried in the back of my mind for ages. Subscribed!
Congrats on the 100th! Your channel is absolutely amazing. This video sets you apart from other favourites and I definitely look forward to the follow up.
Why anybody would vote a thumbs down on this one is beyond me, a double thumbs up is required in this case for me.
Thank you so much!!
I love channels like this . Stuff that interested you as a kid, becomes even more interesting as an adult
It´s fascinating seeing so many skills being used at the same time for one purpose.
Thanks! The combination of software and hardware is the area I enjoy the most 😃
Black in the 80's I had an Amstrad CPC 6128 and a Philips tape recorder. When I was loading games from the tape recorder, I pushed the fast forward half way down, while it was loading, making the tape spool while still playing the "sound" and, yes the games was loading much faster. Sometime it crashed. I had to be very precise, pushing to hard, and it didn't worked.
Very interesting and well done video. Not only did I learn about making loading faster but also why loading from a cassette can be unreliable or complicated at times.
I loved the video!. Your channel is a true gem and each video you do is better than the previous one. I'm also a HoH fan. I managed to finish like 3 worlds after a lot of practice. Keep up the good job.
Thank you! 👍 I think that's about how far I made it in HoH with a lot of map making. I believe I never finished the whole thing. Shame on me!
Epic video this one! Lots of effort and love gone into this one!!!! =D
Thanks a ton! Glad you enjoyed it. Yes, this one took longer than usual to prepare, but it was also lots of fun making it 😃
@@NoelsRetroLab Fantastic really! Your best video yet! It really shows just how talented and experienced you are ;)
@@GadgetUK164 Thanks for sharing the video on twitter too, otherwise I'd never have come across it. Insta-subscribe. Great job Noel and thanks Chris 👍
@@75slaine No worries =D
That was some ingenious and creative engineering. Brilliant stuff!
Congratulations for your 100# episode. Thank you for inspiring us. I wish you much success. God bless you.
Hi Noel, congratulations with your #100 video. I remember that there where cd’s with recorded audio that where loading really fast on the msx with a diskman . See the game collection cd with 33 games on a audio cd
Wow! With each of your videos I'm thinking 'It can't get any better', but then you proof me wrong again!
A very cool video - from a true SME! Very interesting and informative!
i had no idea that's how the tapes loaded, fascinating!! thank you so much : )
Glad you enjoyed!
No idea why YT recommended this but i'm glad it did, super interesting!
Very interesting! I learned a lot about tape loading, thanks!
And happy 100th ;o)
Glad you enjoyed it! Thank you!
Definitely one of my favourite channels although if I don't hear "there we go" in a video when you are repairing something,I feel cheated 😂
Congrats on episode 100!!
Very interesting. I really like the way your videos are done with regards to quality and the way you explain things. Any change of a coffee mug?
Thank you! Really glad to hear that. Sure, I can add a coffee mug 😃 I didn't want to go overboard since I didn't know if people would be interested, but I can easily turn that on. There you go: store.noelsretrolab.com/listing/get-noel-s-retro-lab-logo?product=659
Great video! I was doing something similar a few months ago, but I went the route of using physical tapes. It was on my TRS-80 Colour Computer, using a high speed Poke and rerecording the audio at double speed I was able to cut load time in half! Although it ended up being more reliable to playback the double speed file right from my computer :)
Your best video to this day of those I watched. This video was very instigating, an in depth journey on cassette loading of programs.
I remember that in Brazil an FM Radio (an University radio) had a program where they played computer programs for you to record and load on your computer. I wonder how much the radio transmission and filtering got in the way and if it worked. I think it did as the it lasted fr aa time long enough for me to remember it. Even in the era of diskettes and even HDs.
Es fantástico descubrir los límites del hardware y como se puede ir un poco más allá... Me encanta este canal y lo relacionado con todo lo retro.
This was an amazing watch!
This channel is fantastic. Subscribed.
Your channel and Adrian's are my favorite retro tech channels.
Wow, thanks! Adrian's is also one of my favorites! 👍😃
Happy 100th, very informative and a candidate for a hackaday entry.
Thank you so much!
grats on the 100th, you deserve it bud
Congrats for the 100!!!
Wow that's some in depth research and testing.
I am so impressed always by your analysis!!! Awesome.
fascinating stuff there. Love it.
This is amazing! Love seeing the code too.
I remember I was trying to make my Spectrum+2 to load faster. Friends with Atari machines had their "Turbo 4500" and later "Turbo Universal" and were able to push the limit up to 6000bps. But it was Atari with special tape recorders, so it was possible (and necessary) to modify the recorder HW in order to get through the much higher frequencies. All with regular tapes.
I was trying to analyze the built-in recorder (+2 have one) to get better signal, but it would require quite a big rebuild. I changed the recording scheme, so zeroes and ones were the same length, but ones flipped the signal, so the result was also two frequencies, but just one clock. This improved the speed a bit as zeroes required half the time. In the end with the stock HW I was able to push the speed to somewhere around 2400 - 2500 bps.
And then I moved to other loader tricks - like showing rolling counter instead of the border bars or being able to switch memory banks while also keeping some parts excluded, so I could record or load the whole memory in one block, which I used to create my 128K tape copy program.
The code definitely needs some cleanup. Just write to the PIN port to toggle a bit. The internal state variable is redundant.
Alternately, use the built-in timer to produce a pure tone.
And of course the Arduino library which is made for ease of use and portability, sacrifices way too much speed.
Enjoyed it indeed Noel. Another great video! The concept is great, pushing the limits of existing ecosystem of available programs & hardware to get the fastest load. I guess this 'faster horse' approach is only the start. Having a purpose built 'load on the fly' device which loads directly into the CPC's memory through the bus port would get you the fastest throughput and load times. Without resorting to moving to the "disk interface" world. I think all raspberry pi versions could handle that job well.
Fantastic experiments - now I want to try this on my Oric-1!
This is really interesting, I love the mix of hardware and software.
Congrats on your #100 th episode! I wonder if a smartphone or computer could reliably reproduce the fastest settings for testing purposes, I think that could make a pretty neat video as well
Very interesting project ! Congrats
Great job Noel.
Very good! I'm about to do some similar tests on a MSX !
This was a great video! I remember using a custom loader on my ZX Spectrum 48k to double the tape speed when I was in high school!! An idea that I had while I was watching the video was this: Since the Arduino is used to send the data, while using a custom loader on the Amstrad on a custom pin, why not use a second pin as a clock then? That should be interesting!
What a cool intro! Its the best I've seen!
OMG, I hadn't realised just how much I had forgotten over the years!
I spent weeks, probably months, studying fast loaders on my C64, reverse engineering them (disassembler) and figuring out how they worked. The Commodore 64 Programmer's Reference Guide had an amazing amount of information in it but still skipped most of the required information therefore I had to rely on practical testing and experimentation. In the end I produced a considerably faster saving and loading scheme that worked mostly reliably on my computer... only mostly reliably because there's a disjoint between the recording and read heads on a datasette unit (Commodore) or regular tape player/recorder and a tape recorded at such speed on mine, even reliably, would almost never load on a friends computer. As a result I had to slow the process down until it was reliable on friends computers as too, and the end result? A fast loader that was pretty much the same speed as the original ones that I reversed engineered!
The Arduino problems did amuse me a bit, but then I remember the problems with my turbo loader and NMI (Non-Maskable Interrupts) that might happen at any time in the execution loop and discovering this and having to deal with it. An interruption in a processing loop that's really timing sensitive can really cause chaos and some early turbo-loaders were easy to cause to fail just through pressing some keys on the keyboard during loading (and some game exploits relied on this). Just to add, I can pretty much guarantee that my code would *never* have coped with the difference between PAL and NTSC systems! :)
Anybody who doubts the effort and smarts that went into our early computer days really isn't paying attention or is trying to deprecate them because the early computers weren't multi-GHz monsters with CPU capacity to waste. We had very limited processing resources and we got every bit of speed out of them that we possibly could... and by way of comparison, non-turbo loaders typically had data read times best described in bytes per minute and reading just 32K of data could easily take half an hour or more.
Great video, thanks.
Hi Noel, Congrats on Episode 100! The new logo looks very nice 😁
This video is very interesting; I shall be looking forward to the follow-up. Here´s something I thought during the video: When you mentioned that the Arduino was close to the limit of what it could handle, it occurred to me that perhaps a Raspberry Pi can handle faster speeds, but of course that would probably entail writing a brand new software package for the Pi. What do you think? Is that something that would even be possible, let alone feasible?
I see you've finally crossed over the line from pure hardware to tinkering with software :)
On using a normal compact cassette tape for data transport, an unrelated project that was contemporary with the CPC464 release we used to record audio using stereo heads with one channel fed from a very stable 8KHz pure sine wave source while the other channel contained our target audio. Then using a dynamic buffer on the reader input stage which took out most tape distortion we were able to recognise FSK up to 2,700bps & 16dot PSK up to 9600bps
Brought back memories. I modded a model one TRS-80 to 4 times cassette speed and double clock speed. Those were the days. :)
Really nicely done, thanks :)
This video is fantastic - thanks. So much research and yak shaving :D
Glad you liked it! 👍
@@NoelsRetroLab Btw: I really hope we'll see the new and improved firmware at some point :P
This is great content! Love it!
Happy 100th video posted anniversary! As usual, very nice and pleasant to listen to)
This trick might even work - with some minor modifications - on an MSX with a cassette interface port (which is a DIN-8 connector). The cassette read pin is attached to pin 7 of port A of the PSG instead of the PPI, but the modulation is the same. The MSX BIOS has values for 1200 and 2400 baud, but I have been able to get it up to 4800 baud when using a cassette deck instead of a data recorder (and on Type-II tapes, but I'm not sure if it's relevant). The highest baudrate for the tape port I have seen for the MSX is 9600 baud. Philips made a CD for the MSX with 99 programs on it, which you could fast-load that way.
OpenMSX supports wave files natively as cassette input, so it may be fun to experiment with that as well.
As a longtime TRS-80 cassette port hacker, I support this video! +1
Ooh, I know very little about the TRS-80. Was there something in particular about the system that made it necessary to hack things with the cassette port, or was it just something you experimented with?
@@NoelsRetroLab It served double-duty as a bit-twiddle output device for music & SFX generation, even crude sampled sound. The cassette routines were kind of a gateway to channel coding theory & DSP, although I didn't know it at the time. Some third parties had some amazing high speed loaders, I digitized their cassettes way back thinking one day I might write a soft-emulator for interpreting them.
very cool, waiting for more speedups :)
I did almost the same thing for another Z80 computer, the Video Technology Laser 500, and I also found that the upper limit was imposed by the non linearity of the audio input circuit. I played .WAV files directly from Audacity on the PC. One of my tricks was to elongate the duration of the 7th bit pulse (corresponding to the end of the byte) in order to compensate for the RET from the "ReadOneByte" function.
cant wait for part 2, that was fun
Thank you! Part 2 will take a while since I haven't started yet and these kind of episodes take a while. But I'm really hoping to have it ready in a couple of months.
Fantastic video and very proud that you use my emulator :D
Could you put in the description the CDT files so I can have a look at them?
Hi! I put all the code here: github.com/llopis/HyperLoader The CDT files aren't there, but you can generate them yourself with the script.
I actually *LOVE* your emulator, but I wasn't able to use it for this for some reason! It worked on WinAPE but not on RVM, even at a low speed. Happy to chat about this offline any time (en español también 😃).
@@NoelsRetroLab I didn't know why you said they didn't go in rvm but you are right!!!.
I have created several cdt and they loaded correctly, but of course I was testing it in the version of rvm that I have in development that has a much more accurate emulation of the Amstrad CPC.
When I tested it in the public version, it didn't load, it's a bug about the polarity in the cdt that I fixed some time ago.
It will work properly in the next version.
As a curiosity, in the development version, the fastest I've been able to load it is with a length of 96
Thank you very much and for anything you want, contact me in the mail in my web page ;)
Back in the day, I was told that you didn't want "studio quality" tapes, because they were supposed to be worse. The reason given for that was that studios run their tape at a much higher speed (wider tapes too, I'd guess) and so the actual uniformity of the tape would be far less important. I don't know if it was true, but I did remember this claim all those years...
Love the new logo! 💪🏼☺️
Yay! Thank you!
Great job, very impressive!
Thank you very much!
sweet!... really great job Noel..the printer port loader is brilliant!
Thanks a bunch! 😃
@@NoelsRetroLab "Noel's Busy Loader" ..has a nice ring to it! :P
Many moons ago, I had 2 ZX Microdrives attached to my Spectrum - these were basically an endless tape loop, and you could load a typical game in just a few seconds. 👍
Reminds me of LapLink, and other early PC peripherals that worked with printer ports that were not bidirectional. It probably used the same trick; at least one bit _does_ go the other way, for handshaking.
C316/R310 create a low pass filter with a 3dB point of 10KHz. So a 50us pulse will be half of the full amplitude at a lower frequency. The second opamp with the 47K feedback resistor is an inverter with hysteresis, and if the signal level is less than some amount I can't determine (because I don't know the voltage on the bias divider), then no signal will pass through. This is a form of a noise gate.
You could measure the output of the first and second opamps as you vary the frequency of a pulse train to determine the max allowed frequency.
The time gaps in the Arduino pulse train are likely the time it takes to read a sector or block from the memory card. Often this sort of code is written in an interrupt handler that, when it handles a "sector ready" (or similar) interrupt, simply reads in a loop to get the 512 (or whatever) bytes of data out of the device. During that time it is running with interrupts disabled, so things like timer interrupts get delayed. You will probably find those gaps are a consistent time, and, unless you can make the loader code handle pauses in the bit stream, that will tell you the minimum pulse width you can handle reliably.
I understood about 5% of what you were saying but it certainly is entertaining new subscriber from me
When the arduino loader reached its limit, my first thought was to generate a wave file played back from a phone or directly from the PC?
If sound card supports 192kS/s sample rate, minimal pulse duration will be 5.2uS. It should be enough for such task. With 48kS/s duration is 20.8uS, which may be slower than needed.
Note, however, even with f you recorded a WAV file and played that back you still wouldn't be able to load any faster via the cassette port -- the issues with the amp / noise reduction / other analog components that sit between the audio jack and the analog to digital converter would still distort the signal.
It would improve matters when using the printer port busy pin, of course, but at that point you aren't really loading an audio file -- you are just loading digital data in an odd way.
@@jmr5125 I may be wrong (do not own such device), but it looks like audio is abstraction in this case. It is not needed to make system work. Decoded inputs are electrical signals (which are made either from tape or with DAC), which can go one way or another to CPU.
@@sdjhgfkshfswdfhskljh3360 True, but that's missing the point.
The original stated goal of the video was "Given ideal conditions, how fast can data be loaded *from cassette*?" In my opinion the answer to this question must involve the cassette port.
A different, somewhat related, question is "How fast can data be loaded * without extensive mods*?". In this case, using the parallel port busy line is a clever way to overcome the limitations of the cassette interface. However, I suspect that there are even faster says (that still don't require extensive mods) -- at a minimum, using the joystick port will provide at least 5 digital input pins, allowing (in theory) for 5 bits to be transferred in the same time as one but with the current solution. In practice, I suspect that the optimal solution would be 4 data bits + a sync bit, as that's almost certainly enough to max out the processor.
If you *really* want to make it fast, DMA is the way to go. What, the computer doesn't support that? Well, just create a custom board that connects to the current RAM sockets that emulates the current RAM interface, but if certain bytes are written to certain memory locations in a certain order within a certain time it triggers a "DMA load"... Of course, that would be absurd, right? :)
My objection to the video isn't "He's cheating" but "If he is going to cheat, go all the way!" :)
@@jmr5125 : I've been playing around with schematics for the custom hardware option- if using ideal hardware (which means some _really good audiophile_ tape decks) then you should be able to get better than 33kbps, since 33k was the idealized max for the phone network... which had _less_ bandwidth than audio cassettes. Some estimates online suggest that a high-performance system should be able to fit ~0.7 to 0.9 megabytes per minute of tape with the high-end 22kHz tape machines, which would certainly make for an interesting rogue-like or rpg, or any number of other things. You could fit a decent pure-text dictionary or encyclopedia on tape, for example.
However, part of this also involves error correction, and you also need to sacrifice some speed to allow for sync to correct for tape jitter. It's interesting to poke at.