- My theory: The article mentioned an earlier prototype used 384×256, a 3:2 ratio. 512×342 is the even height that gives closest to a 3:2 ratio with a pixel width of 512.
- Various folks have disassembled the Asteroids arcade ROM. This was helpful recently when I wondered how collision detection was implemented. It turns out to be a sort of axis-aligned octagon intersection algorithm that was easy to implement with just a few adds, subtracts, & compares (6502 doesn't have multiply or divide).
https://github.com/nmikstas/asteroids-disassembly/blob/maste...
(the commentary of the same lines at https://computerarcheology.com/Arcade/Asteroids/Code.html is incomplete by comparison)
My interpretation of the code is that it leads to an effective shape like the one in this graph, where the overall size is determined by the sum of the size of the two involved objects:
- Commodore version conserved (& enhanced) @ https://github.com/asig/MAD_computer_program
- I went looking for old screen capture programs. The first place I checked was simtel (https://archive.org/details/SIMTEL_0692), and found multiple copies of an EGA screen capture program from 1987, such as "CAPTURE.ARC 21504 06-11-87 Screen capture to disk file (from PC Magazine)". There was also an earlier dated file for dumping Hercules screens to Epson printers.
The sibling point about digital prepress is a relevant one too: So you have a file on your computer with the contents of a screen .. whatcha gonna do with it anyway?
- also https://intarch.ac.uk/journal/issue59/3/index.html [linked from spc746's article]
- Related: This is powered by 'c2t', open source software on github. I made a web-based port of c2t that can take a .dsk file from your computer and produce a sound file: https://www.unpythonic.net/web-c2t/
just noticed that if you feed it a .woz file, it segfaults. nice.
source: https://github.com/jepler/web-c2t with the heavy lifting by https://github.com/datajerk/c2t
The pixel resolution is 512x342. The Macintosh Service Source https://www.macdat.net/files/pdf/apple/servicesource/macinto... page 76 says to do the following:
adjust the width control until the raster is 7 inches (177.8 mm) wide
adjust the height control until the raster is 4.7 inches (119.4 mm) high
This gives a physical aspect ratio of 1.489...:1, while the pixel ratio is 1.497...:1 (0.5% off square)
It makes a pixel 1/73.14...inch wide and 1/72.77in tall
Still, as a sibling comment points out: Once you decide you can hit your screen redraw time with around 170,000 pixels on the screen, that you will use a 9" 3:2 CRT, that you want one pixel to be close to one printer's point (1/72 inch), and that your framebuffer needs to be oriented around 16-bit or maybe 32-bit quantities, you aren't left with a lot of options. 480 pixels is not quite enough to show the width of a standard US letter page with 1/2 inch left and right margins, 512 pixels is (and can even fit a scroll bar)
Note: I don't have any evidence that the choice of a 9" screen or a 3:2 ratio preceded the choice of pixel resolution, it could have happened the other way around.
Also blowing a hole in one leg of my argument: MacWrite 1.0, as screenshotted at https://lowendmac.com/2006/macwrite-1-defining-word-processi..., used 80 pixels per inch for the onscreen ruler, not 72! With this scale, 7 inches (US letter paper with 1" left and right margins) plus a scrollbar fits in 512 pixels.