Chips for AGA reproduction

[pandy71]

Originally Posted by Mathesar

On a re-implemented Paula chip, the 14bit mode could be bit perfect.
This is because one would digitally adjust the volume and mix the channels together before sending it off to an external high resolution audio DAC. This is unlike the original Paula which uses 4 individual 8bit (poor) DAC's and PWM (at least that's what I know) volume control.

Technically you can modify signal path and provide 14 bit samples (i.e. AUDxDAT*AUDxVOL) same approach for panpot (a.k.a. panning i.e. possibility to mix channel level between L and R output).

Originally Posted by Mathesar

14bit is almost as good as 16bit in practice (= room with some noise, part of it coming from buzz of that good old CRT).

By combining two 8 bit channels you can have true 16 bit audio so no 14-bit trick required - this is easy in digital domain - so new audio modes without touching anything in Amiga. Support for compressed PCM (ADPCM)
Blitter may have capability (audio mode) to mix channels in RAM (multiplier and adder in blitter path).

Originally Posted by Mathesar

And that would mean no additional software needed other than existing AHI.

High level API is useful to create HAL - IMHO low level HW and high level API's are OK and beneficial for users.

Originally Posted by Mathesar

Also, more generally thinking, there are a LOT of things one could do to make a faster, more capable Amiga chipset without doing anything requiring software changes.

Yes, in fact this is like fixing obvious limitations* in chipset design.

*Chipset limitations due limited technology and/or tight time budget.

Originally Posted by Mathesar

Think about more chipset bandwidth so the CPU can acces the chipram faster (and faster BLITTER, faster floppy, higher audio samplerates, etc, etc) or more chipram

This may affect software - perhaps not as much as on Atari ST where everything is tightly timed so even small CPU timing difference will ruin lot of software but still.
Faster floppy - just add buffer and use default DMA to transfer data not RAW flux signal - this will already double transfer rates and made 500kbps possible.
There is few unused register addresses in DFFxxx space - new features can be accessible trough indirect addressing (with only two 16 bit registers almost 128KiB register space - first shot - real RAMDAC with 24 bit color and for example 32/64K size - easily switchable by single Copper cycle).
Real chunky mode just be changing how interpreted are normal biplanes (HAM-E embedded).
There is plenty possibilities that will not affect any legacy timing - rather they modify way how data are processed.

[Lord Aga]

On topic. It's kinda sensible to go for 1:1 implementation first. And start with the simplest of chips I guess. I don't know what that would be. Gary? CIAs?

[pandy71]

Originally Posted by Lord Aga

On topic. It's kinda sensible to go for 1:1 implementation first. And start with the simplest of chips I guess. I don't know what that would be. Gary? CIAs?

No doubt on 1:1 in first stage.

Gary is simple address decoder so nothing fancy and can be easily replaced even at some point by TTL logic (A1000 can be used as reference).

CIA's are different and based on general issues with them (they are sensitive and at the same time exposed for external signals) it looks like very good candidate for replacement.

[Mick]

It's only a quick mock-up but would it be realistic to do something like this? or would the smaller chips be a problem?



Are the 3.3V FPGA's absolutely not tolerant of 5V or would it just be a case of heat and lower lifespan? maybe find a solution with legs and stick a voltage regulator on the back?

If someone wants to give this a try I'll volunteer my A600 board as guinea pig.

Is there anyone actually able/willing to do the software side? I can try to design a drop in PCB if so.

[AmigaHope]

Originally Posted by pandy71

No doubt on 1:1 in first stage.

Gary is simple address decoder so nothing fancy and can be easily replaced even at some point by TTL logic (A1000 can be used as reference).

CIA's are different and based on general issues with them (they are sensitive and at the same time exposed for external signals) it looks like very good candidate for replacement.

Gary could be probably done incredibly cheaply with a GAL board like has been done for the PLA on the C64.

CIAs would just need a microcontroller, like one of the smaller Arduinos. You could do it with custom silicon but it's probably not worth paying for the wafer rideshare for it, and an FPGA is overkill. If you absolutely wanted to avoid any firmware being involved you could maybe build a small board with part of the logic in a custom ASIC small enough to get on the cheapest/free rideshares like MOSIS, with a few parts like the timers in commodity components.

The hard ones will be Agnus/Alice Denise/Lisa because they're so complex, and Paula because she's so poorly-understood.

[Mick]

So start with something less complicated like the CIA's?

Can't we get the bulk of the code from Mike at FPGAArcade or something? he talks about his cores being made open source and moved to Github?

https://www.fpgaarcade.com/replay2-a...-nano-support/

Plus he really knows his stuff and seems to be a perfectionist so his work should be really high quality.

[SukkoPera]

jbilander did some research for a possible Agnus replacement in my thread here: http://eab.abime.net/showpost.php?p=...&postcount=148

That is more about how to physically make a drop-in replacement rather than the code that would run in it.

[pandy71]

As an alternative to FPGA some more affordable ASIC approach like https://www.efabless.com/ can be investigated. ASIC are expensive but older technologies (130nm so 5V I/O compliant) is more than need when compared to overall Amiga chipset complexity.

btw
Is there any explanation why Lisa in AGA is so much complicated when compared to ECS Denise (transistor count is approx 20 - 30 times bigger) - Lisa was outsourced to HP for their process to make possible 35ns clock but still this not explain so enormous grow of the complexity (i can imagine CLUT is one of primary sources for this - from 32x16 to 256x24(or 25? anyone knows if transparency can be set for CLUT entries same as on ECS?). but beside this and perhaps some buffers i don't see anything else...

[Toni Wilen]

256*25 (Genlock bit is settable and readable if RDRAM=1)

Other things I can think of that are much bigger in Lisa:

- 2 more bitplanes.
- Bitplane registers (I think it is 3 per plane) are 64-bit (was 16-bit)
- Sprite registers (4 per sprite) are 64-bit (was 16-bit)
- Palette registers probably are some kind of complex dual-ported design because they can be written to (or even read) by the CPU without visible glitches.
- "real" shres support, all horizontal comparators use shres timing internally. Denise was mostly lores based except bitplanes supported hires. But this shouldn't increase complexity much.

[pandy71]

Originally Posted by Toni Wilen

256*25 (Genlock bit is settable and readable if RDRAM=1)

Other things I can think of that are much bigger in Lisa:

- 2 more bitplanes.
- Bitplane registers (I think it is 3 per plane) are 64-bit (was 16-bit)
- Sprite registers (4 per sprite) are 64-bit (was 16-bit)
- Palette registers probably are some kind of complex dual-ported design because they can be written to (or even read) by the CPU without visible glitches.
- "real" shres support, all horizontal comparators use shres timing internally. Denise was mostly lores based except bitplanes supported hires. But this shouldn't increase complexity much.

Thx Toni, i should check spec before asking.
Can't find now source but somebody listed that Lisa 391227-01 has over 225 thousand transistors - this mean it is most complex IC - it has more transistors than Agnus (Alice), + Paula + Denise + MC68000 - this is very odd to be honest unless HP process required something special then it is very difficult to justify such complexity.

[AmigaHope]

To be fair, Denise was laid out by hand and was ridiculously optimized. The ECS Denise changes were super tiny modifications, but the extra Lisa features were probably stuff they couldn't fit easily into the existing mask. Maybe they used some automated tool to make Lisa based on clean-sheet I/O requirements and the tool didn't optimize very well.

[pandy71]

Originally Posted by AmigaHope

To be fair, Denise was laid out by hand and was ridiculously optimized. The ECS Denise changes were super tiny modifications, but the extra Lisa features were probably stuff they couldn't fit easily into the existing mask. Maybe they used some automated tool to make Lisa based on clean-sheet I/O requirements and the tool didn't optimize very well.

CSG was incapable to deliver 35ns performance - ECS was already tricky and they need to use tricks as CLUT interleaving (efficiently reduce maximum number of colors to 4 selected from 64 not 4096). Lisa was made in sub-micron technology (0.6um AFAIR) so no problem with 35ns however with enormous amount of transistors when compared to other AGA IC's...

This is something tricky... Lisa can be most challenging task (despite being quite simple at the functional level).

Paula is tricky especially on the floppy part - particularly GCR as it is completely not covered by any official documentation...

Agnus (Alice) can be tricky in terms of errors.

CIA should be straight forward and almost easiest - in fact can be implemented easily in cheap ARM such as RP2040 (with functionality such as transparent integration of the USB 1.1 KB host within Amiga).

[super_adam]

CIA seems to be in the works already, but of course open source solution would make more people happy.
https://1nt3r.net/j-cia/

[pandy71]

Originally Posted by super_adam

CIA seems to be in the works already, but of course open source solution would make more people happy.
https://1nt3r.net/j-cia/

lol - sanded markings... hilarious... i bet same can be done with RP2040 (Programmable I/O and DMA made this inexpensive ARM almost ideal for Amiga IC replacement project)

[AmigaHope]

Originally Posted by pandy71

CSG was incapable to deliver 35ns performance - ECS was already tricky and they need to use tricks as CLUT interleaving (efficiently reduce maximum number of colors to 4 selected from 64 not 4096). Lisa was made in sub-micron technology (0.6um AFAIR) so no problem with 35ns however with enormous amount of transistors when compared to other AGA IC's...

Right, but why so many more transistors? What I was saying is that maybe they didn't just add features to the Denise design and do a die shrink. I'm speculating they just did a clean-sheet replacement, hence the lack of optimization.

Lorraine was developed by hand, without the benefit of smart ASIC design software. This meant years of work but super tight design. By the time AGA came into being, they might have used automatic logic generation software -- which was relatively new and rather inefficient at the time. That would be something to ask some of the old Commodore engineers that are still with us.

[pandy71]

Originally Posted by AmigaHope

Right, but why so many more transistors? What I was saying is that maybe they didn't just add features to the Denise design and do a die shrink. I'm speculating they just did a clean-sheet replacement, hence the lack of optimization.

No clue and curious same like you - this may be problem to generate Lisa clone (but should be not a problem when Lisa function analogue is created)

Originally Posted by AmigaHope

Lorraine was developed by hand, without the benefit of smart ASIC design software. This meant years of work but super tight design. By the time AGA came into being, they might have used automatic logic generation software -- which was relatively new and rather inefficient at the time. That would be something to ask some of the old Commodore engineers that are still with us.

Luckily to us we may have some extrapolated data from Atari yard - Atari people restored original magnetic tapes with Atari IC's topology so they have original documentation. In those times CAE station was used by Commodore and by Atari so work was manual only to some point and i bet then engineers used some form of libraries with some primitives to speedup overall design process. Nowadays IC's are simply poorly optimized due time constraints but in past this kind of pressure was not intense and also logic less complicated and way more skilled engineers...
It would be nice if someone from HP could say something on this...

[elenachen]

Maybe Dave Haynie would know more?

[TEG]

Perhaps it contain AAA or Hombre parts which are deactivated or well hidden. Perhaps we have the one blitter per plan ability and we just don't know.

[pandy71]

Originally Posted by elenachen

Maybe Dave Haynie would know more?

Perhaps but don't get mi wrong - i have more faith in people like PurpleMelbourne. At some point replacement for Amiga IC's will be available and i can bet that this will be possible thanks to passionate people present on forum like EAB and/or similar to EAB.

[PurpleMelbourne]

Originally Posted by pandy71

Perhaps but don't get mi wrong - i have more faith in people like PurpleMelbourne.

Thank you for the compliment of trust Pandy71
I've been distracted from this while attending to my PicassoIV recreation which is now being assembled as prototype.

For Agnus I'm now working with an Altera Quartus fan, so we'll be using an Altera chip.

Late 1990's Altera Acex chips look suitable with 50,000 or 100,000 gates and 5volt GPIO pins, though 2.5volt internal voltage.
The trouble is that you need an OLD version of Quartus to use these chips. The most recent version is Quartus 9.0 SP2
Quartus 9.1 has support for 5volt chips removed.

Agnus from the MiniMig/Mister code seems a good place to start.

Can anyone tell me how many Logic Elements it takes once compiled to silicon?