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.

Analog Schematic Error

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 (-).

SN72741 Package

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.

Digital Board X and Y Outputs

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.

Edge Connectors Wired

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.

Multiple Lines with SCELBI Oscope Output

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.

One Line of Star Bursts

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.

SCELBI O-scope Drawing

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.

Expected Oscope Display

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.

Oscope Display Trace

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.

Last year, Paul Robson sent me this document, describing how he thought the SCELBI Oscilloscope Interface worked.

SCELBI Oscilloscope Interface Description

Paul’s reverse engineering efforts turned out to be right on the money. Having this document has helped me substantially with software design and bring up of real hardware.

There are some aspects to the design that I will elaborate on in future posts. Some parts of Paul’s document will not be obvious to some novices, even though they are described well enough in Paul’s document for many people to understand. Also, I’ve discovered some practical limitations to the implementation, as I go through physical hardware bring up that need further elaboration.

Astronomer use the phrase “First Light” when they use their telescopes for the first time. I decided that turning on my SCELBI Oscilliscope interface on for the first time is, in a sense the same kind of event, so I’m borrowing the astronomer’s phrase. I’ll bet some followers of my blog figured that I’d never get around to hooking this interface up, but they would be wrong.

Here is the test setup. I’m using my reprodution SCELBI 8H, and the “scope”, (not pictured here) is my Tektronics 465.

SCELBI Oscope Test Setup

I wrote a simple test driver that should have repeatedly printed two lines containing “ABC”. This is what I saw when I ran it.

SCELBI O-Scope Interface First Light

The bad news is that this is unintellegible. The good news is that I’m getting signals on both X and Y outputs. The Z output has no signal. Next step will be to figure out if this is a hardware, software or adjustment issue or combination of these.

The 1N5355 helped with the -18voltage, but the positive voltage still was too low. I resolved the positive voltage by changing the dropping resistor down to a value of 20 ohms. I also connected the center tap of the transformer secondary to the ground. With these three changes, the positive and negative 18 volts seem pretty stable.

However, my next problem is that the second channel on my Tektronix’s 465 oscilloscope has become intermittent. Looks like something is wrong on the vertical preamp board. A few hours of debugging hasn’t revealed any obvious component fault. Seems like an intermittent connection somewhere close the input jack is the culprit. I can’t very well test the SCELBI oscope interface until I get both channels working again, so I’ll have to keep working on it.

I’ve now created a few posts about the little split power supply that is used to power the SCELBI Oscilloscope Analog board. Here is another, and most likely, not the last.

After wiring the chassis and powering it up I found the positive side of this supply was 4 or 5 volts low with both digital and analog boards installed. After spending a few evenings fooling around with it, I decided that the main part of the problem probably is the relatively high zener impedance of 45 ohms of the BZX79C18 zener that I had installed in the circuit. I believe that the zener’s impediance is dominating the voltage regulation, not the zener effect. I’ve decided to try an alternate part, the 1N5355, with an impredance of 2.5 ohms. Hopefully it will work better for this application.