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.
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.
"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.
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.
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.
Atari TT did. And is possible on Falcon with expansion.
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).
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.
Realize how late that is, relative to ST's release.
While it was kind of a crappy games machine compared to the Amiga, it certainly was better than a PC or a Mac, and as an all around general home productivity computer was the best value for the $ out there at the time. Which I think was the Tramiel's aim.
But the Atari ST didn't have custom chips, so there was no need for chip ram/fast ram?
The problem persisted through the Falcon, which 68030's was tremendously held back by lack of a fast ram concept.
Most people had a 4-colour hires Workbench so wouldn't be affected. People with a faster CPU would also likely buy Fast RAM to go with it.
Details: http://www.theflatnet.de/pub/cbm/amiga/amigadev.elowar.com/r...
Diagram: http://www.theflatnet.de/pub/cbm/amiga/amigadev.elowar.com/r...