The AT49F002T (70ns) 256K Flash ROM is not needed when the 4K Kernel and 4K BASIC ROMs are implemented in the FPGA. This was just possible with the XS2C200 device by implementing one in logic and one in Xilinx-specific Block RAM. FPGA is not the most efficient way of implementing memory, so external ROM allows smaller FPGA devices to be used. As I do not have a ROM programmer, I can add a small ROM inside the FPGA with firmware to copy the Atom ROM data from the FPGA to the Flash ROM. After that, the design can be modifed to use the external ROM, with the internal ROM removed.
ROM is a fairly profligate use of FPGA resources, consuming about one logic block per byte. So 4K of ROM would consume about 80% of an XC2S200 FPGA (5,292 logic cells). It is important to get firmware into external memory as soon as possible.
The CPU address space is smaller than the 256K ROM, so this is also paged. At the moment, the FPGA implements 8K of ROM. Enough for the BASIC ROM but not the floating-point, DOS or Utility ROMs. The external ROM is paged into the 4K areas starting at a000h (utility ROM area) and e000h (DOS ROM area).
0000-9FFF RAM AXXX 4K page (0 to 63). = 10 by default BXXX I/O space CXXX BASIC DXXX Floating Point EXXX 4K page (0 to 63) = 14 by default FXXX Kernel
I have written some programs (part BASIC, part assembly) that have successfully erased the chip and copied 4K from C000 (Half the Atom BASIC) to E000 (Flash ROM). The FPGA is big enough to implement the essential Atom firmware, but not any more such as utility ROMs. Other target systems may require more ROM than the FPGA can provide. Copying the firmware to external flash ROM can reduce VHDL size and compilation time. Eventually it would be useful to have Flash-programming code in the FPGA, for downloading firmware into the Flash or using it as a Flash disk.
256K doesn't mean much until you start wondering what to put in it! There is enough space to store the firmware for quite a few vintage micros.
This is a provisional map of where things are placed in the
256K ROM device.
So far, only the Atom BASIC has been loaded, because the data is
already inside the FPGA.
It isn't convenient to recompile data into the FPGA, so other
data would be best loaded via the LPT slave port.
This in turn requires me to write software to do this. It's not a
priority right now.
| Atmel sector | +0 | +1 | +2 | +3 | Application | ||
| Memory block 2 |
0 | Mousebox | pcharme | Econet | unknown | Atom Space | |
| 4 | gags | werom | Demo | salfaa | |||
| 8 | Combox | axr1 | Toolkit | Windows | |||
| 12 | BASIC | Floating Point |
DOS | Kernel | |||
| 16 | BBC Space This had two 16K ROMs by default, and up to four 16K paged ROMs. e.g. for DOS, co-processor, etc. |
||||||
| 20 | |||||||
| 24 | BBC BASIC 4 | ||||||
| 28 | BBC MOS 1.2 | ||||||
| Memory block 1 |
32 | Another machine(s) Apple perhaps? |
|||||
| 36 | |||||||
| 40 | Cartridge space | ||||||
| 44 | RFU (4K) | Test | OS & Maths (10K) | ||||
| 48 | My space | ||||||
| 52 | |||||||
| Parameters & Boot block |
56 | Parameter block | Parameter block | ||||
| 60 | Boot block | ||||||
| --- | --- | ||||||
To keep decoding simple, 64K is allocated per potential
machine implementation, and software located at the default
offset.
Thus if 4K blocks 12 to 15 had the standard Acorn Atom firmware,
A15-12 can be connected to the Flash ROM direct.
As an aside, this could all fit in a 16K EPROM if you want to
make a real Atom more compact.
The other Atom ROMs were mapped at A000, so these will require paging.
Some of the firmware ROMs deal with Disk I/O and networking.
These are a bit redundant, as I don't have (or intend to have) my
project utilising compatible antique hardware.
The minimal Atom has the BASIC and Kernel (8K total) in the
FPGA.
If an address contains no IO, or ROM, then the RAM is accessed.
Thus it should be easy to load the floating point binary code (via the LPT slave port) and to develop replacements for the ancient DOS (by assembling code into #E000 or loading a cross-assembled binary).
Apart from being hard to find and assemble an 8271-based disk board, or an Acorn Econet board, there are far more exciting possibilities now that the PC and the Internet are commonplace. There is Compact Flash, IDE, using the PC as a hard disk, or the Kees van Oss TCP/IP stack.
There are two additional registers to control particular 4K blocks of memory space.
The first allows you to disable internal ROM blocks. When this happens, the FPGA logic selects external memory instead.
The second allows you to disable external ROM blocks. When this happens, the FPGA logic selects external RAM instead.
The RAM address multiplexing for these 4K blocks mimics that used for the paged ROM blocks. You can page through RAM just like you can through ROM, though be warned that the system uses some ROM and RAM pages. E.g. external ROM blocks A,C,D,E,F hold default ROM code, and RAM blocks 0 to 9 are used by the system.
There is a control register to enable/disable ROM and expose the RAM "underneath". This allows you to create and test alternative firmware in RAM before committing it to ROM (either inside the FPGA, or outside in Flash). To quickly test this, you can write a small program to:
At this point, the system starts running code from external RAM, where it can be modified. To check this, you can do this:
?#FF6F = #4B LINK #FFB3
This pokes the character 'K' into the sign-on message, then does a reset. The sign-on message is now:
AKORN ATOM
The ability to use RAM for firmware is very useful, because it allows you to 'hack' the code freely. If the modifications crash the computer, simply press reset to restore the known-good internal ROMs.
Other possibilities are to fill the paged space AXXX with many utility firmware ROMs, or to load radically different firmware such as the BBC BASIC conversion for the Atom.