Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why the original Macintosh had a screen resolution of 512×324

512pixels.net

Post reply on HN
Print view View original

51–60 of 138 posts

Re: Why the original Macintosh had a screen resolution of 512×324

#51

Post by bobmcnamara »

stefan_ wrote: post #45
pavon wrote: post #29

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, g…

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.

We see this in embedded systems all the time too.

It doesn't help if your crossbar memory interconnect only has static priorities.

Re: Why the original Macintosh had a screen resolution of 512×324

#52

Post by danudey »

stefan_ wrote: post #45
pavon wrote: post #29

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, g…

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.

I have a 4k 60Hz monitor connected to my laptop over one USB-C cable for data and power, but because of bandwidth limitations my options are 4k30 and USB 3.x support or 4k60 and USB 2.0.

I love the monitor, it's sharp and clear and almost kind of HDR a lot of the time, but the fact that it has a bunch of USB 3.0 ports that only get USB 2.0 speeds because I don't want choppy 30Hz gaming is just... weird.

Re: Why the original Macintosh had a screen resolution of 512×324

#53

Post by bobmcnamara »

ajross wrote: post #40
pavon wrote: post #29

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, g…

Exactly. 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.

It's like dual porting but twin half duplex!

Re: Why the original Macintosh had a screen resolution of 512×324

#54

Post by ajross »

meatmanek wrote: post #48
ajross wrote: post #40

Earlier quoted context omitted.

Exactly. 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.

But 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 -- 512x342 is very close to 3:2 aspect ratio, whereas 347 would give you an awkward 1.476:1 aspect ratio.

That doesn't sound right. The tube the mac was displaying on was much closer to a TV-style 4:3 ratio anyway, there were significant blank spaces at the top and bottom.

If I was placing bets, it was another hardware limitation. Maybe 342 put them right at some particular DRAM timing limit for the chips they were signing contracts for. Or maybe more likely, the ~21.5 kHz scan rate was a hard limit from the tube supplier (that was much faster than TVs could do) and they had a firm 60 Hz requirement from Jobs or whoever.

Re: Why the original Macintosh had a screen resolution of 512×324

#55

Post by tom_ »

silvestrov wrote: post #21
tom_ wrote: post #15

Earlier quoted context omitted.

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.

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.

The cycle counts really don't back this theory up. And indeed, from that link:

> Internally, it uses a 16-bit data arithmetic logic unit (ALU) and two more 16-bit ALUs used mostly for addresses,[4] and has a 16-bit external data bus.

Re: Why the original Macintosh had a screen resolution of 512×324

#56

Post by phendrenad2 »

I 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.

Re: Why the original Macintosh had a screen resolution of 512×324

#57

Post by msephton »

perching_aix wrote: post #19

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…

You'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 — what synchronicity!

Re: Why the original Macintosh had a screen resolution of 512×324

#59

Post by npunt »

perching_aix wrote: post #24
Reason077 wrote: post #22

> “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!

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).

Monochrome CRT phosphors like P4 (zinc sulfide w silver) have longer persistence than ones used in color CRTs, so flicker is less noticeable.

Re: Why the original Macintosh had a screen resolution of 512×324

#60

Post by tom_ »

bryanlarsen wrote: post #25
tom_ wrote: post #15

Earlier quoted context omitted.

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.

According to https://wiki.neogeodev.org/index.php?title=68k_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 b…

Interesting, thanks. I'd missed that particular detail, possibly because I used to do this stupid shit on the Atari ST and its instructions were quantized to the nearest nop (and so 6 cycles wasn't really a thing). Address register operations are always longs, and clearly the sign extension imposes some overhead. Given that pretty much every other long operation is slower, I imagine this is a case of getting lucky with the timing of the 16-bit internal operations.

ADDQ and ADDX are better instructions to look at, as are any with a Dn,Dn addressing mode. The long and word cases are the same number of instruction bytes, but the long case is still slower.

(Register-to-register moves are the same regardless of width, so presumably it has a 32 bit path for this. That's nice. But not as nice as it would be if it had a 32 bit path for everything. Which it really looks like it doesn't. This CPU has registers, but that can't save it.)

Post reply on HN