Behaviour Driven Development with 6502 code | Hacker News Reader

Behaviour Driven Development with 6502 code

github.com

55 pointsingve9 comments

This is super cool. After seeing the Ben Eater videos and marvelling at just how much results the 90s era DOOM games etc. managed to get out of super limited hardware, it makes me want to purposefully program my applications for super limited devices like the 6502 or RPI Pico or a 386-based PC.

But it's a tug of war between desire to have the option to run my programs on such ancient hardware (which will be blazing fast on modern hardware! I say to myself) and my desire to use familiar toolkits and try for cross-platform gains where I can get them (build the codebase once and just throw it and a crappy front end on my phones and my windows PCs and my linux PCs too and my .... etc.)

so something that bridges the modern workflows I admire like BDD comprehensive test suites but targets old school hardware like the 6502 is catnip for me.

Write in C/C++. They target older hardware well and you can still use modern tooling. The key is to not introduce multiple layers of bloat that makes our multi-core pocket supercomputers slower than an 80s PC.

<record scratch> RPI Pico is like a supercomputer on a continuum with 6502 and 386.

If someone sold RPI Pico back in 1980s when we were using 8-bit CPUs like 6502 then that would have been like supplying alien magic technology.

i wrote a vt100 and combined kermit file transfer client/server in pure 6502 assembler back in the mid 1980s on a bbc micro (6502 based). the original was written in bbc basic but was far too slow.

i'm ashamed to say there were no tests at all (but async coms and things like terminal emulators are pretty hard to test anyway), but i got zero bug reports. though of course bug reports were much harder to file back then.

>though of course bug reports were much harder to file back then.

Especially if your terminal software is broken. =) No bugs filed this week again!

true enuf, but i always figured that if edt and eve (vax text editors) worked, then the vt100 stuff was probably ok. and if i could run my kermit implementation against the dec10/20 implementations, that was probably ok too (dec20 was the reference platform for kermit).

but i must say that whatever i have written i have always longed for automatable tests. and you should too.

Oh this is one of my projects, thanks for the boost. :) This video goes into some more detail about how enhancements to Cucumber help to build more descriptive tests: https://www.youtube.com/watch?v=fdeVc2q6oB0&list=PLAAYJEX1Jb...

You might be suprised at how conceptually clear and accessible assembly language for that kind of machine can be.

Reply on news.ycombinator.com