• Please review our updated Terms and Rules here

SCELBI Data Bus Oddities and Debug

A

AgentOrange96

Experienced Member
Joined
Jul 24, 2014
Messages
142
Hello all,
I built a SCELBI-8B a few years back, but I've always had memory issues with it. I had assumed the Tesla 2102 SRAM chips where the culprit, despite all checking out on an Arduino based tester. However, I no longer believe this to be the case. It's been a little bit of whack a mole over the weekend.

First Bit 7 was stuck low. I was able to root cause that to a missing connection to VCC for an associated pull-up. Non-surprisingly @mwillegal had already found and documented this on his blog, but unfortunately, I had missed his two posts about that while debugging. (He sent them to me via email since I've been in touch with him)
Incidentally @kalinchuk found a completely separate instance of VCC not being connected properly on that board, which he documents on his github. This board design doesn't even seem to match the original layout, so there's gotta be a story here.

Anyway, I fixed these issues, but now Bit 0 is stuck high. Which looking at the schematics shouldn't be a direct result of any work done thus far. Things I have noticed:
  1. Voltage drops significantly at the SCELBI if RAM is plugged in, and only if RAM is plugged in. We're talking closer to 4V than 5V. I don't remember the exact number off the top of my head. It doesn't seem to be worse if multiple RAM cards are plugged in vs 1. At the power supply, it still reads 5V. This makes me think the wire I have to the power supply might be too thin and causing a lot of resistance. Unless there are issues with the RAM cards. But they may just be power hungry.
    • I bypassed the wire and ran 5V directly to the board from the power supply with alligator clips. I saw the voltage was at the proper 5V this way which confirms my cables suck. But the issue remained, so I am not going to worry about this right now.
  2. There are internal voltages that are weird. We have a circuit where LOGIC high is ~2V at parts and where logic high appears to be ~2V elsewhere. This seems extremely suspicious.
  3. The pull down network on the CPU card is absolutely bonkers and I don't understand it.
So for context, tracing the data bit 0 signal in relation to memory, I made this table:
1749997265860.png
For reference, schematics can be found for all boards on SCELBI.com

If I don't mention what the logic level high is, it's 5V (or whatever voltage I'm getting in)
If I don't mention what the logic level low is, it's 0V
I saw no difference in logic levels with or without the RAM cards plugged in
On notes where I mention "then latches X", the logic level toggled with the switch when the Int and first status lamp were lit (prior to memory write) and then latched during the memory write operation (both status lamps lit)

What I think is happening is that at Z10 on board 1101, our high and low voltages are too close and getting mixed up.
And I think this is caused by our weird logic low of 2V situation on card 1100, which is the CPU card. And this is where I see something I do NOT understand. The pull-down network on the data-bus:
1749997693155.png
(Again, full schematics can be found at the SCELBI.com link I mentioned earlier)

What is this? I'm pretty sure this is why our logic low only gets pulled down to 2V. Now something itneresting about this is that it seems these tended to be 3k resistors in reality. (As mentioned in the link to Mike's blog linked earlier) Some of my resistors seem closer to 3.5k than 3.3k, so I'm wondering if things are just very marginal/sensitive about this diesign.
Unfortunately I do not have any 3K resistors on hand yet. I'm hoping that fixes my issues. But I just don't understand this to begin with.

What's weirder is that I looked at the schematics for the Mark-8 and also the datasheet for the 8008, and both show pull-up networks rather than pull-down.

Anyway, I'm hoping to get a whole resistor kit this evening. If 3K resistors work, I'll buy carbon comp ones to match the aesthetics but run the kit ones in the meantime.
Today I may swap out the Tesla 2102 chips with some National Semi ones I'd picked up at some point to see if maybe they are less sensitive to issues? But I'm not hopeful.

If anyone has any ideas as to either what else I should check or where issues might be, please do let me know.
And if anybody understands what's going on with this pull-down network, PLEASE explain it to me, because I'm super confused. A little as to the what but mostly as to the why.
I had a lot of good help getting my Altair up and running over in the S100 section, so I figured I'd post here to get more answers as well as to document it for anyone else who might need it.
Thank you everyone! I'll update this thread if I figure anything out.
 
Okay, so I swapped out one RAM board from the Tesla MHB2102 to National Semi MM2102AN-L and no more stuck bit. Actually, I should go check the voltage to see if the voltage drop is less. But either way, it seems at least at first to be less susceptible.
My RAM tester is acting up and failing everything (probably the socket) so I just YOLO'd it and stuffed a whole board full. I can test RAM on the SCELBI if I can get enough working bytes to either load the monitor or toggle in a short program from the manual.
I'll continue to keep y'all updated. Fingers crossed I'll have this fully working with a monitor for VCF SW. (I don't think I have time to get SCELBAL, a form of BASIC, working by then. I don't even have my tape interface built.)

EDIT: 4.6V with the NS RAM. Which I think is better than the Tesla RAM? But still not great! I'll definitely need to replace that wire, but probably after VCF SW if I can get away with it.
 
Last edited:
The pull-downs look wrong to me.

The Mark-8 schematics have pull-ups.

The Intel schematics have pull-downs, but a transistor switch making them a pull-up under certain circumstances.

Anything that should be logic HIGH between 0.8 Volts and (say) 3.5 Volts would be suspect in my book.

As you have already found, you need thick cables on the power supply leads!

The voltage on the logic devices should be greater than 4.75 Volts.

Dave
 
Are your Z1 and Z10 buffers 74L04 devices? The 'L' is important, LOW power.

Z2 and Z3 are open collector outputs - so do not 'provide' a high output voltage. They rely on external resistors to 'pull-up' the data bus of the 8008 CPU when the CPU is reading data from the data bus.

This further supports the thought that the data bus resistors should be pull-ups to +5V and not pull-downs.

EDIT: The SCELBI is the same as the Intel schematic with a transistor switch to +5V. Is the logic working that drives the transistor, and have you installed the transistor the correct way around? Note that some manufacturers have different transistor pinouts to others for the same part!

Dave
 
daver2 said:
Are your Z1 and Z10 buffers 74L04 devices? The 'L' is important, LOW power.

Z2 and Z3 are open collector outputs - so do not 'provide' a high output voltage. They rely on external resistors to 'pull-up' the data bus of the 8008 CPU when the CPU is reading data from the data bus.

This further supports the thought that the data bus resistors should be pull-ups to +5V and not pull-downs.

Dave
Click to expand...

Almost every chip is 74LSXX, so I have 74LS04 for those. (There's like one somewhere that doesn't exist in LS form that isn't. I bought some somewhere but they ended up being counterfeit.)
There are also spots that just call for 7404 which are also 74LS04's on my system. But those don't seem to be causing issues in their respective systems which is good. (I'm sure you remember my affinity for 74LS04's over 7404's, even getting my Altair clock running with them! xD )

And yeah, the pull-down just doesn't make any sense to me. But there are several examples of working machines so like... somehow they're working. And even mine seems to work with this other RAM, although I'm still getting some issue when trying to run the monitor where it hits some point in RAM and then stops running. Not halted. Just not running. I'll have to check again to see if the interrupt light is on in that case. I'm not sure if this issue is related or something else to chase down.
 
I made a critical edit to my last post regarding the data bus resistors.

The L parts for these ICs are (I think) important. But the transistor +5V switch for the group of resistors will be more important (if it is not working)...

Dave
 
It looks like you're talking about this 2N2907:
1750005327042.png
The text is far to small to read on the can, but I was able to find my order from years ago. The datasheet can be found here for the transistor I have.
I remember it's technically mil-spec so I had to deal with export control stuff just to get it to my apartment which seemed silly. Anyway:

Unfortunately, the datasheet does not show any pinout or orientation info.
What I will say is that the tab from the can sticks the same direction as it does in the photo on SCELBI.com. But as you mentioned, this may vary with manufacturer. I'll look into this more.
 
A metal can transistor is much easier (I was thinking of the horrid plastic TO92 variant). The pin near the metal tab should be the emitter, and should be connected to +5V. Check this by eye by following the PCB tracking.

Check the output from pin 2 of Z24. Is it toggling?

However, I would only expect this if the 8008 CPU is actually executing a program...

Dave
 
daver2 said:
A metal can transistor is much easier (I was thinking of the horrid plastic TO92 variant). The pin near the metal tab should be the emitter, and should be connected to +5V. Check this by eye by following the PCB tracking.

Check the output from pin 2 of Z24. Is it toggling?

However, I would only expect this if the 8008 CPU is actually executing a program...

Dave
Click to expand...

Yeah I used metal cans for this project since aesthetics were important to me. If this sheet is anything to go off of, then it's definitely oriented right:

I just finished swapping out RAM chips to the NS ones. Placing even a second board in reverts to a stuck bit. However, now if I bypass my cable, this fixes it. So I think there is some power starvation going on somehow. And adding the extra boards increases the load. That means I'm going to have to make a new cable. Which is not going to be fun. I either need to reuse my existing connectors (desoldering will be a pain. There's a LOT of solder in the pins) or buy new connectors which is expensive and won't get here in time. So the former it is.

MEA monitor is still pauses. Stop lamp unlit. Interrupt lamp unlit. Both status lamps lit which indicates a memory write operation. Weird.

I might try the 3K ohm resistors still this evening when they arrive, but I have other things I need to do today. I'll see if I can catch Z24 toggling with stepping. That's how I've been testing everything thus far. It makes it far easier than dealing with an oscilloscope when it's in human perceptible time already.
 
I would only change the resistors if you have to.

You should be able to trigger your oscilloscope on a low to high transition of the signal on the collector of the transistor to the resistor/diode network.

Dave
 
I used my EEVBlog multimeter for now. I'll set up the scope later if I have to, but that'd be this evening here in the US.
What I saw was that it stayed at 2V except during a memory write operation. At which point it bumped up to 4.8V (probably supposed to be 5V)
I only have one RAM card installed.

Extra info: Frequency counter showed 86.6 kHz. So I think that shows it's toggling. It also showed a voltage of 4.2V, but since it was toggling, I doubt that's useful information.
That reminds me, I need to check what I have this thing clocked to. I had it clocked to 800kHz at one point (since it's an 8008-1) but I think I tuned it back to 500KHz since. I'd definitely need my scope to tune that. It's a process.

EDIT: Oop! I am indeed running at 800KHz. Fastest SCELBI in the west. I'll tune that back to 500 tonight. I wonder if that's causing issues with the monitor. At the very least I doubt 110 baud is 110 baud.
 
Last edited:
If you use a multimeter on something that is pulsing, you just get a misleading DC voltage reading I am afraid. You get an 'average' of the high and low voltage levels, the reading depending upon the percentage of time the signal spends at the high and low levels.

If you are observing a pulse of voltage on the resistor/diode network, then I suspect it is OK. But you have to remember that the transistor will have to be switched ON to get any pull-up voltage on the data bus (via the resistor/diode network.

I will have a re-read of the thread tomorrow if I get a bit of spare time.

Dave
 
daver2 said:
If you use a multimeter on something that is pulsing, you just get a misleading DC voltage reading I am afraid. You get an 'average' of the high and low voltage levels, the reading depending upon the percentage of time the signal spends at the high and low levels.

If you are observing a pulse of voltage on the resistor/diode network, then I suspect it is OK. But you have to remember that the transistor will have to be switched ON to get any pull-up voltage on the data bus (via the resistor/diode network.

I will have a re-read of the thread tomorrow if I get a bit of spare time.

Dave
Click to expand...
Yeah that's what I was thinking per the DC voltage. That only applies to the 4.2V reading at 86.6kHz. I should have specified: The other readings were taken in interrupt mode. The 4.2V and 86.6kHz was in run mode. (Executing whatever randomness was in memory)
I was actually thinking I bet you could work out the duty cycle from that, but then I stopped that train of thought before it gets dangerous. LOL

Thank you for your help and for your time! (Both on this and the Altair, you were a huge help there as well!) Hopefully by tomorrow I'll have set my clocks back to 500kHz at least and have some update. I'm wondering if that's causing whatever is stopping the CPU, but it shouldn't be related to the stuck bit.
Per the stuck bit, again one board of NS RAM fixes this, but two causes the issue to recur. But then bypassing the presumably too thin cable fixes that again. So like, maybe a better cable and 500KHz will fix all my issues. But even if it does, it seems like there's some sensitivity or weirdness. Do all SCELBIs have that? Maybe. Who knows?
 
>>> Do all SCELBIs have that?

Who knows...

>>> Thank you for your help and for your time! (Both on this and the Altair, you were a huge help there as well!)

No problem at all. I learn new stuff at the same time - so it is all useful to everyone (although my wife would not agree with that statement of course!).

 Dave
 
I came home yesterday evening too tired (probably sleep deprivation) and with a headache to do anything on the SCELBI. This morning I reclocked it to 500kHz. Unfortunately this did not fix the monitor from stopping.
It stops at page 00 address 140 (octal) which is in main memory. It is in a write to memory operation, and if I hit step it shows that it wrote the value of octal 004 to memory. If I hit run, I get stuck here over and over. (Although the address changes to octal 155)
Eventually it'll run after several attempts to continue running, but I don't get a serial output so I doubt it's working.

Incidentally, while in interrupt, the data lights show 271, but this also happens if I write a value manually. So I don't think this is useful. I'll have to re-read the manual to see what this is telling me.

Anyway this is all done with only one RAM card inserted, so memory seems to be working fine. Plus the value of 004 shows me that bit 0 isn't stuck even at speed under this condition. If I can't get a new power cable made before VCF, I guess I'll run with just one memory card, but that'd be kind of lame so hopefully I have time to make a new power cord or otherwise get a reliable 5V to this thing in a safe manner.
 
I just refreshed my brain this afternoon by re-reading the SCELBI assembly and checkout notes.

The checkout notes are a bit thin on the ground though...

The recommendation was for 24 to 30 gauge solid-cored wire for wiring. Any idea what you have used on your machine for the power buss interconnections?

I am just wondering whether we can remove all of the cards from your system (except for a card under test) and give each of the cards a clean bill of health before working on the complex CPU board?

Just thinking of the best way of checking things out.

In the meantime, I will print out the CPU card schematic and get my ahead around it again...

One thing that came to mind (whilst reading) is the lack of 0.1 uF decoupling capacitors across the various boards. This will have the effect of increasing the noise on the power supply rails to and fro the logic devices. It may be interesting to observe the +5V rail using an oscilloscope. You may find lots of horrible high-frequency noise - despite reading a 'healthy' DC level using a multimeter.

Dave
 
Last edited:
I'm using the backplane for the power bus. I also soldered over the power traces on the backplane to increase their current carrying capabilities. So that should be adequate. However, I'm not sure what gauge wire I used for the cable going from the power supply to the SCELBI.
I can probe 5V accross the cards with my oscilloscope and see if I see noise. FWIW I just did so on the ROM board (since it was easy to access) and didn't see anything. But that has decoupling capacitors on it.

Mike had told me via email that the logic high of 2V could be due to a blown 74XX logic chip outout or the open collector not getting pulled up, which sounds right. I don't see any more missing pull-ups. But I'm thinking it'd be worth
1. Checking the chips with my XGPro to make sure they are functioning logically. Specifically the ones in the path of the stuck bit.
2. Check that they're not still attempting to pull the voltage lowish.

Perhaps validating these readings with the scope would also help. Maybe said noise is causing the logic high to bounce around and read as 2V on the meter. Another thing to check I guess.
 
I just probed 1102 Z1 pin 6 for MD0N and it turns out that yes, that is why the meter only read ~2V.

1000023326.jpg

Looking at this signal, I actually think it is operating as intended now. (When adequately powered)

Remember the 8008 multiplexes its pins between data and address. The 250kHz signal we see is it multiplexing between data being set to 1 and the address being set to 0. If I set switch B0 to 0 on address 0, it's at steady ground. If I set switch B0 to 1 on address 1, it's steady 5V. If they don't match, we see the multiplexing.

With this in mind, I am not worried that I have further issues with this stuck bit to resolve aside from getting adequate power to the system.

This leaves only whatever is happening with the Monitor Editor Assembler program that's stopping the system from running to be root caused.
 
Last edited:
daver2 said:
Ah ha...

Right tool for the job :)!

Dave
Click to expand...
YESSSS

See the problem is I put my 3D printing spools where my scope used to live "temporarily" and now I need to drag my scope to the kitchen table to work there. So I just like don't. LOL
I need to clean up my work room so it's actually usable and I don't not use the wrong tool out of laziness ;P

As a side note, I just verified all 1702A's are programmed according to the .bin files I made according to the .hex files from scelbi.com.
Next step, verify I made all the .bin files correctly.

My methodology was to import the hex files into HxD, delete the empty lines above that were created because the hex files specify the address in SCELBI memory rather than relative to the EPROM, then save them out as binary files. I'm pretty confident in this technique, but it's always possible I made a mistake while executing on it.
Still, without a halt or an interrupt, I'm still not sure how the processor is even stopping. And looking at the MEA manual, it's not like the Altair ROM where I thought it wasn't working because I didn't know I had to set the sense switches for it to know what serial port to use. As far as I can tell it should just start up immediately once run.
EDIT: Files all check out. So the data on the EPROMs should be correct.
 
Last edited:
You must log in or register to reply here.
Back
Top