81–90 of 138 posts
The 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 kbyt…
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…
Why did they need 60hz? Why not 50 like Europe? Is there some massive advantage to syncing with the ac frequency of the local power grid?
I feel like the extra 16% of screen real estate would have been worth it.
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.
Consequently almost nothing actually renders at 4k. It’s all upscaling - or even worse your display is wired to double up on inputs.
Once we can comfortably get 60 FPS, 1080p, 4x msaa, no upscaling, then let’s revisit this 4k idea.
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.
> “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).
Earlier quoted context omitted.
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 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…
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…
> “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!
But there is less need because LCDs do not flicker (except some designed for videogames that strobe the backlight for some strange reason IIUC). I know I found the flicker of CRTs annoying even at 60 Hz.
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…