
Show HN: CHIP-8 console implemented in FPGA - pwmarcz
https://github.com/pwmarcz/fpga-chip8
======
akamoonknight
I saw the portion of the description that talked about BCD conversion. One
magical method I've used in the past on FPGAs is the Double Dabble algorithm
[0]. Seems like your implementation is succinct enough to not need
improvements, but if you're looking for resource usage reductions it might
help out. In addition, always enjoy talking about good ole Double Dabble, such
a fun name for an algorithm.

[0]
[https://en.wikipedia.org/wiki/Double_dabble](https://en.wikipedia.org/wiki/Double_dabble)

------
arcticbull
Hah, cool, I'm working on one right now too. Got most of the way through it,
it's an awesome learning experience about what you can achieve with FPGAs and
what the limitations are. Especially implementing the 'complex' instructions
like drawing.

~~~
Koshkin
The way it's usually done now is, people simply go with implementing some kind
of a PSM ("programmable state machine"), which is essentially a tiny
microprocessor, and then let the program do the, say, drawing (by either
setting bits in video memory, sending commands to an SPI display, or directly
generating VGA signals).

~~~
FPGAhacker
It gets the job done and can be efficient from a development perspective. If
high speed (ops/sec) operation isn't required, this sort of approach can be
pretty useful.

I needed to do a "headless" build of an FPGA where the software wasn't ready
yet, but the RF guys needed the FPGA operate as if software was there and
running the show. I did a sort of PSM as you call it that was like a really
basic processor. Peek, Poke, Test, Jump, Inc, Dec. It was very helpful for
debug, and the RF guys were able to make progress weeks before software was
ready to go. Plus the software builds were very focussed on flight, and not
doing special configurations to help others figure out corner case issues.

For a hobby project, depending on the goals of why one is doing the project, I
think it's a fine approach. Gets results fast which helps with motivation and
momentum to learn more difficult things. It's also a natural bridge for people
coming from a software background.

------
jerrysievert
I think that the best part of this for me is that they managed to map pins
5-12 to match the screen SPI pins. I suppose that once you have a ground pin,
the rest can be mapped in software (with the power being a high output), but
it's still pretty cool to see.

~~~
pwmarcz
Author here, thanks! What I'm doing in the code is outputting 1 to the VCC pin
and 0 to GND, and that seems to be enough:

[https://github.com/pwmarcz/fpga-
chip8/blob/2168aeea3b1cef3ba...](https://github.com/pwmarcz/fpga-
chip8/blob/2168aeea3b1cef3ba421f6becf7cfc476275699e/chip8.v#L34)

~~~
jerrysievert
yeah, that definitely makes sense. I'll have to start doing that when I
connect screens or sensors: much cleaner, thanks for the inspiration!

------
dancek
Thanks for sharing! I spent one day this autumn getting the open source
toolchain working and dimming the onboard led on an upduino. Turns out testing
on hardware when you don't know what you're doing is cumbersome (surprising!).
Your codebase (hardware definition base?) and tests will make good reading
material.

~~~
pwmarcz
That's great to hear! Just don't take my code as an example of any good
practices, I have no background in HDLs and this is my first big project, so
it's all very hacky.

