Acorn Atom implementation for myStorm BlackIce

hoglet 2017-08-26 16:09:22 UTC #1

Hello all,

I've started work on an Acorn Atom implementation for the myStorm BlackIce board.

I'm sure some of you will be familiar with the Atom. I have a soft spot for it because it was my first computer back in 1982 when I was a teenager.

I'm borrowing some bits and pieces from Atom Fpga (which I also maintain):

However, most of that is written in VHDL, so I thought I would also take the opportunity to port it to verilog, as that seems more popular in IceStorm world.

Here's a link to the top level verilog:

github.com

hoglet67/Ice40Atom/blob/master/src/atom.v

// =======================================================================
// Ice40Atom
//
// An Acorn Atom implementation for the Ice40
//
// Copyright (C) 2017 David Banks
//
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program.  If not, see http://www.gnu.org/licenses/.
// =======================================================================

This file has been truncated. show original

It's using Arlet Ottens' 6502 core, which is one of the smallest available.

At the moment I just have a VGA cable connected via some resistors, giving RGB 322.

Anyway, here's the current state of play:

On a real Atom you often see the same on power up, i.e. just random video RAM contents.

Then, on pressing reset you are greeted with:

The next step is to add support for a keyboard (a PS/2 keyboard plus some logic to emulate the Atom keyboard Matrix). Then I'll actually be able to type in a small program.

Here's the current resource usage:

After packing:
IOs          50 / 107
GBs          0 / 8
  GB_IOs     0 / 8
LCs          1359 / 7680
  DFF        336
  CARRY      88
  CARRY, DFF 17
  DFF PASS   229
  CARRY PASS 18
BRAMs        29 / 32
WARMBOOTs    0 / 1
PLLs         0 / 2

After placement:
PIOs       38 / 107
PLBs       307 / 960
BRAMs      29 / 32

The 16KB of block RAM is the main resource issue at the moment:
- 8KB is used as a 8Kx8 ROM (16 BRAMs)
- 4KB is used as a 2Kx8 dual port RAM (8 BRAMs)
- 2KB is used as a 2Kx8 chararacter generator ROM (4 BRAMs)
- 512B is used as a 512x8 line buffer for the VGA scan doubler (1 BRAM)

What I would like to do is to boot load the 16KB of ROM into external SRAM from the ARM, which would then allow the block RAM to be used as follows:
- 12KB as a 6Kx8 dual port RAM (12 BRAMs)
- 2KB as a 2Kx8 chararacter generator ROM (4 BRAMs)
- 512B as a 512x8 line buffer for the VGA scan doubler (1 BRAM)

The extra ROM space will allow me to add one of the Atom filing systems which would make use of the SD Card and allow real programs (Bug Byte Galaxians) to be loaded.

I plan to use this thread as a progress log over the next few days, so please do ask questions if you are interested.

Dave

ken.boak 2017-08-26 16:52:15 UTC #2

Dave,

Excellent Work! And many thanks for the write up.

The pictures you posted earlier have lit Twitter up - on an otherwise quiet Saturday afternoon!

One question - does the "6502" run at the original clock speed - or are you able to speed things up a bit?

Just to let everyone know that we have programmed the remaining 75 BlackIce boards with the latest firmware - and we are now in a position to offer myStorm BlackIce boards for sale.

There are 75 available from this recent batch

For Customers in UK £40 + £2 postage
For Customers in EU 45 Euros + 4 Euros shipping
For Customers in US $52.50 + $7.00 shipping

For world wide customers - please contact me and ask about shipping costs.

You can PayPal me at ken dot boak at gmail dot com

Please ensure that when you PayPal me, that you include your full mailing address!!

best

Ken

hoglet 2017-08-26 17:06:59 UTC #3

It's currently deliberately slowed down to 1MHz.

There's no reason it couldn't run much faster. Earlier I had it running at 25MHz.

The keyboard is nearly there...

Dave

hoglet 2017-08-26 17:56:15 UTC #4

Another update...

We now have a rather dusty keyboard working:

The PS/2 PMOD adapter was just a few bits soldered together:

My first program!

There's two parts to the implementation of the keyboard:
- a PS/2 Interface
- a mapper to Atom Keyboard Matrix

There seems to be a bug in the 6847 graphics modes, so I'll look at that next.

Then I need to think about how to bootstrap data (16KB of ROM images) into the external RAM from the ARM.

Dave

hoglet 2017-08-27 21:28:48 UTC #5

Hi all,

I've spent quite a productive afternoon / evening on Ice40Atom.

At the end of yesterday I spotted a bug with the graphics modes. Turns out that manually porting ~700 lines of VHDL to Verilog is rather error-prone, especially with several levels of nested if statements. I did first try vhdl2vl without much success; lots of VHDL constructs it didn't support. Anyway, the graphics bug is fixed.

I also added support for sound, cassette input, and cassette output, which was not much work at all, given the simplicity of the these systems on the Atom. The cassette input will need an external LM358 Op Amp, as per the Atom Schematic:

(cassette interface in the bottom right corner).

Anyway on to the main task of the day, figuring out a way to bootstrap 16KB of ROM content from the ARM into external RAM via the FPGA. After pondering this a while, I realized I could re-use the configuration SPI interface, and by doing so the additions to IceBoot are pretty minimal:

	// Additional code to send the Atom ROMs (16KB total)
	gpio_high(ICE40_SPI_CS);
	HAL_Delay(100);
	uart_puts("Sending Atom ROMS\n");
	gpio_low(ICE40_SPI_CS);
	spi_write(atom_roms_bin, 16384);
	gpio_high(ICE40_SPI_CS);
	uart_puts("Done\n");

What's happening here is that after the config bitstream has been sent, the ARM pauses briefly then sends the 16KB of ROM image data over the same SPI port that is used for configuration.

So how does this work? Well, it turns out the pins used for the configuration SPI interface on the iCE40 revert to normal I/Os once the device is configured. Which means you can add your own SPI slave into your design and connect it up to these pins (which happen to be the LED pins as well).

The end result looks something like this:

github.com

hoglet67/Ice40Atom/blob/master/src/bootstrap.v

module bootstrap
  (

   // Clock needs to be clk100 (i.e. >> SCK)
   input         clk,
   output        booting,
   output        progress,

   // SPI Slave Interface (runs at 20MHz)
   input         SCK,
   input         SSEL,
   input         MOSI,
   output        MISO,

   // RAM from Atom
   input         atom_RAMCS_b,
   input         atom_RAMOE_b,
   input         atom_RAMWE_b,
   input [17:0]  atom_RAMA,
   input [7:0]   atom_RAMDin,

This file has been truncated. show original

This holds the 6502 in reset, and then waits for a pre-determined number of bytes to be sent over the SPI interface, writing each of them into external RAM. Once complete, it connects the external RAM back up to the 6502, and releases reset.

This seems to work very reliably, and is fast as the SPI interface is running at 20MHz. So this just adds 6ms to the boot time.

The reason I'm doing all this is two-fold:
- to support ROMS (specifically the Atom Floating Point ROM, and a SD Card file system called SDDOS)
- to free up BRAM so the frame buffer can be increased from 2KB to the full 6KB (which needs 12KB of BRAM)

I then realized I could also bootstrap some useful "test" programs:

This is a great test for the hardware, and it passed with flying colours!

So what's next? Well I did an experiment and added the SD Card file system (SDDOS) plus an SPI master interface. And in the process of doing this, I found SDDOS was not compatible with SDHC cards. Now on the other Atom FPGA implementations this isn't a problem, because they have full-size SD Card slots. So I've been using an old 512MB SD Card, and that's worked just fine.

Unfortunately that won't physically fit into BlackIce as it has a micro-SD sized slot. And as far as I know, all micro-SD sized cards are SDHC (i.e. 4GB or greater).

Which means there will be a bit of a delay while I try to make SDDOS support SDHC cards. I mean, how hard can it be?

Dave

electrified 2017-08-28 18:29:10 UTC #6

Hi Dave,

Great project!

I've got the digilent VGA and PS/2 PMODs. I changed the constraints, and got it up and running althought the colours are a bit off as the VGA PMOD uses 4 bits for each colour, and I've not changed the code to compensate!

I had to go with the version before you changed to bootstrapping the ROM from the ARM as I wasn't sure how to get that going... Do I need to reprogram the firmware on my board?

My branch with the changed constraints is here: https://github.com/electrified/Ice40Atom/tree/digilent-pmods

Cheers,
Ed

hoglet 2017-08-28 18:46:59 UTC #7

Yes, you need to rebuild IceBoot.

There is a copy of the sources in my repository with the changes needed:

I'm not sure whether it's documented anywhere what packages you need, but try starting with::

sudo apt-get install gcc-arm-none-eabi
cd target/blackice/iceboot
make raw

That should give you a file output/iceboot.raw, which can be programmed using:

sudo dfu-util -d 0483:df11 -s 0x08000000  -D output/iceboot.raw --alt 0 -t 1024

Dave

hoglet 2017-08-28 18:48:27 UTC #8

Oh, and by the way Ed, where did you get your PS/2 PMOD adapter?

Dave

electrified 2017-08-28 19:43:41 UTC #9

I got it from Mouser: http://www.mouser.co.uk/search/ProductDetail.aspx?r=424-PMOD-PS2

hoglet 2017-08-29 16:58:43 UTC #10

Hi all,

I've now got the SD Card file system (SDDOS) working with SDHC cards, which gives us access to the complete Atom Software Archive (currently containing ~760 software titles) from Ice40 Atom.

First up, some photos...

On Boot, you should now see a slightly modified reset message:

If you don't have a correctly formatted SD Card plugged in (see notes below), then at the point you will get an INTERFACE? error and the system will appear to have hung:

Pressing Ctrl-F10 will initialize the Atom without initializing the SDDOS file system, and should get you a command prompt.

To boot the Atom Software Archive, press shift-F10, and you should be met with the initial spash screen:

Select one of the Chapters by pressing A..F (this is the Commercial Software chapter):

At this point, pressing the / key will bring up a help screen:

(Rept is mapped to Right-Alt on the PS/2 keyboard)

Probably the most useful command is Search (S), just don't type too quickly...

Exit search mode by hitting return.

Select an individual title by pressing the corresponding letter (or using Ctrl/Shift then return):

And voila, the game is loaded:

A couple of important points:

The BlackIce SD Card socket (underneath) shares the same signals as the DIP switches. So these switches must be in the up position (off) or else you are shorting out the FPGA outputs to ground.
The current AtomSoftwareArchive release can be found here:
https://github.com/hoglet67/AtomSoftwareArchive/releases/tag/V10BETA3
You will need to re-flash IceBoot to pickup the updated SDDOS file system ROM.

you want the SDDOS version:
https://github.com/hoglet67/AtomSoftwareArchive/releases/download/V10BETA3/AtomSoftwareArchive_20170829_V10Beta3_SDDOS.zip

You need up unzip this to get an file called archive.img that should be ~100MB in size.

This needs to be written as a raw image directly to the SD Card.

e.g. On Linux

dd if=archive.img of=/dev/sdxxx

where sdxxx is the device file name of your SD card.

THIS WILL NUKE ANY EXISTING DATA ON THE CARD - BE WARNED

BE ESPECIALLY CAREFUL IF YOU USE DD

On windows, I would use "Win32 Disk Imager" to achieve the same.

Dave

BigEd 2017-08-29 17:25:15 UTC #11

Fantastic! Well done.

There's a windows version of dd which I used to use back in the day:
http://www.chrysocome.net/dd

gururise 2017-09-01 14:44:53 UTC #12

Saw the other thread about enabling VHDL support in Yosys. Does that mean it will be easier to port VHDL cores from other systems (ie. mist) in the future?

hoglet 2017-09-02 07:12:23 UTC #13

The VHDL plugin is based on the parser from the vhdl2vl tool:

github.com

cliffordwolf/yosys-plugins/blob/master/vhdl/vhdl_parser.y

// vim: set noexpandtab tabstop=8 shiftwidth=8 :
/*
    vhd2vl v2.5
    VHDL to Verilog RTL translator
    Copyright (C) 2001 Vincenzo Liguori - Ocean Logic Pty Ltd - http://www.ocean-logic.com
    Modifications (C) 2006 Mark Gonzales - PMC Sierra Inc
    Modifications (C) 2010 Shankar Giri
    Modifications (C) 2002, 2005, 2008-2010, 2015 Larry Doolittle - LBNL

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License along

This file has been truncated. show original

I haven't tried the plugin, but I did try vhdl2vl on my VHDL sources, specifically on this:

github.com

hoglet67/AtomGodilVideo/blob/master/src/MC6847/mc6847.vhd

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
use ieee.numeric_std.all;

entity mc6847 is
    generic
        (
            T1_VARIANT   : boolean := false;
            CVBS_NOT_VGA : boolean := false);
    port
        (
            clk            : in  std_logic;
            clk_ena        : in  std_logic;
            reset          : in  std_logic;
            da0            : out std_logic;
            videoaddr      : out std_logic_vector (12 downto 0);
            dd             : in  std_logic_vector(7 downto 0);
            hs_n           : out std_logic;
            fs_n           : out std_logic;

This file has been truncated. show original

It had so many problems that I decided to translate it manually. It struggled with things like variables, shared variables and attributes.

If your VHDL sticks to the subset of the language that vhdl2vl supports, then you may find the yosys plugin works.

Here's the full list of missing features:

4.0 MISSING FEATURES AND KNOWN INCORRECT OUTPUT:

String types: awkward, because Verilog strings need predefined length

Attribute: easy to parse, but I am not sure what Verilog construct
  to turn it into.  It smells like a parameter, not an (* attribute *).

Multiple actions in one process, as used in DDR logic?

Exit statement incompletely converted to disable statement
  (see examples/bigfile.vhd)

Part select expression zz(31+k downto k) should convert to zz[31+k+:32]
  (see examples/for.vhd)

variables not handled right, show up as declarations within always blocks
  (see examples/for.vhd)

Conversion functions (resize, to_unsigned, conv_integer) are parsed, but
  their semantics are ignored: resize(foo,n), to_unsigned(foo,n), and
  conv_integer(foo) are treated as equivalent to (foo).

VHDL is case insensitive, vhd2vl is case retentive, and Verilog is case
  sensitive.  If you are sloppy with case in the original VHDL, the
  resulting Verilog will have compile-time warnings or errors.  See
  the comments about vhd2vl-2.1 in the changes file.

Doesn't necessarily get clock edge sensitivities right if there is more
  than one clock in the list

Totally broken handling of text in generic mappings, as Xilinx is wont to
  use for their primitives and wrappers

Dave

hoglet 2017-09-05 13:46:38 UTC #14

Hi all,

There's been quite a few incremental improvement to the Ice40 Atom in the last few days.

Full details can be found in the git commit logs.

I'll try to summarise these briefly now.

(1) Atom Ice Boot updated

The Atom now starts correctly if the bitstream is loaded into FLASH. The Atom SDDOS ROM image has also been updated with some fixes to improve reliability and compatibility with certain games in the Atom Software Archive.

(2) A full 6522 implementation is now included

A lots of Atom Games (especially the Retro Software titles) make use of 6522 timers/interrupts. The most accurate 6522 implementation I'm aware of is the one maintained by the FPGA Arcade people. Unfortunately it's in VHDL. But I'm getting quick fast now at translating VHDL to Verilog.

(3) Support for 1, 2, 4 and 8MHz CPU speeds

This was part of an general overhaul of the clocking to use a single 25MHz system clock, with synchronous clock enables to slow certain devices down.

The CPU clock speed can be changed on the fly using keys F1..F4.

(4) Support use of LEDs after initialization

The LEDs (outputs) and SPI (inputs) share the same pins on BlackIce. So I've added some bidirectional buffers so these are inputs while the ARM is loading the ROMs, and then outputs after the system has booted successfully.

At the moment the LEDs are:
- LED1 (Blue) indicates the alternative colour palette is selected
- LED2 (Green) indicates SD Card activity
- LED3 (Yellow) indicates the keyboard shift lock is active
- LED4 (Red) indicates reset is active

(5) Test Bench improvements

I'm using iverilog to simulate the design. The test bench pretends to be the ARM, and first loads the ROM images over the SPI (about 6ms). The Atom startup is quite slow, as it spends a lot of time waiting for the 60Hz frame sync pulse.

On my rather elderly workstation, the simulation runs at about 400 processor cycles/second. The test bench runs for 100,000 processor cycles (100ms), and this takes 4 minutes.

During the simulation, the 6502 address and data buses are dumped.

After the ROMs are loaded and reset is released, this is what you see:

Wr: 01xx = xx    RST released
Wr: 01xx = xx
Wr: 01xx = xx
Wr: 01xx = 30
Rd: fffc = 3f    RST vector read from #FFFC/D
Rd: fffd = ff
Rd: ff3f = a2    LDX @#17
Rd: ff40 = 17
Rd: ff41 = bd    LDA #FF9A,X
Rd: ff42 = 9a
Rd: ff43 = ff
Rd: ffb1 = c2
Rd: ff44 = 9d    STA #0204, X
Rd: ff45 = 04
Rd: ff46 = 02
Rd: 021b = xx
Wr: 021b = c2
Rd: ff47 = ca    DEX
Rd: ff48 = 10    BNE #FF41
Rd: ff48 = 10
Rd: ff49 = f7    
Rd: ff4a = 9a
Rd: ff41 = bd    LDA #FF9A,X
Rd: ff42 = 9a
Rd: ff43 = ff
Rd: ffb0 = 78

(I've added the disassembly annotations)

To make sense of this, here's a handy atom ROM disassembly:
http://www.acornatom.nl/atom_handleidingen/splitatom/f000.txt

FF3F  A2 17     LDX @#17        Set vector table pointer
FF41  BD 9A FF  LDA #FF9A,X     Get byte from vector data table
FF44  9D 04 02  STA #204,X      ..and store in the vector table in RAM
FF47  CA        DEX             Point to next byte
FF48  10 F7     BPL #FF41       ..and set all 12 vectors = 24 bytes

At the end of the simulation, the state of the screen is dumped and you see:

ACORN ATOM + SDDOS              
                                
INTERFACE?

As I'm not simulating the SD card (yet...) this error is expected.

At this point the simulation and real system jump off into the weeds. You can see why by inspecting the simulation.

Rd: ee2f = 00    BRK (after SDDOS Interface? error)
Rd: ee2f = 00
Rd: ee30 = 20
Wr: 01f9 = ee
Wr: 01f8 = 31
Wr: 01f7 = f1
Rd: fffe = b2    BRK vector fetched from #FFFE/F
Rd: ffff = ff
Rd: ffb2 = 85    STA #F2
Rd: ffb3 = ff
Wr: 00ff = ea
Rd: ffb4 = 68    PLA
Rd: ffb5 = 48    PHA
Rd: ffb6 = 29
Rd: 01f7 = f1
Rd: ffb6 = 29
Rd: ffb6 = 29    AND @#10
Rd: ffb7 = 10
Wr: 01f7 = f1
Rd: ffb7 = 10
Rd: ffb8 = d0    BNE #FFC0
Rd: ffb9 = 06
Rd: ffba = a5
Rd: ffc0 = a5    LDA #FF
Rd: ffc1 = ff
Rd: 00ff = ea
Rd: ffc2 = 28    PLP
Rd: ffc3 = 08    PHP
Rd: ffc4 = 6c
Rd: 01f7 = f1
Rd: ffc4 = 6c
Rd: ffc4 = 6c    JMP (#0202)
Rd: ffc5 = 02
Wr: 01f7 = f1
Rd: ffc5 = 02
Rd: ffc6 = 02
Rd: 0202 = xx    oops! BRK vector not set up at this point
Rd: 0203 = xx
Rd: xxxx = xx
Rd: xxxx = xx

There's also some interesting overlapping of instructions going on. This is probably different to a genuine 6502, as Arlet's core does not claim to by cycle accurate.

Finally, if you want a recommendation for a game to play, try Manic Miner. This is one of Kees van Oss's amazing ports.

This has just been added to the latest version of the archive.

It's quite challenging at 2 or 4MHz!

It's also worth checking out some of the other Retro Software titles:

(Press 6 then F to filter by publisher = Retro Software)

As there's still some remaining space in the iCE40HX8K so I might have a go at implementing Atom SID (a SID based sound card extension for the Atom).

Dave

ken.boak 2017-09-05 14:22:51 UTC #15

Dave,

That's great - I have just got my hands on the digilent vga adaptors - is there something that I can do a quick test of VGA output?

A .bin that I can load straight in would be most useful, before I go about rebuilding the whole project.

regards

Ken

hoglet 2017-09-05 14:37:00 UTC #16

Here you go:
ice40atom_20170905_1530.zip

The atom.bin file will give you VGA output, but nothing more as the ROMs will not have been loaded by the standard IceBoot.

The icebootatom.raw file contains the modified IceBoot (to load the ROMs) and also has the atom.bin bitstream embedded at offset 0x1F000. Program it as you would a normal iceboot image, e.g.

sudo dfu-util -d 0483:df11 -s 0x08000000  -D icebootatom.raw --alt 0 -t 1024

If you have a SDHC card, you need to write archive.img from here to the card as a raw file system

(e.g. using dd if=archive.img of=/dev/sdxxx)

If you don't have a SD Card, you can press Ctrl-F10 to bypass SDDOS initialization.

ken.boak 2017-09-05 14:50:58 UTC #17

Thanks Dave - we have working VGA - and Alan is just about to load the version with the ROMs.

Ken

hoglet 2017-09-05 15:05:25 UTC #18

Gotcha #1: Some PS/2 keyboards don't work well at 3.3v. Hope your's does!

Gotcha #2: Make sure the DIP switches are in the off position (or the SD card won't work)

Dave

hoglet 2017-09-11 12:36:00 UTC #19

Hello all,

I've just pushed a new binary release of iCE40Atom to github (here).

Two new features have been added:

1) A "Schakelkaart" paged ROM system

Over the years several extension ROMs were released for the Atom, and certain games rely on one or more of these. In the archive, these games are flagged with a (R) in the title.

Back in the early 1980's Dutch Atom enthusiasts developed a way overlaying multiple 4K utility ROMs at #A000, and switching between them as needed. The hardward was called the Schakelkaart and the bank switching software was called Branquart.

Here's a picture of an original Schakelkaart:

I've added an implementation of this to iCE40Atom.

The following additional ROM images are boot loaded from the ARM:
- Bank 0 = AXR1
- Bank 1 = PCharme v1.73
- Bank 2 = Atomic Windows v1.1
- Bank 3 = GAGS v2.3
- Bank 4 = Program Power Toolkit
- Bank 5 = Watford Electronics ROM
- Bank 6 = FPGA Utils v0.28
- Bank 7 = configured as RAM initially empty

Each of these adds additional BASIC commands. Most of the manuals can be found here.

2) Atom SID

The second new feature is a implementation of the 6851 SID sound chip.

Although not original to the Atom, this is quite a popular modern extension, known as Atom SID:

There are quite a few titles in the archive that feature SID based music. Just select Chapter F and search for SID. Here's a couple of examples:

Atomic Flappy Bird:

Atom SID Compilation:

Space wise, things are now quite tight:

After packing:
IOs          58 / 107
GBs          0 / 8
  GB_IOs     0 / 8
LCs          6598 / 7680
  DFF        1600
  CARRY      627
  CARRY, DFF 196
  DFF PASS   920
  CARRY PASS 65
BRAMs        23 / 32
WARMBOOTs    0 / 1
PLLs         0 / 2

After placement:
PIOs       41 / 107
PLBs       953 / 960
BRAMs      23 / 32

I'm actually quite surprised the SID fitted, as it includes an 18x18 multiplier in the filter, and a 8x12 multiplier in each of the three voices. In a Xilinx these make use of the hard DSP blocks, but in an iCE40 they are implemented using logic gates.

There are many more SID music compilations in the archive, as I have a mechanical (i.e. automatic) way of porting Pitfall Jones's BeebSID compilations:

The audio output of iCE40 Atom is on PMOD 11/12 pin 9 (that's the top row). The signal is driven from a PWM DAC inside the FPGA, so ideally you need an external low pass filter. I'm using a 3.3K resistor followed by a 4.7nF capacitor to ground. The output to your amplifier should be taken from across the capacitor:

Enjoy the music!

Dave

disneysw 2017-09-28 21:08:18 UTC #20

Thank you for this.

The Atom was the first computer I built from kit and the reason I ended up having a career in computing. I still remember my excitement when it first booted and I tentatively typing in

10 print "hello"
run

and got ‘hello’ back. Not powered on the real machine in years but I still keep it.

Playing the old games on the FPGA brought back many fond memories and some not so fond frustrations relating to typing code in from magazines

I will have to try the Beeb emulator next, that was my first real love, and a machine I knew inside out at the time.