TonB

The loader I'm talking about can only load spectrum bitmaps from tape. They're like a separate tape format. I'm pretty sure my program presents a menu with options to load/save from tape/disk. I remember mailing this to Ray Kazmer when I first finished it.

Ha! I remember writing this code. It is al based on the basicode standard, an attempt of a group of people to create a cross-platform basic. With it came a digital format to stream programs from/to tape, and I figured out how to read/write (actually, I created the reader while a friend of mine, also called Ton, created the initial version of the writer). Then I started modifying the timings to create turbo loaders/savers, utilities to stream program files to tape, and this full disk backup program. I remember also reverse engineering the ZX-Spectrum tape protocol, so ZX-Spectrum bitmaps pictures (which could be saved separately) could be loaded on TI. One key improvement was that I use the leader tone to calibrate the algorithm, so timing constants could be removed and the program would work when I increased the tape pitch (had a player with a speed wheel). I also built in a second crystal with a switch in my console to clock it to 3MHz. The VDP got confused by this speed at times, but the tape loader actually worked better. So you could set the computer to turbo, and crank up the speed of the tape... Funny enough, this was like 30 years ago, and today I'm working on reverse engineering a variant of SPDIF. Same box of tricks, only kHz have become MHz...

The way I remember it the cassette on/off switch is just another CRU register. Why not disconnect the motor control and start/stop the tape manually when the routine starts listening? I remember I had a cassette player that even didn't allow motor control... The turboloader I wrote was derived from the basicode protocol. I think I increased the frequencies to the max that was achievable with somewhat reliable readback. I may have thrown out one of the two stop bits for an extra couple of percent... not sure.

The way I implemented the loader back in the days, is to sample the frequencies during the lead-in tone of the playback. Then you can calibrate the speed of the CPU against the speed of the tape. With this mechanism you can speed up the tape if you want, and if your CPU can keep up, load even faster. You can then implement a loader without any magic constants, since they're all calculated on the fly.

I remember! What I did there was simply switch the 9938 to 80 col mode in the interrupt (in an unused piece of RAM) and copy the contents of the 32-col screen into the 80 col screen. So you don't really have 80 columns to type in. But the effect was cool. (Geez why do I remember this).

Guys, I remember writing this! Stumbled upon this forum by accident. What do you want to know... When I first started experimenting with the CRU inputs to read "the beeps from the cassette tape", I figured the format for basicode out at some point. It's pretty straightforward, with two frequencies, startbit, stopbit etc. I then applied the very same knowledge to create AFSK telex decoder, ZX-Spectrum loader, and turbo loader for the 4A. The latter was just the basicode format with less delay. My friend Ton Damen (yeah, same first name) at the same time figured out the opposite direction, ie., writing to tape. What you're looking at is some highly optimized subroutine to write one bit. R8 contains the statement SBO or SBZ (set bit to one or to zero) and I use the XOR trick to convert one command into the other on the fly. The JMP statement was actually the NOP instruction. Since there doesn't seem to be any external timing, you will find that this code will generate a higher pitch on systems running at higher speed (I remember I had two crystals in my computer...). Anyway, nice memory lane this is. Damn this is long ago!!

Hi there! Bumped into my own name while googling, so thought I'd join the discussion. Wow, you're talking about stuff that happened 25 years ago! I vaguely remember creating something like this. The way it worked (if I remember correctly) is that you could relocate a basic program in memory to create a bit of "no-mans-land" in the high memory area. You can hide the assembly program there, and it will be saved to tape along with the basic program. Then all you need is a bit of code that relocates that binary to the start location (usually 0xa000?) and you're good to go. So cool to read that people are still active with this!!