[HN Gopher] Behaviour Driven Development with 6502 code
       ___________________________________________________________________
        
       Behaviour Driven Development with 6502 code
        
       Author : ingve
       Score  : 51 points
       Date   : 2023-06-13 22:10 UTC (2 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | Multicomp wrote:
       | 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.
        
         | kevin_thibedeau wrote:
         | 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.
        
         | djmips wrote:
         | <record scratch> RPI Pico is like a supercomputer on a
         | continuum with 6502 and 386.
        
       | PaulHoule wrote:
       | You might be suprised at how conceptually clear and accessible
       | assembly language for that kind of machine can be.
        
       | zabzonk wrote:
       | 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.
        
         | lowbloodsugar wrote:
         | >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!
        
           | zabzonk wrote:
           | 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.
        
       | wellytopness wrote:
       | 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...
        
       ___________________________________________________________________
       (page generated 2023-06-15 23:02 UTC)