SCELBI Tape Interface Mic Connection

[AgentOrange96]

Okay, so I fed this data in ChatGPT and it was really helpful! I had been using it to help me develop my scripts. It's done a lot of heavy lifting, but definitely not all of it. It also tried to gaslight me later on.
Anyway, in summary, this is what seems to be the case.

Firstly, everything is processed in nibbles, not bits. However, two nibbles will be paired into bytes. But they will be processed independently. (usually?) This is why we see in my longer example that there's what appear to be the right nibbles, but split up between different bytes.

Secondly, we have control codes.
0000 0001 is the start of a transmission. I'm not sure why SCELBAL is 0100 0001, but it seems maybe only the second nibble matters?
1000 1000 says the next byte will be your high address
0100 0100 says the next byte will be your low address
0000 0001 also seems to appear after the high nibble is specified

For each nibble of data, a 0001 nibble is sent right after.
0000 1111 means increment the address. Why this only happens sometimes I'm not sure

After data is sent, we get some ending bytes. Allegedly these aren't needed (according to ChatGPT) but I suspect they are and I don't know what they mean.

Here are the first two examples annotated by nibble:

0000 - Padding
0001 - Start of transmission
1000 - Next byte is high address
1000 - Next byte is high address
0001 - High nibble of high address
0001 - Low nibble of high address
0000 - ???
0001 - ???
0100 - Next byte is low address
0100 - Next byte is low address
0000 - High nibble of low address
0000 - Low nibble of low address
1111 - High nibble of 377
0001 - Last nibble is data
1111 - Low nibble of 377
0001 - Last nibble is data
1111 - High nibble of 376
0001 - Last nibble is data
0111 - Low nibble of 376
0001 - Last nibble is data
0000 - Incriment address
1111 - High nibble of 375
0001 - Last nibble is data
0000 - Incriment address
1011 - Low nibble of 375
0001 - Last nibble is data
0000 - Increment address
1111 - High nibble of 374
0001 - Last nibble is data
0000 - Incriment address
0011 - Low nibble of 374
0001 - Last nibble is data
1111 - High nibble of 373
0001 - Last nibble is data
1101 - Low nibble of 373
0001 - Last nibble is data
0000 - Incriment address
1111 - High nibble of 372
0001 - Last nibble is data
0000 - Incriment address
0101 - Low nibble of 372
0001 - Last nibble is data
1111 - High nibble of 371
0001 - Last nibble is data
1001 - Low nibble of 371
0001 - Last nibble was data
1111 - High nibble of 370
0001 - Last nibble was data
0001 - Low nibble of 370
0001 - Last nibble was data
0000 - Incriment address
1111 - High nibble of 371 - Maybe I did an extra address?
0001 - Last nibble was data
1001 - Low nibble of 371 - Maybe I did an extra address?
0001 - Last nibble was data
0001 - ???
0000 - End of transmission
0000 - End of transmission

0000 0001 Start of transmission
1000 1000 Next byte is high address
0000 0000 High address
0000 0001
0100 0100 Next byte is low address
0000 0000 Low address
1010 0001 High byte of 125
1010 0001 Low  byte of 125
1010 0001
0010 0011
0000 1000

Okay, so speaking of that second example, I have gotten the script such that it'll re-create that second one exactly. We're talking data is identical, waveforms look right. The only difference I see is timing between bytes isn't always the same. Yet the original reads fine and the synthesized one fails. I don't know what would possible be meaningfully different.

The original SCELBI generated one is attached to this comment: https://forum.vcfed.org/index.php?threads/scelbi-tape-interface-mic-connection.1254680/post-1479768
The one I generated is attached here. When attempting to load, I do include a 3s lead in of 0's and a 1s lead out of 0's. I'm omitting them here for ease of analysis.

I'll make sure my script is up to date on my github.

I will say once this is all figured out I want to make sure it's well documented how this all works. The best documentation I can find on this is flat out wrong.

 

[AgentOrange96]

SUCCESS! At least for the single byte.
Two factors: 1, I did actually have a mistake in my closing bytes. Fixed.
The second is timing between symbols. I perfectly emulated the file's timing and now it loads in!
Will those timings apply to other files? Who knows?
Newest .wav attached along with non-truncated version I actually used.

EDIT: Trying the SCELBAL .hex file, it fails pretty early on. So definitely some more stuff to figure out.
EDIT: Even just changing the byte I'm writing in the single-byte file breaks it. So there's gotta be some checksum or something going on in the trailing code.

 

[AgentOrange96]

Per the July 1975 newsletter, also reproduced in the tape documentation on scelbi.com, it indeed says something about a checksum and word count. It also explains such a checksum before this. But I'll have to take a look in the morning.