Yes, last year I was able to show a little bit at the TechSat.
The system I am making has many similarities with the Acorn Atom.
The implementation of SDDOS is in C and would be able to run over the #B800 interface just like the software SPI version for the Atom. It uses the same strategy and disk format.
Since it is an FPGA I am thinking about hybrid systems with multiple CPUs. The specific up5k chip is a bit too small to have two CPUs but the HX8K certainly should be able to run a combined 6502 and 16bit RISC. The Roland Atom has a AVR for the SD/MMC card access and there is no reason why the 16bit RISC could not work in a similar setup. Also Second processor / Tube solutions have been made in FPGA and even RPi.
I have another board (IceZero) that piggybacks on a RPi-0W. That one can have fast communication to the RPi and at the same time have 256KB SRAM, VGA out, Keyboard etc. The options are far more than i can find time.
On a side note, I do occasionally chat with people from anycpu but mostly I end up chatting with the guy that build the ZipCPU. Mainly because he has piles of experience and a full stack running already. Also he is a very nice guy to talk to.
Currently I have written in C/C++: a ATOM BASIC like BASIC , Graphics system (MOVE/DRAW/PLOT) , SDDOS (read-only), serial-port console (if no graphics), a Disassembler (RISC16), Atom Keyboard handler, GPIO (a bit like the VIA, 8 or 16 bits)
Everything is an exercise that wanders the path of a 'what if' scenario.
We have all seen the 32 bit ARM replace the 6502 at Acorn. So I wondered if the Atom would get a similar 'upgrade' to 16 bits, what would I have done. I already was fiddling with a G65SC816 in the old days with the ATOM but there wasn't much hope to modify the mainboard to have a lot more SRAM. (32KB chips was about the biggest I could find back then and my ATOM already had 2 of those.)
In my day jobs I always worked with the latest and fastest big computing systems, Big Data and Datacenters. It never felt as good as the ATOM..
Somewhere in 2015 (i think) I was dusting off my ATOM and wondered if I could find a simple way to connect modern storage to my ATOM. (I have very fond memories of programming things for the ATOM. Even wrote a compiler once and still hope to find that tape.) While looking for solutions I stumbled over the Roland Atom and it was the perfect solution for my ATOM revival. I ordered the PCB with the vital components and added the components that were laying in the bottom drawer for years. After soldering carefully and getting the machine working it felt great to see the ACORN ATOM prompt on the VGA monitor.
It did not stop there. It triggered a whole new set of ideas. Most importantly the GODIL was a version of FPGA boards that is easily accessible and to modify. Much more compact than the old FPGA boards I had laying around. (the license keys of the software for those boards had long expired and i already had put them aside.)
Then I stumbled over a nice writeup of Project Icestorm, an open source FPGA toolchain for cheap FPGA boards. It enabled me to quickly do simple test and projects and soon enough a simple Acorn ATOM. Since the people here at stardot seemed to have similar projects there was plenty to read up on for the Acorn ATOM implementation. When I hooked up an SD-card to the FPGA, Hoglet was very helpful in finding the timing issues for getting the SD-card to switch to SPI mode. He already had done something similar and has a huge wealth of information on the ins-and-outs for how everything interacts with the software. Sure I had looked around at the opencores area but it did not feel anything like the Acorn ATOm experience. It seemed that everyone was pursuing a copy of an existing CPU or find ways to mimic some other device. My interest was drawn by the talks of Sophie Wilson who explained how the ARM chip came about. The idea that it could be simple, efficient and have the programmability in assembler like on the Acorn ATOM in 6502 mnemonics.
The ARM chip can already be bought for a few pennies so no real challenge to design something with the hundreds of ARM developer boards. (I have been buying many different ones and most are now in the bottom drawer..) Simply no fun. I already have programmed ARM assembly since 1991 and still use inline assembly on Linux if i feel it is necessary.
The ATOM has limited resources, a 64KB memory space and that really makes everything a nice puzzle on how to use those resources optimally. So I wanted a 16 bit system. 16 bit address space, 16 bit wide bus and 16 bit wide registers. The number 16 permeated also into the amount of registers. With the 6502 in mind the instructions would be simple and many run in one cycle. ALU ops, Branches, Jumps and Load/Store ops in a total of.. 16. A more-or-less uniform instruction of 4x4 bits.
4 bits for Op, 4 bits destination register , 4 bits source A register , 4 bits source B register.
Soon enough i saw that using registers for jumps and branches wasn't the right solution. Those got modified into:
Op=BRA (4bits) , 1 bit for immediate adress, 2 bits for EQ/NE/MI/PL and 9 bits for relative offset. enabling BEQ rel/abs, BNE rel/abs, BMI rel/abs and BMI re/abs.
The JUMP followed in a similar fashion. JUMP rel/abs.
Having the circuitry for reading a second value after the instruction made it very easy to do the same with all the ALU ops and LDR/STR:
next to ADD R0,R1,R2 I could now do ADD R0,R1,#12345 too.
next to LDR R0,[R1,R2] I could now have LDR R0,[R1,#12345].
ADD R0,R1,R2 is one cycle and ADD R0,R1,#12345 is two cycles. (requires an extra memory cycle)
LDR R0,[R1,R2] is two cycles ( one for processing the instruction and one for the extra memory cycle.)
LDR R0,[R1,#1234] requires three cycles simply because there are 3 memory fetches.
I really wanted a more efficient way in order to reduce the overhead and implemented a ADI , LDI, STI where the offset was 4 bits. The 4 bits meaning -8..+7 giving faster operations for the most often used offsets.
ADD R0,R1,#1 would be one cycle if used as ADI R0,R1,#1 and SUB R0,R1,#1 could now become ADI R0,R1,#-1.
Yes, with this circuitry I could do the same with the LDR and STR now becoming LDI and STI.
Resulting opcodes:
B(EQ/NE/PL/MI) <address>
JSR <address>
LDI Rd,[Rs,#-8..7]
STI Rd,[Rs,#-8..7]
LDR Rd,[Ra,Rb]
STR Rd,[Ra,Rb]
ADI Rd,Rs,#-8..7
LIT Rd,<8bit value>
ADD Rd,Ra,Rb -or- ADD Rd,Ra,#<16bitvalue>
SUB Rd,Ra,Rb -or- SUB Rd,Ra,#<16bitvalue>
AND Rd,Ra,Rb -or- AND Rd,Ra,#<16bitvalue>
ORR Rd,Ra,Rb -or- ORR Rd,Ra,#<16bitvalue>
EOR Rd,Ra,Rb -or- EOR Rd,Ra,#<16bitvalue>
SHL Rd,Ra,Rb -or- SHL Rd,Ra,#<16bitvalue>
SHR Rd,Ra,Rb -or- SHR Rd,Ra,#<16bitvalue>
MUL Rd,Ra,Rb -or- MUL Rd,Ra,#<16bitvalue>
Multiplications almost come free in Verilog thus I added that as the last one.
After that I wrote a python program to convert assembler into a binary blob for the cpu and started writing lots of assembler programs. I added a BASIC interpreter in assembler and.. I got lost in the code. Too much assembler and waay to little time to code or get this as far as a full ATOM like system. I needed a compiler.
So I wrote a simple C compiler to generate assembler output from C code.
It worked okay-ish and I felt it could be a lot easier if I could use OO like C++ to improve the speed of developing.
C++ is extremely complex from a compiler's perspective. That I already knew and thus I decided to reduce the complexity by setting the goal for a C-plus-ish compiler.
Simple rules:
classes with members and methods. (no struct, use a class instead.)
classes can have sub-classes but no inheritance. (yet.. it obscures a lot.)
No templates and operators (although the operator '=' requires attention.)
Mostly C with straight forward logic. (for,while,switch,case,break,continue..)
The cc16 compiler was born and I could quickly implement the ideas I had in a flexible language.
The compiler is far from finished but works well and has seen some improvements regarding speed and peephole optimizations.
When I implemented division in software I noticed that it would be nice to move more complex operations such as MUL and DIV to a coprocessor like structure in the FPGA.
7 cycle DIV and 2 cycle MUL was the end result. Testing it was a simple matter of modifying the compiler backend. The MUL instruction had now become a co-pro instruction. CPR Rd,Ra,Rb and CPR Rd,Ra,#<16bit value> If Rd=15 it's a write to co-pro and Rd!=15 it's a read from co-pro.
Programming graphics draw routines and 3D animation became possible at ease.
The library of C-plusish code now has: basic, disassembler, expressions, gpio, keyboard, math, screen, graphics, serial_console, strings, types, sdcard_spi and SDDOS.
The basic still is unfinished but can run:
PRINT, INPUT, GOTO, IF-THEN-ELSE, GOSUB-RETURN, FOR-NEXT,DO-UNTIL,
CLEAR, MOVE, DRAW, TRI, RECT, COLOR, RUN, NEW, LIST, AUTO, DISASM,
SDDOS, DISKS, SECTOR, MOUNT, DIR, DUMP, LOAD.
AUTO was inspired by P-Charme,
DIR was used instead of CAT.
COLOR instead of COLOUR (Sorry, Roland..
)
At github I will try to put enough to allow people to try it out.
Hope it gives some idea of what and why. It's been great to do this in the evenings and just think about the what if's.
Jan Rinze.
