Over on another board, Martin A has built a version of an Acorn Atom. There's a main board with the CPU, RAM, and ROM with original Atom integer Basic, and a second board with the cassette I/O and video subsystem. And a third board for I/O, implementing a parallel port and an IDE interface.

All using relatively authentic through-hole parts - no programmable logic - but a fast (55ns) SRAM.

The Atom is unusual in running the video subsystem with its own clock, asynchronous to the CPU, originally faster than the CPU clock but in this case slower. The ROM's printing code waits for vertical blank to avoid contention. Any machine code can just go ahead and write to screen memory, which generally causes snow. There were clever fixes for this, one of which relied on the RAM being fast enough to service both VDU and CPU. (Also unusual, the Atom's video runs at a 60Hz frame rate.)

But with this build, the CPU is clocked faster than the VDU. Martin even manages to run at 10MHz, and upgrades the VDU board to a dual port RAM.

via stardot.

I've been meaning to do a write up of the Atom build for a while, so here goes:

There aren't any circuit diagrams, I worked from either the original one, or a point to point wiring map I drew out in Excel.

CPU board:
32k ram in a single device
128k flash of which 16k is visible
CMOS 65C02
TL7705 reset controller
CPU clock oscillator
2 x 74HC138 3 to 8 decoder
74HC08 AND
74HC00 NAND
The ram occupies the lower 32k, and uses A15 for chip select, it’s a 55ns part because that’s what I had In the box. The HC00 decodes the R/*W signal from the CPU into separate PHI qualified active low read and write for the rest of the board.
One of the HC138 splits the top 32k of memory into 4k blocks as on the original Atom. The second HC138 then splits the Bxxx onto 8 I/O blocks. The original Atom used half of a 139 for this so only had 4 I/O decodes instead of 8.
The original atom used mostly 4k roms however there was one 8k part on the motherboard, but that was mapped into a split address range, so the HC08 combines the Cxxx and Fxxx blocks into a single chip select. It also combines 8xxx and 9xxx blocks into a single 8k select for the video ram.
Since there were 2 spare gates on the HC08 I added an option to map all of the top 16k to the rom. One gate combined Dxxx and Exxx. And the other the 2 8k blocks. That adds an extra gate delay to the rom CS. Running with 16k configured therefore has a lower maximum clock rate than running as 8k. In practice the SST flash is performing MUCH better than it’s specs and will run even with the additional delay at 10mhz.
With the jumper in the 8k position the board runs atom integer basic, in the 16k position the floating point rom also becomes available, the intention is to add in a disc rom in the remaining 4k to access the CF at the moment however that’s unused.

Version 2 I/O board
82C55A-2 PPI (8mhz version)
1.2288 Clock oscillator
74HC4040 12 bit counter
74HC00 NAND
7445 (or 74145) BCD to decimal decoder
IDC7005 8k dual port ram
MC6847 VDG
74HC74 flip flop
14.318mhz clock oscillator
2 x 74HCT157 multiplexer
74HCT161 4 bit counter
28C64 8k eeprom 8k
The PPI is wired as per the original Atom and handles the VDG mode settings, keyboard, tape (not currently fitted) and beeper. Because of the extra I/O decodes on the CPU board the PPI is mapped to a 512 byte block at B000 instead of a 1k one, that shouldn’t be an issue as the ROMs etc. use the B00x addresses and not any of the shadows.
The 1.2 mhz clock and the HC4040 produce a 2.4khz clock for the tape components when/if they get fitted, to avoid leaving floating inputs on the HC00 both clock and counter are fitted. The HC00 serves as the buffer for the sound output, and handles the tape output as on the original Atom.
Keyboard, sound and tape output circuits are (would be) as per the original
The VDG is set up to use either internal characters as on the original Atom, or the external character rom. The circuit on P23 of the MC6847 data sheet has *A/S and *int/Ext as the triggers for the character rom. However, I found I needed to use *A/G to control the multiplexers and not *A/S.
The 8k DP ram is accessed on the CPU side at 8xxx/9xxx The VDG side the ram data bus connects the character rom and the 2 multiplexers. With the 2 jumpers set on “internal” The multiplexers always feed the data from the ram to the VDG and the D6 data line to the *int/ext input on the VDG.
In external mode, *int/ext is held permanently high, and the multiplexers will feed in the character rom data in alphanumeric modes and the data from the ram in graphic modes.
The HCT161 counter is wired as per the VDG data sheet to provide the row count for the 16 row high character matrix.
The multiplexers and counter are HCT types as the MC6847 has a TTL outputs.
The VDG luminance output stage is exactly as per the original, while the 2 colour difference signals are fed through transistors as per info I found on the stardot forums. With the DP ram being used there’s no snow on the display when accessing the video memory while the screen is active.
 

VIA board
65C22VIA
82C55A-2 PPI
74HC04 inverter
74HC244 buffer
The VIA provides a 7 bit printer port from the A side via the HC244 as per the original atom, but with the 8th data line tied low instead of being left floating. The unused B port thay goes to external expansion on the atom is wired as a BBC micro user port on the 20 way header. It uses the I/O block at B8xx.
The 82C55 PPI is wired to provide a 16 bit IDE interface. I found the basic design on PJRC.COM where it’s used with the 8051 but the basic design is easy to fit the 6502 (or Z80 or 6809 or…)
The PPI is visible in the I/O block at BCxx that’s unused on the basic atom. I have the code written for reading and writing single sectors, but no Disc filing system as yet.
 

Rom development board
74HC133 13 input NAND
74HC273 octal flip flop with clear
74HC32 OR
ZIF socket
With the need to program a DFS rom, I’ve added a short board with a ZIF socket fitted. I didn’t have a spare 32 pin type so the socket has 40 pins with some high-tech markings to indicate the unused pins!
The rom is connected to the Axxx memory select which is the utility rom area in the original Atom.
The rom could have been wired as a single 4k image, but I decided to add support for rom paging. The rom socket is therefore wired for a 128, 256 or 512k flash device.
The HC133 is connected to the lowest 12 address lines (plus 1 pin tied high) to decode any xFFF addresses. That output is combined on the HC32 with the BExx/BFxx IO select that comes “free” with the HC138 on the CPU board to decode BFFF.
Accessing address BFFF with then latch the databus value onto the 273 which provides the upper 7 bits of the rom address. The 273 has the active low clear signal connected to reset so that its in a known state on boot.
The HC32 doesn’t currently check that the access is a write. That’s because there are already 2 gate delays in the I/O memory select before reaching the rom board. With no protection reading BFFF can have “interesting” side effects, realistically though, it shouldn’t be an issue with home written software. If it turns into an issue, qualifying the xFFF signal with write before it’s mixed with the IO decode is an option.
 

The rest
The backplane has 4 sockets and a plug in 3v and 5v PSU I borrowed from another project. 3v isn’t used as everything is driven from 5v.
The connector layout is a heavily modified variation of PL6/7 on the original atom. The A row is more or less the same, but the c row (b row on the smaller Atom connector) has almost nothing in common, just a few of the CPU signals.
The keyboard is a close to the original layout as was possible using 0.5” keys with a 0.6” spacing on a 9” matrix board. Originally the keycaps were marked with so called permanent ink, but that soon wore off. For now, there’s some temporary labels stuck on.
The 20 way ribbon cable connects to the header on the I/O board is a couple of feet long, and about as much as I thought I could get away with since it’s unshielded.
With some nylon posts added the whole thing builds into a nice solid structure.

Fantastic - thanks for all the detail!

Wonderful

Mark

I just got around to reading all of this. This is amazing work!

Your soldering is completely free of spaghetti!

_________________
Cat; the other white meat.