5 ms·

How did you do that? Did you bootstrap it with hand-assembled code or some Basic? Did you assemble the assembler with itself?

dhosek 4y ago
When I was in high school, I hand-assembled my 6502 code. I’d write it longhand out on graph paper, then write down addresses in the leftmost column, opcodes in the middle & finally I’d type in all the hex from the Apple Monitor. It was slow, painstaking and error-prone, but it made for clear thinking about how the program worked before I sat at the computer.
- jacquesm 4y ago
  It probably also really honed your ability to simulate a CPU in your head. That's invaluable when looking at code, to build up a mental model of what it really does (rather than what the comments say it does).
- colanderman 4y ago
  I did the same (after reverse-engineering the opcodes by filling memory with sequential bytes and listing the output) until I discovered that the Apple //e (and maybe others) included a built-in mini assembler: https://www.youtube.com/watch?v=yJp2TnKhnzY https://www.youtube.com/watch?v=yJp2TnKhnzY
  - dhosek 4y ago
    The Mini Assembler was part of the Apple ][ ROM with Integer BASIC but not on the ][+ ROM with AppleSoft BASIC. I think I eventually got a floppy from someone at a math competition or something like that which had a loadable Integer BASIC image that could be loaded into the RAM of a 64K Apple ][+ or //e, but that was not long before I graduated high school and at a point where I was doing most of my programming on a VM/CMS system (and then later VAX/VMS).
    - colanderman 4y ago
      The //e "Enhanced" model (which I had) had the mini assembler built-in. [1] The monitor even had a shortcut to start it -- "!". (Had to Google to remember this bit of trivia again -- funnily enough turned up this [2] HN comment I replied to 9 years ago with nearly the exact same comment I made above.) [1] https://support.apple.com/kb/TA39083?locale=en_US&viewlocale=en_US https://support.apple.com/kb/TA39083?locale=en_US&viewlocale... [2] https://news.ycombinator.com/item?id=6200660 https://news.ycombinator.com/item?id=6200660
- jdswain 4y ago
  There’s a story about someone watching Woz entering hex into the computer directly to write a program, and every now and then he’d pause for a little. They asked him why and he said he was calculating the offset for a forward branch, which would mean he’d have to think of all the code up until the branch destination and count the bytes. Then he could carry on and enter those bytes.
  - jacquesm 4y ago
    That's pretty amazing. I would do something similar but easier: invert the branch do a jmp [word] and then continue as though nothing changed. Then, afer you know the destination address fill it into [word]. That way you don't end up running out of memory (your own, not the computer's). But Woz's trick is far more impressive.
jacquesm 4y ago
Getting it to the point where it would assemble itself was pretty much the goal of the whole exercise. Hand assembly with Leventhal's book (which I still have :) ) to get it to work, usually one subroutine at the time. And then once it work things got much quicker, the bigger problem then was a proper editor. https://www.amazon.nl/Assembly-Language-Programming-Lance-Leventhal/dp/0079310354 https://www.amazon.nl/Assembly-Language-Programming-Lance-Le... Memory management was a tricky part and macro expansion only got done after the whole thing worked (that would have saved a lot of time but I couldn't see the wood for the trees at that point). The nasty part was that instructions were variable length so you could get into these weird errors where your initial guess for a jump target was too small, which would then move everything else as well, which might lead to other jumps becoming too small. I don't have the code any more but I think I fixed that by making all the jumps long jumps initially. A bit wasteful but that way I could at least get it to work in one pass. Later on when I got better at assembly that sort of thing got fixed. The end product was endless 'data' statements that were poked into memory at 48K and up, right over the basic interpreter, which we had figured out a way to page out and replace from software. This later led to an annotated version of the basic that came with that computer (a version of MS Basic) and subsequently a replacement interpreter with a lot of built in goodies (double speed tape interface, a whole raft of new statements and functions). Good times! Shout out to my friend Henri G. who did at least half of that work, we had identical home computers (Dragon 32) and worked together a lot on this. He probably still has his in working order :)
- tambourine_man 4y ago
  That was awesome. You should consider expanding it to a blog post or podcast. This is good stuff.
  - jacquesm 4y ago
    It was good stuff, it's a bit dated now, to put it mildly. Those neurons haven't fired for decades.
- rightbyte 4y ago
  > ... initial guess for a jump target was too small ... Ye that one is annoying. I am making a VM compiler right now, and I have the same problem. I would probably have to make some intermediate tree to solve it without making every jump a "far jump". Moving instructions is a headache :)
WalterBright 4y ago
The company I worked for in the 1970s, Aph, developed a lot of embedded systems. Their secret weapon was they developed macro assemblers for the various microprocessors in BLISS on a PDP-10. (I think Dan O'Dowd, yes, that Dan! developed them.) With a proper macro assembler, as good as the ones on mainframes, that ran on a mainframe, you could develop code much faster.
- jacquesm 4y ago
  A properly used macro assembler is a halfway house towards a high level language.

dhosek 4y ago

When I was in high school, I hand-assembled my 6502 code. I’d write it longhand out on graph paper, then write down addresses in the leftmost column, opcodes in the middle & finally I’d type in all the hex from the Apple Monitor. It was slow, painstaking and error-prone, but it made for clear thinking about how the program worked before I sat at the computer.

jacquesm 4y ago
It probably also really honed your ability to simulate a CPU in your head. That's invaluable when looking at code, to build up a mental model of what it really does (rather than what the comments say it does).
colanderman 4y ago
I did the same (after reverse-engineering the opcodes by filling memory with sequential bytes and listing the output) until I discovered that the Apple //e (and maybe others) included a built-in mini assembler: https://www.youtube.com/watch?v=yJp2TnKhnzY https://www.youtube.com/watch?v=yJp2TnKhnzY
- dhosek 4y ago
  The Mini Assembler was part of the Apple ][ ROM with Integer BASIC but not on the ][+ ROM with AppleSoft BASIC. I think I eventually got a floppy from someone at a math competition or something like that which had a loadable Integer BASIC image that could be loaded into the RAM of a 64K Apple ][+ or //e, but that was not long before I graduated high school and at a point where I was doing most of my programming on a VM/CMS system (and then later VAX/VMS).
  - colanderman 4y ago
    The //e "Enhanced" model (which I had) had the mini assembler built-in. [1] The monitor even had a shortcut to start it -- "!". (Had to Google to remember this bit of trivia again -- funnily enough turned up this [2] HN comment I replied to 9 years ago with nearly the exact same comment I made above.) [1] https://support.apple.com/kb/TA39083?locale=en_US&viewlocale=en_US https://support.apple.com/kb/TA39083?locale=en_US&viewlocale... [2] https://news.ycombinator.com/item?id=6200660 https://news.ycombinator.com/item?id=6200660
jdswain 4y ago
There’s a story about someone watching Woz entering hex into the computer directly to write a program, and every now and then he’d pause for a little. They asked him why and he said he was calculating the offset for a forward branch, which would mean he’d have to think of all the code up until the branch destination and count the bytes. Then he could carry on and enter those bytes.
- jacquesm 4y ago
  That's pretty amazing. I would do something similar but easier: invert the branch do a jmp [word] and then continue as though nothing changed. Then, afer you know the destination address fill it into [word]. That way you don't end up running out of memory (your own, not the computer's). But Woz's trick is far more impressive.

jacquesm 4y ago

Getting it to the point where it would assemble itself was pretty much the goal of the whole exercise. Hand assembly with Leventhal's book (which I still have :) ) to get it to work, usually one subroutine at the time. And then once it work things got much quicker, the bigger problem then was a proper editor. https://www.amazon.nl/Assembly-Language-Programming-Lance-Leventhal/dp/0079310354 https://www.amazon.nl/Assembly-Language-Programming-Lance-Le... Memory management was a tricky part and macro expansion only got done after the whole thing worked (that would have saved a lot of time but I couldn't see the wood for the trees at that point). The nasty part was that instructions were variable length so you could get into these weird errors where your initial guess for a jump target was too small, which would then move everything else as well, which might lead to other jumps becoming too small. I don't have the code any more but I think I fixed that by making all the jumps long jumps initially. A bit wasteful but that way I could at least get it to work in one pass. Later on when I got better at assembly that sort of thing got fixed. The end product was endless 'data' statements that were poked into memory at 48K and up, right over the basic interpreter, which we had figured out a way to page out and replace from software. This later led to an annotated version of the basic that came with that computer (a version of MS Basic) and subsequently a replacement interpreter with a lot of built in goodies (double speed tape interface, a whole raft of new statements and functions). Good times! Shout out to my friend Henri G. who did at least half of that work, we had identical home computers (Dragon 32) and worked together a lot on this. He probably still has his in working order :)

tambourine_man 4y ago
That was awesome. You should consider expanding it to a blog post or podcast. This is good stuff.
- jacquesm 4y ago
  It was good stuff, it's a bit dated now, to put it mildly. Those neurons haven't fired for decades.
rightbyte 4y ago
> ... initial guess for a jump target was too small ... Ye that one is annoying. I am making a VM compiler right now, and I have the same problem. I would probably have to make some intermediate tree to solve it without making every jump a "far jump". Moving instructions is a headache :)

WalterBright 4y ago

The company I worked for in the 1970s, Aph, developed a lot of embedded systems. Their secret weapon was they developed macro assemblers for the various microprocessors in BLISS on a PDP-10. (I think Dan O'Dowd, yes, that Dan! developed them.) With a proper macro assembler, as good as the ones on mainframes, that ran on a mainframe, you could develop code much faster.

jacquesm 4y ago
A properly used macro assembler is a halfway house towards a high level language.