Hacker News new | past | comments | ask | show | jobs | submit login

Hmmm, I'm alway really surprised when people comment on threads like this.

How much time did you take to do this, I can read code, but I simply can't casually take a look at code like this and say, hey that's cool, hey that's interesting, I have to concentrate and go line by line, a more debugging state of mind.

There are programmers that can sort of skim read code which just amazes me.

Maybe a few seconds per page? Truly, it's really not that much of an accomplishment -- the comments are superb. I spent 10 years writing games in 6502 assembly, so it feels pretty natural to me.

Keep in mind that a lot of this kind of code follows a pattern : lots of EQU ("equates") statements that link a variable to an address like a port or a signal line. Then you'll have the setup code that gets everything into a basic state where it's ready to run the next part

The big loop Here's where the action's act. Just spin in a big loop, waking up every few hundred cycles or so to check and see if a button is pressed, or the IR chip is sending a byte, or the battery is dead, etc. If you're already doing something, keep doing it until you're done. If you're done, wait around for a while or go do something else.

At least, that's what I come expecting. So when I see code like this that basically fits that model, parsing it is simple.

And, like I said, there are great comments. Even a couple about the round-robin service routine that made me laugh.

" I spent 10 years writing games in 6502 assembly"

Well that would be the answer ...

ha! Yeah, I guess that's the secret -- just do something for a 10,000 hours and it comes naturally. But I still remember the learning process "X and Y index, what's that good for? and why do I need an accumulator? Stack? flags? Rotate?" but once I put that first pixel on the screen and made it move, I was hooked.

what's funny to me is the idea that a person can go do something else for 10 or 20 years (C, C++, DotNet, robotics) and barely touch a line of assembly, yet it's all still there waiting. Maybe it's because game development in 6502asm was at the start of my career and I was so passionate about it, but some things are just ingrained. Even stuff like favoring zero-page memory (the first 256 bytes of memory from $0000 to $00FF) because it can be accessed in one cycle instead of two like indexed, offset or direct access memory. Later, moving to the 68000 family felt like a high-level language (Multiply AND divide opcodes -- you mean I don't have to write a multiply routine?)

But having a asm background has ruined me in some ways. Learning C was straightforward enough, and the jump to C++ felt very natural. However, I find modern languages repulsively inefficient (e.g. Ruby) and struggle with functional programming (Lisp, Elixir). Python feels reminiscent to Applesoft BASIC so while I have to look up the syntax every time, it still feels normal.

somewhat related, since I'm rambling...

I recently read "Making 8-bit arcade games in C" by Steven Hugg and found it brought on a strong dose of nostalgia. It's a really ambitious book that attempts to give a feel for programming various 8bit game platforms, and covers some surprisingly advanced techniques and some basic stuff that schools may not event each any longer (two's complement, run-length encoding, interrupts, etc.). The book has some rough edges and wanders a bit but the good parts easily outweigh the defects. It achieves its aim of

Speaking of game programming -- how about meta-game programming? programming in a game.

I bought a game called TIS-100, and found it to be loads of fun in the same way a mechanic might buy a derelict car and restore it to new condition, or an EE might fiddle around with an old tube radio just for fun. The premise is that an uncle dies suddenly/disappears and leaves a prototype computer behind. Hidden in this computer are some signal processing circuits that hold a secret. You (the player) are tasked with restoring this prototype military computer to unlock the knowledge held within. Very simple, only a handful of opcodes, but it's a challenge and fun in a way I haven't felt since the 80s. Being forced to juggle a variable around on the stack or between indexes or the accumulator an only having a few bytes of storage requires a different type of thinking. Good stuff.

TIS100 definitely isn't for everyone and the challenge curve gets rather steep but once I "got it" it was one of those stay-up-all-night challenges. https://store.steampowered.com/app/370360/TIS100/

great review: https://blog.codinghorror.com/heres-the-programming-game-you...

Perhaps this is a naive question, but why would something like this be written in assembler, and not C or similar?

It seems assembler makes it a bit more complicated without much benefit, and surely there's a compiler for a chip as common as the 6502.

No higher level languages were ever competitive with assembler for the 6502. The stack model of C is not a good fit, as the 6502 machine stack doesn't give any support for reading or writing stack-based variables. Good performance depends on effective use of the zero-page -- the first 256 bytes of memory which have special addressing modes and allow more efficient access. Registers are few and quirky -- accumulator, two index registers which are not quite interchangeable, a byte stack pointer. All operations are 8 bit; 16 bit calcs like for pointers are costly both in code size and speed.

Back in the 80's and 90's the best compiled languages were probably COBAL and Forth. As far as I know nobody seriously used these for games or applications.

There are more recent C compilers, but the code generation is multiples of size and speed (5* maybe?) away from assembler.

Well, Mattel used Forth: https://groups.google.com/d/msg/comp.lang.forth/omi6PUvymEE/...

Because it was cheap: https://groups.google.com/d/msg/comp.lang.forth/LzOasFOyIMg/... (forth not mentioned here; plausibly(?) extrapolating)

Some nearby discussion about 6502 market penetration (I can't determine whether Forth is being discussed here - oh and dodge the cartoon fistfight-cloud wending its way between the posts, happens a lot on this usenet group): https://groups.google.com/d/msg/comp.lang.forth/Yoa9u55cpbo/...

For those into modern (!) medium-level 6502 programming, PLASMA [0] may be better (syntax-wise) than Forth and better (size and performance-wise) than C.

[0] https://github.com/dschmenk/PLASMA

Ha! Yes, COMAL. Thanks.

Because the cheapest chips have very limited code and memory space.

And back when this product was released, optimizing compilers were really poor by comparison with a human for these tasks.

Today you probably wouldn't bother with assembly for all but the most timing critical parts.

From my reading of the code, this microcontroller has 128 bytes of RAM.

Compilers just didn’t get as good of code as assembler. Really, for the 6502, 6809, and space constrained 68000s assembler was really fun and just worked. Have a decent macro assembler and some discipline and assembler was pretty easy and understandable. Heck, I’ve seen C code that was a whole lot less clear or understandable.

You'd be surprised how much overhead a compiler adds even for something like C. Also you can do things in pure assembly that you just can't do in C (w/o inlining assembly haha).

Well written code in any high level language is basically Chinese to most people.

*low level

I can skim a lot of things, but they're all a lot higher than assembly.

Applications are open for YC Summer 2019

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