Hacker News Reader

Comment by hyperhello | Hacker News Reader

The article really didn’t explain why they picked that number.

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.

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.

It was 32bit?!

The data and address registers of the 68000 were 32 bits wide.

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

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.

It has 32-bit registers, but it has a 16-bit ALU, so it's a matter of opinion if that makes it a 16 or 32-bit processor. I'd go with 32-bit in that it's instruction set gives the impression to the programmer that they are working with a 32-bit system.

And for more evidence, the Z80 is referred to as an 8-bit processor but has a 4-bit ALU.

The 68000 actually had three 16 bit ALUs, so could munch a peak of 48 bits per clock cycle. Only one could do all operations while the other two were basically just add. These days we would say there were part of the AGU (address generator unit) but one of them was shared with the data register operations.

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.

Like a lot of things, the taxonomy kind of breaks down at the edges and arguments can be made either way.

I will throw out there though that ALU width and buses are generally seen as orthogonal to 'bitness' of a processor, and more an implementation detail. The Z80 had a 4bit ALU, but is considered an 8bit CPU. The PDP-8/s and SERV have single bit ALUs, but are considered 12 and 32 bits respectively. The 8088 is considered a 16bit CPU despite having both an 8bit ALU and bus.

'Bitness' is generally defined more as 'what is the width of whatever is the closest thing to a GPR'.

Seconded. If you were an ASM programmer, you’d have no idea it had a 16 bit ALU. All the ops were 32 bit, regardless of what the underlying silicon looked like.

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 bit internally.

There's a subtlety -- word adds are only 8 cycles when adding to an address register. They're 4 cycles to a data register. This is because the 68000 always does address computations in 32-bit, and 16-bit operands are sign extended to 32-bit when adding to an address register. A word add to a data register, on the other hand, only produces a 16-bit result. This is reflected by the canonical instruction being ADDA.W instead of ADD.W for address register destinations.

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

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

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.

The 286/386SX/486SLC could address 16MB, the full 24 bit address space.

> the ISA bus was only 16-bits wide, which limited the utility of the 32-bit bus for fast graphics transfers.

Not only that, it was 8MHz to match the speed of the fastest IBM AT. VLB on a 486/33 or 66 ran at 33 MHz and was a godsend, 8x the bandwidth of 16-bit ISA.

The 68008 saw a lot of use in embedded and could easily create a whole microcomputer on a breadboard.

And was also used in the Sinclair QL.

It started out as 16bit enhancement to previous product, and evolved into being a 32bit architecture over development time.

The separation of Data and Address registers are also result of how it evolved over time, AFAIK, ultimately because it allowed to make the CPU cheaper/easier to make. Another element is that 68000 at least has two layers of microcode - first microcode engine generates instructions interpreted by second microcode engine which finally actually drives execution units.

The article says: In short, there’s no easy answer to explain why early compact Macs ran at a screen resolution of 512×342. Rather, Apple was doing what it does best: designing a product with the right trade-offs for performance, ease of use, and cost.

It was noticeably better than anything else I had ever seen.

Reply on news.ycombinator.com