• Please review our updated Terms and Rules here

SCELBI Data Bus Oddities and Debug

I have the same problem with space.

Are you able to ZIP up and post the binary file you created. I should be able to duplicate your code as a cross-check.

Where are your EPROMs located in the memory address space?

MEA is based at page 60 (octal) = 3000 (hexadecimal).

3000 (hexadecimal) is encoded within the MEA.hex file. Changing it would result in the line checksum being incorrect. Incidentally, there appears to be an extraneous '0' in the MEA.hex file that I have not noticed before (at a record starting address of 31D0 (hex)).

Correction to the above. The relevant records (from MEA.hex and P61.hex respectively) are:

Code: 
:1031D000068544A9313CCC48DF31068644A9313C100
:1031D000068544A9313CCC48DF31068644A9313C00

It is the '1' that is extraneous not the '0'...

Dave
 
Last edited:
daver2 said:
I have the same problem with space.

Are you able to ZIP up and post the binary file you created. I should be able to duplicate your code as a cross-check.

Where are your EPROMs located in the memory address space?

MEA is based at page 60 (octal) = 3000 (hexadecimal).

3000 (hexadecimal) is encoded within the MEA.hex file. Changing it would result in the line checksum being incorrect. Incidentally, there appears to be an extraneous '0' in the MEA.hex file that I have not noticed before (at a record starting address of 31D0 (hex)).

Correction to the above. The relevant records (from MEA.hex and P61.hex respectively) are:

Code: 
:1031D000068544A9313CCC48DF31068644A9313C100
:1031D000068544A9313CCC48DF31068644A9313C00

It is the '1' that is extraneous not the '0'...

Dave
Click to expand...

Yeah, attached is the ZIP file with both the binaries and the hex files. I did briefly look into how Intel Hex files work to validate that and I saw the checksum, otherwise I would have tried to see if my download got corrupted as a next step.
I have the EPROM card in the last slot which starts at page 60. I verified that the intel hex showed 3000 as noted as well, so that looked good. I also was able to verify the first few bytes of ROM on the SCELBI itself, so it seems to be reading them correctly at the right location.
When I tried to download MEA.hex the other day I got a blank 0 byte file. I'm operating off of the P61.hex

I definitely appreciate having someone double check my work. Thanks!
 

Attachments

I have had a quick random look and things appear to be OK.

So that is not a factor.

How are you attempting to start MEA when you turn the power on?

Dave
 
Toggle in JMP (Octal 104)
Hit INT
Step until the INT light turns on
Step until the first status light turns on
Toggle in address 000
Step again (First status light remains on)
Toggle in page 030
Step again, status lights turn off
Press the run button
 
Page 030 or 060?

Page 060 (octal) = 30 (hexadecimal)...

It should be:

104
000
060

Shouldn't it?

3000 (hex) = 11 0000 0000 0000

Lop off the lower 8 bits as the MEMORY ADDRESS gives:

11 0000

Convert into OCTAL: 110 000 = 60 (octal) for the PAGE.

Dave
 
Here is a video of me attempting to run MEA:


I continue to hit run until it stays running in case that's useful information. It doesn't connect to my terminal at that point though.

Incidentally, I noticed after toggling in a command, the INT light is out but we aren't running yet, so the same state as the program leaves the system.
 
I have a solid idea of why the system is stopped. Pin 17 on the 8008 is the ready signal. The CPU is waiting for the ready signal:
1750119015566.png
I have confirmed on the scope that it is being held low. However, I'm trying to understand the run/wait circuit to figure out what is stopping the system. It seems plausibly memory related based on this, but the circuitry for this is quite complicated. I am currently trying to understand it such that I can dig deeper into what is going on and how to fix it.
 
Okay, so I'm really confused now.

For more context:
1750121651134.png


The ready signal to the CPU comes from some circuitry in the bottom-right of the CPU board schematic. That takes inputs of the sync signal, the step button, the run button and "T1IN"
T1IN comes from a 4-bit BCD to decimal decoder. (Only using 3-bits) Ultimately, T1IN is stet to high whenever all three status pins on the CPU are high.

1750121772341.png

This indicates we are in T4.

Which per my last message is this:
1750121808132.png

So if I'm not mistaking, this indicates that the CPU will put itself into this state anytime we execute an instruction that requires these states. Which I'm not exactly sure which ones these are or why this would be wanted. Unless I'm misunderstanding something here.
 
I still haven't figured out what's up. But I set the switches to 300 (LAA) which is essentially a NOP. This is recommended in the manual for when you want to resume a program without changing the registers.
Once I get it into a run state (in the video you can see after several tries, it runs) it enters that same "stopped" (but stop light isn't on) state whenever I enter anything into the terminal.

There is still no output on the terminal, but this tells me it's receiving the input from the terminal. So something is happening. But I'm not sure what.
 
Hold up, I'm wrong about it being T4. I mixed up pin numbers and decimal output numbers:
1750129102853.png


T1IN is on pin 7, which actually corresponds to decimal 6
1750129072886.png
This occurs when pin 15 is low and pins 14 and 13 are high. Which is on the 8008 is pin 13 low and pins 11 and 12 high. Which in turn means S0 is low, S1 and S2 are high.
Looking at the table earlier, this is T1I (Duh) which occurs when we're in an interrupt state. This makes a lot more sense!

But then the question is, what causing this interrupt. As far as I have read, there are no software interrupts on the 8008. Am I wrong here?

Next steps:
1. Probe the interrupt line and see if I'm getting any noise.
2. If not, see if I'm wrong and software interrupts exist on the 8008.
 
A lot of the interrupt circuit is easier to understand when you realize that INTC and TTY are both grounded in the chassis. Meaning a lot of the circuitry ends up just inverting the INT button.
That goes into some D flip-flops that can only be set by the INT button but can be cleared through some other circuit. But that means nothing else can set the interrupt besides the button.
Hmm

1750131773445.png
 
Last edited:
I am looking at the two (2) status lamps as you enter the JMP (104) 000 060 instruction and they make sense up to the point at which you hit run. Then everything goes to rack and ruin.

The two (2) status lamps being D7 and D6 of 00 (both off) indicates that the 8008 is performing a memory read of the first byte (opcode) of an instruction.

Then the status lamps change to 10 indicating that the 8008 is performing a memory read of an additional byte (in this case the jump address operand).

There are two bytes required - so the status lamps do not change from 10 for each of the two jump operand bytes.

The lamps then go out - indicating that the 8008 is wishing to read the first byte of an instruction again.

My understanding is that the JMP instruction should have been obeyed by this time.

However, when you then hit RUN, it all falls to pieces. Somehow the CPU ends up at address 00 140 (page 00 address 140) trying to execute instructions. What it is trying to do (from the status lamps) is to perform a memory write.

Either the JMP instruction that we previously entered went wrong or the RUN state is not working correctly.

Dave
 
Last edited:
Ah...

RDYN also comes in from the lower left-hand side of the schematic on pin AZ. This is fed (via Z12 pins 1 and 2) into the 8008 CPU pin 17 (READY IN). So this is the actual edge connector pin that drives the CPU itself, not the pin on the lower right-hand side.

There should be a wire link between the following points:

XA02 AX RDYN
XA02 AZ RDYN

And a separate wire link between the following points:

XA02 AY T3N
XA02 BF T3N

If the wire links are present, then we can do some probing to see what is going on...

Dave
 
I was looking into the interrupt circuit last night, but again the INT light isn't being set. So I don't know that that's the right path. Maybe I should probe S0, S1, S2 directly to see exactly what state the CPU is in.

EDIT: I had refreshed, but somehow your replies didn't show up til I posted this. Lemme read them!

Ah yes, those wires are present. I had looked into that. I ended up probing from the resistor on the board though. I forget what I saw.
 
LOL It's literally just the voltage issue. I just adjusted the power supply until the voltage was at 5V and it's staying running now.
Let me probe the output though before I plug power back into the serial interface. My concern is that it may be too high now for that.

EDIT: 5.6V. The max supply voltage for the 74SN74 is 5.25. So I'm still afraid to plug that in. I'm expecting some new wire to come in today. I won't rebuild the connector, but I was planning on essentially supplementing it with the banana jacks. Unfortunately, this seems too low for a typical VR to turn back into 5V.
 
You must log in or register to reply here.
Back
Top