[HN Gopher] Why the Original Macintosh Had a Screen Resolution o...
___________________________________________________________________
Why the Original Macintosh Had a Screen Resolution of 512x324
Author : ingve
Score : 86 points
Date : 2025-05-27 20:02 UTC (2 hours ago)
(HTM) web link (512pixels.net)
(TXT) w3m dump (512pixels.net)
| johnklos wrote:
| The title is incorrect, because b&w Macs have 512x342 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 wrote:
| It looks like it's just the HN submitted title which is wrong
| (currently "Why the Original Macintosh Had a Screen Resolution
| of 512x324"). The article's title is "Why the Original
| Macintosh Had a Screen Resolution of 512x342", and "324"
| doesn't appear anywhere on the page.
| bscphil wrote:
| Looks 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...
| ChuckMcM wrote:
| Oh that's priceless. Real time HN feedback loops.
| dhosek wrote:
| Wouldn't be the first time.
| 90s_dev wrote:
| > wouldn't've
|
| Really, John? You really had to make me parse that word?
| webstrand wrote:
| It's a great word, I use it all the time.
| kevin_thibedeau wrote:
| It usually isn't transcribed with Klingon orthography.
| JKCalhoun wrote:
| Worth 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 wrote:
| The article really didn't explain why they picked that number.
| bryanlarsen wrote:
| For 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 wrote:
| It was 32bit?!
| tom_ wrote:
| The 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 wrote:
| The 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!)
| sitkack wrote:
| The 68008 saw a lot of use in embedded and could easily
| create a whole microcomputer on a breadboard.
| UncleSlacky wrote:
| And was also used in the Sinclair QL.
| EndsOfnversion wrote:
| From memory, the primary advantage of the 386SX was the
| ability to use a cheaper 16-bit motherboard layout and
| components. The lack of a 32bit bus mattered less when
| most software was written with 286 compatibility in mind,
| and the ISA bus was only 16-bits wide, which limited the
| utility of the 32-bit bus for fast graphics transfers.
|
| The reduced 24-bit address bus was never a significant
| bottleneck during its commercial lifetime, as little
| consumer software at the time would require more than 4mb
| of RAM, and by the time it did the 486SX (32bit busses
| with no maths coprocessor) was the new value champion.
| silvestrov wrote:
| No, this is very wrong. The 68000 is 32 bit internally
| and it has 32 bit registers:
| https://en.wikipedia.org/wiki/Motorola_68000
|
| Externally it had 16 bits for databus and 24 bits for
| addresses. That is why we later got the 32 bit clean ROMs
| as Apple used the upper unused 8 address bits for flags.
| bryanlarsen wrote:
| According to https://wiki.neogeodev.org/index.php?title=6
| 8k_instructions_... the 32 bit register add on the 68000
| is faster (6 cycles) than the 16 & 8 bit register add (8
| cycles).
|
| Most 32 bit operations are slower than 16 bit operations
| because the external data bus is only 16 bits and most
| operations use the external data bus. But simple internal
| ops are faster at 32 bits, so that seems to indicate the
| 68000 is 32 bit internally.
| mayoff wrote:
| The data and address registers of the 68000 were 32 bits
| wide.
| kzrdude wrote:
| That reminds me of this old system settings panel
| https://lowendmac.com/2015/32-bit-addressing-on-older-macs/
|
| I remember the "enable 32-bit addressing" part (but it's
| not pictured..)
| edwinjm wrote:
| The article says: In short, there's no easy answer to explain
| why early compact Macs ran at a screen resolution of 512x342.
| Rather, Apple was doing what it does best: designing a product
| with the right trade-offs for performance, ease of use, and
| cost.
| detourdog wrote:
| It was noticeably better than anything else I had ever seen.
| kmill wrote:
| I don't know, but I can do some numerology: a 3:2 aspect ratio
| that's 512 pixels wide would need a 341 and a third lines, so
| round up and you get 512 by 342.
|
| The later 384 number corresponds to an exact 4:3 aspect ratio.
| russellbeattie wrote:
| The answer is probably more akin to: "As small of a resolution as
| they could make it without Steve bitching at them about it."
| codr7 wrote:
| Apple could use some Steve drama, they seem to be moving
| backwards lately.
| perching_aix wrote:
| Regardless 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 wrote:
| For 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 wrote:
| >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.
| Reason077 wrote:
| > _"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 wrote:
| It'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 wrote:
| >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 wrote:
| If 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).
| bluGill wrote:
| Have you ever seen something running at 30 Hz? Or even 15?
| The difference in flicker between 30 and 60 is much much
| larger than the difference between 60 and 120! Yeah 60 isn't
| flicker free, any finite number is not (there is probably
| quantum limits), but realistically you reach a point where
| you can't really tell. For most purposes 60Hz is close
| enough, though you can still tell.
| perching_aix wrote:
| I don't remember frankly. For what it's worth, TV sets
| would always be 50 Hz here (PAL) (unless they did some
| tomfoolery I'm not aware of and ran at 100 Hz "in secret"
| or something) and evidently I could watch those on end
| without too many holdups for years and years, so clearly it
| wasn't a dealbreaker. But on monitors, yeah, I just
| wouldn't tolerate it, whereas 85 Hz felt perfect (no
| discernible flicker for me that I'd recall).
| nyanpasu64 wrote:
| - I hear that some later digital PAL TVs stored an image
| in a framebuffer and scanned it out twice at 100 Hz,
| which retro gamers today avoid because it increases
| latency relative to direct scanout.
|
| - I've heard mixed reports over whether CRT monitors had
| faster-decaying phosphors than televisions. Maybe part of
| it is a computer has a white image, which causes more
| noticeable flicker than a dark background with white text
| (or darker TV scenes).
| msgodel wrote:
| That's interesting. 60hz TVs always gave me headaches but
| my 75 hz computer monitor didn't.
|
| I think it was actually the interlacing and not the
| refresh rate that did it.
| pavon wrote:
| The 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_Ha..
| .
|
| [2]https://archive.org/details/Guide_to_the_Macintosh_Family_Ha..
| .
| ajross wrote:
| Exactly. Like the Apple ][, the original Mac framebuffer was
| set up with alternating accesses, relying on the framebuffer
| reads to manage DRAM.
|
| 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.
| analog31 wrote:
| A lot of those old machines had clock speeds and video pixel
| rates that meshed together. On some color machines the system
| clock was an integer multiple of the standard colorburst
| frequency.
|
| The Timex Sinclair did all of its computation during the
| blanking interval which is why it was so dog slow.
| stefan_ wrote:
| Displays are still bandwidth killers today, we kept scaling
| them up with everything else. Today you might have a 4k 30bpp
| 144hz display and just keeping that fed takes 33Gbit/s purely
| for scanout, not even composing it.
| pragma_x wrote:
| It's also interesting to look at other architectures at the
| time to get an idea of how fiendish a problem this is. At this
| time, Commodore, Nintendo, and some others, had dedicated
| silicon for video rendering. This frees the CPU from having to
| generate a video signal directly, using a fraction of those
| cycles to talk to the video subsystem instead. The major
| drawback with a video chip of some kind is of course cost
| (custom fabrication, part count), which clearly the Macintosh
| team was trying to keep as low as possible.
| simne wrote:
| Impressed 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.
___________________________________________________________________
(page generated 2025-05-27 23:00 UTC)