Was originally just planning on using the TFT to debug the frame buffer logic (which is next to write) while generating #Retroputer's screen… (I _think_ this will be easier to debug any VGA output I add if I know the logic to build the frame buffer is correct.)
But it's such a cute screen that I'm toying with the idea of making a mini-Retroputer with a tiny keyboard and case.
I think that would be retro-licious.
#Retroputer #FPGA Update
Bought a 2.4" TFT ILI9341 from @adafruit and connected it up via 4-line SPI using #Alchitry Br (breakout board). I added an I/O device so the CPU can send D/C select bits and data bytes using a FIFO buffer.
After a bit of a false start (involved adapting Adafruit's init sequence and experimentation), we have something coherent on the screen!
Super slow to fill the screen w/ #BASIC (using OUT commands), but validates that my understanding mostly matches reality. Woot!
#Retroputer #FPGA successfully ran a modified sieve of Eratosthenes on a modified kernel (for terminal output). Woohoo!
On screen you can see some code (full code here: https://github.com/kerrishotts/retroputer/blob/workers/basic/examples/sieve.bas), along with the primes below 1000.
Even though the internal timer is not accurate, it's close enough for this—it took 22 seconds w/ an incomplete integer BASIC. Compare to the #Commodore64 which took 34 seconds.
Not super fast, but right in line with the era! Plenty of room for optimizations later.
Success! #Retroputer #fpga #BASIC is executing commands from the console using a patched kernel.
Far from perfect—without MUL implemented, parsing integers doesn't work, so you can't have more than one line of code, nor can it do math (it's always zero!), and occasionally it gets input characters mucked up (debugging that should be fun)…
But it took a command and did what I asked! Woohoo! Long way to go, but feels good :-) No more work on it tonight, but happy with the progress so far.
The moment when you realize the really strange behavior after you press a key and #retroputer #fpga reads it is the CPU doing all the right things...
you just advanced the wrong FIFO and so the poor machine thinks you're really, really, really good at pressing the same character continuously…
and the resulting behavior is to fill up screen memory really quickly and need to scroll it.
No, it hasn't gone off into some strange random loop—it's doing exactly what I told it to do.
Lol!
Just to compare w/ the emulator version of Retroputer -- still a long ways to go (will need to figure out the video generator & some sort of output signal... preferably HDMI, but that’s a ways off still)
Even with a long way to go, it feels really nice to have something in hardware that's doing the same things as the emulated version!
#Retroputer #fpga is successfully running the init portion of Retroputer BASIC. Welcome text and "READY." are getting successfully printed to both the console and screen memory (at 0x10000).
Retroputer doesn't use ascii — it has its own graphical symbols above 0x7F, so console output isn't ideal. Also not handling escape sequences correctly on the console.
Next up: wire up the serial input to simulate a keyboard and see if it can actually run BASIC programs... may need more math support tho.
For the first time I've been able to load #Retroputer's ROM* onto the #fpga via the serial port and have the mostly complete CPU attempt to boot & run the kernel.
Does it work? Hell no — POP is broken which immediately borks MM (memory mapper), BR jumps to the wrong address, and I'm sure there are a thousand more bugs.
But it was running real** code... and then corrupting memory... before crashing.
I count that as a win!
* very incomplete
** what does real mean for a fantasy computer anyway?
#Retroputer #fgpa is actually executing instructions! A limited set, to be sure, but proof that the CPU is able to read both ROM & RAM to fetch an instruction, decode the instruction, handle "fixups" to account for some "fun" instruction sizes that are hard to encode, execute the instruction, including using the ALU and working with flags, and repeat that all again for the next instruction. Which means I can, yet again, make the world's most complicated counter! ;-)
#fpgadev is too much fun :-)
I must also say, learning fpgas kinda feels like when I was a kid learning to program my #Commodore64... fun & frustrating, exciting & so much potential... the highs when it works, the lows when it doesn't, the "bang-head-on-desk" moments when you realize it's doing exactly what you're telling it to do and you got the braces mixed up and had the logic in the wrong place…
It's nice experiencing that feeling! (Except for the actual "bank head on desk" bit. That smarts a bit!)
Kerri Shotts