7 ms·

It's interesting to me that one of the big ideas that made the Amiga different was having a unified memory (the chip memory) where the specialised processors an

It's interesting to me that one of the big ideas that made the Amiga different was having a unified memory (the chip memory) where the specialised processors and CPU had equal access; it's now very mainstream in the gaming arena, with the XBox and PlayStation both using AMD processors that do just that.

Veliladon 3y ago
It's pretty different compared to the Amiga. The Amiga flipped the bus between CPU and chipset every cycle and the CPU could only access chip RAM every 1/2 cycles. No matter how little the chipset was doing, the CPU could only access RAM half the time. The Xbox/PS5 SoCs have both the CPU and GPU behind the memory controller so even under load the CPU will still have access to its full amount of memory bandwidth.
- snvzz 3y ago
  >No matter how little the chipset was doing, the CPU could only access RAM half the time. Only applicable to CHIP RAM. CPU could access FAST RAM, the default allocation target, all the time. It also was not as simple as odd/even, although there's sense to the simplification. 68000's design meant it could ultimately only access RAM every other cycle, thus it was sensible to aim for that as the default. Higher 68000 models did not have that restriction. And even the original chipset also wasn't limited to half the cycles. This was only true of the default video mode (4 color "hires", 640 pixels wide). The blitter also had a flag (BITHOG) that allowed it to use full DMA, stealing cycles from the CPU.
  - rasz 3y ago
    >Only applicable to CHIP RAM. CPU could access FAST RAM, the default allocation target, all the time. "default" haha. Afaik the only Amiga that ever shipping with fast ram was A4000. It was introduced at $4600 in 1992. In 1993 it was down to $2500, same price ARL was selling Pentium 60MHz system with 8MB ram.
    - snvzz 3y ago
      >"default" haha. Yes, default. AmigaOS AllocMem() will use fast32, then fast, then slow, then chip. Thus software needs to request Chip explicitly when required. This is fortunately well respected by software, thanks to "slow ram" being commonly mounted inside Amiga 500's trapdoor. >Afaik the only Amiga that ever shipping with fast ram was A4000 A3000 already shipped with a 1M+1M CHIP/FAST split in 1991. For the other Amiga, fast ram is a priority expansion. Typically over 2x performance for the A1200's CPU just from having any, via trapdoor expansion slot. On A500, the most sold model, you'd get this through the left expansion slot, either as a standalone board or mounted inside an HDD adapter, back in the day. Today, A500 CPU socket adapters giving 8MB Fast RAM are common.
    - deleted 3y ago
      [deleted]
cmrdporcupine 3y ago
This model of bus sharing was extremely common at the time, just splitting access to the bus on the off cycle of the bus. Commodore 64 and Atari ST were also like this, among others. I forget if the Atari 8-bit machines (also partially Jay Miner designs) were fully like this, but I believe they were. It worked because the world then was almost the opposite of the way it is now. Back then memory & bus was as fast or faster than the CPU and so you could do this kind of thing. To the point where there were architectures where the CPU itself had basically no registers (TMS 99xx), and the processor did registers (or register-like as in the 6502 'zero page') access via SRAM. Now memory access is many times slower than the processor, keeping things in on-die cache and in registers is key.
13of40 3y ago
The flip side of that was if you were writing a vanilla computer program that didn't take advantage of the special hardware, your perf was directly tied to what resolution mode the screen was on.
- snvzz 3y ago
  ... as long as there was no "FAST RAM" left. Allocations would get fast ram with priority, unless chip ram was specifically requested. Fast ram is exclusive to the cpu, and unaffected by the chipset accessing chip ram. Amiga had this fast ram concept. Atari ST unfortunately did not.
  - cmrdporcupine 3y ago
    > Atari ST unfortunately did not. Atari TT did. And is possible on Falcon with expansion.
    - snvzz 3y ago
      It was only really possible by not using the OS. The main issue is that the OS did not have a way to request "chip RAM", thus software compatibility hell if added too late (never actually got added AIUI).
      - cmrdporcupine 3y ago
        Not that it mattered by that point but TOS 3 for the TT did? For what, I don't know, really. Maybe people running Calamus or something could use it? I think Atari Corp had a burst of engineering competence at the end after Tramiel Sr handed over the reigns to his sons. But it was too late, the market moved on. The Falcon is a lovely machine. The last TOS releases addressed some longstanding problems. Hiring Eric Smith to work on TOS/MuliTOS was a good, but late effort. Porting SystemV and trying to make a budget Unix workstation was a doomed but clever effort (I still remember the UnixWorld news clip box headline "Up from toyland"). I bought a 486 late 1992, put Linux 0.97 on it, and moved on.
      - 3y ago
fulafel 3y ago
And also of course in most x86 computers and Macs.

Veliladon 3y ago

It's pretty different compared to the Amiga. The Amiga flipped the bus between CPU and chipset every cycle and the CPU could only access chip RAM every 1/2 cycles. No matter how little the chipset was doing, the CPU could only access RAM half the time. The Xbox/PS5 SoCs have both the CPU and GPU behind the memory controller so even under load the CPU will still have access to its full amount of memory bandwidth.

snvzz 3y ago
>No matter how little the chipset was doing, the CPU could only access RAM half the time. Only applicable to CHIP RAM. CPU could access FAST RAM, the default allocation target, all the time. It also was not as simple as odd/even, although there's sense to the simplification. 68000's design meant it could ultimately only access RAM every other cycle, thus it was sensible to aim for that as the default. Higher 68000 models did not have that restriction. And even the original chipset also wasn't limited to half the cycles. This was only true of the default video mode (4 color "hires", 640 pixels wide). The blitter also had a flag (BITHOG) that allowed it to use full DMA, stealing cycles from the CPU.
- rasz 3y ago
  >Only applicable to CHIP RAM. CPU could access FAST RAM, the default allocation target, all the time. "default" haha. Afaik the only Amiga that ever shipping with fast ram was A4000. It was introduced at $4600 in 1992. In 1993 it was down to $2500, same price ARL was selling Pentium 60MHz system with 8MB ram.
  - snvzz 3y ago
    >"default" haha. Yes, default. AmigaOS AllocMem() will use fast32, then fast, then slow, then chip. Thus software needs to request Chip explicitly when required. This is fortunately well respected by software, thanks to "slow ram" being commonly mounted inside Amiga 500's trapdoor. >Afaik the only Amiga that ever shipping with fast ram was A4000 A3000 already shipped with a 1M+1M CHIP/FAST split in 1991. For the other Amiga, fast ram is a priority expansion. Typically over 2x performance for the A1200's CPU just from having any, via trapdoor expansion slot. On A500, the most sold model, you'd get this through the left expansion slot, either as a standalone board or mounted inside an HDD adapter, back in the day. Today, A500 CPU socket adapters giving 8MB Fast RAM are common.
  - deleted 3y ago
    [deleted]

cmrdporcupine 3y ago

This model of bus sharing was extremely common at the time, just splitting access to the bus on the off cycle of the bus. Commodore 64 and Atari ST were also like this, among others. I forget if the Atari 8-bit machines (also partially Jay Miner designs) were fully like this, but I believe they were. It worked because the world then was almost the opposite of the way it is now. Back then memory & bus was as fast or faster than the CPU and so you could do this kind of thing. To the point where there were architectures where the CPU itself had basically no registers (TMS 99xx), and the processor did registers (or register-like as in the 6502 'zero page') access via SRAM. Now memory access is many times slower than the processor, keeping things in on-die cache and in registers is key.

13of40 3y ago

The flip side of that was if you were writing a vanilla computer program that didn't take advantage of the special hardware, your perf was directly tied to what resolution mode the screen was on.

snvzz 3y ago
... as long as there was no "FAST RAM" left. Allocations would get fast ram with priority, unless chip ram was specifically requested. Fast ram is exclusive to the cpu, and unaffected by the chipset accessing chip ram. Amiga had this fast ram concept. Atari ST unfortunately did not.
- cmrdporcupine 3y ago
  > Atari ST unfortunately did not. Atari TT did. And is possible on Falcon with expansion.
  - snvzz 3y ago
    It was only really possible by not using the OS. The main issue is that the OS did not have a way to request "chip RAM", thus software compatibility hell if added too late (never actually got added AIUI).
    - cmrdporcupine 3y ago
      Not that it mattered by that point but TOS 3 for the TT did? For what, I don't know, really. Maybe people running Calamus or something could use it? I think Atari Corp had a burst of engineering competence at the end after Tramiel Sr handed over the reigns to his sons. But it was too late, the market moved on. The Falcon is a lovely machine. The last TOS releases addressed some longstanding problems. Hiring Eric Smith to work on TOS/MuliTOS was a good, but late effort. Porting SystemV and trying to make a budget Unix workstation was a doomed but clever effort (I still remember the UnixWorld news clip box headline "Up from toyland"). I bought a 486 late 1992, put Linux 0.97 on it, and moved on.
    - 3y ago

fulafel 3y ago

And also of course in most x86 computers and Macs.