Speaking as one grizzled veteran of 1980s coin-op, I've seen with my own eyes a teenager a couple of years older than me "roll the machine".
"Rolling the machine" meant scoring 100,000. At that point, the machine score went from 99,999 back to 0.
The way I saw it done, the player left 1 asteroid on the screen so as not to advance to the next wave.
The player then parked his ship near one of the corners.
After some time, a saucer would appear and the player would directly fire on it using the shortest route possible which, sometimes, was not in the obvious direction of the ship because of screen wraparound.
Wraparound meant, for example, that the shortest distance between the upper right corner and the lower left and right corners was northeast, not southwest.
Saucers always shot at the spaceship on-screen, and so would almost always lose.
We younger observers stood in awe when the machine score rolled over. [0]
We Asteroids snobs always considered this to be cheating. I could never roll the machine in the old days, but nowadays I can roll the emulator without lurking.
Another strategy I've seen was to again, destroy all but one asteroid, and then accelerate full speed vertically, and wait for saucers and pick them off, while being a fast moving target the saucers were not great at hitting.
Unfortunately, after this strategy became popular, Atari released updated ROMs, with much better targeting from the small saucers, and the strategy stopped working. I suspect this also invalidated the corner strategy.
No two ways about it, you've got to learn to drive the ship. Trying to hold the center is nigh impossible. Also, the cannon has a short cool-down after 5 rapid shots, so you need to get that 1-2-3-4-5-pause cadence baked into muscle memory.
That said, I never managed to last very long on that cabinet.
Seeing 6502 assembly language made me feel a bit nostalgic - sixteen year-old me spent quite a lot of time coding in it for a year or so, first on my Vic 20 then on an Acorn Electron. I was surprised to find that I can still almost read it and, browsing an instruction set reference just now, I'm impressed all over again by its succinctness.
Wiki has a few notes on the game hardware and implementation at [1]. The Quadrascan graphics processor, which presumably ran the code in 'asteroids_vector_rom.asm', doesn't seem to be well described on the net (as far as I can tell) but there's a hardware service manual for the colour version at [2]. It seems to me from reading it that the vector processor was tightly integrated with the CRT tube, and the manual has lots of scary/exciting warnings about high voltages and potential tube implosion.
> sixteen year-old me spent quite a lot of time coding in it for a year or so
I always assumed this was what I would be doing for a living when I grew up - I was honestly a little disappointed that high-level languages had progressed so far by the time I joined the workforce.
I think deep knowledge of any assembly helps with any type of programming. You'll have very good perspective of how the CPU and RAM really work, even if modern CPUs are more complex and you have caching and out-of-order in the mix.
> I think deep knowledge of any assembly helps with any type of programming.
I very much agree. I've never written any assembly-level code as part of my work, but having an appreciation of the concepts at that level helped me as newbie C/C++ developer in the mid nineties.
Nowadays I work slmost entirely in the .net stack, but even there having even a shallow knowledge of the "next level down" helps - the concept of a jitted language only really makes sense if you grok what the jitter is emitting. And the idea of compiler optimisations is easier to understand if you get that language constructs can be realised in different ways, with different costs, as machine code.
Abstraction layers are certainly easier to think about if you see them (even shallowly) from both sides.
You might find ARM assembly interesting, especially the simpler 16-bit "thumb" subset used on various embedded devices (eg, RP2040). It was apparently inspired by the 6502 ISA, and still exhibits many similarities to this day.
21 comments
[ 1.7 ms ] story [ 62.7 ms ] threadhttps://github.com/historicalsource/asteroids
Speaking as one grizzled veteran of 1980s coin-op, I've seen with my own eyes a teenager a couple of years older than me "roll the machine".
"Rolling the machine" meant scoring 100,000. At that point, the machine score went from 99,999 back to 0.
The way I saw it done, the player left 1 asteroid on the screen so as not to advance to the next wave.
The player then parked his ship near one of the corners.
After some time, a saucer would appear and the player would directly fire on it using the shortest route possible which, sometimes, was not in the obvious direction of the ship because of screen wraparound.
Wraparound meant, for example, that the shortest distance between the upper right corner and the lower left and right corners was northeast, not southwest.
Saucers always shot at the spaceship on-screen, and so would almost always lose.
We younger observers stood in awe when the machine score rolled over. [0]
We dubbed this "playing the corners".
[0] Wikipedia calls this the "lurking exploit": https://en.wikipedia.org/wiki/Asteroids_(video_game)#Lurking...
I was just referencing the line from the movie Pixels, staying in the middle probably doesn't work that well.
Didn't know it was a quote. Added to my queue!
Unfortunately, after this strategy became popular, Atari released updated ROMs, with much better targeting from the small saucers, and the strategy stopped working. I suspect this also invalidated the corner strategy.
That said, I never managed to last very long on that cabinet.
Due to needing the extra shots for defense, a 1-2-pause or 1-2-3-pause cadence can be advantageous.
(inflation adjusted)
Wiki has a few notes on the game hardware and implementation at [1]. The Quadrascan graphics processor, which presumably ran the code in 'asteroids_vector_rom.asm', doesn't seem to be well described on the net (as far as I can tell) but there's a hardware service manual for the colour version at [2]. It seems to me from reading it that the vector processor was tightly integrated with the CRT tube, and the manual has lots of scary/exciting warnings about high voltages and potential tube implosion.
[1] https://en.wikipedia.org/wiki/Asteroids_(video_game)#Hardwar...
[2] https://www.manualslib.com/manual/689160/Atari-Quadrascan-92...
I always assumed this was what I would be doing for a living when I grew up - I was honestly a little disappointed that high-level languages had progressed so far by the time I joined the workforce.
I very much agree. I've never written any assembly-level code as part of my work, but having an appreciation of the concepts at that level helped me as newbie C/C++ developer in the mid nineties.
Nowadays I work slmost entirely in the .net stack, but even there having even a shallow knowledge of the "next level down" helps - the concept of a jitted language only really makes sense if you grok what the jitter is emitting. And the idea of compiler optimisations is easier to understand if you get that language constructs can be realised in different ways, with different costs, as machine code.
Abstraction layers are certainly easier to think about if you see them (even shallowly) from both sides.
[1] https://www.jmargolin.com/vgens/vgens.htm
[2] http://www.jmargolin.com/xy/xymon.htm