Note that this is a challenging project and at this point, documentation is not organized. You can download schematics and SCELBI documents from scelbi.com. Documentation is sparse, a few notes scattered among the MEA and SCELBI sales documents. My blog contains some of what I have learned, but not all of it.

The oscilloscope digital card requires rework, which is documented (incorrectly at this point) on my blog. I needed to make changes to the keyboard interface to make my PS/2 keyboard adapter work, and I’ve bypassed a resistor on the oscilloscope analog board in order to make blanking work better with my Tektronix 465. All that said, as far as I can tell at this point, the boards do match the original SCELBI designs.

Software is a work in progress. I’m working on the MEA compatible EPROM code this week. It will be quite different than the example code that I posted on my blog a few days ago.

Cost is $75 for the set of three boards.

I you are not in the USA, add $15 for international shipping.

Send email to mike@willegal.net for more information

I had to change resistor R33 on the analog board to 0 ohms in order to make blanking work reasonably well, but it’s still not perfect. Your mileage may vary depending upon the exact scope that you connect to this interface. I’d like to move onto focussing on getting some real software working, but I have one more significant issue to resolve. I think that the loading of the latches off the data bus is a little flakey, which is causing some flickering of the display. I also have to investigate the artifact at the top of the screen a little more.

In case you are interested, here is the driver that was used to generate the display in the picture. Keep in mind that it is a very much a work in the progress.
oscope-keyboard driver

Still an artifact at the top, and I frequently see some dots flash on the screen (not seen in this image), but I’d say I”m almost there.

I had a couple of issues that had to be solved to get to this level.

The big one was that I had inverted the logic for displaying vectors. I had programmed ones in the registers to display lines and zeros to suppress vectors. The problem with that logic was that all the vectors that repositioned the cursor to the next position were enabled with this logic. I had to invert the output and use zeros to turn on vectors. Once I fixed this, I could easily adjust my Tektronix 465 to suppress vectors that were not to be displayed.

The second issue was that my rework instructions were wrong and had pins 1 and 3 swapped on Z3. This kept vector B2 enabled all the time.

Next step is to add the keyboard driver and check the vectors that I have programmed for the other characters and make sure the remaining lines and columns look OK.

I reversed the Y axis connections and tweaked the software some more.

This picture demonstrates that one remaining issue is related to the Z Axis. First 5 characters on first line are supposed to be starburst, space, A, Z, 0 and 9.

Seems like hooking the Z axis to my scope with a 10x scope probe causes a lot of latency in Z axis display, due to RC delay in the Z. The lag causes a line to be displayed, to actually not show, but the next line will show. Changing the probe to 1X causes Z axis to completely not function. Could be my Tektronix 465 isn’t compatible with the SCELBI design. I’ll have to investigate both the scope and the SCELBI O-scope implementation in order to find a good fix.

I finally took the time to figure out why the Oscope Y axis is upside down. It all stems from an error in the schematics.

If you look closely at this cropped image of the schematic, you will notice that pin 4 of the Y axis op-amp is labelled (+) while pin 4 of the X axis op-amp is labelled (-). Both can’t be correct, as op-amps all have a negative and positive input. Here is the pinout of the SN72741 from the TI data sheet showing that the correct labelling of pin 4 should always be (-).

The X and Y, plus and minus inputs to the analog board come directly from the digital board. If you look look at the digital and analog board schematics, the X and Y outputs match up nicely with the analog board inputs.

Xp is pin B-W on the digital board and connects to pin W on the analog board

Xm is pin B-Z on the digital board and connects to pin Z on the analog board

Yp is pin B-Y on the digital board and connects to pin Y on the analog board

Ym is pin B-X on the digital board and connects to pin X on the analog board

There is an image showing how I connected them in a previous blog post. Pins W, X, Y and Z are to the far right in the following image.

Overall, it looks like a very clean solution. The problem is that the mislabelling of pin 4 and pin 5 of the Y axis op-amp caused the Y inputs to also be labelled backwards on the analog card schematic. Therefore, Y plus is really connected to Y minus and visa versa. The solution is to cross the connections for Y plus and minus between the digital and analog boards.

I would have to assume that this swapping was done when constructing the original SCELBI Oscilloscope Interfaces, but I don’t have access to an original unit to confirm. The images I have, don’t show the connections between boards, so I can’t go on that. I would also assume that the intention of the design was to make connecting the boards easy, and if enough units were built, that Y minus and Y plus would be swapped on the PCB, so that connecting the digital to analog board, would be more straight forward. My guess is that so few oscilloscope cards were made, that this change was never made.

Fortunately, I’m pretty sure that I will be able to swap these connections, without dissassembling the entire Oscilloscope Interface.

Here, I finally have multiple lines of star bursts displayed.

My problem was that I had the input port data bus hooked up wrong. When I connected it, I assumed that the edge connector would be wired from data bit 0 to data bit 7 in order, but that wasn’t the case. I also had to turn off the invert switch on the scope. The problem with inverted characters will have to be investigated further.

I also have a good understanding of adjustments for Horizontal Width (R10), Horizontal Speed Balance (R6), Vertical Speed Balance (r17) and Tilt (R20). The speed balance adjustments are necessary to make sure that movements left and right are at the same speed and movements up and down are at the same speed.

I still need to figure out what’s happening at the beginning of each line and at the beginning of the page.

The driver implementation is being investigated. It promises to be a serious challenge to fit it in 256 bytes, as half of it will be taken up by an ASCII to 2 byte output table.

The SCELBI Scope project is not revealing it’s secrets easily. With some tweaks of the pots and some new software I now have a line of star bursts. Dumping the entire pre formatted buffer in one shot seems like the way to go. I inverted the display by using the invert button on my oscilloscope. I’ll look into the implementation more thoroughly later on.

It looks a bit better in real life. Next step is to figure out how to make multiple lines work. The software I wrote is supposed to print 5 lines, just like the MEA manual says it supports. One page is reserved for the scope output buffer. With 2 bytes per displayed character, 20 characters per line and 5 lines, that takes up 200 bytes. Right now, I’m automatically adding 2 extra bytes per line for the LF and end of page functions. That brings buffer consumption up to 210 bytes.

It’s going to be a real challenge to fit the software for the both the scope and keyboard displays in 256 bytes. Currently almost half of the 256 bytes is consumed just by the ASCII to a 2 byte code table in my implementation. I do think that with some clever coding, I should be able to free up a few bytes from that table and I’ll probably need it.

Read the article in the previous post in order to get an overview of the Oscilloscope Interface design. Here is an expanded image of a single starburst character as my implementation currently stands.

This is clearly not what is desired in displaying text, but you can see how the scope is attempting to draws a starburst image. In order to make more sense of what was happening here, versus what I thought the design should do, I drew a series of lines over the top of actual image.

The software writes two bytes “A” and “B”, which controls which lines are “on” and which ones are “off”. The line starts at line “A0” and proceeds to draw through “A7”, then B0 through B7. A0 represents bit 0 of the first byte, A7, bit 7 of the first byte. B0 through B7 represent the second byte. NA represents lines that are never “on”, those lines are simply used to reposition the cursor in order to draw the next line. For purposes of debug, I had all lines turned on for this image.

Next I moved the arrows to match what is seen on the oscilloscope.

This technique clearly revealed two big issues, and a few smaller ones.

The first major problem is that the Y axis is inverted versus what was expected. I’ll have to investigate hardware connections to clearly understand what is going on with that. It could be as simple as incorrect hookup between the digital and analog board, or perhaps an incorrect analysis of the design. In any case, this can be handled by reversing line segment assignment in order to flip the characters.

The second issue is apparent without the process of analyzing the drawing sequence. That is the bright spot to the right of the character. That problem is actually due to the software algorythm used to draw a series of characters. An ASCII character is sent to a lookup routine that searches through a table of characters in order to find the matching bytes that must be sent to the “A” and “B” registers of the digital board. Once the lookup is complete, the 2 bytes are written to the digital board. The problem is that the scope is stuck on a single spot while the lookup is done. Even though the “Z” input should dim the scope, it isn’t turned all the way off. The solution to this problem will be to look up all the text and create a buffer of all the data to be sent to the “A” and “B” registers. That should avoid burning in one spot.

The other problems are uneven and tilted lines. I’m hoping that this can be eliminated though carefull adjustment of the variable resistors on the analog board. I’ll discuss this further in a future post as I work through those issues.

The good news with all this analysis, is that it is clear that the majority of the hardware must be working correctly in order to display this much of the starburst, as distorted as it is.