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 😃
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!
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.
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.
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!
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.
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.
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.
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.
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!
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.
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!
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!
3 ปีที่แล้ว +4
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 :)
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.
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!
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.
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
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.
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.
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.
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 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.
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.
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.
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 :-)))
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.
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...
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.
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
Nice video again But, if you resort to a purely digital input (the busy bin) It makes no sense to keep the same data format as in the tape. That FSK-like coding was used to remove the DC component of the data because audio equipment will block any DC component, but it will double the bandwidth of the signal with respect to a plain NRZ. It would be simpler and way faster to use a serial data format: start bit + data + stop bit (This only increases the bandwidth by 10/8). I'll guest 30Kbaud can be achievable, and the UART in the Arduino can also help a lot to avoid unintended pauses. (I managed to read a 115200 baud serial data using bitbanging in a 4MHz PIC10F200. The Z80 is slower, but not an order of magnitude) Best regards
Some time ago I discussed another way of speeding up the tape loading: just use only half of the wave, thus duplicating the speed without increasing the bandwidth; this is: converting it into a non-return-to-zero protocol. It has only the inconvenient of inserting DC level, but it should be removed by the capacitor in the tape input (and also, in average, it should also be cancelled).
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
You could use an ESP32 with it's two cores and higher speed to help out with these issues. You could have one core read the SD card and the other core generate the signal.
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.
From a signal theory perspective, a mono tape is good for something in the ballpark of ~250kbps with ideal encoding (Shannon limit, assuming a reasonable 15kHz of bandwidth and 50dB of signal to noise margin). FSK is far from ideal in this respect, but has the advantage of very simple encoding/decoding. I suspect you could achieve at least 1/10 the theoretical maximum if you used an external peripheral to do the tape decoding using a more advanced coding scheme like one of the low order (4/8/16) QAM modes with error correction then fed that to the CPU (since the CPU is unlikely to be fast enough to handle the decoding and won't have a good way to interpret a more complex encoding that takes advantage of the analog nature of the channel). Obviously not generally practical, but since you're already in the realm of theoretical limits it might be interesting to explore!
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.
I assume you're just using a generic ol' SD card? If so, try using a faster one. I'd recommend a small size SanDisk Ultra, because they're cheap, but any card with the "A1" symbol will have low access latency. (I.e. delay between issuing a read command and the card responding with the data). IME that's the main performance difference between cards when used on a microcontroller.
I don't think it's latency problem. The arduino only has 2kb of RAM, some of that goes to variables, some can be used for data buffer, so you don't need to access the SD card as often. MCU is running out of steam at those higher speeds because it doesn't have any DMA, so juggling data around has to be done by the processor itself. The code probably might be improved to speed the proces up.
I'd be seriously tempted to re-jig a TZXDuino with a Pi Pico instead of the Arduino Nano. It could pre-load the tape image into RAM and spit it out as fast as you like. Probably a little bit cheaper than using even a Chinese clone of the Nano, too.
If you want a challenge, how about you create your own input device and read all 8 heads on an 8 track real to real? Reading a byte at a time should be pretty fast. :-)
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. 👍
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 ;)
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.
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.
The TRS-80 tapes used a system which, as I understand it, was also used in early disk drives. A clock pulse would be recorded then either a second clock pulse for a one or a period of silence for a zero. Reading consisted of waiting for the first clock pulse and then waiting a specific amount of time before checking to see if there was a second pulse or not. Early TRS-80's had a fault in the timing programmed into the firmware which meant that the reading could be unreliable, especially with a less-than-perfect tape. This was fixed later, but not before the machines had earned their nickname of "trash-eighties."
There was a kit-built computer known as the "Dick Smith Super-80" which used cassettes recorded and loaded at 300bps, but by changing two memory locations you could double that to 600bps or quadruple it to 1200bps, at the cost of requiring better tape quality for the highest speed. Speeding it up further was not possible since it used 1200/2400Hz Frequency Shift Keying and it's not possible to either save or load any faster than half the upper frequency. It might have been interesting to try changing the FSK frequencies to 2400/4800 but that would have required re-tuning the Phase Locked Loop used to detect the upper frequency and would have made it incompatible with the default speed.
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.
I was expecting a c-cassette doing mach 1 :/ Fun fact: timers always run over the allocated time in a non real-time system that has a scheduler, because it's about sleeping the thread and asking the scheduler to wake it up after the allocated time. The precision depends on many things, but can be quite rough.
Right. I dug out somewhere from the docs that the callback has a 2.5us overhead, which matches up nicely with the measurements we got. Precision isn't super important yet, so that's fine (or we can take it into account if it is). The thing that baffles me is that it's chocking beyond a certain point with the SD read interaction (which, as far as I know, should be completely in parallel). Anyway, I'm hoping to be able to write something much simpler and faster.
I honestly think future digital archeologists will be thankful for these conversion of material that would simply be gone in a couple of more decades. 👍🏻
4:36 - Wow! That's one second faster than Animal Crossing: New Horizons! (Not over-exaggerating, literally timed New Horizons to be 60 seconds while spamming the A button to get past the menus and forgetting the announcements.)
Codemasters produced a CD which loaded games extremely quickly. The CD came with a cable that plugged into 3.5mm headphone socket of the CD player one end and the Joystick port of the computer at the other end. I wonder if trying to load via the joystick port would be feasible in this case.
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!
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.
![[Re:all TREASURE] EP.6 in 방콕ㅣ🚩 쩡캠의 방콕 투어 빵 마이 와이 👍](http://i.ytimg.com/vi/uyFw-nItA_s/mqdefault.jpg)
(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.
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.
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!
Congrats on Ep 100 man!! Well done!
Thank you!! It was a fun milestone! 😃
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 !
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
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.
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.
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.
Wow, very cool. I love the idea of using the 'parallel' port as a sort of serial port :)
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 😃
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!
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
Wow! 100! Congrats to you. You're still in my Top 2.
Whoo-hoo! 😃👍
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.
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.
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!
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!
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! 👍
I love channels like this . Stuff that interested you as a kid, becomes even more interesting as an adult
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.
Congratulations Noel! All the best to your brilliant channel!!
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!
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!
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.
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
This will be nice to see an update in the near future. Good work 👏
No idea why YT recommended this but i'm glad it did, super interesting!
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! 👍
A very cool video - from a true SME! Very interesting and informative!
Wow! With each of your videos I'm thinking 'It can't get any better', but then you proof me wrong again!
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 some ingenious and creative engineering. Brilliant stuff!
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.
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 see you've finally crossed over the line from pure hardware to tinkering with software :)
That was amazing. It really makes me want to look at older equipment and see what sort of fun things can be done.
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.
Congrats on the 100 anniversary! This video was really interesting! Thanks!
fascinating stuff there. Love it.
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.
i had no idea that's how the tapes loaded, fascinating!! thank you so much : )
Glad you enjoyed!
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.
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.
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 :-)))
Great job Noel.
Wow, this answered some questions that were buried in the back of my mind for ages. Subscribed!
Your channel and Adrian's are my favorite retro tech channels.
Wow, thanks! Adrian's is also one of my favorites! 👍😃
Brought back memories. I modded a model one TRS-80 to 4 times cassette speed and double clock speed. Those were the days. :)
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
Congrats on episode 100!!
Congratulations on the 100th episode, I wish you a lot of success on this channel. Nice new intro. Greetings!
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 😂
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.
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...
I have no idea what he’s talking about, but I was on the edge of my seat
Happy 100th, very informative and a candidate for a hackaday entry.
Thank you so much!
A lot of impressive technical deep dive in this one Noel, really enjoyed the watch! Thank you :)
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.
Happy 100th video posted anniversary! As usual, very nice and pleasant to listen to)
Excellent video. A very interesting topic, well researched, and clearly presented. Well done. Looking forward to the follow up.
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
Wow...that Amstrad CPC is flawless.
Nice video again
But, if you resort to a purely digital input (the busy bin) It makes no sense to keep the same data format as in the tape. That FSK-like coding was used to remove the DC component of the data because audio equipment will block any DC component, but it will double the bandwidth of the signal with respect to a plain NRZ. It would be simpler and way faster to use a serial data format: start bit + data + stop bit (This only increases the bandwidth by 10/8). I'll guest 30Kbaud can be achievable, and the UART in the Arduino can also help a lot to avoid unintended pauses. (I managed to read a 115200 baud serial data using bitbanging in a 4MHz PIC10F200. The Z80 is slower, but not an order of magnitude)
Best regards
Your SD card is made in TAIWAN!!! I am from TAIWAN!!! :)
I used a RSX command from a computer mag listing to speed load some Cassettes , back in the 1980s
Some time ago I discussed another way of speeding up the tape loading: just use only half of the wave, thus duplicating the speed without increasing the bandwidth; this is: converting it into a non-return-to-zero protocol. It has only the inconvenient of inserting DC level, but it should be removed by the capacitor in the tape input (and also, in average, it should also be cancelled).
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
You could use an ESP32 with it's two cores and higher speed to help out with these issues. You could have one core read the SD card and the other core generate the signal.
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.
grats on the 100th, you deserve it bud
From a signal theory perspective, a mono tape is good for something in the ballpark of ~250kbps with ideal encoding (Shannon limit, assuming a reasonable 15kHz of bandwidth and 50dB of signal to noise margin). FSK is far from ideal in this respect, but has the advantage of very simple encoding/decoding.
I suspect you could achieve at least 1/10 the theoretical maximum if you used an external peripheral to do the tape decoding using a more advanced coding scheme like one of the low order (4/8/16) QAM modes with error correction then fed that to the CPU (since the CPU is unlikely to be fast enough to handle the decoding and won't have a good way to interpret a more complex encoding that takes advantage of the analog nature of the channel). Obviously not generally practical, but since you're already in the realm of theoretical limits it might be interesting to explore!
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.
I assume you're just using a generic ol' SD card? If so, try using a faster one. I'd recommend a small size SanDisk Ultra, because they're cheap, but any card with the "A1" symbol will have low access latency. (I.e. delay between issuing a read command and the card responding with the data). IME that's the main performance difference between cards when used on a microcontroller.
I don't think it's latency problem. The arduino only has 2kb of RAM, some of that goes to variables, some can be used for data buffer, so you don't need to access the SD card as often. MCU is running out of steam at those higher speeds because it doesn't have any DMA, so juggling data around has to be done by the processor itself. The code probably might be improved to speed the proces up.
I'd be seriously tempted to re-jig a TZXDuino with a Pi Pico instead of the Arduino Nano. It could pre-load the tape image into RAM and spit it out as fast as you like.
Probably a little bit cheaper than using even a Chinese clone of the Nano, too.
If you want a challenge, how about you create your own input device and read all 8 heads on an 8 track real to real? Reading a byte at a time should be pretty fast. :-)
Wow that's some in depth research and testing.
Congratulations for your 100# episode. Thank you for inspiring us. I wish you much success. God bless you.
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. 👍
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 ;)
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!
Mother of God.... *runs to find his old Amstrad* 10/10 video! o7
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.
Very interesting! I learned a lot about tape loading, thanks!
And happy 100th ;o)
Glad you enjoyed it! Thank you!
When I was a kid I used to wonder how these 'magic' Amstrad fast tape loads work. 33 years later I finally have some clue!
The TRS-80 tapes used a system which, as I understand it, was also used in early disk drives. A clock pulse would be recorded then either a second clock pulse for a one or a period of silence for a zero. Reading consisted of waiting for the first clock pulse and then waiting a specific amount of time before checking to see if there was a second pulse or not.
Early TRS-80's had a fault in the timing programmed into the firmware which meant that the reading could be unreliable, especially with a less-than-perfect tape. This was fixed later, but not before the machines had earned their nickname of "trash-eighties."
There was a kit-built computer known as the "Dick Smith Super-80" which used cassettes recorded and loaded at 300bps, but by changing two memory locations you could double that to 600bps or quadruple it to 1200bps, at the cost of requiring better tape quality for the highest speed. Speeding it up further was not possible since it used 1200/2400Hz Frequency Shift Keying and it's not possible to either save or load any faster than half the upper frequency.
It might have been interesting to try changing the FSK frequencies to 2400/4800 but that would have required re-tuning the Phase Locked Loop used to detect the upper frequency and would have made it incompatible with the default speed.
That seems a lot more reliable, but perhaps slower. I like it better though.
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.
I was expecting a c-cassette doing mach 1 :/
Fun fact: timers always run over the allocated time in a non real-time system that has a scheduler, because it's about sleeping the thread and asking the scheduler to wake it up after the allocated time. The precision depends on many things, but can be quite rough.
Right. I dug out somewhere from the docs that the callback has a 2.5us overhead, which matches up nicely with the measurements we got. Precision isn't super important yet, so that's fine (or we can take it into account if it is). The thing that baffles me is that it's chocking beyond a certain point with the SD read interaction (which, as far as I know, should be completely in parallel). Anyway, I'm hoping to be able to write something much simpler and faster.
I honestly think future digital archeologists will be thankful for these conversion of material that would simply be gone in a couple of more decades. 👍🏻
4:36 - Wow! That's one second faster than Animal Crossing: New Horizons! (Not over-exaggerating, literally timed New Horizons to be 60 seconds while spamming the A button to get past the menus and forgetting the announcements.)
I understood about 5% of what you were saying but it certainly is entertaining new subscriber from me
Very good! I'm about to do some similar tests on a MSX !
This was an amazing watch!
Codemasters produced a CD which loaded games extremely quickly. The CD came with a cable that plugged into 3.5mm headphone socket of the CD player one end and the Joystick port of the computer at the other end. I wonder if trying to load via the joystick port would be feasible in this case.
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!
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.