| VCF Montreal | Jan 24 - 25, 2026, | RMC Saint Jean, Montreal, Canada |
| VCF SoCal | Feb 14 - 15, 2026, | Hotel Fera, Orange CA |
| VCF East | Apr 17 - 19, 2026, | InfoAge, Wall, NJ |
| VCF Pac. NW | May 02 - 03, 2026, | Tukwila, WA |
| VCF Southwest | May 29 - 31, 2026, | Westin Dallas Fort Worth Airport |
| VCF Southeast | June, 2026, | Atlanta, GA |
| VCF West | Aug 01 - 02, 2026, | Mountain View, CA |
| VCF Midwest | Sep 12 - 13, 2026, | Schaumburg Convention Center, IL |
-
Please review our updated Terms and Rules here
SCELBI Tape Interface Mic Connection
- Thread starter kalinchuk
- Start date
daver2
10k Member
Thanks.
There is another possibility.
The SCELBI and terminal may be truly grounded. The laptop supply may be double insulated (the power supply may have a square within a square printed on it).
On our video system at Church, we had a load of double insulated power supplies feeding video converters.
Interestingly, I measured 20 to 40 V AC between the 'ground' of the video cables that were fed from the double insulated supplies and the 'real ground' of the video equipment that was really connected to ground.
This was causing us problems. There is very little current flow, but it is enough to confuse things. We sorted it in the end.
The other possibility is that the 'ground' of the SCELBI or terminal is actually connected to mains neutral. That will also mess things up.
Lots of possibilities when you mix old and new equipment.
I used to repair televisions in my youth. You would come across TV chassis that were actually connected to mains live that would give you a potentially lethal zap if you were not careful!
Connecting an earthed oscilloscope clip to the chassis would either blow the fuse, trip the earth leakage breaker, or melt the oscilloscope earth clip!
Dave
There is another possibility.
The SCELBI and terminal may be truly grounded. The laptop supply may be double insulated (the power supply may have a square within a square printed on it).
On our video system at Church, we had a load of double insulated power supplies feeding video converters.
Interestingly, I measured 20 to 40 V AC between the 'ground' of the video cables that were fed from the double insulated supplies and the 'real ground' of the video equipment that was really connected to ground.
This was causing us problems. There is very little current flow, but it is enough to confuse things. We sorted it in the end.
The other possibility is that the 'ground' of the SCELBI or terminal is actually connected to mains neutral. That will also mess things up.
Lots of possibilities when you mix old and new equipment.
I used to repair televisions in my youth. You would come across TV chassis that were actually connected to mains live that would give you a potentially lethal zap if you were not careful!
Connecting an earthed oscilloscope clip to the chassis would either blow the fuse, trip the earth leakage breaker, or melt the oscilloscope earth clip!
Dave
jlang
Veteran Member
Ground and neutral are not the same. The ground is a safety connection and goes to the ground in the breaker box.
Neutral connects to the neutral bar in the breaker box. It is the return path for the current from the line (hot wire).
The neutral wire has resistance the neutral current will produce a voltage across the neutral wire.
Neutral and ground are bonded together at the breaker box. Any where else they are not the same and should not be connected together.
Neutral connects to the neutral bar in the breaker box. It is the return path for the current from the line (hot wire).
The neutral wire has resistance the neutral current will produce a voltage across the neutral wire.
Neutral and ground are bonded together at the breaker box. Any where else they are not the same and should not be connected together.
If those outlets aren't beside each other then maybe try running all three devices from the same power strip? That way they at least share the same ground.
Also you could for testing purposes use a serial port on the laptop rather than the actual terminal.
An ugly hack is to put two higher-current diodes in "anti-parallel", I.E. in parallel but in opposite directions, and connect that in series with the ground between the terminal and the computer. That will allow the serial ground to float about 0.6-1V which would still make the signals to be within spec, while the diodes does at least an attempt at protecting from mishaps where the ground would be needed for larger currents (say mains ground gets disconnected from one of the two devices and there is a fault that makes mains power flow through the signal ground, then the diodes at least put some effort in protecting you from mains voltage difference on the serial signals). (Smaller boats uses this setup for shore power, except the diodes are in a large pack of sorts, and in this case it's not to remove mains hum but rather to avoid corrosion due to voltage differences between the water and the mains ground).
Another option would be to use transformers in series with the audio signals. Transformers intended to give good audio quality tend to cost a bit, but still.
Somewhat related tangent: I salvaged the transformers from a bunch of old modem PCBs, from the days when the transformers were able to handle the DC current from the phone line (which I think is handled by some separate circuit in "modern" modems) and thus were fairly large. I had good results using them as isolation transformers for audio, like connecting them between various more or less questionable sources like computers at computer nerd meetups to PA systems or whatnot. Sure, there were some difference with and without these transformers but you kind of needed a higher quality hifi system to really notice the difference.
Also you could for testing purposes use a serial port on the laptop rather than the actual terminal.
An ugly hack is to put two higher-current diodes in "anti-parallel", I.E. in parallel but in opposite directions, and connect that in series with the ground between the terminal and the computer. That will allow the serial ground to float about 0.6-1V which would still make the signals to be within spec, while the diodes does at least an attempt at protecting from mishaps where the ground would be needed for larger currents (say mains ground gets disconnected from one of the two devices and there is a fault that makes mains power flow through the signal ground, then the diodes at least put some effort in protecting you from mains voltage difference on the serial signals). (Smaller boats uses this setup for shore power, except the diodes are in a large pack of sorts, and in this case it's not to remove mains hum but rather to avoid corrosion due to voltage differences between the water and the mains ground).
Another option would be to use transformers in series with the audio signals. Transformers intended to give good audio quality tend to cost a bit, but still.
Somewhat related tangent: I salvaged the transformers from a bunch of old modem PCBs, from the days when the transformers were able to handle the DC current from the phone line (which I think is handled by some separate circuit in "modern" modems) and thus were fairly large. I had good results using them as isolation transformers for audio, like connecting them between various more or less questionable sources like computers at computer nerd meetups to PA systems or whatnot. Sure, there were some difference with and without these transformers but you kind of needed a higher quality hifi system to really notice the difference.
daver2
10k Member
>>> I was under the impression that ground was already connected to neutral in the breaker box. Why would doing it inside the SCELBI make a difference?
@jlang has answered this.
If you have a residual current breaker for the circuit back in the distribution box - usually connecting neutral to earth (at a remote socket) will trip it. The device works by detecting an imbalance in the current flow between the live and neutral conductors of the circuit. This implies that some current is flowing from the remote neutral connection to earth. If there is a current flow, there must be a voltage difference to drive the current.
Depending upon where this connection is made, could cause the earth loop and hence the hum.
Dave
@jlang has answered this.
If you have a residual current breaker for the circuit back in the distribution box - usually connecting neutral to earth (at a remote socket) will trip it. The device works by detecting an imbalance in the current flow between the live and neutral conductors of the circuit. This implies that some current is flowing from the remote neutral connection to earth. If there is a current flow, there must be a voltage difference to drive the current.
Depending upon where this connection is made, could cause the earth loop and hence the hum.
Dave
bzotto
Experienced Member
I have found the hard way more than once that an inexpensive, generic power supply was itself the cause of substantial noise (hum in audio stuff, poor digital signal integrity leading to glitches etc). Have gone off chasing ghosts with an oscilloscope only to find that just using a high quality power supply fixed the problems!
AgentOrange96
Experienced Member
- Joined
- Jul 24, 2014
- Messages
- 142
I've just gotten my tape interface built. I actually built the boards years ago, but only built the enclosure today. So far, the following is working:
1. Control of the tape player. Both the read and write commands in MEA will turn on and off the tape player
2. Tone recognition. If I use the read command, it'll continue listening until I start playing data, then it will eventually throw an error.
Which leads me into what's not working:
1. Reading data. I always get an "I" which according to the MEA manual means there was an error reading data.
2. Writing data. No sound wave appears in audacity when I try to record.
@kalinchuk mentioned in his video that @mwillegal had timing issues and needed to replace a capacitor with a different value. (I'm guessing in his blog somewhere)
I'm not sure though that that would cause my writing issues. Perhaps my reading issues. I'll need to break out the scope and look around I suppose.
But excitingly, that's some luck!
I'd also like to know if anyone has SCELBAL in an audio form already. I worked with ChatGPT to create a python script to send an Intel Hex file over serial to MEA, but at 110 baud it'll take all day. I'll do it if I have to, but I'd rather not.
EDIT: The silence when writing data may be issues getting a line in working reliably on any of my systems. I plugged a pair of headphones in directly and I get a continuous tone whenever the system is powered on at all. It sounds like probably a square wave. When I send data I do hear the data being sent I think when I run the write command. If I unplug P1, (from SCELBI to tape interface) it goes away. P2 (from tape interface to SCELBI) is still plugged in. Maybe I'm hearing the sync signal?
EDIT2: I was able to record it on my laptop and it's a 1303Hz square wave. I'm not sure yet what to correlate that to. (Sync is 250kHz) It also happens if I plug into a different port on the SCELBI.
1. Control of the tape player. Both the read and write commands in MEA will turn on and off the tape player
2. Tone recognition. If I use the read command, it'll continue listening until I start playing data, then it will eventually throw an error.
Which leads me into what's not working:
1. Reading data. I always get an "I" which according to the MEA manual means there was an error reading data.
2. Writing data. No sound wave appears in audacity when I try to record.
@kalinchuk mentioned in his video that @mwillegal had timing issues and needed to replace a capacitor with a different value. (I'm guessing in his blog somewhere)
I'm not sure though that that would cause my writing issues. Perhaps my reading issues. I'll need to break out the scope and look around I suppose.
But excitingly, that's some luck!
I'd also like to know if anyone has SCELBAL in an audio form already. I worked with ChatGPT to create a python script to send an Intel Hex file over serial to MEA, but at 110 baud it'll take all day. I'll do it if I have to, but I'd rather not.
EDIT: The silence when writing data may be issues getting a line in working reliably on any of my systems. I plugged a pair of headphones in directly and I get a continuous tone whenever the system is powered on at all. It sounds like probably a square wave. When I send data I do hear the data being sent I think when I run the write command. If I unplug P1, (from SCELBI to tape interface) it goes away. P2 (from tape interface to SCELBI) is still plugged in. Maybe I'm hearing the sync signal?
EDIT2: I was able to record it on my laptop and it's a 1303Hz square wave. I'm not sure yet what to correlate that to. (Sync is 250kHz) It also happens if I plug into a different port on the SCELBI.
Last edited:
AgentOrange96
Experienced Member
- Joined
- Jul 24, 2014
- Messages
- 142
From the build manual:
So the 1300Hz tone is essentially a logic low and 2600Hz is logic high. I'm not sure if maybe it's normal for that tone to be continuous when the system is operating or not. If so, then I think that may be working correctly. As for why reading isn't working right, I'm not sure yet.
EDIT: Per the linked video above, the variable resistor needs to be set ~6k. I did so and I am now able to read Mark Arnold's recording! Unfortunately, my previous recording does not read in correctly, nor does Mike's recording on that same page. But maybe I just need a little more fine tuning.
I'm actually able to read in the tone from @kalinchuk's video too at 47:10. In fact, it reveals some editing magic. That was not the recording of "HELLO FROM SCELBI" but actually "HELLO WORLD" which I had to double check because that was the string I had used for testing.
So the 1300Hz tone is essentially a logic low and 2600Hz is logic high. I'm not sure if maybe it's normal for that tone to be continuous when the system is operating or not. If so, then I think that may be working correctly. As for why reading isn't working right, I'm not sure yet.
EDIT: Per the linked video above, the variable resistor needs to be set ~6k. I did so and I am now able to read Mark Arnold's recording! Unfortunately, my previous recording does not read in correctly, nor does Mike's recording on that same page. But maybe I just need a little more fine tuning.
I'm actually able to read in the tone from @kalinchuk's video too at 47:10. In fact, it reveals some editing magic. That was not the recording of "HELLO FROM SCELBI" but actually "HELLO WORLD" which I had to double check because that was the string I had used for testing.
Last edited:
AgentOrange96
Experienced Member
- Joined
- Jul 24, 2014
- Messages
- 142
I determined that reading was working based on the above which meant writing was not. I replaced the 0.022uF cap with a 0.0047uF cap as that was the closest value I had to the 0.004uF referenced in previous posts and it works now!
Although the first time I started it after that, the tone was wild. After restarting it, the tone was normal, but data isn't being read back from memory correctly or something. That "HE\LO WORLD" was happening even after just putting it in the text buffer.
As such, I think writing is working fine now! I hope I don't have a failing RAM chip or something.
EDIT: After sitting, the memory seems fine now. But sometimes it starts up with a different nasty sounding tone instead of 1300MHz. Anyway, with it working properly:
Last edited:
daver2
10k Member
I have taken a quick look at the write schematic.
The input clock is connected to P1-10 (AH) and this should be wired to the CPU SYNC signal (XA02 B-A and B-B). This forms the master clock for the interface derived from the CPU clock. As a result, the CPU clock needs to be adjusted correctly - otherwise the interface frequencies will be 'off'.
There appears to be a number of simple dividers (7493) producing the frequencies for the two tones. The '0' and '1' tones are derived by Z6 on pins 9 and 12 (respectively). Pin 12 is from the /2 counter output and pin 9 is from the /4 counter output (hence a factor of 2 difference in the frequencies).
These two frequencies are fed into the logic comprising Z12 (wired as a 1 of 2 selector); so either the higher frequency or the lower frequency is selected (based upon the logic level of Z5 pin 10), divided further (by Z13 - /16) and output to the cassette recorder.
Z5 (7496) is a 5 bit shift register that can be parallel loaded. The serial input (pin 9) is permanently connected to 0V, the four (4) data lines are loaded from P1-1 through P1-4, with the fifth input (pin 7) being held permanently HIGH.
Effectively, there should always be a tone output from the write circuitry. It is possible that the logic powers up in a strange state and requires initialising. However, I can't see a power-on reset of any kind. This may account for the strange 'wailing'? The only way that anything other than one of the two tones could be realistically produced is if the tones are being 'switched' / modulated by data being sourced from Z5 pin 10.
It should be possible to to use an online logic simulator (e.g. https://www.falstad.com/circuit/) to simulate the logic and to see exactly what happens under controlled conditions. I do this quite often to visualise certain logic state problems.
Dave
The input clock is connected to P1-10 (AH) and this should be wired to the CPU SYNC signal (XA02 B-A and B-B). This forms the master clock for the interface derived from the CPU clock. As a result, the CPU clock needs to be adjusted correctly - otherwise the interface frequencies will be 'off'.
There appears to be a number of simple dividers (7493) producing the frequencies for the two tones. The '0' and '1' tones are derived by Z6 on pins 9 and 12 (respectively). Pin 12 is from the /2 counter output and pin 9 is from the /4 counter output (hence a factor of 2 difference in the frequencies).
These two frequencies are fed into the logic comprising Z12 (wired as a 1 of 2 selector); so either the higher frequency or the lower frequency is selected (based upon the logic level of Z5 pin 10), divided further (by Z13 - /16) and output to the cassette recorder.
Z5 (7496) is a 5 bit shift register that can be parallel loaded. The serial input (pin 9) is permanently connected to 0V, the four (4) data lines are loaded from P1-1 through P1-4, with the fifth input (pin 7) being held permanently HIGH.
Effectively, there should always be a tone output from the write circuitry. It is possible that the logic powers up in a strange state and requires initialising. However, I can't see a power-on reset of any kind. This may account for the strange 'wailing'? The only way that anything other than one of the two tones could be realistically produced is if the tones are being 'switched' / modulated by data being sourced from Z5 pin 10.
It should be possible to to use an online logic simulator (e.g. https://www.falstad.com/circuit/) to simulate the logic and to see exactly what happens under controlled conditions. I do this quite often to visualise certain logic state problems.
Dave
I think the tape playback had multiple recordings playing one after another which is why you might've gotten the "HELLO WORLD" as I may have recorded that text previously and did multiple overwrites of the same tape. I'm glad that you got it working! I've found that, if you play around with the pot and the volume of the tape player, you can get a fairly consistent reading.
daver2
10k Member
The cassette read board should have an LED present and there is a documented procedure for (best) adjusting the volume control.
Dave
Dave
AgentOrange96
Experienced Member
- Joined
- Jul 24, 2014
- Messages
- 142
I'll have to record what I was hearing at some point if it continues to be an issue and also check the waveform and spectrum.
I did use the LED to adjust which worked nicely! I should probably put a hole in the case to make that easier. Or move the LED onto the case panel mount.
That makes sense on the HELLO WORLD! Having access to that video was not only informative for troubleshooting but also having access to that clip was helpful for confirming the read functionality! Thanks!
I did use the LED to adjust which worked nicely! I should probably put a hole in the case to make that easier. Or move the LED onto the case panel mount.
That makes sense on the HELLO WORLD! Having access to that video was not only informative for troubleshooting but also having access to that clip was helpful for confirming the read functionality! Thanks!
AgentOrange96
Experienced Member
- Joined
- Jul 24, 2014
- Messages
- 142
Okay, so I have a script to create a WAV file encoded in the standard SCELBI tape format as seen here:
The output from this file looks right. The waveforms look right. However, I get an error while trying to load audio from it. The MEA prompt returns "I"
I had previously written on page 010 addresses 000 to 007 the data 377 down to 370 (Octal)
So 010 000 has 377 and 010 007 has 370
I wrote this to tape, and looking at the wave form, I do not see the standard SCELBI tape format at all. It's something completely different. And I'm quite confused.
What I expect to see:
What I actually see (assuming 1 start bit, excluded below):
I see no relation to what's being written out. But I can replay this wave form and the SCELBI happily loads it back into memory successfully and accurately.
If anyone else understands what's up, I'd greatly appreciate the feedback.
My recorded wave file is attached. I'll upload my current script to github for reference.
Also a note on the FSK scheme:
A single large pulse is a 0
A double small pulse is a 1 (Two pulses make a 1)
The output from this file looks right. The waveforms look right. However, I get an error while trying to load audio from it. The MEA prompt returns "I"
I had previously written on page 010 addresses 000 to 007 the data 377 down to 370 (Octal)
So 010 000 has 377 and 010 007 has 370
I wrote this to tape, and looking at the wave form, I do not see the standard SCELBI tape format at all. It's something completely different. And I'm quite confused.
What I expect to see:
Code:
PHLTXXXX
11000000 Page 010
10001000
10100000 Address 000
00000000
00001111 Data 377
00001111
00001111 Data 376
10001110What I actually see (assuming 1 start bit, excluded below):
Code:
10000000
10000111
00000011
10000001
00000011
10000000
10011001
00000011
10000000
11111111
00000011
11111111
00000011
11111111
00000011
10011111
00000011
10000000
11111111
00000011
11100111
00000011I see no relation to what's being written out. But I can replay this wave form and the SCELBI happily loads it back into memory successfully and accurately.
If anyone else understands what's up, I'd greatly appreciate the feedback.
My recorded wave file is attached. I'll upload my current script to github for reference.
Also a note on the FSK scheme:
A single large pulse is a 0
A double small pulse is a 1 (Two pulses make a 1)
Last edited:
AgentOrange96
Experienced Member
- Joined
- Jul 24, 2014
- Messages
- 142
I think I've made some progress here.
Firstly, a correction on the FSK scheme:
TWO large pulses is a 0
FOUR small pulses is a 1
With this in mind, I encoded data 125 at address 000 000
This is binary 01010101 at 00000000 00000000
I've attached the audio, but also I've transcribed the bit stream:
The labels at the top are my best guess as to what's going on here. I'm still a little confused. Each raw byte is accurate. My notation may not be.
Firstly, a correction on the FSK scheme:
TWO large pulses is a 0
FOUR small pulses is a 1
With this in mind, I encoded data 125 at address 000 000
This is binary 01010101 at 00000000 00000000
I've attached the audio, but also I've transcribed the bit stream:
Code:
7654 HLTP
3210 0000
0000 0001
1000 1000 High address
0000 0000
0000 0001
0100 0100 Low address
0000 0000
1010 0001
1010 0001 Data 01010101
1010 0001
0010 0011 Trailer
0000 1000The labels at the top are my best guess as to what's going on here. I'm still a little confused. Each raw byte is accurate. My notation may not be.
AgentOrange96
Experienced Member
- Joined
- Jul 24, 2014
- Messages
- 142
And here is the same corrected transcription of the bytes for this:I had previously written on page 010 addresses 000 to 007 the data 377 down to 370 (Octal)
Code:
00000001
10001000
00010001
00000001
01000100
00000000
11110001
11110001
11110001
01110001
00001111
00010000
10110001
00001111
00010000
00110001
11110001
11010001
00001111
00010000
01010001
11110001
10010001
11110001
00010001
00001111
00011001
00010001
00000000AgentOrange96
Experienced Member
- Joined
- Jul 24, 2014
- Messages
- 142
Here's my annotations thus far, just looking at the two examples I've generated:
Example 1
Example 2
So it's very clear where most of the data is. Although I appear to be missing some high bytes. Unless I'm off on the byte frames somehow?
But I'm not sure how this would happen. I may have to re-examine the wave file.
There is also some clarification needed on the header data and the footer data.
Example 1
| Page\Addr | 000 | 001 | 002 | 003 | 004 | 005 | 006 | 007 |
| 010 | 377 | 376 | 375 | 374 | 373 | 372 | 371 | 370 |
Code:
0000 0001 Start of transmission
1000 1000 Next byte is high address
0001 0001 - What is this doing here?
0000 0001 High address
0100 0100 Next byte is low address
0000 0000 Low address
1111 0001 High byte of 377
1111 0001 Low byte of 377
1111 0001 High byte of 376
0111 0001 Low byte of 376
0000 1111 - Thing 1/2
0001 0000 - Thing 2/2
1011 0001 Low byte of 375
0000 1111 - Thing 1/2
0001 0000 - Thing 2/2
0011 0001 Low byte of 374
1111 0001 High byte of 373
1101 0001 Low byte of 373
0000 1111 - Thing 1/2
0001 0000 - Thing 2/2
0101 0001 Low byte of 372
1111 0001 High byte of 371
1001 0001 Low byte of 371
1111 0001 High byte of 370
0001 0001 Low byte of 370
0000 1111 - Thing 1/2
0001 1001 - Dunno
0001 0001
0000 0000
377 = 1111 1111 010 000 = 0000 1000 0000 0000
376 = 1111 1110 010 001 = 0000 1000 0000 0001
375 = 1111 1101 010 002 = 0000 1000 0000 0010
374 = 1111 1100 010 003 = 0000 1000 0000 0011
373 = 1111 1011 010 004 = 0000 1000 0000 0100
372 = 1111 1010 010 005 = 0000 1000 0000 0101
371 = 1111 1001 010 006 = 0000 1000 0000 0110
370 = 1111 1000 010 007 = 0000 1000 0000 0111
MIRROR
377 = 1111 1111
376 = 0111 1111
375 = 1011 1111
374 = 0011 1111
373 = 1101 1111
372 = 0101 1111
371 = 1001 1111
370 = 0001 1111Example 2
| Page\Addr | 000 |
| 000 | 125 |
Code:
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
125 = 0101 0101 000 000 = 0000 0000 0000 0000
MIRROR
125 = 1010 1010So it's very clear where most of the data is. Although I appear to be missing some high bytes. Unless I'm off on the byte frames somehow?
Code:
1111 0001 High byte of 373
1101 0001 Low byte of 373
0000 1111 - Thing 1/2
0001 0000 - Thing 2/2
0101 0001 Low byte of 372
Becomes
1111 0001 High byte of 373
1101 0001 Low byte of 373
1111 0001 High byte of 372
0101 0001 Low byte of 372There is also some clarification needed on the header data and the footer data.
AgentOrange96
Experienced Member
- Joined
- Jul 24, 2014
- Messages
- 142
Mike had sent me a recording of SCELBAL a few days ago. Unfortunately, I can't get it to read fully. It sounds to have been recorded to tape and then played back and recorded on a computer via a microphone near the tape player. (You can hear the button being pressed to start the tape player) The SCELBI makes it a good way through before giving up, which is a testament to how robust this system is. (Similarly, the fact that I could read in a program from a similar circumstance in a YouTube video is too!) The square waves have been turned into sine waves (which is not an issue) presumably due to losing high frequencies.
Anyway, despite this, I am able to load it into audacity and make out the bytes. So I've done analysis of the header:
The bottom notes are based on what I see in the Intel hex file. But I'm thinking perhaps this version of SCELBAL is different. Maybe a different revision. (It was labeled as 1975, and the one from SCELBI.com seems to be 1976? IDK) Anyway, I can identify parts, but I'm still confused. I don't even see data being loaded the same way after the header.
Anyway, despite this, I am able to load it into audacity and make out the bytes. So I've done analysis of the header:
Code:
SCELBAL
0100 0001
0000 1001
0001 0000 High address (0x08 or octal 10)
0000 0001
0100 0100 Next byte is low address
0000 0000 Low address
1100 0001 High Byte of 044 (But in octal? Should be 44 hex)
0110 0001 Low Byte of 044 (But in octal? Should be 44 hex)
0000 0000
0110 0000
0000 0001
0000 1000
0000 1010
0001 0001
1100 0100
0001 0000
1000 0001
0001 0110
Hex: 40
Oct: 100
Bin: 0000 0000 0100 0000 -> 0000 0010 0000 0000
Hex: 44
Oct: 104
Bin: 0100 0100 -> 0010 0010The bottom notes are based on what I see in the Intel hex file. But I'm thinking perhaps this version of SCELBAL is different. Maybe a different revision. (It was labeled as 1975, and the one from SCELBI.com seems to be 1976? IDK) Anyway, I can identify parts, but I'm still confused. I don't even see data being loaded the same way after the header.