Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: CHIP-8 console implemented in FPGA (github.com)
120 points by pwmarcz 3 months ago | hide | past | web | favorite | 9 comments

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

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.

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).

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.

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.

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:


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

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.

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.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact