What spec would the A1200 had launched with if it was up to YOU

[pandy71]

Originally Posted by Gorf

The A3000 uses still way too slow RAM ICs that trick: 120ns access time
But the A1200 uses 70ns chips and 60ns chips would have been available.

Fastest DRAM was 50ns but still - you could introduce memory interleaving to speedup things and of course use fast page mode or later EDO.
Definitely CBM made one very serious mistake - with such slow chipset (overall low bandwidth) they should push for better memory management - shift "CHIP" to "FAST" (instead allowing CPU access CHIP from time to time shift principle to allow chipset to access CPU RAM from time to time in strict defined way).

[Gorf]

Originally Posted by pandy71

Disagree - seem you didn't experienced how ugly was PC desktops then - old XT/AT desktops was truly ugly - better look provided by so called 'baby AT' desktops but still - in those times nobody care about enclosure esthetic - this started to change with workstations - 'pizza box' was most esthetic desktop ever IMHO.

The fact, that there were even uglier boxes out there, doesn't make the A2000 any prettier

I agree with you on the contemporary pizza-box design, with the A3000 at least resembled in part (actually it is more like a A1000 without garage of course)

SPARKstation, SGI Indy, NextStation

[Gorf]

Originally Posted by pandy71

Fastest DRAM was 50ns but still - you could introduce memory interleaving to speedup things and of course use fast page mode or later EDO.

Interleaving, Fast Page Mode and EDO are not that helpful for my proposed idea, since it would relay on true random access to very different memory regions not being guarantied in the same memory page and also not being necessarily in different ones either.

70ns DRAM usually have a roundtrip time (before you can issue the next access) of 140ns.
The typical DMA slots in the Amiga are 285ns long (3.5Mhz)
So it would theoretically just fit with 70ns ICs ... but roudtrip my vary and 5ns are a very slim margin since every inch of traces on the board add to the delay... DRAM management before the introduction of synchronized RAM is a very "analog" game.

But 60ns DRAM really should do the trick.

[albino]

In my opinion the 1200 should have been what the 3DO, a powefull hardware computer.

[AestheticDebris]

Originally Posted by pandy71

Fastest DRAM was 50ns but still - you could introduce memory interleaving to speedup things and of course use fast page mode or later EDO.
Definitely CBM made one very serious mistake - with such slow chipset (overall low bandwidth) they should push for better memory management - shift "CHIP" to "FAST" (instead allowing CPU access CHIP from time to time shift principle to allow chipset to access CPU RAM from time to time in strict defined way).

I'm not sure that makes sense. "Fast" RAM was only faster because the chipset never accessed it and thus never blocked the CPU. If the chipset was also accessing it, it would all just be "Chip" RAM.

The only thing that might have made sense would be DMA copying of data from Fast RAM directly into Chip without CPU intervention. It would have slowed "Fast" RAM occasionally but could still have been worth it for cases where the CPU could prep data in advance. Could even have done C2P conversion at the same time possibly...

[Gorf]

Originally Posted by AestheticDebris

I'm not sure that makes sense. "Fast" RAM was only faster because the chipset never accessed it and thus never blocked the CPU. If the chipset was also accessing it, it would all just be "Chip" RAM.

Yes ... but:

one of the big problems here is, that Alice still occupies one in two 285ns slots, even if it has nothing to do. So the CPU is not only blocked during display and sound DMA and during blits but 50% of the time, no matter what.
Hence the abysmal slow ChipRAM bandwidth.

If this blocking of the CPU could be reduced to cases where it really needs to be blocked, the speed penalty would decrease dramatically. Especially if you use the DoubleCAS modes, where Lisa is fed with 64 pixels per bitplane at once, there are plenty of unused slots. This would reduce the penalty to around -20% compared to real FastRAM in the case of an 020@14MHz.

This would make the need for the inclusion of FastRAM much less severe.

[Promilus]

@Gorf, AestheticDebris
DMA is an answer to all of that but... it's not a magic tool which will both increase bandwidth and decrease latencies WITHOUT reworking whole memory subsystem. Also high res modes and wider palette would require bigger bandwidth as well. So, sure... it would've been possible to just introduce 10MB of chip ram (using Z2 area for chipram on fully 32b machines) but to get everything working ok you'd most likely need to redesign DMA, memory and chipset A LOT. And still, at some point swapping to faster CPU would still result in significant bottleneck when trying to access on-board RAM. So, yeah, engineers did find solution to that with every SoC out there integrating graphics and sound and peripherals and CPU... but that ain't so trivial. And TBH kind of system on a chip working with unified memory is ARM250 but that one was still using CPU to manage the data transfers...

[Karlos]

I think the reason the chip ram access was never fixed is simple. The engineers knew that adding fast ram basically solved almost all of the problems it caused. It would have been great if AGA had addressed the issue properly and not blindly blocked half the access, but it was probably a trade off they thought would be acceptable given AGA was supposed to be a stop gap.

[pandy71]

Originally Posted by Gorf

Interleaving, Fast Page Mode and EDO are not that helpful for my proposed idea, since it would relay on true random access to very different memory regions not being guarantied in the same memory page and also not being necessarily in different ones either.

Not necessarily - that's why you have buffers on chip, that's why you have FMODE and similar limitations like word/qword alignment etc.
All this is to maximally use bandwidth - of course you can intentionally write software to cripple performance but usually coders trying to squeeze each cycle even at a cost of weird data organization.

Originally Posted by Gorf

70ns DRAM usually have a roundtrip time (before you can issue the next access) of 140ns.
The typical DMA slots in the Amiga are 285ns long (3.5Mhz)
So it would theoretically just fit with 70ns ICs ... but roudtrip my vary and 5ns are a very slim margin since every inch of traces on the board add to the delay... DRAM management before the introduction of synchronized RAM is a very "analog" game.

But 60ns DRAM really should do the trick.

Yes but 70ns is guaranteed parameter over full temperature and other for example voltage operation of device - normally those values are meet with some safe margin thus not always you need follow this so strictly, yes, i agree for mass production you are usually avoid pushing beyond but well - i have impression that with proper design this would be not a serious issue.

[pandy71]

Originally Posted by AestheticDebris

I'm not sure that makes sense. "Fast" RAM was only faster because the chipset never accessed it and thus never blocked the CPU. If the chipset was also accessing it, it would all just be "Chip" RAM.

The only thing that might have made sense would be DMA copying of data from Fast RAM directly into Chip without CPU intervention. It would have slowed "Fast" RAM occasionally but could still have been worth it for cases where the CPU could prep data in advance. Could even have done C2P conversion at the same time possibly...

Once again - problem is in inefficiency of time when DMA slots occupying RAM bus - for UMA architecture you need to be able efficiently use every cycle.
By adding bus arbiter/manager and introducing more aggressive buffering schemes you could made AGA significantly faster - perhaps efficiently double bandwidth so less penalty for CPU.
That's why i think full integration of Alice, Paula and Lisa would be more beneficial from cost but also performance perspective.
And C2P should be part of display HW - similarly to mentioned Headley display (A2024) - why CBM not introduced packed planar (4 bit chunky) and 8 bit chunky directly in Lisa is really difficult to understand - this is simply way how bitplane data are interpreted - allowing to sequential bitplane access would be quite obvious and it would allow easily to use FPM DRAM to get higher bandwidth.

[Gorf]

Originally Posted by pandy71

Not necessarily - that's why you have buffers on chip, that's why you have FMODE and similar limitations like word/qword alignment etc.
All this is to maximally use bandwidth - of course you can intentionally write software to cripple performance but usually coders trying to squeeze each cycle even at a cost of weird data organization.

Yes, but my idea was to squeeze in one additional access into the 285ns slot, so CPU and Blitter can have both access.
Which means chances are very high, that these two different chips will access totally different locations in chipram!
And for the Blitter these accesses need to be guaranteed.
So alignments, FPM, ... is simply not helping here.
Just raw random access speed.

[pandy71]

Originally Posted by Gorf

Yes, but my idea was to squeeze in one additional access into the 285ns slot, so CPU and Blitter can have both access.
Which means chances are very high, that these two different chips will access totally different locations in chipram!
And for the Blitter these accesses need to be guaranteed.
So alignments, FPM, ... is simply not helping here.
Just raw random access speed.

But fitting two DMA cycles into 285ns will do the job especially for successive access i.e. bitplanes - big hurtle is inability of Amiga to create screen organization where bitplane pointers are grouped together- this is possible on line by line basis...
Bitplane DMA is most problematic one - highest priority and huge demand on bandwidth so optimizing sequential access for this is absolute must.

[Promilus]

I don't know what you mean by that Mr. Gorf - you cannot make access by 2 devices to shared memory at the same time. Especially when they try to address different locations. Because most of address bus and basically whole data bus is shared. It might've been possible with most likely buggy and costly way to access 16b chunks of data at the same time by CPU and chipset out of 32b chipram. But that's that. Adding extra memory access slot is great (so basically use faster RAM and faster memory controler in chipset) but either way you'd have to assign specific slot to specific device (so that device and only that device has access at that time). What Amiga did need surely was more mem slots, yes. But a lot could've been accomplished with more advanced DMA which could've split memory access slots between cpu and chipset components smarter.

[Gorf]

Originally Posted by pandy71

But fitting two DMA cycles into 285ns will do the job especially for successive access i.e. bitplanes

Your are still not hearing me:

It is about the access to ChipRAM at times, when there is NO doubleCAS BitPlane DMA.
Active Bitplane DMA Slots are Double-CAS already - you can't squeeze anything else in there.

It is about the stage AFTER the Bitplane fetch is complete, but Alice ist still blocking every second slot, without doing anything with it, or just doing single 16bit Blitter operations.

THERE one could split one 285ns slot into half and grant the CPU access as well.

Neither bitter operations nor the 68020 can to burst modes - so we are stuck with singe random accesses - 16bit wide for the Blitter and 32bit wide for the 020.
Both Blitter and 020 would have change to use the slot - even in pseudo "parallel", with fast enough DRAM.
But they would of course read or write to totally unrelated locations in memory, as the Blitter does its blitting and the CPU does its processing.

I hope I could describe this now in a better and clearer way.

[Gorf]

Originally Posted by Promilus

I don't know what you mean by that Mr. Gorf - you cannot make access by 2 devices to shared memory at the same time. Especially when they try to address different locations.

Of course you can:
BBC micro, C64, Amiga 1000 .. 500 .. 2000

they all have shared memory and make access to it without slowing each other down - because the RAM was fast enough the alternate access cycles, without blocking the CPU.

The very same method should be possible for the 68020@14MHz and the Blitter with 70ns or 60ns DRAM.
(Except during display DMA fetches were in Double-CAS mode)

[AestheticDebris]

Originally Posted by Gorf

Of course you can:
BBC micro, C64, Amiga 1000 .. 500 .. 2000

they all have shared memory and make access to it without slowing each other down - because the RAM was fast enough the alternate access cycles, without blocking the CPU.

The very same method should be possible for the 68020@14MHz and the Blitter with 70ns or 60ns DRAM.
(Except during display DMA fetches were in Double-CAS mode)

The 6502 and 68000 only ever access the bus on alternate cycles, a design feature which makes it easier for video hardware to use the other cycles to access RAM without slowing anything down.

The 68020 doesn't work like that, it could potentially access the bus on any cycle and thus has to be stalled if a shared device is accessing it.

[Promilus]

@Gorf - as I've said - it's alternated access. It's 1 device at particular cycle. Never more. So e.g. if 6502 running at 1MHz requires RAM access every 1us and so does VIC you create memory controller which works at 2MHz and creates slot every 500ns, then create phase shifted clock so VIC will sync with VIC slots and 6502 with CPU slots. It works. And it does kind of the same thing on Amiga (with one exception - C128 can run 2MHz mode but with no VIC, or at least 2MHz in a moment VIC doesn't have to have memory access so if I understood correctly when beam is off screen; afaik 68k can't do the same so steal chipset DMA cycles when chipset doesn't really need it). So one solution is to make more slots (faster memory and mem controller) - which is of course costly. The other solution is to make DMA more flexible and let CPU steal unused chipset memory cycles. And that one might cause less compatibility issues because all timings would've been exactly the same.

[Gorf]

Originally Posted by AestheticDebris

The 6502 and 68000 only ever access the bus on alternate cycles, a design feature which makes it easier for video hardware to use the other cycles to access RAM without slowing anything down.

That is exactly what I wrote....

The 68020 doesn't work like that, it could potentially access the bus on any cycle and thus has to be stalled if a shared device is accessing it.

YES!
That is exactly what my idea tries to mitigate!

right now on every A1200 the CPU has access only once every 560ns (two times Amiga DMA slot duration )
This is only every 8th cpu clock-cycle (1.75 Mhz vs. 14MHz)


But 70ns DRAM is fast enough to split the usual 280ns DMA slot into two 140ns slots:
one half for the Blitter and one half for the CPU.

Now we have actually doubled the possible CPU accesses.

This is of course still not every CPU cycle but only every 4th, but:
a) even FastRAM is no where fast enough the allow every cycle
b) the 020 needs on most operations more than one clock cycles

That's why adding FastRAM to the A1200 will only double the performance at best. If we could grant the CPU roughly twice as much accesses to the ChipRAM, the immediate need for FastRAM would almost disappear.

[pandy71]

Originally Posted by Gorf

Your are still not hearing me:

It is about the access to ChipRAM at times, when there is NO doubleCAS BitPlane DMA.
Active Bitplane DMA Slots are Double-CAS already - you can't squeeze anything else in there.

It is about the stage AFTER the Bitplane fetch is complete, but Alice ist still blocking every second slot, without doing anything with it, or just doing single 16bit Blitter operations.

THERE one could split one 285ns slot into half and grant the CPU access as well.

Neither bitter operations nor the 68020 can to burst modes - so we are stuck with singe random accesses - 16bit wide for the Blitter and 32bit wide for the 020.
Both Blitter and 020 would have change to use the slot - even in pseudo "parallel", with fast enough DRAM.
But they would of course read or write to totally unrelated locations in memory, as the Blitter does its blitting and the CPU does its processing.

I hope I could describe this now in a better and clearer way.

I hear you - this exactly is what i've already wrote - different bus arbiter - faster memory, to provide legacy compatibility "old DMA" cycles with static arrangement, "new DMA" cycles in adaptive way. Thanks to buffering hide this 285ns bus occupation.

Also blitter cycles could be combined to form 32bit (if they are related to same area - should be not difficult to add such logic, clocking blitter faster internally would efficiently speed up without being to complex)

[Gorf]

Originally Posted by Promilus

@Gorf - as I've said - it's alternated access.

YES!
And so have I!

It's 1 device at particular cycle.

Of course!
I never said otherwise!

So e.g. if 6502 running at 1MHz requires RAM .....

I know all that!
That's exactly how I came up with my idea...

Am I really so terrible at explaining things?
Or are you just jumping to unreasonable conclusions without reading carefully, what I did actually write?

So one solution is to make more slots (faster memory and mem controller)

Finally!!
Yes - but as I pointed out the memory in the A1200 is already 70ns.
So it only comes down to the controller logic.

- which is of course costly.

What is more costly in 1991:
adding 1 MB FastRAM or implementing a faster ChipRAM controller logic?

The other solution is to make DMA more flexible and let CPU steal unused chipset memory cycles.

You don't say ... of course that would be preferable!
I clearly stated that my solution would be for the case, Commodore could not figure out how to fix Alice in time.
In that case they could leave Alice unchanged and use a external memory controller logic that allowed for using 140ns slots instead of 280ns (or having two accesses per 280ns slot as I described it earlier) without Alice or the rest of the chipset being aware of it.

And that one might cause less compatibility issues because all timings would've been exactly the same.

The Chipset timings would not affected at all by my proposed solution.