Over the weekend, I started work on the SCELBI O’Scope PCB layout. There are two boards that make up the package, a standard size analog board, and a double width digital board. The standard size analog board looks like it will be pretty easy to layout. However the double width digital board looks pretty complicated. It has 35 chips, and around 220 VIAs. By comparison, the Apple II, rev 0, which has to be the most complex PCB that I have recreated has about 380 VIAs. The chip count is the second most for any SCELBI board. It trails behind the 4K SRAM board, which has 37, 32 of which are SRAM chips. All the SRAM chips on a SRAM board are connected the same way, which simplified things quite a bit on that board.

Image of the Inside of the O’Scope Interface at the Computer History Museum (courtesy Jack Rubin)

The good news is that, so far, I haven’t run across any components that will be excessively difficult to find.

Another complication on the digital board, is that I only have three good images of two different O’Scope boards. The front and back of one board, and the front view of a second. The board that I have front and back views of, has quite a bit of rework on it. I don’t know if these are design issues or customer modifications. It will be interesting to sort through these changes and see if there are any differences between these two boards.

The final challenge will be figuring out the details of the power supply that is integrated into the O’Scope chassis. At this point, all that I have to go on, is a picture. When you put everything together, the SCELBI O’Scope interface turns out to be far more complicated than many single board “trainer” type computers.

The keyboard interface layout is complete. I have done design checks and have a quote in hand. I probably will not order boards until the O’Scope layouts come together, or at least until they get further along. I think of the keyboard and O’Scope boards as kind of a matched set, the keyboard for input, and the O’Scope for display output. One, without the other is kind of a half solution, though I will be able to test them out independantly.

I think this version has some significant improvements that bring operation, look and feel to a new level. Besides incorporating some support for teletype, front panel and cassette “sounds”, a help system has been added that should provide enough support for even a novice to be able to boot a SCELBI to the MEA monitor prompt.

Check it out at http://www.willegal.net/scelbi/scelbiapp.html

If you like what you see, let me know. If you have ideas for more improvements or discover issues, input is always welcome.

While putting the finishing touches on a new version of my OS/X SCELBI app, I spent some time porting over the classic Lunar Lander game program to SCELBAL. I started with the version from a 1978 edition of “BASIC Computer Games” by David H. Ahl. I bought my edition of that book back in 1978, along with my Apple II.

BASIC Computer Games

I remember trying to type in a game from this book, the first night that I had the Apple II, only to almost immediately run out of memory. I initially purchased a 4K Apple II system, and only about 2K was usable by BASIC, so it didn’t take much to exceed it’s memory capacity.

Anyway, back to the present. I found porting Lander to SCELBAL was pretty easy. I had two issues.

While working on this, I wondered if there was a single number solution for Lunar Lander. Using a simple binary search mechanism and multiple copies of the SCELBI app, I was able to determine that with 6 digits of precision allowed by SCELBAL that there isn’t a single number that can be entered every time and result in a safe landing. The closest I could get is a burn rate of 76.4386, which results in a crater only 33.83179 feet deep. Entering a number of 76.4387 results in an out of fuel situation, as the lander just misses landing before proceeding to accelerate upward after which it runs out of fuel and then comes crashing back down.

As far as releasing an updated SCELBI app, it is in pretty good shape and I should be releasing it within the next week. I’ve taken advantage of a holiday break from work in order to make significant improvements and revisions and I think this version will be a vast improvement over the last release.

Oh and here is a link to the ported version of Lunar Lander.

I’m really excited to be able to release version 2.2 because of it’s capabilities. After several years of on and off effort, this version is good enough to completely support all the features of MEA, SCELBI’s 8008 software development environment.

You should be able to develop and test 8008 applications without ever leaving this application. In addition, the audio files it reads and writes are completely compatible with the actual SCELBI cassette tape interface hardware. This means that you can transfer object and source files back and forth to real SCELBI hardware with ease.

Read more about it on this webpage

The MEA manual can be downloaded from scelbi.com.

Instructions for operating the front panel, which is necessary to boot MEA can also be found at scelbi.com.

To start MEA, you must toggle a JUMP to location 060-000 with the front panel.

I’ve recently encountered some issues assembling the small program that I use for checking out MEA on my SCELBI 8B. 1702 EPROMs are notorious for “forgetting” data and my first thought was to verify the contents of those EPROMs.

Since the cassette write function still worked, it turns out that the verification process is pretty easy. Here is what I did.

1) I captured the contents of the MEA proms (060-000 to 077-377) to an audio AIFF file on my PC by connecting the audio output of the SCELBI to the mic in port of the PC. This assumes that the MEA cassette driver/utility to write the data out still works.
2) I converted the audio file to an Intel hex file using the utility that I had previously written.
3) I used an UNIX shell program named “diff” to compare this new INTEL hex file with the one that can be found at scelbi.com

What I found, was a couple of errors in the EPROM at page 73. I removed this EPROM from the PROM board, reprogrammed and verified it. After reinserting the EPROM and board, assembly of my little test program, once again, worked as expected.

As far as part 3 goes, I actually did a couple of additional verification steps by loading my OS/X SCELBI emulator with the Intel hex image converted from audio tape format and verifying that assembly of my test program also failed in that environment. I then dumped contents of suspicious memory locations with my emulator loaded with a good version of MEA and compared to dumps executed on the real SCELBI to confirm that those locations really had problems. Those extra steps aren’t strictly necessary, but helped confirm the issue, before I started the process of pulling boards and chips.

Note that I didn’t erase or use a new EPROM in this repair, but simply overwrote and verified contents of the existing EPROM with bad data. It will be interesting to see if these locations act up again in the future.

The whole repair process, including the extra verification steps and updating my ME1702 programmer with new firmware, probably took an hour or so. This was one of the easier vintage repairs that I’ve experienced, at least in recent memory.

First of all, much to my surprise, the layout for a reproduction SCELBI keyboard interface is nearly complete, well ahead of schedule. I’m not sure when I’ll pull the trigger on getting boards made, as I think it really needs to be used in conjunction with the oscilloscope interface or something similar.

Using the interface with many vintage keyboards may present a bit of a problem, as it was designed to interface with the keyboard design in the April 1974 issue of Popular Electronics magazine. The basic interface design is described in the first SCELBI Computer Digest, which can be found at Cameron Cooper’s scelbi.com website. The PE keyboard is unusual, in that it is ASCII decoded, but does not latch data. This means that data is only present while a key is actually pressed, or shortly thereafter (the keyboard circuit has a RC network that will hold data for a little while). This is why the SCELBI keyboard interface has latches incorporated into it.

Since there is no latching of data on the PE keyboard, the actual latch mechanism on the SCELBI interface is triggered whenever data is actively being sent by the keyboard. This will not work with keyboards that have onboard latches, since they present data to the interface all the time. Some kind of modification with have to be made for interfacing with those kinds of keyboards. This is not a huge problem, but will require some additional thought.

Of course, a more interesting solution would be to build a reproduction PE style keyboard to go with this interface. I couldn’t entirely rule out the possibility of taking on that project sometime in the future, but first I’m going to finish the few remaining SCELBI boards that are begging to be built.

Cassette Rub-on Lettering

Though I still have to add a protective clear coat, it looks like a successful trial. You can get your sheet by contacting averyschroeder@mac.com at drytransfer.com. Since the film/plate is already made, the price should be $32 for a 4×6 1 color (black) sheet. You will have to tell him that this is the same sheet that Mike Willegal had made. I can’t make guarantees, but I think this sheet should have enough transfers to make a couple of complete SCELBI systems.

After trying a couple of different items for burnishing the transfer, I ended up using a cheap ball point pen.

New TTY Enclosure

After I clean the leaves off of the yard, I should be able to finish the TTY enclosure. I have been wiring the edge connectors first, labelling the wires with port and pin. After the edge connector is wired, I can put it in position, cut wires to final length and solder to the input and output ports. I think this works pretty well.

With this enclosure, the port for the TTY device exits from the reverse end. Here is a view of bundle of wires that will be routed out that end of the enclosure.

TTY Enclosure Reverse View

Cassette Interface Hooked Up

I have my reproduction cassette boards mounted in the enclosure and functioning. I still have the adjustment and read LED holes to drill and lettering to do. I have rub on lettering ordered and should have it in about a week. If it works out well, I’ll provide ordering information from the vendor, and you will be able to order directly from them. I made use of some white space and added lettering for keyboard interface, power supply and oscilliscope interface to the sheet.

A couple of hints on construction/assembly and wiring of the cassette chassis. The brackets are mounted about 2/3″ back from the end of the chassis. It’s a pretty tight fit in there. Mount the edge connectors on the brackets, but don’t connect the brackets to the chassis. Connect wires to the edge connectors. Then feed the wires through the holes in the panel and cut to length and solder to the connectors. Power and ground lines all go to the power and ground connections on the edge connectors. Power and ground of the two edge connectors are bussed together.

The cable to the cassette tape recorder is only four wires. They are write, read, and two ground wires. Both ground wires connect to pin 11, read is pin 1 and write is pin 2. Tie-wrapped to the outside of this cable are the 2 wires for the motor on/off control. I think that SCELBI might have used the same 4 conductor cable that was normally used for connecting the power supply to the main chassis for this application.

I’m still working on perfecting my silk screen making technique for the front panel. I’m determined to get to the point where I can get near professional quality results. Unfortunately I still have some learning to do.