Not long after the previous article, someone asked me about making the ROM cartridge loading technique work on a BASIC program written specifically for the CoCo3. Although the issue hadn't occurred to me before that, I immediately suspected that the existing technique would not work in that situation. A little experimentation revealed that to be true...
What's The Deal?
I knew that the CoCo3 had a more complicated boot process than its predecessors. The CoCo3 boot-up involves copying code from ROM to RAM, patching some existing BASIC routines, and adding some new ones designed to take advantage of CoCo3 hardware enhancements. I also knew that to preserve some compatibility with the original CoCo and the CoCo2, ROM cartridge programs were given an environment that looked much more like those earlier machines. In other words, the ROM cartridge environment doesn't get access to the CoCo3 extensions to BASIC. So, a BASIC program written specifically for the CoCo3 won't work with the ROM cartridge environment as our existing technique would try to use it.
Finding The Solution
Understanding the CoCo3 boot process requires some understanding of the actual code in the CoCo3 ROMs. This could be done the hard way, manipulating the CoCo3 registers to expose the actual ROM contents, dumping those contents, then analyzing them with f9dasm or some other disassembler. In this case, however, that work has already been done for us in the Unravelled Series. Referring to Super Extended Basic Unravelled II gives a good disassembly of the code in question and some useful commentary as well.
I had never had cause to look so closely at the CoCo3 boot sequence. I was confused and believed that the Color BASIC and Extended BASIC ROMs in the CoCo3 were essentially untouched from the CoCo and CoCo2 equivalents, and that the CoCo3 ROM got control in a chained fashion similar to how Disk Extended BASIC gets control from Extended Color BASIC. This misunderstanding led to some initial puzzlement until I was able to clear-up the situation in my mind.
In reality, there are some changes to the original Color BASIC and Extended BASIC ROMs that are actually burned into the hardware, as detailed by Super Extended Basic Unravelled II. Among these changes, the startup code is changed to transfer control to the CoCo3 ROM early in the boot process. This code then copies the BASIC ROM contents to RAM and patches the code as required for the CoCo3. After this is done, the patched ROM code (now in RAM) is entered and BASIC initializes itself. Late in this process the cartridge autostart sequence is enabled. When the cartridge autostart is detected, then the CoCo3 re-enables the ROMs and jumps to the code at the start of the cartridge.
The point here is easy to miss -- the CoCo3 has already initialized itself, including copying its patched BASIC code to RAM. But then it purposefully turns-off access to the RAM with the patched code in favor of accessing the ROM with the more-or-less original CoCo2 BASIC. It's no wonder that CoCo3 BASIC programs won't run!
As an experiment, I hacked-together a simple BASIC-in-a-cart program that would run and then exit. From there I verified that by default, I could not access CoCo3-specific BASIC commands (e.g. HSCREEN). But if I executed the POKE to turn-off the ROMs and re-enable the RAM first, I could access the CoCo3 BASIC commands with no problem!
New Loader
So now we must consider modifications to the "loader" program. My first thought was to add the equivalent of the required POKE as an assembly language instruction in the program. But that won't work -- since the loader is executing from ROM, swapping-out the ROM for whatever is in RAM at the same address after the swap will almost certainly cause the CPU to do something weird, foolish, or just wrong. What we really need is a way to execute the POKE after the "loader" has already executed, but before the BASIC program is RUN...
BASADR EQU 7680
ORG 49152
LOADER LDA #85 SET WARM RESET
STA 113
LDD #32960 SET EXTENDED BASIC RESET VECTOR
STD 114
JSR 47452 SET UP PARAMETERS FOR BASIC
LDA #53 RESTORE INTERRUPTS
STA 65283 THAT ARE
LDA #5 DISABLED ON
STA 65315 CARTRIDGE AUTO START
BASIN LDX #BASLOD
LDY #BASADR THIS IS LOAD ADDRESS OF BASIC (S)
STY 25 SAVE IT IN BASIC START
INC 26 CORRECT THE ACTUAL START VALUE
TNSFER CLRB SET END COUNTER TO ZERO
TNSFR2 LDA ,X+ GET FIRST BYTE FROM ROMPAK
STA ,Y+ TRANSFER BYTE TO BASIC RAM
BNE TNSFR2 NON ZERO DATA, KEEP TRANSFERRING
ENDCHK INCB ZERO DATA DETECTED, INCREMENT COUNTER
CMPB #3 IS THERE 3 CONSECUTIVE ZERO'S?
BEQ LODDON IF YES, STOP TRANSFER
LDA ,X+ LOAD NEXT ROMPAK BYTE AFTER ZERO
STA ,Y+ TRANSFER BYTE TO BASIC RAM
BNE TNSFER NON ZERO DATA, RETURN TO MAIN LOOP
BRA ENDCHK ZERO DATA, INC COUNTER, STAY IN LOOP
LODDON STY 27 SAVE END ADDRESS FOR BASIC
STY 29 SAVE VAR START AT END OF TEXT
STY 31 SAVE ARRAY START AT END OF VAR/TEXT
AUTRUN LDX #733 BASIC LINE INPUT BUFFER
LDD #$504f LOAD CHARS "PO"
STD ,x++
LDD #$4b45 LOAD CHARS "KE"
STD ,x++
LDD #$2648 LOAD CHARS "&H"
STD ,x++
LDD #$4646 LOAD CHARS "FF"
STD ,x++
LDD #$4446 LOAD CHARS "DF"
STD ,x++
LDD #$2c30 LOAD CHARS ",0"
STD ,x++
LDA #$3a LOAD CHAR ":"
STA ,x+
LDD #21077 LOAD LETTERS "RU"
STD ,X++
LDD #19968 LOAD "N" AND END
STD ,X++
LDB #17 INDICATE 17 CHARACTERS
CLRA
STA 112 SET CONSOLE IN BUFFER FLAG
LDX #732 POINT TO LINE INPUT BUFFER
JMP 44159 START MAIN BASIC LOOP
BASLOD EQU * BASIC PROGRAM DATA STARTS HERE
FCB $00
END
Wrap-Up
As you can see, the solution is a bit clever -- just add the POKE to the same line of BASIC input that causes the program to RUN! Aside from that, the process is the same as described in the earlier blog post -- enter the BASIC program, save the in-memory image of the program to emulated cassette, extract the file, append it to the assembled "loader" program above, burn it to an EPROM, and use that in a cartridge. I used Robert Gault's PALETTE.BAS program as a test subject for the technique described, and it works perfectly for me.
For now, I'll leave the actual BASIC conversion work as an exercise for the reader. Perhaps in the future I will seek permission to post converted versions of PALETTE.BAS or some other BASIC programs, along with pre-assembled "loader" images both for the CoCo/CoCo2 and the CoCo3. If you want to see that, then for now you'll just have to stay tuned...
Tuesday, August 15, 2017
Friday, August 4, 2017
Color BASIC Program On A Cartridge?
Wow! It's been a while since I posted on this blog. I guess the podcast has been keeping me busy, among other things. Anyway, I'm back for now so let's talk about something cool and retro... :-)
Games On Cartridge
Those of you familiar with my Fahrfall project will recall that I ultimately packaged Fahrfall as a ROM cartridge, one of the available mechanisms for distributing software for the Tandy Color Computer (aka CoCo). I even went so far as to produce silicon molds and to cast cartridge cases made of plastic resin for that project. For me, no other means of distributing software seems as cool and "retro" as using a ROM cartridge, and I am very pleased with the results of that project. Nevertheless, producing resin cast plastic cartridges was not without its problems.
3D-printed plastic projects are 'all the rage' these days, but 3D-printing still has plenty of its own problems: filament is expensive, surfaces usually have visible texture marks, the layered construction often leads to "delamination" and other structural problems, and printing times are so long that bulk production runs become at least impractical. With these issues in mind, some time ago I partnered with Boisy Pitre and Mike Rowen to produce injection-molded cartridge cases for the CoCo. These cases are beautiful, strong, and despite considerable setup costs fairly cheap in large quantities.
Having produced a large number of cartridge cases, my partners and I have explored a variety of ways to market them to the community. My preferred approach is to wrap cases around software releases, and I have done so with Fahrfall and a number of other titles both from myself and from others. To date all of these titles have been written either in assembly language or C, resulting in machine language programs running directly from ROM on the CoCo. But many CoCo authors are skilled in Color BASIC (Extended or otherwise).
BASIC Games Too!
Ultimately, ROM is just another storage medium. So, it should come as no surprise that a BASIC program could be distributed on a ROM cartridge as well. No version of Color BASIC supports loading programs from ROM, so a little trickery is required to make the CoCo aware of the program stored in ROM. So, what has to be done?
Long ago there was a web page called "Paul D's CoCo Pages". This was nearly lost after Yahoo bought GeoCities, but fortunately an archive exists. The page in question describes a technique for loading a BASIC program from a ROM cartridge. Boisy and I had also sought advice from Robert Gault on this topic, and he proposed a technique that was substantially the same. I had some trouble replicating the procedure described on the "Paul D" page, but below I'll summarize what worked for me.
Extraction Procedure
Start with loading the BASIC program on the CoCo. Then you will need to determine the start and end of the RAM used to store the actual BASIC program itself in memory:
Now you will need to save that as a memory image (i.e. not as a normal BASIC program). Here I will presume that one is using an emulator and capturing the CSAVEM to a file called cartprog.cas:
CSAVEM "CARTPROG",S,E,0
Now on the machine running the CoCo emulator, we will use the cecb comand from the Toolshed project to extract the binary image file of the CoCo's memory:
cecb copy -2 -b cartprog.cas,CARTPROG cartprog
Building the ROM Image
The Color BASIC ROM will jump to the beginning of cartridge ROM as part of the machine's initialization. We need to put some machine code there to do the job of loading the BASIC program. The assembly language program I am using for this task is shown below. It is based upon the loader program shown on the original "Paul D" page, but with some minor changes to suit my way of working:
BASADR EQU 7680
ORG 49152
LOADER LDA #85 SET WARM RESET
STA 113
LDD #32960 SET EXTENDED BASIC RESET VECTOR
STD 114
JSR 47452 SET UP PARAMETERS FOR BASIC
LDA #53 RESTORE INTERRUPTS
STA 65283 THAT ARE
LDA #52 DISABLED ON
STA 65315 CARTRIDGE AUTO START
BASIN LDX #BASLOD
LDY #BASADR THIS IS LOAD ADDRESS OF BASIC (S)
STY 25 SAVE IT IN BASIC START
INC 26 CORRECT THE ACTUAL START VALUE
TNSFER CLRB SET END COUNTER TO ZERO
TNSFR2 LDA ,X+ GET FIRST BYTE FROM ROMPAK
STA ,Y+ TRANSFER BYTE TO BASIC RAM
BNE TNSFR2 NON ZERO DATA, KEEP TRANSFERRING
ENDCHK INCB ZERO DATA DETECTED, INCREMENT COUNTER
CMPB #3 IS THERE 3 CONSECUTIVE ZERO'S?
BEQ LODDON IF YES, STOP TRANSFER
LDA ,X+ LOAD NEXT ROMPAK BYTE AFTER ZERO
STA ,Y+ TRANSFER BYTE TO BASIC RAM
BNE TNSFER NON ZERO DATA, RETURN TO MAIN LOOP
BRA ENDCHK ZERO DATA, INC COUNTER, STAY IN LOOP
LODDON STY 27 SAVE END ADDRESS FOR BASIC
STY 29 SAVE VAR START AT END OF TEXT
STY 31 SAVE ARRAY START AT END OF VAR/TEXT
AUTRUN LDX #733 BASIC LINE INPUT BUFFER
LDD #21077 LOAD LETTERS "RU"
STD ,X++
LDD #19968 LOAD "N" AND END
STD ,X++
LDB #4 INDICATE 4 CHARACTERS
CLRA
STA 112 SET CONSOLE IN BUFFER FLAG
LDX #732 POINT TO LINE INPUT BUFFER
JMP 44159 START MAIN BASIC LOOP
BASLOD EQU * BASIC PROGRAM DATA STARTS HERE
FCB $00
END
This program is assembled and a "raw" format image is produced, called "loader"...
lwasm -9 -l -f raw -o loader loader.asm
The BASIC program image "cartprog" is concatenated with "loader" to produce the data for programming into the cartridge ROM:
cat loader cartprog > eprom.dat # DOS/Windows command differs
How Does It Work?
Once the auto-start cartridge is detected, Color BASIC transfers control to the loader program listed above. The "loader" program performs some simple initializations for the Color BASIC interpreter before proceeding to copy the BASIC program to the CoCo's program memory. This includes setting the start address of the BASIC program.
The "loader" program starts reading from the location labeled BASLOD. There it will read the value zero as shown, and it will write it to the location defined by BASADR. After the first zero, "loader" continues with the next location which will correspond to the first value from "cartprog". The sequence of reading and writing byte-by-byte continues until 3 consecutive zeroes are read. This corresponds to the end of the BASIC program. (The original "Paul D" version looks for 4 zeroes, but AFAICT that is incorrect.) At this point, the end address of the BASIC program (and the end addresses for BASIC variables and arrays) is set for the Color BASIC interpreter.
Finally, the "loader" program manipulates the keyboard input buffer used by Color BASIC in order to force a "RUN" command to be executed immediately. Then, control is transferred to the Color BASIC interpreter and the loaded BASIC program is now executed.
So, there it is -- a BASIC program loaded from a ROM cartridge on a Tandy Color Computer. Now Color BASIC programmers can publish their programs on ROM cartridge, with all of the prestige, durability, and collector value that entails. That includes ROM cartridges with extra hardware, like my CoCo Games Master Cartridge. But that is another story -- you'll just have to stay tuned!
Games On Cartridge
Those of you familiar with my Fahrfall project will recall that I ultimately packaged Fahrfall as a ROM cartridge, one of the available mechanisms for distributing software for the Tandy Color Computer (aka CoCo). I even went so far as to produce silicon molds and to cast cartridge cases made of plastic resin for that project. For me, no other means of distributing software seems as cool and "retro" as using a ROM cartridge, and I am very pleased with the results of that project. Nevertheless, producing resin cast plastic cartridges was not without its problems.
3D-printed plastic projects are 'all the rage' these days, but 3D-printing still has plenty of its own problems: filament is expensive, surfaces usually have visible texture marks, the layered construction often leads to "delamination" and other structural problems, and printing times are so long that bulk production runs become at least impractical. With these issues in mind, some time ago I partnered with Boisy Pitre and Mike Rowen to produce injection-molded cartridge cases for the CoCo. These cases are beautiful, strong, and despite considerable setup costs fairly cheap in large quantities.
Having produced a large number of cartridge cases, my partners and I have explored a variety of ways to market them to the community. My preferred approach is to wrap cases around software releases, and I have done so with Fahrfall and a number of other titles both from myself and from others. To date all of these titles have been written either in assembly language or C, resulting in machine language programs running directly from ROM on the CoCo. But many CoCo authors are skilled in Color BASIC (Extended or otherwise).
BASIC Games Too!
Ultimately, ROM is just another storage medium. So, it should come as no surprise that a BASIC program could be distributed on a ROM cartridge as well. No version of Color BASIC supports loading programs from ROM, so a little trickery is required to make the CoCo aware of the program stored in ROM. So, what has to be done?
Long ago there was a web page called "Paul D's CoCo Pages". This was nearly lost after Yahoo bought GeoCities, but fortunately an archive exists. The page in question describes a technique for loading a BASIC program from a ROM cartridge. Boisy and I had also sought advice from Robert Gault on this topic, and he proposed a technique that was substantially the same. I had some trouble replicating the procedure described on the "Paul D" page, but below I'll summarize what worked for me.
Extraction Procedure
Start with loading the BASIC program on the CoCo. Then you will need to determine the start and end of the RAM used to store the actual BASIC program itself in memory:
A=PEEK(25)
B=PEEK(26)
C=PEEK(27)
D=PEEK(28)
S=256*A+B
E=256*C+D-1
Now you will need to save that as a memory image (i.e. not as a normal BASIC program). Here I will presume that one is using an emulator and capturing the CSAVEM to a file called cartprog.cas:
CSAVEM "CARTPROG",S,E,0
Now on the machine running the CoCo emulator, we will use the cecb comand from the Toolshed project to extract the binary image file of the CoCo's memory:
cecb copy -2 -b cartprog.cas,CARTPROG cartprog
Building the ROM Image
The Color BASIC ROM will jump to the beginning of cartridge ROM as part of the machine's initialization. We need to put some machine code there to do the job of loading the BASIC program. The assembly language program I am using for this task is shown below. It is based upon the loader program shown on the original "Paul D" page, but with some minor changes to suit my way of working:
BASADR EQU 7680
ORG 49152
LOADER LDA #85 SET WARM RESET
STA 113
LDD #32960 SET EXTENDED BASIC RESET VECTOR
STD 114
JSR 47452 SET UP PARAMETERS FOR BASIC
LDA #53 RESTORE INTERRUPTS
STA 65283 THAT ARE
LDA #52 DISABLED ON
STA 65315 CARTRIDGE AUTO START
BASIN LDX #BASLOD
LDY #BASADR THIS IS LOAD ADDRESS OF BASIC (S)
STY 25 SAVE IT IN BASIC START
INC 26 CORRECT THE ACTUAL START VALUE
TNSFER CLRB SET END COUNTER TO ZERO
TNSFR2 LDA ,X+ GET FIRST BYTE FROM ROMPAK
STA ,Y+ TRANSFER BYTE TO BASIC RAM
BNE TNSFR2 NON ZERO DATA, KEEP TRANSFERRING
ENDCHK INCB ZERO DATA DETECTED, INCREMENT COUNTER
CMPB #3 IS THERE 3 CONSECUTIVE ZERO'S?
BEQ LODDON IF YES, STOP TRANSFER
LDA ,X+ LOAD NEXT ROMPAK BYTE AFTER ZERO
STA ,Y+ TRANSFER BYTE TO BASIC RAM
BNE TNSFER NON ZERO DATA, RETURN TO MAIN LOOP
BRA ENDCHK ZERO DATA, INC COUNTER, STAY IN LOOP
LODDON STY 27 SAVE END ADDRESS FOR BASIC
STY 29 SAVE VAR START AT END OF TEXT
STY 31 SAVE ARRAY START AT END OF VAR/TEXT
AUTRUN LDX #733 BASIC LINE INPUT BUFFER
LDD #21077 LOAD LETTERS "RU"
STD ,X++
LDD #19968 LOAD "N" AND END
STD ,X++
LDB #4 INDICATE 4 CHARACTERS
CLRA
STA 112 SET CONSOLE IN BUFFER FLAG
LDX #732 POINT TO LINE INPUT BUFFER
JMP 44159 START MAIN BASIC LOOP
BASLOD EQU * BASIC PROGRAM DATA STARTS HERE
FCB $00
END
This program is assembled and a "raw" format image is produced, called "loader"...
lwasm -9 -l -f raw -o loader loader.asm
The BASIC program image "cartprog" is concatenated with "loader" to produce the data for programming into the cartridge ROM:
cat loader cartprog > eprom.dat # DOS/Windows command differs
How Does It Work?
Once the auto-start cartridge is detected, Color BASIC transfers control to the loader program listed above. The "loader" program performs some simple initializations for the Color BASIC interpreter before proceeding to copy the BASIC program to the CoCo's program memory. This includes setting the start address of the BASIC program.
The "loader" program starts reading from the location labeled BASLOD. There it will read the value zero as shown, and it will write it to the location defined by BASADR. After the first zero, "loader" continues with the next location which will correspond to the first value from "cartprog". The sequence of reading and writing byte-by-byte continues until 3 consecutive zeroes are read. This corresponds to the end of the BASIC program. (The original "Paul D" version looks for 4 zeroes, but AFAICT that is incorrect.) At this point, the end address of the BASIC program (and the end addresses for BASIC variables and arrays) is set for the Color BASIC interpreter.
Finally, the "loader" program manipulates the keyboard input buffer used by Color BASIC in order to force a "RUN" command to be executed immediately. Then, control is transferred to the Color BASIC interpreter and the loaded BASIC program is now executed.
So, there it is -- a BASIC program loaded from a ROM cartridge on a Tandy Color Computer. Now Color BASIC programmers can publish their programs on ROM cartridge, with all of the prestige, durability, and collector value that entails. That includes ROM cartridges with extra hardware, like my CoCo Games Master Cartridge. But that is another story -- you'll just have to stay tuned!
Sunday, October 30, 2016
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...
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!
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... |
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!
Tuesday, October 25, 2016
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.
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!
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!
Friday, October 14, 2016
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.
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...
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!
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... :-)
 |
| Some Progress |
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? |
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 |
Monday, October 10, 2016
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...
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...
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...
Monday, September 19, 2016
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... :-)
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... :-)
Subscribe to:
Posts (Atom)