What we have here is a complete, original operating SCELBI-8B. It includes 12K SRAM, 4K EPROM loaded with MEA, a TTY interface, a cassette interface and on the right, an extremely rare SCELBI factory power supply.

I was asked by the owner of this system to get it working and I agreed to do the job. After setting it up, the only problem I could find was a bad smoothing capacitor on the five volt power supply. I will write up the power supply diagnostic process in a future blog posting.

I ran SRAM tests, and a number of applications on this system, including most of the features of MEA as well as SCELBAL. The owner was concerned about EPROM contents, so I wrote an EPROM verification program, which it passed with flying colors. Once the power supply was fixed, the system ran these diagnostics and applications in several sessions covering several days without a single glitch. SCELBI’s usually are pretty reliable machines and this one was no different.

By the way, I will be posting the EPROM verification program at some point on my 8008 application page.

However, there has been one snag. After I returned the system to owner, he reported that it didn’t work. The symptoms sound exactly like the original power supply problem, so I hope that this can be resolved relatively easily.

I really tend to shy away from doing repairs for the reason that a lot can go wrong while shipping an old system around the country. For example, quite a few years back, I repaired an Apple II, rev 0 motherboard which had three different faults. By the time it got back to it’s owner, a forth fault occurred. Even though I did this repair as an experiment and didn’t charge the owner anything, he appeared quite annoyed with me. Fortunately, in that case, based on the symptoms, I was able to correctly guess the root cause of the forth failure and get that machine running again, without having to ship it again.

Despite the challenges associated with repairing old computers, getting a chance to get an original 8B running and document it was too exciting to pass by. Though I have heard of one or two other original SCELBI-8Bs that partly work, this is the only one that is completely working, at least that I know about

Well it’s actually not working at this instant, but I’m certain that with a little more effort, it will be running, again.

I managed to test the version of MCMON for Digital Group Video card on real hardware, but there was a bit of drama involved. I started seeing corrupted characters when running Hangman with this card. From the beginning it looked like a memory issue.

First, I ruled out the problem being in the SCLEBI system memory by stopping the program and examining the local copy of the video buffer which looked correct. Then I took some time to isolate exactly what was wrong with the Digital Group Video Card memory. After closely examining the symptoms and running some simple tests, I determined that the most significant bit of video memory had a problem with adjacent locations. In other words, if I wrote MSB of address 0 to zero or one, then MSB of address 1 would also change to the same value. Same thing happened when writing to address 1. This was true of all pairs of memory locations where the upper six address bits (of seven) were the same.

The problem was finally tracked down to a pin that wasn’t soldered which left this address line floating. This turned the 256 bit SRAM chip in that location into a 128 bit chip. Adjacent memory locations were sharing the same data in this chip, accounting for the error.

I didn’t see this problem when testing a full array of characters displayed on the screen or when running MCMON because in those cases all adjacent characters share the same value of the MSB.

With this problem resolved, I was able to verify that Hangman with Digital Group video drivers worked correctly. This software can now be downloaded from my 8008 application page.

My MCMON (8008 mini-monitor) with Digital Group Video support can be downloaded from my MCMON page.

This version adds support for the Digital Group Video Board, as well as a ported MCMON monitor for the 8H that works with that interface. The following image is a screen shot of the app, showing the DG Video screen displaying an MCMON prompt.

This application is freely available for download from my web site.

I’m having a bit of trouble with the Apple Help system, but in case it is not working for you, you can also access the help pages from my web site.

The I/O port mapping for this emulator can be found on the Menu Options page of the help system.

The Digital Group Video Board interface for SCELBI has been one of the longest Vintage Computer projects I have been involved with. You wouldn’t think that fairly simple video card would involve so many different sub projects, but it has been quite an interesting challenge.

That said, I’m not quite done with it, as I still have to put together a nice demo application. That application is planned to be a port of SCELBI hangman. I have started flowcharting the video output software, but have a little ways yet to go.

The final section of the MPS-10 gives some comparative cost estimates for several solutions. The comparisons are with a PDP-8/M.

http://www.willegal.net/blog/wp-content/uploads/2020/01/MPS-10-cost-performance.pdf

One interesting thing to note here is that the PDP-8/M solution, though it is more expensive, isn’t orders of magnitude more expensive. It seems to carry a 50% cost disadvantage.

So finally, here is the entire document in one PDF.

http://www.willegal.net/blog/wp-content/uploads/2020/02/logic-products-MPS-10-plan.pdf

Here is where this document really looks more like a product plan more than anything else. This section starts with a statement of availability of prototypes on March ’74 and production unit in June ’74. It follows with statements that no field service will be offered and a warranty period of 90 days. The lack of field service is due to the expectation that the customer will be technically capable, the relatively low cost of the product and high cost of field service contracts.

The next page contains a product promotion and support plan. It mentions several trade magazines, was well as a direct mail campaign. I checked several of the periodicals mentioned and couldn’t find any relevant MPS-10 ads, so I don’t know if they came out later or exactly what happened.

The documentation plan is mentioned, as well as some trade shows.

Given this extensive marketing plan, it is somewhat surprising that so little is known of the MPS-10 today.

The competition section might be the most interesting to vintage computer hobbyist. Among other architectures, the National IMP16 series is mentioned. The IMP16 is classified as a microprogrammed machine, rather than a fixed instruction set, as the 8008 and 8080 and a few others are classified as.

On the next page are listed a number of competitive systems made up from the previously listed microprocessors. Except for the the Microl and Sim-8, most of these systems are little known by the vintage computer hobbyist of today.

There is a chart showing features of the various systems, including the all important development tool support. This section is definitely worth review by the vintage computer hobbyist.

http://www.willegal.net/blog/wp-content/uploads/2020/01/Pages-from-MPS-10-marketing-plan.pdf

The lettering on the front is made with water slide decals printed with a laser printer. After applying, several coats of satin lacquer were sprayed on to protect the lettering.

There is only one edge connector for this double wide card. I decided this wasn’t enough support so I added those red blocks seen towards the bottom of this image. The small card on the upper left hand corner is used to latch the SCELBI output.

In a way, this is a project that doesn’t want to end. I still have to get some kind of demo application going and update my OS/X emulator to support this card. I’ll probably do the later, first, as it is easier to debug with the emulator than on the real system.

In an addendum to my previous post, I noted that I had MCM6571A instead of regular MCM6571. It seems like the A part is easier to find than the regular part, so I decided to hack the board to support the A part, while I look around for a non-A part. Here’s an example of the resulting video output after the hack.

These parts have the same character set, but the row decoding goes up from 0 to 8 on the A part instead of from 14 down to 6 on the regular part.

Fortunately, on the DG video card, row input to the MCM6571 is entirely from the four outputs from the 74193 at U9. The 74193 supports counting down or up as well as configurable preloads. So all you need to do to support the “A” part is count up instead of down and reconfigure the preload, preload trigger and carry out to the next 74193. This can all be done without extra gates.

The standard DG card counts down from 15 to 2 and then restarts the count using the gate at U-22. To make the circuit work for the “A” part, I choose to reconfigure the counter to count up from 0 to 12. This is one less sweep of horizontal per line of characters, but it doesn’t seems to affect vertical hold on the terminal that I am using and it prevents the last line of text from being too “low” on the screen and puts the lines a little closer together for a slightly more pleasing display.

The carry over to U-10 occurs on the rising edge of the most significant bit of the the counter. This happens when the count goes from 2 (binary 0010) to start over at 15 (binary 1111). To make the circuit work for the “A” part, I choose to use the inverted version of the most significant bit, so it carries over when the output goes from 12 (1100) to 0 (0000).

Here is the wiring list needed to make this change. I choose to put the 74193 in an extra socket to make the rework easier. The way I made this change, it is completely reversible and requires no cuts to the PCB, so when I find a non-A part, I’ll be able to retrofit it to this board with minimal effort.

• Remove the 74193 at U9 from the PCB and insert into a spare 16 pin socket with the following legs lifted:1,4,5,9,10,15
• the following two steps change count down function to count up
• Connect pin 4 of the 74193 to the socket pin 5
• Connect pin 5 of the 74193 to the socket pin 4
• the following step changes the preset from 1111 to 0000
• Connect pins 1,9,10,15 of the 74193 to the socket pin 8
• the following two steps changes the reset from a value to 2 to a value of 12
• On the 7410 at U-22 lift pins 9 and 10
• Connect pin 9 of the 7410 at U22 to U9, pin 7 (it can be connected to a convenient via near the MCM6571 that leads to U9, pin7)
• Connect pin 10 of the 7410 at U22 to U9, pin 6 (it can be connected to a convenient via near the MCM6571 that leads to U9, pin6)
• the last step inverts the carry input to the 74193 counter at U10
• Lift U10, pin 5
• Connect pin 5 of the 74193 at U10 to U17, pin4

Now all I need to do is to get some kind of demo application running and update my Macintosh SCELBI app to support emulation of this new SCELBI capability.

If anyone wants one of these reproduction DG video boards, cost will be $50 each, with free shipping in USA, $10 shipping outside the USA. Send me an email if you are interested.

I’m making some progress on the Digital Group video card debug, but it has been a bit more difficult than I expected. First I had to connect it to my SCELBI and write a short program to test it with. Here is the test setup.

I needed to add an 8 bit latch in order to latch the SCELBI output port. This was easily accomplished with 2 7475 four bit latches and a bread board that I had in my parts bin. If I was thinking ahead, I would have added it to the PCB that contains the +5 volt to + 12 volt converter. Now I’m going to have to add another board to the final chassis design in order to hold the 8 bit latch.

The 5 volt to 12 volt converter is resulting in 11.96 volts at the MCM6571. That is nearly spot on, so it looks like that effort has paid off. One other thing to keep in mind when wiring the power for peripherals on the SCELBI, it’s pretty important to avoid ground loops and run power and ground directly back to the power supply. It’s tempting to use the ground wire on the peripheral cable, but it’s best not to do that.

Debug has been a bit slow, and I found a couple of assembly mistakes on the PCB. First, I put capacitor C8 in the wrong holes which caused problems with the R/W output of U-23. The second mistake was forgetting to solder the ground pin of the 6571 character generator. I also had a bad 74193 in the circuit that was used for writing to video memory. In this build, I used sockets, so testing and replacing the 74193 was pretty easy.

The documentation suggests that a user could use a second output port and directly address video memory, rather than use the counter solution. Given that there usually is no shortage of output ports on the SCELBI, this might make a better solution for the SCELBI. It would be fairly simple to replace the two 74193 counters with 7475 latches in order to achieve this.

During this process I wrote two short programs for debug. The first one puts the same character in every location in memory. This was helpful when I was having trouble writing to memory. Putting the same data in every location made it easier to tell whether writes to the 1101 memory were working or not.

000 000 ORG 002 000
002 000 016 000 STRT, LBI 000
002 002 006 301 CONT, LAI 301
002 004 161 161
002 005 044 177 NDI 177
002 007 161 161
002 010 010 INB
002 011 301 LAB
002 012 074 000 CPI 000
002 014 110 002 002 JFZ CONT
002 017 000 HLT
002 020 104 000 002 JMP STRT
002 023 END

The second program writes every possible character to the screen memory.

000 000 ORG 002 000
002 000 016 200 STRT, LBI 200
002 002 301 CONT, LAB
002 003 161 161
002 004 044 177 NDI 177
002 006 161 161
002 007 010 INB
002 010 301 LAB
002 011 074 177 CPI 177
002 013 110 002 002 JFZ CONT
002 016 000 HLT
002 017 104 000 002 JMP STRT
002 022 END

These programs were both short enough that I just toggle them in through the front panel, rather than worry about setting up a TTY or scope and run MEA or MCMON.

The display with the second program loading up memory with a range of characters currently looks like this:

So the good news is that the horizontal and vertical sync is looking pretty good. In fact, given my concerns about the PCB layout, the video is downright crisp, much better than the Apple 1 or Apple []. I’m pretty impressed. The bad news is that the characters are all displayed upside down and clipped at the bottom. I’ll have to figure that out in my next debug session.

UPDATE: I just figured out that my reversed character problem is that I’m using a MCM6571A part which has a different/reversed decode when compared to a regular MCM6571. With character generators, you have to be careful about versions of the part and I guess I didn’t pay enough attention in this case.