Building an Acorn System 1 replica - Part 4 (26/04/2020)
Not much has been happening with this project until recently when like trains, a lot of things all happened at the same time.
I'd ordered a new set of PCBs and when assembled everything seems to work... sort off.
My original test program seemed fine, so now was the time to fit the INS8514 chip, an EEPROM with the monitor program and connect the keyboard/display card.
IT'S ALIVE....
It seemed to be working with one weird exception.
If you walked up and down memory, the display would show address 0051, 0052, 0073, 0074, 0075, 0056, 0057 etc.
There were multiple areas in the memory map that this would occur. What made this more confusing was that the monitor program did seem to be running ok - it was letting me explore memory quite happily. To me this ruled out there being problems with the address or data lines, but I checked them again just in case, but everything looked ok.
I also found that if when walking memory and the address jumped on the display I wrote new values at that location, then inspected memory at the address that had been displayed, the values were different. To me, this indicated it was a display problem and that the monitor was accessing memory correctly, just not displaying the address correctly.
I swapped to my backup 8514 chip but exactly the same problem. Then I realised that these windows of corruption in the map seemed to move around.
Back to the original 8514 chip and again, the locations seemed to be moving around. Cycling the power seemed to cause the windows to shift, so it seemed unlikely to be a faulty/suspect IC.
I'd started using EEPROMS and thought this may be causing problems, so switched back to an EPROM but it made no difference.
I spent several days looking at this. I wrote test programs with the Arduino to read the EPROM, read/write RAM, each test program getting more complex than the last but to no avail. Everything seemed to check out fine.
In frustration the project got dumped on the back-burner which is my secret code for leave it for 10 years then bin it.
And that's where it stayed, until several days ago when I was contacted by a reader who asked if I could flash him an EPROM as he wanted to make one of these infernal machines for himself. Why not I thought.
I broke out my crappy EPROM programmer, and flashed him a couple of 2716 EPROMS and popped them in the post.
Build decent EPROM programmer is STILL on my to-do list.
This re-ignited my interest in the project again so I went back to it for another play. The fault of course was still there.
As a bit of a hail-Mary and with nothing to lose, I posted details of my problem to the StarDot forum and within a couple of hours somebody came back with a list of suggestions. Several of them were red-herrings but one of them peeked my curiosity.
I'd opted to use the W65C02 variant of the CPU as it has quite a few benefits over the traditional 6502; including support for a clock frequency from DC to 14MHz and you can implement single-step debugging. One of the nagging feelings I'd had was that somehow I'd screwed up the clock area of the design; I'd made a lot of changes in this area to support different crystals and clock speeds, so I included this part of the schematic in my post for help.
It turns out that the W65C02 clock doesn't work in the same way as the 6502 and I'd used the wrong clock pin.
It took me 10 minutes with a scalpel and a couple of jumper wires to correct the problem and hey-presto it worked perfectly.
I've had it running for several hours and it's been fine.
In my defence it's not that I didn't read the clock section of the datasheet for the W65C02 CPU, it's that I apparently didn't understand it.
I'd ordered a new set of PCBs and when assembled everything seems to work... sort off.
My original test program seemed fine, so now was the time to fit the INS8514 chip, an EEPROM with the monitor program and connect the keyboard/display card.
IT'S ALIVE....
It seemed to be working with one weird exception.
If you walked up and down memory, the display would show address 0051, 0052, 0073, 0074, 0075, 0056, 0057 etc.
There were multiple areas in the memory map that this would occur. What made this more confusing was that the monitor program did seem to be running ok - it was letting me explore memory quite happily. To me this ruled out there being problems with the address or data lines, but I checked them again just in case, but everything looked ok.
I also found that if when walking memory and the address jumped on the display I wrote new values at that location, then inspected memory at the address that had been displayed, the values were different. To me, this indicated it was a display problem and that the monitor was accessing memory correctly, just not displaying the address correctly.
I swapped to my backup 8514 chip but exactly the same problem. Then I realised that these windows of corruption in the map seemed to move around.
Back to the original 8514 chip and again, the locations seemed to be moving around. Cycling the power seemed to cause the windows to shift, so it seemed unlikely to be a faulty/suspect IC.
I'd started using EEPROMS and thought this may be causing problems, so switched back to an EPROM but it made no difference.
I spent several days looking at this. I wrote test programs with the Arduino to read the EPROM, read/write RAM, each test program getting more complex than the last but to no avail. Everything seemed to check out fine.
In frustration the project got dumped on the back-burner which is my secret code for leave it for 10 years then bin it.
And that's where it stayed, until several days ago when I was contacted by a reader who asked if I could flash him an EPROM as he wanted to make one of these infernal machines for himself. Why not I thought.
I broke out my crappy EPROM programmer, and flashed him a couple of 2716 EPROMS and popped them in the post.
Build decent EPROM programmer is STILL on my to-do list.
This re-ignited my interest in the project again so I went back to it for another play. The fault of course was still there.
As a bit of a hail-Mary and with nothing to lose, I posted details of my problem to the StarDot forum and within a couple of hours somebody came back with a list of suggestions. Several of them were red-herrings but one of them peeked my curiosity.
I'd opted to use the W65C02 variant of the CPU as it has quite a few benefits over the traditional 6502; including support for a clock frequency from DC to 14MHz and you can implement single-step debugging. One of the nagging feelings I'd had was that somehow I'd screwed up the clock area of the design; I'd made a lot of changes in this area to support different crystals and clock speeds, so I included this part of the schematic in my post for help.
It turns out that the W65C02 clock doesn't work in the same way as the 6502 and I'd used the wrong clock pin.
It took me 10 minutes with a scalpel and a couple of jumper wires to correct the problem and hey-presto it worked perfectly.
I've had it running for several hours and it's been fine.
In my defence it's not that I didn't read the clock section of the datasheet for the W65C02 CPU, it's that I apparently didn't understand it.
I've just ordered another new set of PCBs that contain the corrections to the clock circuit and some other enhancements then, hopefully, it will be done (ha - famous last words... these things are never done!).
Of course when I say done, I mean that the basic system will work, but the reality is that you can't really do that much with a basic system 1 and you would be hard pressed to create even a basic calculator. So creating expansion boards is now on the list of things to do. However, there are a couple of more pressing tasks to look at.
After reviewing the design of the original system 1 there were some things that I didn't like and so I made some hardware changes. Also, times and components have moved on and it seemed silly to build an exact replica using hard to find parts.
Major differences between the original and my version.
I only support the W65C02 CPU. You could modify the board to support the standard 6502, but the W65C02 is better in all respects and still being manufactured. DON'T try just putting a standard 6502 in and expect it to work... it won't.
I dropped support for the onboard two small PROMS. I don't think you can even buy them anymore so I've just kept the EPROM socket. However instead of supporting a 2716 as in the original, I opted for a 2764 because 2764's are cheaper and more common and most EPROM programmers will support the 2764 because of it's lower Vpp programming voltage. A depressingly high number of programmers won't handle the 2716 - more on that in my blog later.
I did make changes around the onboard oscillator so that it can accommodate 1,2,4,8 or 16MHz crystals and still be able to generate a 1MHz clock.
The 1MHz crystal is hard to find and expensive, so this just gives added flexibility, can save the builder some money, and allows you to leverage the additional speed available from the W65C02 CPU if required.
The 2 x 2114 RAM chips that gave the board it's 1K of RAM have been replaced with a single 6116 that gives 2K of RAM (there is a jumper that allows for only 1K to be useable if required).
Now I thought I was being sensible here as I've a box full of 6116's, but it turns out that I'm in the minority. A later revision of the PCB supports 6164 RAMs (but only up to the first 2K).
The edgeway connector is different and supports more signals. The basic layout is the same, but additional useful signals have been routed to the connector.
There's now no onboard 5v regulator. This was probably sensible for a basic system 1, but once you start expanding it that onboard regulator is under powered so becomes a bit of a hinderance. The board accepts a 5v regulated DC input via either a couple of pads on the CPU board, or via the edge connector.
The connection between the CPU board and keypad/display board was updated.
The original used a soldered ribbon cable which I really disliked, so changed it to a 20 way IDC connector and ribbon cable. I also took the opportunity to move the IRQ and NMI buttons from the CPU cards to the keypad board.
There's no cassette interface. There is provision for one to be added and all the required signals and power are routed to a port on the keypad/display board, but the actual interface electronics aren't there. I decided that there were probably better ways of storing programs and data in the 21st century but left it so a cassette interface could be added if required.
There is a slight enhancement around the LED display. The pinout is designed to support the standard NSA LED bubble display but I added two additional pins that make +5v and 0v available. This should make it easier to add larger/different displays that require external power to drive any additional electronics.
I also took the opportunity to make provision for power LED indicators to be added to the keypad and CPU boards if desired.
Dropped support for the second INS8514 IC.
These are hard to find, expensive, and nobody in their right mind would use one for a new design.
Next tasks
I've stated above that I dropped support for the second ISN8514 as they are very hard to find and very expensive, but even a basic system 1 still needs one if you want the keypad/display to work.
So, my first project is to create an alternative.
Somebody on the StarDot forum confirmed my suspicion that a 6522 would be a suitable replacement with a bit of jiggery in the wiring.
I wasn't convinced so sat down with the datasheets for the INS8514 and the 6522 and went though the Monitor program source code listing to see how it interacts with the original INS8514 and was pleasantly surprised.
On paper, it looks like a 6522 could replace this INS8514 with the only limitation being that the 128 bytes of RAM available on the 8514 would be missing on the 6522. Apparently this is no loss as this RAM was only known to be used in one application.
So, I've designed a converter PCB that plugs into the INS8514 socket on the CPU board, and itself has a 65C22 plugged in.
If this works as expected, no code changes to the monitor firmware are required and it would act as a direct replacement for the 8514 that's used to drive the keyboard/display.
I then need to look at creating a modern suitable display using more common parts.
Once these two tasks are completed, anybody should be able to assemble one of these machines.
For now, I've got to wait for my PCB house to ship my new PCBs so I can assemble a new System 1 and make sure everything works as expected, and then test my INS8514 replacement module and after that, I'll report back.
Of course when I say done, I mean that the basic system will work, but the reality is that you can't really do that much with a basic system 1 and you would be hard pressed to create even a basic calculator. So creating expansion boards is now on the list of things to do. However, there are a couple of more pressing tasks to look at.
After reviewing the design of the original system 1 there were some things that I didn't like and so I made some hardware changes. Also, times and components have moved on and it seemed silly to build an exact replica using hard to find parts.
Major differences between the original and my version.
I only support the W65C02 CPU. You could modify the board to support the standard 6502, but the W65C02 is better in all respects and still being manufactured. DON'T try just putting a standard 6502 in and expect it to work... it won't.
I dropped support for the onboard two small PROMS. I don't think you can even buy them anymore so I've just kept the EPROM socket. However instead of supporting a 2716 as in the original, I opted for a 2764 because 2764's are cheaper and more common and most EPROM programmers will support the 2764 because of it's lower Vpp programming voltage. A depressingly high number of programmers won't handle the 2716 - more on that in my blog later.
I did make changes around the onboard oscillator so that it can accommodate 1,2,4,8 or 16MHz crystals and still be able to generate a 1MHz clock.
The 1MHz crystal is hard to find and expensive, so this just gives added flexibility, can save the builder some money, and allows you to leverage the additional speed available from the W65C02 CPU if required.
The 2 x 2114 RAM chips that gave the board it's 1K of RAM have been replaced with a single 6116 that gives 2K of RAM (there is a jumper that allows for only 1K to be useable if required).
Now I thought I was being sensible here as I've a box full of 6116's, but it turns out that I'm in the minority. A later revision of the PCB supports 6164 RAMs (but only up to the first 2K).
The edgeway connector is different and supports more signals. The basic layout is the same, but additional useful signals have been routed to the connector.
There's now no onboard 5v regulator. This was probably sensible for a basic system 1, but once you start expanding it that onboard regulator is under powered so becomes a bit of a hinderance. The board accepts a 5v regulated DC input via either a couple of pads on the CPU board, or via the edge connector.
The connection between the CPU board and keypad/display board was updated.
The original used a soldered ribbon cable which I really disliked, so changed it to a 20 way IDC connector and ribbon cable. I also took the opportunity to move the IRQ and NMI buttons from the CPU cards to the keypad board.
There's no cassette interface. There is provision for one to be added and all the required signals and power are routed to a port on the keypad/display board, but the actual interface electronics aren't there. I decided that there were probably better ways of storing programs and data in the 21st century but left it so a cassette interface could be added if required.
There is a slight enhancement around the LED display. The pinout is designed to support the standard NSA LED bubble display but I added two additional pins that make +5v and 0v available. This should make it easier to add larger/different displays that require external power to drive any additional electronics.
I also took the opportunity to make provision for power LED indicators to be added to the keypad and CPU boards if desired.
Dropped support for the second INS8514 IC.
These are hard to find, expensive, and nobody in their right mind would use one for a new design.
Next tasks
I've stated above that I dropped support for the second ISN8514 as they are very hard to find and very expensive, but even a basic system 1 still needs one if you want the keypad/display to work.
So, my first project is to create an alternative.
Somebody on the StarDot forum confirmed my suspicion that a 6522 would be a suitable replacement with a bit of jiggery in the wiring.
I wasn't convinced so sat down with the datasheets for the INS8514 and the 6522 and went though the Monitor program source code listing to see how it interacts with the original INS8514 and was pleasantly surprised.
On paper, it looks like a 6522 could replace this INS8514 with the only limitation being that the 128 bytes of RAM available on the 8514 would be missing on the 6522. Apparently this is no loss as this RAM was only known to be used in one application.
So, I've designed a converter PCB that plugs into the INS8514 socket on the CPU board, and itself has a 65C22 plugged in.
If this works as expected, no code changes to the monitor firmware are required and it would act as a direct replacement for the 8514 that's used to drive the keyboard/display.
I then need to look at creating a modern suitable display using more common parts.
Once these two tasks are completed, anybody should be able to assemble one of these machines.
For now, I've got to wait for my PCB house to ship my new PCBs so I can assemble a new System 1 and make sure everything works as expected, and then test my INS8514 replacement module and after that, I'll report back.