• Please review our updated Terms and Rules here

SCELBI Data Bus Oddities and Debug

So I'm still not getting a serial output. I put my scope on the output signal and it's getting a waveform. But there's no strobe signal on that port.

I do see though that a strobe signal works if I manually output to that port, and I see strobe is set high for something when I probe the DBB.

I interrupted the program while running and stepped through til I got to the output and it's outputting on port 11. This is what it should output on for the scope writer.

I know the MEA manual says it can only output to one at a time, but there's no information on how to select the output. Furthermore the manual may imply the rom varies, but the ROM on scelbi.com specifically says TTY. So it seems like I should have the right ROM.

I feel like it's functioning but that I'm missing something. I'll E-mail Mike again since he probably knows. But this seems so close!
 
daver2 said:
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
Click to expand...

I am wondering if the CPU is actually bad or if the 8008-1 has some incompatibility. I'll have to investigate at some point, but NOT NOW.
 
I just found a post on Mike's blog about this. Apparently the only known version IS for TTY. The scopewriter variant is lost media.
So why then is my SCELBI trying to output to port 11?!?
 
Unfortunately right after that last post, address 7 got stuck and I've been debugging that for hours because god forbid I have even a functional system. :(
 
It's not the CPU because swapping that out doesn't change anything. If I have the CPU out, I can remove any card with no effect aside from the CPU card and the DBB card, so that tells me it's likely on one of those cards.

The DBB data path for D7, which connects to the light on the front panel, is here:
1750216427601.png
And on the CPU card it's here:
1750216464470.png

Curiously, if I remove Z3 from the CPU board, it's still stuck high. But without Z3 and the CPU, there's nothing to drive a high signal here.

Also, I do note that Z9 on the DBB board is controlled as follows:
1750216611351.png1750216639575.png
Pin 13 is tied to Z15 pin 12, which is the D3 signal for some reason. I was wondering if maybe D3 wasn't switching, so C wasn't going high, but this isn't the case.
All logic chips in the D7 path check out. I believe it's the same for D3.

The pull-downs on the CPU board seem to be fine. I used diode check on my meter and they all read the same forward voltage. I did not desolder them from the board, but I did check with Z3, Z1 and the CPU removed so they were pretty isolated.

It's just wild. And I have no clue why this happened. But it's super frustrating because I finally felt like I had hope of having everything ready for VCF and now I'm back to spending all my free time debugging this. It's miserable. I do really appreciate the help though! I do want to make that clear. Thank you!
 
Yeah, you're not gonna guess what it was. I decided to probe the output ports for shorts because I'd been messing with them for the serial thing and I couldn't think of anything else and I was desperate. I found a short between pins 8 (D7) and pins 10 (sync). Yeah that was the entire issue. I cleared the short. (Honestly IDEK where it was, I just kinda pushed wires around back in that rat's nest) and now the short is gone and now it works again. THANK GOD. I was really starting to crash out and even if I don't get serial working I need this to at least be somewhat functional.

I want to share the joy of this system this weekend, not the pain.
 
I fussed a little bit more with trying to get serial working. Again, I know output works because I tested it. That includes the strobe signal (I mixed up which pin was sync and which is probe in my last post, my bad) It seems like the program is working and I can see it respond to my keypresses, so it's getting input. On the scope, I can see the data being sent from the output. I can even see that a strobe signal is being sent. I just don't know where. But software shows port 11 which is odd.

Anyway, I'm done for the night. I'm going to change gears and clone my DOS drive for my IBM and clean it up for VCF then go to bed. If I get the missing link in this thread or from Mike, I'll give it a go. Or if I manage to have free time I might check on some stuff. Otherwise I'll just exhibit it with instructions for the front panel and let it be that way. My ambitions (For this event) went from SCELBAL to MEA to just the front panel. Oof.
 
From my information, the port assignments are as follows:

1750234178212.png
INPUT port is 5.

OUTPUT port is 16 (octal) = 14 (decimal).

Where do you get your software port 11 from - and what base are you counting in (octal, decimal, or what)?

The oscilloscope interface uses output ports 10 and 11 (octal) and the ASCII keyboard interface uses output port 12 (octal).

Which output strobe pin did you observe operating in response to the input?

I see there is a pin on XA03 (pin BU - signal name OPSN). Is that connected to anywhere? This pin appears to have the potential for disabling the OS0 through OS7 and OS10 through OS17 strobe outputs. I can't actually see this pin mentioned anywhere in the construction manual wiring.

Note that the teletype requires both a data output (wired to the 7475 IC Z2 pin 2 from connector pin AX) and a clock output (wired to the 7475 IC Z2 pin 13 from connector pin AY) - both on the teletype interface board. The AY pin should come from the output strobe and the AX pin should come from the CPU data bus.

You can also choose the output polarity by the use of a link (link 1-2 OR 3-2) on the teletype board. One (or the other) of the links have to be installed.

There are corresponding links on the receiver half of the teletype interface also.

Dave
 
Last edited:
Ah, octal. Duh

Eithed way I was using physical output port OUT6, which should be correct.

Port 11 I read in decimal. So 13 octal. When doing an output operation, the port that is used for output is displayed on the page LEDs and the data is displayed on the address LEDs per the SCLEBI-8H user manual, so that's where I got that number. I can double check this or try moving the out down a port because this seems suspiciously close to what it should be. One off.

OSPN is essentially what I was probing to see that something was getting strobed while then program was being executed. I measured either R37 or R42 on the DBB right after it gets inverted. So I presume it's controlled somewhere but I'd have to see where. I also ran OUT 16 (135 octal) through the front panel and observed the pulse on the strobe line at the serial board. (Which to confirm is indeed hooked up)

Specifically for the RS232 peripheral, I am using Mike's design which is software compatible with the type 33 teletype interface. Though I've packaged it in the style of a SCELBI card/interface. I have verified that all connections are the same as his circuit, and in the process now understand how it works. Although I'll have to go back and check if I got any pins wrong. I know at least one unused control signal is mislabeled in my schematics. But it's all connected properly in my system.
 
Switching to that port didn't work.
Also FWIW, serial settings I'm using:

110 Baud
Parity = None
Data Bits = 8
Stop Bits = 2
Flow Control = None

I derived these from this slide deck.

Also I just reconfirmed, 13 octal for the port per the page lights.
 
OPSN is a common signal to all of the strobe outputs. Which strobe is actually changing is determined by the LOW active logic output from either Z11 or Z12.

Also consider that the TTY firmware generates the serial bit stream itself, so this is dependent upon the CPU clock frequency and the firmware delays.

The board that you have contains a 7474 - so that should have a strobe (feeding the clock input of one of the internal gates) AND a data input (feeding the D input of the same gate). as stated in my previous post - you need bothe clock (strobe signal) and the data input for the transmitter to work.

Dave
 
Last edited:
Yeah it seems the 7474 latches in the data on the strobe signal and then the MAX202 reads that data for serial.

From running the OUT 16 command I was able to see the strobe coming to the 7474 so that part is connected. I just don't see the strobe while the program is running. At least not on that pin.

Per baud, I did see the data coming into the 7474 was much faster than 110 baud, but I'd want to see what comes out of the MAX202 once we have a strobe to see exactly what baud rate I need.
 
I was thinking probing the inputs to Z12 would be difficult (especially four at once) but I see there are pull-ups I can hook to. So I'll give that a go. Space is cramped between the boards so some probe angles are not great.
 
If you have a 2-channel oscilloscope, monitor pins 2/3 or 12/11 of the 7474 (depending upon which flip/flop internal gate is used).

Pins 2 or 12 is the data input and pins 3 or 11 is the clock/strobe input.

You HAVE to see signals on both pins of the 7474 - the clock/strobe latches in the data signal that is passed on to the RS232 transmitter buffer. If one is missing, you will get nada...

Dave
 
I probed A-D on Z12 (I was already doing this prior to your last comment)
So top channel is D and bottom channel is A.

1000023347.jpg

1101 and 1111 are both invalid and should set all outputs to high.

For OS6, which is OUT6, (confirmed in the assembly manual. It's not supposed to be OS16) we'd want to see pin 7, which us BCD 9 go low. This ends up being 1001

I had yesterday probed both data and strobe at the serial interface on the scope and only saw data. No strobe. So the 7474 is not getting a strobe signal.

EDIT: Corrected order as shown on scope. Also for Z11, you can invert channel D, so it'd be 0101 or 0111 depending. Which means out 5 or 7 which is pins 4 or 6 which is OS13 or OS15. OS13 matches software. Also based on the pulses it makes more sense.

So why are we strobing a port that's not even connected?
 
Last edited:
The 'D' input to Z11/Z12 will be such that either they are both disabled (D=1 in both cases) or only one (either Z11/D=0 OR Z12/D=0).

I would, therefore, expect to see D toggling on your oscilloscope trace above.

As to why it is Z11 = 0101 = 5 = pin 6 = OS15?

I suspect when the B input goes HIGH (x111), I would have expected the D input to have gone high at the same time (or OS17 would be selected).

I am getting different OSnn signals to you though...

Dave
 
Hold on, as a sanity check:
Here is the strobe wiring:
1750255362883.png
Here are the output port and socket numbers:
1750255407008.png
1750255421812.png
Combined:

1750255862552.png

So, OUT6 is SK13 which should be wired to A21 on the DBB which is OS6. Even though it's output port 16 which should be pin AY. But also instead we're seeing port 13 strobed which would be pin AV on the DBB which should go to OUT2, but actually OUT2 goes to A17. Confusing.
 
daver2 said:
The 'D' input to Z11/Z12 will be such that either they are both disabled (D=1 in both cases) or only one (either Z11/D=0 OR Z12/D=0).

I would, therefore, expect to see D toggling on your oscilloscope trace above.

As to why it is Z11 = 0101 = 5 = pin 6 = OS15?

I suspect when the B input goes HIGH (x111), I would have expected the D input to have gone high at the same time (or OS17 would be selected).

I am getting different OSnn signals to you though...

Dave
Click to expand...

That is a good point about D. It may be 1 for both Z11 and Z12. I did not check to be clear. So ti may be 1101 for Z12 too for all I know. I could probe that too to see.
What do you mean exactly by getting different OSnn signals? Thanks!
 
>>> What do you mean exactly by getting different OSnn signals?

Your post (#75) identifies OS13 or OS15.

My post (#76) identifies OS15 or OS17.

The output port numbers are a bit strange on the 8008...

Input ports are numbered INP 0 to INP 7 (8008 CPU instruction set).

Output ports are numbered OUT 8 to OUT 31 (8008 CPU instruction set). The number base here is DECIMAL. In OCTAL these are OUT 10 to OUT 37. Not all of these ports exist within the SCELBI though.

OUT 6 does not exist!

However, the assembler (or whatever) may convert OUT 6 into out 16 under the hood?

If you look at the 8008 instruction set:

Code: 
INP = 0100MMM1
OUT = 01RRMMM1

Where MMM is the port number (for input ports) and RRMMM is the port number (for output ports) where RR cannot be 00 (as this would code for an input port!).

In the MEA manual you can see the discrepancy with the output port being described as both 16 and 6:

1750257405655.png
Dave
 
Yeah, so "OUT6" in the MEA manual refers to how the chassis is labeled.
ciarcias-8h.jpg

This example is from the SCELBI registry. Aside from some obvious modifications, it should show that labeling well enough. Note the layout diagrams I referenced in my last post are actually upside down.

So OUT6 as labeled aligns with output port 16 per that diagram. Socket 13.

So I guess then if we start at octal 10, then it makes sense that OUT6 is output 16. So I guess that makes sense sorta? Then the SCELBI-8H manual shows instructions for output 6 but it's probably the 8008 instruction for output 16.
 
You must log in or register to reply here.
Back
Top