• Please review our updated Terms and Rules here

SCELBI Data Bus Oddities and Debug

:)...

Don't forget to check the -9 Volt supply also. There is much less load on this rail, so you should be OK - but the 0V cable to the power supply returns the current from BOTH the +5V and -9V rails.

Dave
 
Ugh, false alarm. Something is still wrong. IDK what I did that I though I saw it running but apparently I did NOT. I noticed it was in STOP. Not on the right page. And I just jumped back to 060 and hit run and same symptoms. I'm still waking up, so I probably didn't do what I thought I did. Still an issue, but now voltage is right.

Last night right before I went to bed I saw another stuck bit while trying to run the JMP 000 000 program, so that's why I tried this this morning. I still want to try that program to see if it enters this same state.
 
I might have to switch back to the Tesla RAM. Every single RAM card has a stuck bit at address 0. But it differs by RAM card. That does NOT bode well for batch of NS RAM as a whole.
 
Actually, it is behaving differently. It's stopping rather than doing whatever weirdness it did before. So this is improvement!
It appears to be stopping because it's trying to access page 36, which I don't have populated. So it gets all 1's which would halt.
Why is it accessing that? I don't know. but it may be due to faulty memory.
 
If you are not careful you are going round in circles...

A HALT instruction is either 00, 01 or FF so a HALT instruction that the CPU tries to execute will (as you say) cause the machine to transition from RUN to HALT.

The trouble with all of this is that things are 'in a circle', so one thing affects another and so forth...

The 'faults' you are observing could just be random RAM values causing random effects - it all may just depend upon how the 8008 goes into the weeds.

Dave
 
Yeah I see what you're saying.
I got my 2102 tester working again.

I borrowed the Arduino to debug my 1702A programmer, but I had reflashed it with the non-working code for the tester. I flashed it with the working code and now it's good!

I'm testing chips during my work meetings, so hopefully I can either fix what's wrong or rule out the SRAM chips themselves.
 
1 bad chip on the first board. With that replaced, I no longer see it halt as described this morning.

However, now it's going back to that other stopped state. But now only like three times with one board installed and twice without. Then it stays running. It was like 40 times before.

I got a notification that my "tin coated copper" wire should be here very soon, so I think I'll want to get the power situation sorted and ruled out too next.

I really hope it's not just aluminum. Amazon special so who knows? I'm just gonna run it through the hole in an unused IO port, solder to the power rails and put banana plugs on the other end. Jank, but it'll do for now. I don't want to disassemble my normal power cable this close to a deadline.
 
Okay so, update:

I have soldered on the beefy 5V cables and terminated them in banana plugs. 5V issues SOLVED.
One card of memory is memory tested and we know it's good. SOLVED (I still need to do the other two)

Unfortunately, I have the same behavior. Even once I get it running, I do not see output on the serial terminal either unfortunately. But that may be getting ahead of myself. But at least we now know the memory and power issues are likely unrelated.
 
daver2 said:
Excellent.

So it is still halting after you attempt to JMP 000 060?

Dave
Click to expand...
It's still going into that state where it's not running.
But it's not running a halt instruction and entering "STOP"

Also, since my last message, it went back to taking like 40 tries or something. So I'm not sure what's up about that. :(
It seems like it's always on a memory write, but I don't see why that would be.
 
I ran a program to write 125 to a memory address in a loop to see if it'd stop running and it did not. It does that fine.
 
Do you have a means of using front panel mode to examine memory? If so, we should be able to examine the EPROM program at 060 000 and examine various 'random' bytes (say the first and last of each 1702 EPROM) to see if we can correctly observe what is there.

Dave
 
daver2 said:
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
Click to expand...
Yeah, let me probe this and see. There is a way to observe memory. I'm a little fuzzy on it. I think if you jump to that location though it'll show what's there.
 
>>> There is a way to observe memory. I'm a little fuzzy on it.

The manuals could be a bit more clear on this...

Dave
 
When not running ready is high.
When running, ready is low.

When the system stops while executing that code, ready is high. Just as it would be if just powered on or in interrupt mode.
I do sometimes see noise on this line, but it's not constant by any means. I'm not sure what it is. It's ~1V in amplitude and seems digital. It just shows up as a square wave momentarily every so often. I'd have to pay attention next time I see it to estimate the frequency.

Also, I do not see the "RUN" light lit even while running. This should only be on during the T1 (not T1 Int) state though, so maybe it's just effectively too dim for me to see.
 
So the links are present if the CPU is running under certain circumstances.

I am going out now for the rest of the evening...

See if you can read something correct from the ROM card...

Dave
 
I figured it out. I became convinced that there is no way in hell any of this could be causing this, and I just so happen to have an extra 8008.
Well, before that I tried to probe something and must have shorted something because I blew some fuses. But after that I put in the other 8008 and it is no longer stopping.

I do, however, still need to get the terminal working. But that may be my interface or some settings to adjust.
But yeah, I guess my 8008-1 wasn't happy for some reason. No 800kHz for me then if I need to use my 8008 regular.
 
Interesting that the CPU was toast.

You should be able to see some activity (on your oscilloscope) on the output port used for the serial interface when you run MEA as it tries to display the '>' prompt.

Dave
 
You must log in or register to reply here.
Back
Top