7 ms·
Why the original Macintosh had a screen resolution of 512×324
- johnklos 1y agoThe title is incorrect, because b&w Macs have 512×342 resolution, not 512x324. It wouldn't've been too crazy had Apple went with 64K x 4 chips, so they'd've just needed four of them to get 128 KB at a full 16 bits wide. 512x342 was 16.7% of 128 KB of memory, as opposed to 18.75% with 512x384. Not much of a difference. But having square pixels is nice.
- jerbear4328 1y agoIt looks like it's just the HN submitted title which is wrong (currently "Why the Original Macintosh Had a Screen Resolution of 512×324"). The article's title is "Why the Original Macintosh Had a Screen Resolution of 512×342", and "324" doesn't appear anywhere on the page.
- bscphil 1y agoLooks like someone is reading Hacker News comments and editing the page - archive.org captured the page probably mid-edit, and it says "324" in one place: https://web.archive.org/web/20250527202300/https://512pixels.net/2025/05/original-macintosh-resolution/ https://web.archive.org/web/20250527202300/https://512pixels...
- 90s_dev 1y ago> wouldn't've Really, John? You really had to make me parse that word?
- brookst 1y agoYou version of shouldn’t’ve’s punctuation isn’t like that?
- webstrand 1y agoIt's a great word, I use it all the time.
- kevin_thibedeau 1y agoIt usually isn't transcribed with Klingon orthography.
- 90s_dev 1y agoI bet you also work for the IRS don't you
- kragen 1y agoYou shouldn't've tho. Who'd've complained if you hadn't've?
- kstrauser 1y agoWho’d’ve thought?
- JKCalhoun 1y agoWorth adding? The (almost [1]) omni-present menu bar ate 20 pixels of vertical space as well — so you could say the application had 322 of useable rows. [1] To be sure, many games hide the menu bar.
- hyperhello 1y agoThe article really didn’t explain why they picked that number.
- bryanlarsen 1y agoFor efficient graphics routines on a 32 bit machine, it's important that the scan line direction (aka horizontal for normally mounted CRT's) be a factor of 32, preferably one that's a power of 2. The article mentions the desire for square pixels. So presumably they chose the horizontal resolution first and then chose the vertical resolution that gave them square pixels for a 512 pixel horizontal resolution.
- nssnsjsjsjs 1y agoIt was 32bit?!
- mayoff 1y agoThe data and address registers of the 68000 were 32 bits wide.
- tom_ 1y agoThe 68000 is 16 bit internally, and can access memory only 16 bits at a time, but the instruction set was designed with future iterations in mind, and most instructions can operate on 32 bit quantities - with a performance penalty. (Because in essence it has to do the work in 2 stages.) Whether this is enough to make it count as actually 32 bits is one for the philosophers.
- rsynnott 1y agoThe 386SX was a similar story, and is normally thought of as basically 32bit. I think the perception difference may be down to timing; the 386SX came out _after_ the DX (with 32 bit data bus), so was thought of as a cheap 32bit chip, vs the 68000 which started off life with a 16bit data bus. (Fun fact: there was also the 68008, which was a 68k with an 8 bit bus!)
- russellbeattie 1y agoThe answer is probably more akin to: "As small of a resolution as they could make it without Steve bitching at them about it."
- codr7 1y agoApple could use some Steve drama, they seem to be moving backwards lately.
- perching_aix 1y agoRegardless of whether we go with 512x324, 512x342, or 512x384, the claim of 72 PPI (exact) and 9" of diagonal size (exact) are not simultaneously possible. Extremely nitpicky thing I know, but this kinda stuff really bugs me, could somebody please clarify what was the real size (and/or PPI) here? For reference: 512x324 @ 72 PPI = 8.42" (or 214 mm) (rounded) 512x342 @ 72 PPI = 8.55" (or 217 mm) (rounded) 512x384 @ 72 PPI = 8.89" (or 226 mm) (rounded) The first two don't even yield an integer result for the number of diagonal pixels, let alone yield an integer multiple of 72. Or would there be bars around the screen, or how would this work?
- pavlov 1y agoFor CRTs, the diagonal measurement was of the physical tube. The actual viewable area was smaller. Part of the tube’s edges were covered by plastic, and there was always also some margin that wasn’t used for picture so it was just black. It was a 9” tube with 3:2 aspect ratio. Your calculation of a 8.5” image at 72 dpi sounds right.
- Suppafly 1y ago>For CRTs, the diagonal measurement was of the physical tube. The actual viewable area was smaller. That's also why TVs and monitors of that era always seemed smaller than advertised. I remember having to explain that to a lot of people.
- deleted 1y ago[deleted]
- msephton 1y agoYou're quite right, the screen would be centred with margin/border around it. Whilst the CRT is 9", according to period repair guides the screen should be adjusted so that the visible image was 7.11" x 4.75", pretty much exactly 1.5:1. This meant 72dpi, which was to match PostScript point size for print output and WYSIWYG. So it's your 8.55" diagonal. Some classic Macintosh users today are unaware of this screen size reasoning, or don't agree with it, and stretch the screen to fill the whole CRT. Yikes! BTW, I posted pretty much the same info earlier today at https://news.ycombinator.com/item?id=44105531 https://news.ycombinator.com/item?id=44105531 — what synchronicity!
- Reason077 1y ago> “To minimize CRT flicker, Apple worked to achieve a vertical refresh rate of 60 Hz” … a limitation that many Macs, and even some iPhones, are still stuck with over 40 years later!
- perching_aix 1y agoIt's always surprising for me to see people regard 60 Hz CRT as "flicker-free", or "minimal flicker", etc. Whenever I saw a CRT running at 60 Hz, I'd be immediately be able to tell. Always used at minimum 75 Hz but preferably 85 Hz at home (early 2000s, Windows).
- Suppafly 1y ago>Whenever I saw a CRT running at 60 Hz, I'd be immediately be able to tell. Always used at minimum 75 Hz but preferably 85 Hz at home (early 2000s, Windows). Same, I remember installing some program that would let you quickly change the display settings on basically every computer I ever interacted with. It was especially bad if the crt was in a room with fluorescent lighting.
- bluGill 1y agoIf your lighting and display have flicker at mathematical ratio you will notice unless the frequency is extremely high. 1:1 is most likely because it is easy to sync lights and the CRT to the AC line frequency which is 60Hz in the US (50Hz in Europe). 1:2 (used to be somewhat common) or 4:5 ratios would also cause issues. Though now that I think of it, the CRT should be syncing with the signal and there is no reason that sync needs to be related to the AC line, but it does anyway (all the computers I know of generate their own sync from a crystal, I have no idea where TV stations get their sync but I doubt AC line frequency).
- meatmanek 1y agoWikipedia for NTSC alludes to a couple reasons why you'd want your refresh rate to be based on your power line frequency: > Matching the field refresh rate to the power source avoided intermodulation (also called beating), which produces rolling bars on the screen. Synchronization of the refresh rate to the power incidentally helped kinescope cameras record early live television broadcasts, as it was very simple to synchronize a film camera to capture one frame of video on each film frame by using the alternating current frequency to set the speed of the synchronous AC motor-drive camera. (I suspect shows that were pre-recorded and telecined for broadcast would've also been filmed at 30fps using a synchronous AC motor.) > In early TV systems, a master voltage-controlled oscillator was run at twice the horizontal line frequency, and this frequency was divided down by the number of lines used (in this case 525) to give the field frequency (60 Hz in this case). This frequency was then compared with the 60 Hz power-line frequency and any discrepancy corrected by adjusting the frequency of the master oscillator. I think later TVs would've just synchronized to the received signal. https://en.wikipedia.org/wiki/NTSC#Resolution_and_refresh_rate https://en.wikipedia.org/wiki/NTSC#Resolution_and_refresh_ra...
- pavon 1y agoThe article didn't nail down an exact reason. Here is my guess. The quote from Andy Hertzfeld suggests the limiting factor was the memory bandwidth not the memory volume: > The most important decision was admitting that the software would never fit into 64K of memory and going with a full 16-bit memory bus, requiring 16 RAM chips instead of 8. The extra memory bandwidth allowed him to double the display resolution, going to dimensions of 512 by 342 instead of 384 by 256 If you look at the specs for the machine, you see that during an active scan line, the video is using exactly half of the available memory bandwidth, with the CPU able to use the other half (during horizontal and vertical blanking periods the CPU can use the entire memory bandwidth)[1]. That dictated the scanline duration. If the computer had any more scan lines, something would have had to give, as every nanosecond was already accounted for[2]. The refresh rate would have to be lower, or the blanking periods would have had to been shorter, or the memory bandwidth would have to be higher, or the memory bandwidth would have had to be divided unevenly between the CPU and video which was probably harder to implement. I don't know which of those things they would have been able to adjust and which were hard requirements of the hardware they could find, but I'm guessing that they couldn't do 384 scan lines given the memory bandwidth of the RAM chips, and the blanking times of the CRT they selected, if they wanted to hit 60Hz. [1]https://archive.org/details/Guide_to_the_Macintosh_Family_Hardware_Second_Edition/page/193/mode/2up https://archive.org/details/Guide_to_the_Macintosh_Family_Ha... [2]https://archive.org/details/Guide_to_the_Macintosh_Family_Hardware_Second_Edition/page/399/mode/2up?q=blanking https://archive.org/details/Guide_to_the_Macintosh_Family_Ha...
- ajross 1y agoExactly. Like the Apple ][, the original Mac framebuffer was set up with alternating accesses, relying on the framebuffer reads to manage DRAM refresh. It looks like DRAM was set up on a 6-CPU-cycle period, as 512 bits (32 16-bit bus accesses) x 342 lines x 60 Hz x 6 cycles x 2 gives 7.87968 MHz, which is just slightly faster than the nominal 7.83 MHz, the remaining .6% presumably being spent during vblank.
- meatmanek 1y agoBut why 342 and tune the clock speed down instead of keeping the clock speed at 8MHz and having floor(8e6/2/6/60/32) = 347 lines? I suspect kmill is right: https://news.ycombinator.com/item?id=44110611 https://news.ycombinator.com/item?id=44110611 -- 512x342 is very close to 3:2 aspect ratio, whereas 347 would give you an awkward 1.476:1 aspect ratio.
- simne 1y agoImpressed to see, how many people read whole article, not see just one phrase: "We don’t need a lot of the things that other personal computers have, so let’s optimize a few areas and make sure the software is designed around them". Mac was not cheap machine and Apple that time was not rich to make unnecessary thing - they really need to make a hit this time, and they succeed. And yes, it is true, they was limited by bandwidth, it is also true they was limited by semi-32bit CPU speed. But Mac was real step ahead at the moment, and had significant resources to grow when new technology will arrive. That what I think lack PCs of that time.
- kristianp 1y agoThe folklore link they reference: https://www.folklore.org/Five_Different_Macs.html https://www.folklore.org/Five_Different_Macs.html The 1st edition of macworld, notably the first page is an advert for microsoft's products, multiplan spreadsheet, word, etc. https://archive.org/details/MacWorld_8404_April_1984_premier/mode/2up https://archive.org/details/MacWorld_8404_April_1984_premier... The original floppy used on the mac was a single-sided 400KB disk. I imagine that was another set of trade-offs. https://folklore.org/Disk_Swappers_Elbow.html https://folklore.org/Disk_Swappers_Elbow.html
- kalleboo 1y ago> The original floppy used on the mac was a single-sided 400KB disk. I imagine that was another set of trade-offs Originally they planned on using custom 870K drives, but they were too unreliable so at the last minute they switched to the Sony 400K 3.5" disks https://en.wikipedia.org/wiki/Apple_FileWare https://en.wikipedia.org/wiki/Apple_FileWare https://folklore.org/Hide_Under_This_Desk.html https://folklore.org/Hide_Under_This_Desk.html
- phendrenad2 1y agoI always assumed it was a compromise between memory usage, refresh speed, and the GUI that they wanted. Don't forget that the Macintosh was preceded by the Lisa (800x364) and the IIGS (640x200), so they probably had a good sense for what was comfortable given a certain resolution.
- sgerenser 1y agoThe IIGS came out well after the original Macintosh: https://en.wikipedia.org/wiki/Apple_IIGS https://en.wikipedia.org/wiki/Apple_IIGS
- dragonwriter 1y ago> Don't forget that the Macintosh was preceded by the Lisa (800x364) and the IIGS (640x200), Lisa was January 1983 Macintosh was January 1984 Apple IIgs was September 1986
- wkat4242 1y agoThe Lisa was also about twice as expensive as the Macintosh which is why it failed hard. So the price limited the hardware and that caused this display bandwidth constraint.
- dtgriscom 1y agoI remember in the early '80s using a computer (a Xerox Star, perhaps?) that used the CPU to generate the display. To speed up CPU-intensive tasks, you could blank the screen.
- p_l 1y agoAlto had its entire display control in microcode, IIRC. Out of similar tricks, Symbolics 3600 (at least first model) had major portions of disk driver implemented as one of the tasks in microcode (yes, the microcode was a multi-tasking system with preemption). Don't know how much of MFM wrangling was going there, but ultimately it meant that reading and writing a page from/to disk was done by means of single high level instruction
- bane 1y agoThe answer is something that's harder and harder to do these days with all the layers of abstraction -- set a performance target and use arithmetic to arrive at the specifications that you hit and still achieve your performance goal. It's a bit of work, but I suspect you can arithmetic your way through the problem. Supposing they wanted 60 Hz on the display and a framebuffer you need 196,608 bits/24,576 bytes/24 kbytes [below] on a 1-bit display at 512x384. The Mac 128k shipped with a Motorola 68k at 7.8336 Mhz giving it 130560 Hz per frame @ 60 fps. IIR the word length of the 68k is 32bits, so imagining a scenario where the screen was plotted in words, it's something like 20 cycles per fetch [1], you can get about 6528 fetches per frame. At 32-bits a fetch, you need 6144 or so fetches from memory to fill the screen. You need a moment for horizontal refresh so you lose time waiting for that, thus 6528-6144 = (drumroll) 384, the number of horizontal lines on a display. I'm obviously hitting the wavetops here, and missing lots of details. But my point is that it's calculable with enough information, which is how engineers of yor used to spec things out. 1 - https://wiki.neogeodev.org/index.php?title=68k_instructions_timings#Move_instructions https://wiki.neogeodev.org/index.php?title=68k_instructions_... below - why bits? The original Mac used 1-bit display, meaning each pixel used 1-bit to set it as either on or off. Because it didn't need 3 subpixels to produce color, the display was tighter and sharper than color displays, and even at the lower resolution appeared somewhat paperlike. The article is correct that the DPI was around 72. Another way to think about it, and what the Mac was targeting was pre-press desktop publishing. Many printing houses could print at around 150-200 lines per inch. Houses with very good equipment could hit 300 or more. Different measures, but the Mac, being positioned as a WYSISWYG tool, did a good job of approximating analog printing equipment of the time. (source: grew up in a family printing business)
- wmf 1y agoIn typography there are 72 points per inch so they made 1 pixel = 1 point.
- p_l 1y agoMotorola 68000 used had 16 data lines and 24 address lines, so it took at least two cycles to just transfer a CPU full word (disregarding timings on address latches etc). Some of the code AFAIK used fancy multi-register copies to increase cycle efficiency in graphics code. As for screen, IIRC making it easy to correlate "what's on screen" and "what's on paper" was major part of what drove Mac to be nearly synonymous with DTP for years.
- kazinator 1y ago> but given the name of this website, it was pretty embarrassing. Why, the name of the website is 512pixels.net not 342pixels.net; he nailed the 512 dimension. :)
- badc0ffee 1y agoIt doesn't say exactly why 512x342 was chosen. But I'm more interested in why it was changed to 512x384 on later Macs. Is it just to fill the full 4:3 screen? Beyond that, this article really wants to tell you how amazing that resolution was in 1984. Never mind that you could get an IBM XT clone with "budget" 720x348 monochrome Hercules graphics that year and earlier.
- fredoralive 1y agoThe 512x384 models are Macintosh LC adjacent, so the original LC monitor (the LC itself can do 640x480), or the Colour Classics. AFAIK it was partly in order to making the LC work better with the Apple IIe card (although the IIe software uses a 560x384 mode). A Hercules card, whilst nice does suffer from the same non-square pixels issue as the Lisa, so not as nice for creating a GUI.
- badc0ffee 1y ago> although the IIe software uses a 560x384 mode Nice, that's line doubled from the //e's 560x192 and would probably look crisp.
- rasz 1y agoBoth MDA and Hercules were 50 Hz. Real mid eighties king of cheap crisp displays would be 12 inch 640x400@71Hz Atari SM124 monitor. You could buy Atari ST + SM124 + Atari SLM804 laser printer + Calamus DTP package for the price of just the Apple laser printer alone :)
- badc0ffee 1y agoI had a XT clone + Hercules at the time (and SIMCGA for games), and the 50Hz refresh wasn't as bad as you'd think - the MDA CRTs were designed with slow decay phosphors to reduce flicker. I actually had no idea that Atari made a laser printer. Everyone I knew with a ST (admittedly, not many people) was either doing MIDI or playing video games.
- jhallenworld 1y agoCRTs are very forgiving- 512x342 vs x384 would have made very little difference. You could still get square pixels by minor adjustments to vertical and horizontal size. My question is what is the htotal and vtotal times in pixels and lines? Maybe there was a hardware savings to have vtotal exactly equal to 384 (which is 128 times 3). Perhaps they saved one bit in a counter, which may have resulted in one fewer TTL chip.