@cdimauro

Quote:

Quote: Would this have effectively doubled chip memory bandwidth like it sounds? Are there articles or documentation somewhere that talks about this? I had an idea about how to keep the whole system 16-bit (so, still using a 68000 and with the same 16-bit chips), but I don't know if the memories available at the time were able to run at double the frequency (14Mhz instead of 7Mhz).

You have to remember that the 68000 bus-wise runs in sort of DDR mode, where a minimum bus read cycle is 8 wait states or 4 clocks. You also have to remember that the fastest memory in 1990 was 70ns, I think FPM and 60ns came around 1991, EDO RAM immediately after that and then SDRAM about 1993 (we heard about it in 92, but I don't think it was generally available).

DRAM without FPM and EDO modes take almost two whole "access time from /RAS" units. For instance HY534256AJ-70 which had a stated access time of 70ns but took 130ns minimum per cycle. A PAL or NTSC synced 68000 running at about 14.3MHz has ~70ns clock cycles.
So in the 280ns it takes the 68000 to read 16 bits of data, there's plenty of time for a chipset running at a higher clock frequency to ALSO read 16 bits of data, if you can control your timing down to about the 20ns range (which means 28MHz with the same idea of using both edges of the clock for the DRAM interface).

That would actually be quite sweet. BUT, it's a bit optimistic because a read-modify-write cycle takes a little longer time (185ns), which DOESN'T leave enough time for a minimum read cycle in the 280ns window, so at minimum I think 2 additional wait states would need to be inserted (always, to make it predictable), for a maximum throughput of 5.6MB per second of emulated dual port memory.

I'm a bit out of the loop, but I don't think anyone has tried to do this in an FPGA yet.
To summarize, the best case scenario is if every 10 28.3MHz PAL/NTSC clocks, chipset reads 16 bits and CPU reads, writes or modifies 16 bits of data. CPU access would go through the chipset and be buffered so that each CPU access takes 8-10 cycles on the CPU side but only 4-6 cycles on the DRAM side, and the chipset itself does fast 4 cycle accesses directly to the DRAM.

Now, how ECS actually operates I don't know. I _think_ ECS does exactly this but on 7.1MHz CPU side and 14.3MHz DRAM side. Or rather, 28.6MHz using only one edge of the clock. This would perfectly explain the 0.71 MIPS from a 68000 with only chip ram.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@olegil

Btw, that's a VERY long week for the weekly pet peeve, but it still disappoints me after all these years. Coulomb is my new favorite SI unit

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@matthey

After a little bit more investigation, 100ns was common in 1990, while 70ns was "preliminary" datasheets. But it's a bit depressing that with the 3-4 times difference in price between wedge and desktop Amigas there was no difference in things like this.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@olegil

EDO Ram was slow to take off in Amiga circles. Did ANY C= have EDO Ram sockets out of the box? Crazy this was all left to 3rd parties!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@BigD

Just a couple of 3rd part accelerators did benefit of EDO.

@BigD

EDO came after the last Amiga was released, so no. And for chip ram, it wouldn't have helped since CPU and DMA gets every second access. Modern memory can have multiple open pages but only if they're in different banks, so even a DDR4 takes about 45ns for a fully random access cycle if you don't use any of the burst features. So we've gone from 140ns for a full cycle in 1991 to 45ns in 2020. It's hard to be impressed. Basically ALL the performance gains have come from increased burst lengths and larger caches.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@olegil

Quote:

I think FPM and 60ns came around 1991, EDO RAM immediately after that

So that could have made it into at least the Amiga 4000T! Only the DCE accelerators from 1996 supported it in my experience. It makes quite a bit of difference too!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

Quote:

cdimauro wrote: The engineers systematically put all the blame on the (unsuccessful) management, but they are by no

Absolute BS


Engineers like Jay Miner developed new chipsets before he left the company. The chipset would have used (dual ported) VRam, that costs more than the average A500 buyer would have paid, that's one of the reasons it was never put into production by the management.

There where a lot of improvements made by the engineers of C=, that where not brought into production because the management was never interested, they could have had AGA in the A3000+ with a fast SCSI interface, but the management screwed it.

The management had stupid ideas how to sell the Amiga, ideas like a trade in of A500 computers for A500+ or CDTV, during a time when most people feared the A500+ would only be an incompatible upgrade for their existing A500.

C= / Amiga Engineers where proud for having one of the best 68k Linux systems, one of the first 68030 cards in the world and the A2410 Tiga card that was never really advertised by the C= managers. The Amiga developers at C= where an tiny group of developers, hindered by the obsolete chip production technologies at MOS, technologies that have been good enough for a 2MH 6502 but couldn't even be used for most of the 8/14 MHz chips used in the Amiga.

C=/MOS could have continued the production of the 6502 as an embedded chip, if they would have had the opportunity of updating the old production process from NMOS to CMOS but inseatd they didn't even get the money for proper handling of the waste they produced.
https://en.wikipedia.org/wiki/MOS_Technology#GMT_Microelectronics

Instead of focusing on the Amiga, some where forced to develop the C65 that was produced in a small batch of 200 peaces, but dumped by all C= sales departments.

@olegil

Quote:

EDO came after the last Amiga ...

We all would have been glad if at least the A1200 would have used one of the existing and faster RAM access technologies that where around when the A500 was introduced.

But it would have meant 256 colors of chunky GFX with higher resolution instead of the 8 Bit planar Grafik, burst cycles when reading RAM are the reason why other systems got fast but they Amiga didn't but this time of read cycles works best on cached CPUs and GFX system using continuous addresses, something that brakes the type of GFX that was used on planar graphics.


Keep in Mind:

In an another interview with a Commodore Engineer the running joke from the management was "read my lips no new chips".

Last edited by OneTimer1 on 27-Oct-2023 at 03:48 PM.

@OneTimer1

Quote:

C= / Amiga Engineers where proud for having one of the best 68k Linux systems,

Eh?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Quote:

we can see with regard to the successor of the original chipset, the so-called ECS.

ECS wasn't a successor it was just another revision of the OCS similar to how OCS was just a minor revision to the EHB less one used in early A1000 prototypes.

AGA was the "lets see how far we can push it without really going into it" revision.

AAA would have been far too little far too late (even if C= had survived and fast tracked it to a XMAS 94 release).

SuperAGA/Apollo is the alternate universe late 90s chipset that would have killed C= or whomever hold the IP in that time&reality for sure.


-> constant and real updating the HW would have made the Amiga stay relevant till the late 90s at best at which point a break from the old designs would have been overdue.
Either to 3rd party chips or if the had a 10x bigger cashflow to inhouse legacy free chips.

Both would have required constant OS upgrades forcing developers to go through proper APIs instead of hitting bare metal.

Neither happened in the 80s and the efforts done in the 90s were insufficient.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@OneTImer1
Quote:

Engineers like Jay Miner developed new chipsets before he left the company. The chipset would have used (dual ported) VRam, that costs more than the average A500 buyer would have paid, that's one of the reasons it was never put into production by the management.

@kamelito
Quote:

When the original team left the next chipset was finished they didn’t use it.

Not true, at least according to Jay Miner. Sometime in the late 80s I think I found a BBS run by Jay Miner. And like the fanboy kid I was, I peppered him with questions including rumors of a new chipset they had designed before leaving Commodore.

His reply was "Nope, never was such a thing". I had the foresight to print out that chat, and I ran across it years ago and scanned it to PDF. I posted it here years ago but can post it again if you are interested.

Back then, from my point of view, Commodore fans like myself were hanging on the idea of a rumored groundbreaking new graphics chipset to put Amiga back in front. Not much came with the 3000, and only a minor AGA upgrade with the 1200/4000. Not enough to put Amiga back on the podium.

This is an interesting topic and one I've thought about in the past. Commodore engineers are treated like celebrities, while Commodore's downfall is blamed on management. I suspect there was a lot of blame to go around.

What resources were utilized when creating the original Amiga computer & chipset? How many people, how many hours, how much $$? Were those resources not duplicated under Commodore's management? I'm not sure.

With all the time/effort put into other oddball things, I find it hard to believe Commodore wouldn't have wanted an updated graphics chipset. Perhaps the engineers on staff just weren't up for the task? Perhaps engineers underestimated the need for a major graphics upgrade?

In my eyes, the best thing done under Commodore management and engineering was the continued development of AmigaOS. The hardware upgrades were marginal, but the OS jumped forward tremendously.

Last edited by Kremlar on 27-Oct-2023 at 06:33 PM.

@OneTimer1
Quote:

C= / Amiga Engineers where proud for having one of the best 68k Linux systems, one of the first 68030 cards in the world and the A2410 Tiga card that was never really advertised by the C= managers.

Amix was a waste of time and resources, just like the C65, the PC compatibles, etc.

The A2410 was great! But why did AmigaOS not run on it???

@Kremlar

Quote:

Amix was a waste of time and resources, just like the C65, the PC compatibles, etc.

I wonder if Commodore sold in 1992/1993 more such PCs than Amigas. At least some Commodore dealers reported such numbers back in early 1993.

@pavlor

I can give you the exact number:
C= sold 0 PCs running AMIX

(yeah, not the way you meant it, but still...)

But there is that story that HP wanted to sell/rebrand the A3000UX running AMIX as their entry level UNIX workstation.
Wich would have created at least some cash flow.


Would have, could have, should have, the story of post Tramiel C=....

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@pavlor
Not sure, but my interest at the time was the success of the Amiga. Wanting Commodore as a company to succeed was secondary.

@Kremlar

With so low margins on Commodore PCs it was a dead end (and resource drain) anyway. Commodore was able to sell big number of cheap computers (4th computer manufacturer by volume of production in 1992), but low-end market means thin margins and few resources for research and development (not that Commodore cared for such thins, the company was known for underfunded R/D - in comparison to other players in this sector - at least since the mid 1980s). In my POV quite unsustainable strategy.

Last edited by pavlor on 27-Oct-2023 at 08:33 PM.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: My argument is about what was really needed an achievable with the same constraints that engineers had for ECS. Look at Commodore's IP not used for Amiga graphics. The building blocks exist within Commodore to develop competitive hardware graphics solutions.

That's exactly what my article was about!
Quote:

Quote: That's already 1992. I was talking about 1990 and my ECS version would have been WAY better than AGA for games (and not only) even staying 16 bit. FYI, the Amiga 3000+ AGA design was completed around Q1 1991 and it was delayed since Commodore's "IBM PC Jr" management was focusing on 020+ with ECS development, hence losing more than 6 months. Amiga 4000 is based on Amiga 3000+ AGA design. Amiga 1200's Budgie is effectively a cost-reduced 32-bit Super Buster, 32-bit Fast RAM controller (for additional 32-bit Fast RAM like A3000/A4000's Ramsey), and CPU's access to 32-bit Chip RAM. Commodore UK wanted a CPU-accelerated A1200 games bundle in mass production. CPU performance was a major factor in 1993.

OK, and? What's not clear to you that my article was/is about 1990 = ECS time?

@kamelito

Quote:

kamelito wrote: When the original team left the next chipset was finished they didn’t use it.

AFAIR there's not proof of that. Different opinions are floating around this topic.

@pixie

Quote:

pixie wrote: @cdimauro Quote: PiStorm doesn't "emulate" the chipset. But a good part of the system, yes (RTG, AHI, 3D acceleration is possible). In Emu68 the drivers are accessed natively, no emulation needed

Yes, but I was referring to the Amiga API for handling RTG, AHI and 3D: PiStorm implements or can implement them to offer a way better user experience.

If this is made natively or not it's "just" a detail: very important, for sure (native = much better performance), but the most important thing is having those APIs implemented, so offer those functionalities to the users.

@olegil

Quote:

olegil wrote: @cdimauro Quote: I had an idea about how to keep the whole system 16-bit (so, still using a 68000 and with the same 16-bit chips), but I don't know if the memories available at the time were able to run at double the frequency (14Mhz instead of 7Mhz). You have to remember that the 68000 bus-wise runs in sort of DDR mode, where a minimum bus read cycle is 8 wait states or 4 clocks. You also have to remember that the fastest memory in 1990 was 70ns, I think FPM and 60ns came around 1991, EDO RAM immediately after that and then SDRAM about 1993 (we heard about it in 92, but I don't think it was generally available). DRAM without FPM and EDO modes take almost two whole "access time from /RAS" units. For instance HY534256AJ-70 which had a stated access time of 70ns but took 130ns minimum per cycle. A PAL or NTSC synced 68000 running at about 14.3MHz has ~70ns clock cycles. So in the 280ns it takes the 68000 to read 16 bits of data, there's plenty of time for a chipset running at a higher clock frequency to ALSO read 16 bits of data, if you can control your timing down to about the 20ns range (which means 28MHz with the same idea of using both edges of the clock for the DRAM interface). That would actually be quite sweet. BUT, it's a bit optimistic because a read-modify-write cycle takes a little longer time (185ns), which DOESN'T leave enough time for a minimum read cycle in the 280ns window, so at minimum I think 2 additional wait states would need to be inserted (always, to make it predictable), for a maximum throughput of 5.6MB per second of emulated dual port memory. I'm a bit out of the loop, but I don't think anyone has tried to do this in an FPGA yet. To summarize, the best case scenario is if every 10 28.3MHz PAL/NTSC clocks, chipset reads 16 bits and CPU reads, writes or modifies 16 bits of data. CPU access would go through the chipset and be buffered so that each CPU access takes 8-10 cycles on the CPU side but only 4-6 cycles on the DRAM side, and the chipset itself does fast 4 cycle accesses directly to the DRAM. Now, how ECS actually operates I don't know. I _think_ ECS does exactly this but on 7.1MHz CPU side and 14.3MHz DRAM side. Or rather, 28.6MHz using only one edge of the clock. This would perfectly explain the 0.71 MIPS from a 68000 with only chip ram.

I'm not so much involved in those technical details.

From what I read, it should be possible to have 70ns memories and doubling the clock for them (and the processor).

Just to be more clear, no fancy solution using both edges of the clock is required: only imagine an Amiga 500 with 68000, memory and chipset running at 14Mhz.

So, everything still works exactly like the original 500, but the frequency of those components which is doubled.
It means that the same DMA slots allocation is used for accessing the memory by both the chipset (2 cycles per slot / access) and the processor (4 cycles), with no other change.

This is the base for the new system. However a few, simple, changes are required to have the display controller generate the proper NTSC/PAL signal (otherwise nothing is working anymore, because of the frequencies which are doubled).