Yes, of course, the purpose of the skip64 loop is to ignore garbage during motor startup, but this is done by reading and ignoring 64 bytes of data, not a delay loop, hence the label name.
Cool! Re recreating the cassette format on a modern computer: I had a look at it, and it seems like general opinion is that the audio playback application has to use WASAPI or ASIO in order for Windows to not do some internal sample rate conversion or whatnot. I don't think that the problem you saw was due to some filtering to make the audio sound in a particular way, but rather the result of the DAC constantly running at a fixed frequency and all audio ending up to be sample rate converted to fit that fixed frequency, with no exceptions for audio that runs at the same frequency as the DAC or where the DAC frequency is an even multiple of the audio data sample rate. It seems like there are plugins both for WASAPI or ASIO for FooBar2000, which IMHO is the best audio player for Windows. Btw maybe I missed something, but are there any code that checksums the second stage loader itself? I assume that most read errors of it would result in something that don't work at all, but in theory there could be some load error that causes weird errors further on. Highly unlikely, but still. Are there any archived tapes available for this tape format att all?
Mike, the worst thing you can do to a frequency shift keyed signal is run it through a psychoaccoustic model, between the initial aggressive bandpass filtering that occurs at the front-end, to the discrete cosine transformation that occurs on the back-end of the MPEG audio CODEC, you'll wind up with something really gnarly at the end.
That trick of assembling program twice with different org address, to find out where relocations needs to be done is really clever and simple. As of whetever one would a bitmap, or list of offsets is another thing (this is how modern relocations in dynamic linkers work). Depends on a number of relocations, and size of the final program. But I am sure there is more than 256 relocations, so 1 byte offsets would not be enough. I am sure it was done here with a bitmap, because it is pretty simple, and in the end quite effective and efficient here.
It is oddly satisfying to see those old S100 computers to be useful for anything. And the fact 8080 was the only CPU "produced" in Poland during the first microcomputer revolution, just before the dusk of ancient regime, warms my hart even more. "Produced" most probably from Soviet or East Germany "recreated" masks.
For sending audio to tape, perhaps you can use a "Covox" module if you can somehow drive a parallel port. It's just a DAC made out of a 20K resistor ladder, attached to the data output pins of the parallel port.
The old trick I'd use for 6502 page-level relocation, would be to assemble the resulting code twice, 0100H apart, and store the difference of any 3 byte instruction into a table, which could then be quickly fixed up.
At least one of the 6502 "variants" (possibly the 6809) had PCR data loading instructions (Program Counter Relative). Added to relative jumps and calls, it was possible to make a machine code program completely relocatable so it could reside anywhere in memory without modification. You only needed to assemble the program with an ORiGin of zero. I did that with one program for the TRS-80 CoCo, which was a program designed to sit "behind" BASIC and take USR calls to print text onto the high-res graphics screen; something which was not supported by the hardware.
@@melkiorwiseman5234 The 6502 and 6809 are very different CPUs from a common ancestor, and yes, the 6809 did have PCR addressing. The 6502 didn't, and you really had to do your own acrobatics to relocate things around.
@@tschak909 Ah, well, I'm not certain what had what, since I was mainly a Z80 guy, but I certainly did like the PCR data handling instructions and wish the Z80 folks had thought to add them.
I'm currently making a modem for my Altair replica, I haven't tried CUTS format yet but from what I read it's manchester encoding and it sounds simpler to decode than the frequency shift since there is a comparator interrupt on my microcontroller
I got to 8:08 and paused, wondering how to use bits in the relocation table to calculate what byte to add to in order to set it to the proper address, and then I realised that all you need is a shift command and then jump on no carry to skip the relocation code if the bit was zero. Sometimes, the solution is too obvious and it takes ages to figure it out for that reason. 😄
A slight correction to the disassembly comment is that the code you call “skip 64 bytes “ is actually a “wait for motor to come too speed” loop.
Yes, of course, the purpose of the skip64 loop is to ignore garbage during motor startup, but this is done by reading and ignoring 64 bytes of data, not a delay loop, hence the label name.
Very impressive! It’s really great to see this type of preservation work. Thanks for sharing
Very nice recreation effort here. Great forensics as far as reverse engineering the loader and tape format :)
Cool!
Re recreating the cassette format on a modern computer:
I had a look at it, and it seems like general opinion is that the audio playback application has to use WASAPI or ASIO in order for Windows to not do some internal sample rate conversion or whatnot.
I don't think that the problem you saw was due to some filtering to make the audio sound in a particular way, but rather the result of the DAC constantly running at a fixed frequency and all audio ending up to be sample rate converted to fit that fixed frequency, with no exceptions for audio that runs at the same frequency as the DAC or where the DAC frequency is an even multiple of the audio data sample rate.
It seems like there are plugins both for WASAPI or ASIO for FooBar2000, which IMHO is the best audio player for Windows.
Btw maybe I missed something, but are there any code that checksums the second stage loader itself? I assume that most read errors of it would result in something that don't work at all, but in theory there could be some load error that causes weird errors further on. Highly unlikely, but still.
Are there any archived tapes available for this tape format att all?
Mike, the worst thing you can do to a frequency shift keyed signal is run it through a psychoaccoustic model, between the initial aggressive bandpass filtering that occurs at the front-end, to the discrete cosine transformation that occurs on the back-end of the MPEG audio CODEC, you'll wind up with something really gnarly at the end.
That trick of assembling program twice with different org address, to find out where relocations needs to be done is really clever and simple.
As of whetever one would a bitmap, or list of offsets is another thing (this is how modern relocations in dynamic linkers work). Depends on a number of relocations, and size of the final program. But I am sure there is more than 256 relocations, so 1 byte offsets would not be enough. I am sure it was done here with a bitmap, because it is pretty simple, and in the end quite effective and efficient here.
It is oddly satisfying to see those old S100 computers to be useful for anything. And the fact 8080 was the only CPU "produced" in Poland during the first microcomputer revolution, just before the dusk of ancient regime, warms my hart even more. "Produced" most probably from Soviet or East Germany "recreated" masks.
For sending audio to tape, perhaps you can use a "Covox" module if you can somehow drive a parallel port. It's just a DAC made out of a 20K resistor ladder, attached to the data output pins of the parallel port.
The old trick I'd use for 6502 page-level relocation, would be to assemble the resulting code twice, 0100H apart, and store the difference of any 3 byte instruction into a table, which could then be quickly fixed up.
At least one of the 6502 "variants" (possibly the 6809) had PCR data loading instructions (Program Counter Relative). Added to relative jumps and calls, it was possible to make a machine code program completely relocatable so it could reside anywhere in memory without modification. You only needed to assemble the program with an ORiGin of zero.
I did that with one program for the TRS-80 CoCo, which was a program designed to sit "behind" BASIC and take USR calls to print text onto the high-res graphics screen; something which was not supported by the hardware.
@@melkiorwiseman5234 The 6502 and 6809 are very different CPUs from a common ancestor, and yes, the 6809 did have PCR addressing. The 6502 didn't, and you really had to do your own acrobatics to relocate things around.
@@tschak909 Ah, well, I'm not certain what had what, since I was mainly a Z80 guy, but I certainly did like the PCR data handling instructions and wish the Z80 folks had thought to add them.
@@tschak909yeah, the 6502 was targeting the intel 4004. The z80 targeted the intel 8080. The 6809 was targeting itself.
I'm currently making a modem for my Altair replica, I haven't tried CUTS format yet but from what I read it's manchester encoding and it sounds simpler to decode than the frequency shift since there is a comparator interrupt on my microcontroller
I got to 8:08 and paused, wondering how to use bits in the relocation table to calculate what byte to add to in order to set it to the proper address, and then I realised that all you need is a shift command and then jump on no carry to skip the relocation code if the bit was zero. Sometimes, the solution is too obvious and it takes ages to figure it out for that reason. 😄
Man, I am SO SAD your Altair 8800 clones aren’t available anymore! 😞😞
Cool video, thanks!
Are we actually supposed to be able to read this?