RC2016/10 -- Happy, Happy, Joy, Joy!

After several hours of wrapping wires, I completed the wiring of my COSMAC ELF replica. At that point, I flipped it over and stuffed the various parts into the sockets. The ICs installed without problems, while the discrete components required a little bending and trimming to fit into the sockets but were not really a problem. Two 0.1" jumpers (a.k.a. "shunts") were required by the design yet not included in the package, but luckily the local Radio Shack is still in business and had them in stock. With everything in place, I attached the battery, flipped the switch, and...nothing happened! Now what?

Follow The Process

The exact procedure for loading code in to the COSMAC ELF is not entirely intuitive, so I reviewed all of the available information to ensure that I was following the correct process. Convinced that I was trying to do the right things and yet still not getting any results, I broke out the schematics and started my analysis...

After basic circuit "first aid" like checking power and ground lines and ensuring that the clock was ticking, I started trying to isolate specific bits of functionality on the board to make sure that flipping switches was sending the right signals to the correct pins on the CPU. While poking around, I found that the output of one of the inverters did not change when it was supposed to change. A bad chip? Well, not so fast...

Chip Test

Long ago I picked-up an EPROM programmer that includes the ability to test logic chips, including a variety of 74xx and 40xx chips. I took advantage of this piece of kit by testing the 40106 chip that seemed to be producing the wrong output. Oddly enough, the chip worked fine in the tester! I took the precaution of testing most of the other logic chips on board, all of which proved to be working fine. Hmmm...

The culprit...

Circuit Inspection

Reassured that the chips were working fine, I refocused my attention on the possibilities of bad wiring. Not surprisingly, I found one wire out of place. Despite having checked along the way during construction and further checked all the connections afterwards, one wiring mistake had escaped detection. Oh well, at least it was just the one!

With that one wire removed and replaced correctly, the machine is working! Too bad I don't have any COSMAC ELF software lined-up for Halloween. But for your amusement, I have included my recreation of the classic COSMAC ELF construction photo above... :-)

Anyway, this project is mostly done. I'll probably still wire-up the expansion port and maybe secure a few bits here and there with some hot glue or something in the near future. Hopefully there will also be some bigger and better ELF or RCA1802 projects in the future as well. But no matter what, I hope that you will continue to stay tuned!

RC2016/10 -- Wiring Complete

October is winding-down, and with it the Retrochallenge RC2016/10 event. As we round the last turn and start the sprint to the finish, how are things going? Well, not too bad -- the birth of my new COSMAC ELF is coming along well... ;-)

Wiring Wrap-Up

As predicted, learning the skill of wire wrapping was not without its hardships. I think I have achieved basic competency at this lost art, but I am still far from comfortable with the technique. Just as I settle into the groove of things, usually I will hit a run of a dozen premature wire breaks in a row or something equally frustrating to the builder. Nevertheless, the directions provided in the VCF ELF kit and a little patience and diligence have allowed me to complete the basic wiring for the new machine.

Just before wiring the toggle switches...

Pre-Flight Check-Up

With the wiring completed, it is tempting to charge ahead to power-up! However, prudence demands some basic testing be done, lest one enjoys the smell of "magic smoke". Using the audible continuity checker on a multimeter, I ensured that the pins at each end of every node were connected. Testing between the outside pins of a node is a shortcut to prevent walking pin-to-pin testing for continuity at ever point along the way. This shortcut should be fine...hopefully... In my hubris, I have neglected to do any sort of extensive checking for short-circuits -- wish me luck?

Stuff-N-Go?

At this point, there is little left to do but to stuff the parts into the sockets on the board and apply power. Considering the risk of shedding tears at that point, I may delay a day or two just to ensure that I have had a chance to remember anything I might have forgotten! I need to line-up some simple ELF programs to use for testing as well. But really, at some point we must proceed...

There is only so much time left in this competition and little excuse not to proceed at least until power-up. Whether that turns out well or not, I suspect that I will see this project through one way or another. If you are reading this, then I imagine that you want to see this ELF in action...well, stay tuned!

RC2016/10 -- Halfway @ Half-time...

So it turns-out that walking through a wire-wrapping project isn't as thrilling as one might imagine. Hopefully the end of the project will enable new COSMAC adventures, but the steps along the way are mostly a 'lather, rinse, repeat' sort of process -- one wire after another, for dozens or hundreds of wires. But it has enabled me to build the paleotechnical skill of wire wrapping, allowed me to exercise my engineering sense to discover a mistake in the docs I was provided, and introduced me to some new friends on the Internet.

Some Progress

Building Skills

This project is my first time using wire wrap as a construction technique. While the process seems simple, it is not without its pitfalls. Cutting the wires to the proper length requires some expertise, as does proper placement of the wire in the wrapping tool, and proper use of the tool to minimize wire breakage. Good judgment about wire routing and proper use of wire colors also contributes to project success. I am reasonably pleased with the project so far, but I can only imagine that more practice will yield some improvements. As it stands, I am not completely convinced that this technique is in any way better than point-to-point construction with solder...

From PIN6 of IC1?

Finding Mistakes

The documentation included with my VCF ELF kit contained a wiring list for use while building the kit. This list includes each individual wire, grouped by circuit node. Each node's list reads something like "from A to B; from B to C; from C to D". As I reached the node for the /LOAD signal, I saw something more like "from A to B; from B to C; from D to E" -- notice the disconnect? That made me check the schematic, which made it clear that the wire list was wrong. But what is right?

The wire list showed the next to last wire as ending at "PIN6 of IC11", and the last wire as starting at "PIN6 of IC1" -- notice the similarity? Checking the schematic confirmed that starting the last wire at "PIN6 of IC11" makes sense, so I went with that. Later I found that there was an updated wire list at the VCF ELF website which confirmed my correction.

New Friends


For years I have been a member of the COSMAC ELF and 1802 Microcomputing Yahoo group. Until now, I have had little reason to actually interact with the individual members. I was curious about the RCA1802 and the COSMAC ELF, but I didn't have any hardware to use. Now I'm building this kit, so I made the members of that group aware of the project. So far they have been friendly and responsive, taking a healthy and welcome interest in my project. It's always good to make new friends!

More Progress

As I write this, the month of October is almost halfway over. That means half of the RC2016/10 event is over, and half still remains. Will I finish my build? Will it work at the end? If you want to find out, then I guess you will just have to stay tuned... :-)

RC2016/10 -- A Good Start...

So, I've been a bit slow with my updates -- I could blame the extra duties involved with running the contest, or I could just blame laziness.  Which one is more believable? :-)

Setting-Up

Before any wires can be wrapped for the VCF ELF, some preparation needs to be done. The base platform for the wiring is a piece of "perfboard", which serves as a framework for holding the sockets and other parts in a fixed physical configuration. In order to facilitate placing the various parts, the kit creators included a paper template that is designed to be laid on the back of the perfboard. This identifies the location of each part and explicitly labels the numbering of each pin, making this information available from the back (where it is needed when wire wrapping). In addition, the bottom of the template folds back over the front of the perfboard to provide some simple graphics for the "console" area of the board. This was a great idea, but...

Check The Scale

Laying the printed paper template provided with the kit down on the perfboard that came with the kit revealed a problem -- the paper was not printed at exactly 1:1 scale! Since the paper was ostensibly designed to match the physical layout of parts exactly, this rendered the paper template a bit useless. Fortunately, the kit creators have made the template graphics available as a PDF at their site. I was able to print a new copy of the template, this time at the correct scale. Using this template I was able to get started with placing parts on the perfboard.

Fit And Finish

With the template in place, I started poking socket pins through the perfboard and the paper template. I added the side rails, and continued placing most of the parts necessary for the wire wrap process. The only real problem for me was making space for the toggle switches.

Toggle switches are used for a variety of purposes on the VCF ELF. These purposes include turning the machine on and off, enabling the memory protection circuitry, and controling execution of the program on the machine. Most prominently the row of switches at the bottom are used for entering addresses and data while loading programs. Unfortunately, all those toggle switches need holes drilled for mounting them...

Drilling the holes is no big deal per se -- just drill the hole! Even "good enough" alignment with the spaces allocated on the paper template is reasonably easy to do. However, aligning holes for eight switches in a row is a bit too much for my skills with a hand-held drill. I would like to think that I might have done better using a drill press...maybe... Anyway, I got the holes drilled. Alignment is less than perfect, but that won't effect the operation of the device!

Overall, the assembly process was relatively simple and a necessary step. Nevertheless, it did take most of my available time for the first day of work -- I failed to anticipate the prep time! At least at this point I was ready to move onto the real wire wrap work. If you wanna hear more about that, then I guess you'll just have to say tuned...

Retrochallenge 2016/10 entry -- VCF-ELF!

I have had a soft spot in my head (or is that heart?) for the COSMAC ELF ever since I first learned of it years ago. The wire-wrapped construction, the front panel switches, the blinkenlights -- what's not to love? We won't even mention the..."unusual"...architecture of the CPU... :-)

COSMAC Proportions

Anyway...I managed to win a VCF-ELF kit in the auction at VCFMW 11, so now this seems like the perfect project for Retrochallenge 2016/10! I've done plenty of electronics projects in the past, including retro computer builds. But, I've never done any wire-wrapped builds until now. This should be fun...wish me luck!

Cool Runnings

In other news, I have taken-on the task of actually running the Retrochallenge 2016/10 event (and probably the future events as well). Don't worry, I won't declare myself the winner unless everyone else is just lame! Plus, Michael Mulhern from the Retro Computer Roundtable will be assisting in the judging duties -- I'm sure Michael will help to keep me honest... :-)

Using A Receipt Printer With The CoCo/MC-10

In Episode 9 of The CoCo Crew Podcast, Neil and I discussed the role of printers in the retrocomputer hobby. For some reason this became one of our most popular segments! We continue to get comments and requests for information about printers and how to make use of them with the CoCo and MC-10...

Upon Receipt

Around that same time, I developed an interest in receipt printers. These thermal printers are a popular target for various microcontroller and "Maker"-style hacking projects, partly because they are readily available through eBay and other surplus vendors. The continued use of such devices in retail also ensures a ready supply of paper to feed them. The fact that many such printers feature an RS-232 serial interface is just icing on the cake! The Epson TM-T88III M129C is just such a device...but not all of them have RS-232 serial ports!

Having acquired a receipt printer with a serial port, I set about to connecting it to my MC-10. This is somewhat trickier that it sounds, since the MC-10 (and the CoCo) redefine the usage of the pins on the serial port depending on whether one is talking to a printer or to a modem, as explained here. With the proper cable in place, there is still the matter of setting the communications parameters, particularly the baud rate. The settings for the printer are handled by setting DIP switches internal to the device, while setting the baud rate used by the internal ROM routines on the CoCo and MC-10 involved setting a value in memory (i.e. "POKE 16932,10" for 4800 baud on the MC-10, or "POKE 150,7" for the same speed on the CoCo).

With the correct cabling and speed settings, printing almost works! Unfortunately, the printer and the CoCo/MC-10 don't agree on what constitutes the end of a line of output. This not only causes delays when printing small amounts of text, it also causes the output itself to be formatted incorrectly.

Hook Me Up

In the distant(?) past, there was some disagreement about how to indicate the start of a new line of text (a.k.a. "newline") in an ASCII-encoded file. In the days of the teletype, "carriage return" (CR) represented physical movement of the print mechanism to the left edge of the paper, while "line feed" (LF) represented moving the paper vertically down to the next line of text. These two functions generally go together, making some folks feel that having two characters to represent one action was redundant. Therefore, some systems used just the CR, some used just the LF, and others continued to use both. The CoCo and MC-10 are in the "CR-only" category, while the receipt printer requires both CR and LF to process a newline.

What needs to happen is to change Color BASIC to output an LF immediately after any CR is sent to the printer. But Color BASIC is in the ROM! How is this possible? Well, it turns-out that the writers of Color BASIC were smart enough to identify several places in the ROM where it seemed potentially useful to let other software take control and modify Color BASIC's behavior. These are called RAM hooks, and there are a number of them. One such hook gets called whenever a byte is output by Color BASIC. We just need a little assembly language program to insert an LF after a CR is sent to the printer, and a way to hook it into Color BASIC...

The CoCo assembly language program looks like this:

DEVNUM  equ        $006f

        pshs       b            save B reg
        ldb        DEVNUM       load device number
        incb                    increment for testing purposes
        puls       b            restore B reg
        beq        exit         if device number == -1, then exit
        bpl        exit         if device number >= 0, then exit

        cmpa       #$0d         is output a CR?
        bne        exit         if not, then exit
        jsr        $a2bf        send CR to line printer
        lda        #$0a         change original CR output to LF

exit    rts                     return from RAM hook

While the MC-10 version looks like this:

DEVNUM  equ        $00e8

        tst        DEVNUM       test device number (only 0 or -2)
        beq        exit         if device number == 0, then exit
       
        cmpa       #$0d         is output a CR?
        bne        exit         if not, then exit
        jsr        $f9c9        send CR to line printer
        ldaa       #$0a         change original CR output to LF

exit    rts                     return from RAM hook

The assembly language program itself is fairly trivial. It checks the output  device number for a value of "-2" (which represents the printer). If the device number is "-2" then it checks for a CR. For an output value other than CR or for any output device value other than "-2" it simply returns having done nothing. For a value of "-2", the program proceeds to output the CR to the printer, then modifies the output value to LF and allows the program to proceed to output an LF as well.

BASICly Done

The BASIC program that installs the assembly code is a bit more complicated. It starts by determining the highest address in use by the BASIC interpreter. It then uses the CLEAR command to adjust that address downward just enough to leave space for the assembly language program described above. The CLEAR command wipes-out any existing variables, so the program then proceeds to again determine the highest address used by BASIC and saves that information for later. At this point, the BASIC program takes the opportunity to set the printer port baud rate as required by the printer, and to send a reset command sequence to the printer.

At this point the program POKEs the assembly code into memory just above BASIC. Then it pokes the address of the start of the assembly program into the 2nd and 3rd bytes of the character output RAM hook. Finally, the value for a JMP instruction is POKEd into the 1st byte of the character output RAM hook, activating the character output hook program. Now the printer will work with Color BASIC!

Here is the CoCo version of the BASIC code as described above:

10 MT=256*PEEK(35)+PEEK(36)
20 SB=256*PEEK(33)+PEEK(34)
30 SS=MT-SB : NT=MT-21+1
40 CLEAR SS,NT
50 MT=256*PEEK(35)+PEEK(36)
60 EX=MT+1
70 POKE 150,7
80 PRINT #-2,CHR$(27)+"@"
90 PRINT #-2,CHR$(10)
100 FOR OF=1 TO 21
110 READ IN
120 POKE MT+OF,IN
130 NEXT OF
140 EH=INT(EX/256):EL=EX-256*EH
150 POKE 360,EH
160 POKE 361,EL
170 POKE 359,126
180 DATA 52,4,214,111,92,53,4,39
190 DATA 11,42,9,129,13,38,5,189
200 DATA 162,191,134,10,57

And, here is the MC-10 version:

10 MT=256*PEEK(161)+PEEK(162)
20 SB=256*PEEK(155)+PEEK(156)
30 SS=MT-SB : NT=MT-15+1
40 CLEAR SS,NT
50 MT=256*PEEK(161)+PEEK(162)
60 EX=MT+1
70 POKE 16932,10
80 LPRINT CHR$(27)+"@"+CHR$(10)
90 FOR OF=1 to 15
100 READ IN
110 POKE MT+OF,IN
120 NEXT OF
130 EH=INT(EX/256):EL=EX-256*EH
140 POKE 17033,EH
150 POKE 17034,EL
160 POKE 17032,189
170 DATA 125,0,232,39,9,129,13
180 DATA 38,5,189,249,201,134
190 DATA 10,57 

Those little programs may not look like much, but they sure are handy for giving the CoCo or MC-10 a modern-ish printer that can be fed with off the shelf paper. Plus, they allow for lots of interesting printer output to be driven by Color BASIC rather than having to do it all with assembly language. Not bad for some eBay shopping and a little bit of BASIC code!

This little project has been fun, and I think it could lead to more. These little printers have some cool capabilities, including various graphics capabilities and some point-of-sale features. Maybe we can explore those in the future? If you want to see what comes next then I hope that you will continue to stay tuned!

SEGA Genesis Joypad Adapter for CoCo3

In earlier posts on this blog, I have covered a couple of options for building a digital joystick to work with the Tandy Color Computer (i.e. CoCo) or for hacking an existing controller for the same purpose. One complaint I receive is that people want to use their existing (either purchased or home-built) digital controllers without having to modify them for use with a CoCo. Fear not -- there is a solution! Just read on...

Design Basics

This joypad adapter design is fundamentally based upon the design described in "Atari Joystick Adapter" on page 135 of the February 1984 edition of Color Computer Magazine. The direction signals are identical between the "standard" 80's-era Atari joystick and the later SEGA joypads, so an identical circuit handles both types of controllers with regard to direction control.

Schematic blatantly "borrowed" from vrai.net -- thanks!

The schematic above shows a single button (labelled as "F") with a "straight-through" connection. That works fine for the single button on an Atari joystick. When using a CoCo3, a 2nd "straight-through" connection will handle use of the 2nd button on a SEGA Master System controller as well. Unfortunately, SEGA Genesis (aka Mega Drive) controllers complicate matters...

Genesis Buttons

The hardware used to multiplex the buttons on the Genesis joypad does not merely pull-down the button signal.  Instead it drives the signal either low or high depending on the state of the button presses. This works fine for the Genesis where presumably the button lines are not shared for any other purpose. But on the CoCo, those lines are also used when scanning the keyboard. Using a "straight-through" connection to a Genesis controller will cause some keys on the keyboard to appear "dead" (i.e. unresponsive). Adding reverse-biased diodes in-line with each button signal will prevent the Genesis controller from driving the lines high, thereby avoiding any interference with the keyboard scan on the CoCo. The circuit continues to work fine with Atari joysticks and SEGA Master System controllers as well, of course.

More Is Better

The CoCo3 only supports two buttons on its joystick inputs, so we could stop here. But a little research reveals that the Genesis controller only uses two lines for button inputs, and a third line to drive a multiplexer that switches between B/C and A/Start. If the CoCo3 could drive that multiplexer, then the CoCo3 could also read those extra buttons!

The only easily accessible digital output on the back of the CoCo is the "Transmit" line on the RS-232 serial port. That signal is not electrically compatible with the input to the Genesis controller's multiplexer, but a simple circuit using an NPN transistor and a couple of resistors can condition the CoCo's RS-232 "Transmit" line suitably for the multiplexer. Now the CoCo3 can select the active button pair with the equivalent of a "POKE 65312,0" or "POKE 65312,2". This allows the CoCo3 to read all four buttons on the Genesis controller.

If you are interested in more technical details, please refer to the schematic online.

A dual-joypad version of this adapter was produced and built by my podcasting partner Neil Blanchard.  He had it available for sale at CoCoFEST!, and he continues to take orders for them by email. This device uses the design described above and will support use of all of the buttons on the standard "3-button" SEGA Genesis joypad on the CoCo3. I believe these items have sold well, so now there is a "critical mass" of these items out in the community waiting to be used effectively. Hopefully we all can think of ways to make use of 3 action buttons (plus Start) in a CoCo3 game -- what will you write?  What will I write? Well, stay tuned...