SPAM-1 - 8 Bit CPU

Started a new module to support the VGA component of SPAM-1.

I wanted 32KB of dual port ram for video but wasn't willing to shell out for it. I found a couple of 16KB PLCC modules so I need a board to support them as part of SPAM-1 and the new sub-project is a PCB to create a 32KB module that's R/W from the CPU side and Read-only from the GPU side and fast enough for 160x120 approx video.

It's a work in progress.

https://oshwlab.com/john.lonergan.sharing/32kb-dual-port-video-memory

I want it to fit amongst my breadboards so it's size constrained.

Several people asked those questions so I made a video to explain....

I've been wondering about how one homebrew CPU arch compares to another. How the memory addressing modes contribute, or which ALU ops are worth implementing or Harvards vs VN.

Anyway I came across Matt Heffernan's 8 Bit Battle Royale channel where he discusses multiple popular commercial machines and I decided it would be interesting to see how SPAM-1 stacks up.

The first step is to figure out how to do 16 bit fractional arithmetic on an 8 bit CPU like SPAM-1 that has no concept of floating point or even 16 bits. In the video Matt mentions using fixed point integer arithmetic and then presents an assembly language impl of mMandelbrot, but that's too far too fast for me to learn from.

So I wrote my own "C" fixed point integer impl of mandelbrot using "8.8" encoding in 16 bits which I should be able to translate to my existing SpamCC compiler and which I should also be able to code in SPAM-1 assembly for speed comparison purposes. I wrote it in 'C' because I want to quickly understand the "8.8" arithmetic and because I expect GCC to be bug free, unlike SpamCC.

The Fixed point Integer implementation I came up with is at  https://github.com/Johnlon/mandelbrot   and there is also a line by line equivalent floating point impl for comparison and learning purposes.

I'll see if I can get SpamCC to implement the same thing. I pretty much expect this to show up a bug in the SpamCC compiler - but then that's a good thing.

.........,,,,,,,,,,,,,,,,,,,,,,,
........,,,,,,,,,,,,,,,,,,,,,,,,
.......,,,,''''''''''',,,,,,,,,,
......,,,'''''''~~=<=~'',,,,,,,,
.....,,'''''''~~~=+[<+~~'',,,,,,
....,,'''''''~~~=+/  ;==~'',,,,,
....,''''''~~~=x/o&  /;:/~'',,,,
...,''''''~===+[        /=''',,,
...''''~= ++::/         /+~''',,
...'~~~=+[ X /           +~''',,
...~~~+:/o               =~''',,
...                     :=~''',,
...~~~++/?               =~''',,
...'~~~=+;   <           +~''',,
...''''~=&::::/         <+~''',,
...,''''''~===+/        /=''',,,
....,''''''~~~= / &  ?[:&~'',,,,
....,,'''''''~~~=+/  [==~'',,,,,
.....,,'''''''~~~=+[<+~~'',,,,,,
......,,,'''''''~~=&=~~',,,,,,,,
.......,,,,''''''''''',,,,,,,,,,
........,,,,,,,,,,,,,,,,,,,,,,,,

I've Made really good progress on porting a the C compiler to SPAM-1.  The capability of the product of my labours is best seen from the integration tests which can be seen in the SPAM-1 assembler test suite...  

https://github.com/Johnlon/spam-1/blob/master/jvmtools/compiler/src/test/scala/asm/VbccAndAssemblerTest.scala

This test suite is pretty reliable in that it uses VBCC to compile various C of increasing complexity each down to SPAM-1 assembler, it then converts the assembly to ROM images and then runs the ROM images on the Verilog simulation.

See actual the SPAM-1 VBCC code is https://github.com/Johnlon/spam-1-vbcc/tree/main/demo - needs doco and also needs a way to keep is up to date with changes in the core VBCC code base.

I will do a vidoe at some point to cover getting started with porting it as there's nothing out there that I found really useful.

There are loads of undone stuff like I support 32 bit integer arithmetic only, I only support add and nothing else yet -  there's probabl;y a ton of language features I've not covered. However, supporting 32 bit is cool on an 8 bit CPU and adding other arith ops isn't hard.  Also I want to add at least 8 bit ops since they are native to the hardware and would be super fast. 

I really think this is something others building such machines would benefit from.

GCC and LLVM were basically impenetrable.

Currently struggling with undertstanding the VBCC C compiler with the idea of creating a back end for SPAM-1.

I read up on LLVM and decided that was probably impossible for me.

VBCC looks a lot simpler, certainly lines of code needed, but it's the style of C code with lots of single letter variables and little commenting in the code and some massive functions. It would be nice if the code were documented with the text that's in the PDF that's been written. I don't like having to switch to a PDF to figure things out.

Still others have done it. 

There is an existing 6502 back end and another 8 bit port called 832 but I really wanted to start by seeing a really minimal impl with no optimisations at all as otherwise it's pretty incomprehensible understanding what's needed. I wrote C for yearas and never regretted moving on and this stuff is hard work.

If (when) I figure it out then I may do a write up or video on what I did if it seems useful to others.

So it's nearly Christmas again and everyone at work is doing Advent Of Code. I did that for a couple of years and eventually I get hacked off with it and bail.

So this year rather than finishing off the hardware for SPAM-1 I'm going to learn something new seeing if I have the energy to write an emulator for SPAM-1 to speed up software development.

 Currently I road test my software on a timing accurate emulation built using my 7400 verilog model. Whilst Verilog been a really useful tool for checking hardware ideas I found that the Icarus Verilog engine is quite slow and so my Sims take too long. For instance running the Chip-8 tertis have via the Verilog model/SIM is super slow motion.

So I have the Verilog for hardware verification but what is want is something faster for simulation for software dev purposes.

So if I have the patience then I will write an emulator in multiple languages and that can be my advent of code.

I'm most of the way there with a typescript impl and have already come to the conclusion that although the language ecosystem has a few niggles the lack of good doco on building a basic typescript app and what certain errors mean is a pain in the arse. Still I'll push ahead. Disclosure I am historically a C/C++/Java/Scala programmer with a bit of assembler and python. 

Once that's done maybe I'll have a look at go and maybe even rust again. My last look at rush left me feeling that it would be unproductive to take a team and adopt it because it's so hard to get a program to even compile successfully, but on the other hand I had the feeling that if you can get a rust program to compile then it probably had relatively few coding bugs in it. Strange tradeoff, getting fired Vs accepting a high bug rate.

I did say to myself I'd try Nim or Elixir but I'd also like to do something more substantial like my emulator in kotlin. I have most experience in the last 10 years with Scala and I'd like to have a better go at kotlin because right now I'm using Java and remembering why I was glad to start functional programming in Scala.

Anyway seasons greetings (if it's tolerable to say that on 2 Dec)

So it's nearly Christmas again and everyone at work is doing Advent Of Code. I did that for a couple of years and eventually I get hacked off with it and bail.

So this year rather than finishing off the hardware for SPAM-1 I'm going to learn something new seeing if I have the energy to write an emulator for SPAM-1 to speed up software development.

 Currently I road test my software on a timing accurate emulation built using my 7400 verilog model. Whilst Verilog been a really useful tool for checking hardware ideas I found that the Icarus Verilog engine is quite slow and so my Sims take too long. For instance running the Chip-8 tertis have via the Verilog model/SIM is super slow motion.

So I have the Verilog for hardware verification but what is want is something faster for simulation for software dev purposes.

So if I have the patience then I will write an emulator in multiple languages and that can be my advent of code.

I'm most of the way there with a typescript impl and have already come to the conclusion that although the language ecosystem has a few niggles the lack of good doco on building a basic typescript app and what certain errors mean is a pain in the arse. Still I'll push ahead. Disclosure I am historically a C/C++/Java/Scala programmer with a bit of assembler and python. 

Once that's done maybe I'll have a look at go and maybe even rust again. My last look at rush left me feeling that it would be unproductive to take a team and adopt it because it's so hard to get a program to even compile successfully, but on the other hand I had the feeling that if you can get a rust program to compile then it probably had relatively few coding bugs in it. Strange tradeoff, getting fired Vs accepting a high bug rate.

I did say to myself I'd try Nim or Elixir but I'd also like to do something more substantial like my emulator in kotlin. I have most experience in the last 10 years with Scala and I'd like to have a better go at kotlin because right now I'm using Java and remembering why I was glad to start functional programming in Scala.

Anyway seasons greetings (if it's tolerable to say that on 2 Dec)

I've added an NES gamepad adapter to the project. This gives me a way to provide interactve input to games and get on with more of the build.

The implementation is based around a PIC micro which handles the I2C comms with the two gamepads.

I also needed a random number generator for the games so with a bit of space on the breadboard and a small addition to the design I added that too.

For more info ...

Hackaday project for the adapter ...

https://hackaday.io/project/181036-nes-controller-interface-using-pic16f18446

As usual I have a verilog simulation of the adapter....

https://github.com/Johnlon/spam-1/blob/master/verilog/gamepadAdapter/gamepadAdapter.v

The hardware schematic is ...

https://easyeda.com/editor#id=c41219d653c64b329350f3ddb47a70a8

The main routine of the microcontroller code is ... 

https://github.com/Johnlon/NESInterfaceAndPeripherals/blob/main/main.c

I wired in the register file, the RAM, the ALU and the memory address registers 

Did it work?

No, an error showed up when I tried running the CHIP-8 Tetris program.  

I spent hours trying to figure our my mistake and in the end it was my wiring of the signals from a 74245 transceiver being off by one pin. Gah !

Anyway, I happily watched SPAM-1 playing Tetris but without any means to interact with the game and having no random number generator (yet) for CHIP-8 it was a major milestone but limited.

It has been great though that I have had literally zero timing issues with this CPU that didn't also show up in the Verilog simulation - this has been a great vindication.

I have two options for integrating a controller into SPAM-1. The first is to provide the hex keypad input via the over the UART as I've done previously and the other is to wire up some games controllers to the hardware; specifically a pair of Nintendo NES controllers. This latter approach helps wean the CPU off the UART interface and eventually I'll add a VGA interface so the UART inteface can be detached entirely.  

Anyway, to fill in a few of the hardware gaps including the lack of games controllers I've come up with a side project to build a parallel interface adapter to NES controllers.

This new device will also provide a whole load of other peripheral functions and it's rather akin to how the 6522 complements the 6502.

Take a look and subscribe for updates.  

So I've also wired in the Register file now which means I have a total memory of 4 bytes.

Not a lot but plenty to adapt my trivial UART program to echo back whatever is typed at the console.

This all seems to work fine at around 2MHz which is where my 555 timer clock maxes out. I'm quite interested to see how fast this thing can be made to run on a breadboard. I'm pretty sure that the critical timing data path is about 200ns half cycle, so I'll see if I can get 5MHz at least from it. The single biggest component in the latency is the 80ns-100ns EEPROM used for the ALU, add to that say another 100ns for other components in th data path and 4-5MHz seems reasonable. It will be interesting to see if the IC's outperform the advertised timings.

I've also wired up all the ALU status register flags to the control logic so all that's left to hook up is the Memory Address Registers and the 64KB RAM.

As soon as I have the RAM in place I'll try running some of my MUST more complicated CHIP-8 programs on SPAM-1 CHIP-8 emulator.

This is a massive achievement for me given I've spent ages building this thing in fits and starts.

I'll need to add a few more things like a random number generator and an IO port to which  can add something like a games controller. And, the thing I'm really interested in is adding some video RAM and VGA output.

Anyway lots to come - but I want to get that CHIP-8 stuff working this week if possible.