Chips for AGA reproduction

[Chucky]

still no explanation why risking of breaking compability with adding chipset stuff. we need uniformity as told so it needs to be done via a API so current solutions is available as well as future.. doing chipset stuff is just no reason whatsoever.. and as adding 16 bit audio etc would require reprogramming anyway why not do it proper?

I am still amused how people seems to think: add 16 bit paula and suddenly protracker will handle 16bit audio...

[pandy71]

Originally Posted by Chucky

still no explanation why risking of breaking compability with adding chipset stuff. we need uniformity as told so it needs to be done via a API so current solutions is available as well as future.. doing chipset stuff is just no reason whatsoever.. and as adding 16 bit audio etc would require reprogramming anyway why not do it proper?

I am still amused how people seems to think: add 16 bit paula and suddenly protracker will handle 16bit audio...

Not sure why adding functionality will add risk of breaking compatibility - if new functionality will be designed wisely then there is no risk of breaking compatibility. Adding 16 bit audio may be done without loosing original functionality - there is at least two ways to do such extension and not loose any previous one. And old Protracker for sure will be not able to use 16 bit but new ones should have no problem with this.
I bet that some people will be happy to write new Protracker or perhaps MilkyTracker can be used for this. More important is to create standard 16 bit extension and later use it in all HW (this of course will not remove possibility to add different audio extensions beyond plain 16 bit capability).

But from this thread this is less relevant - i understand your idea - providing alternate source of the spare parts for old/legacy HW.
Adding extension's is nice to have but less important.

[coldacid]

Yeah, first let's put together the synthesizable VHDL or Verilog specifications for the chips, and then worry about extensions afterwards.

[Chucky]

Originally Posted by pandy71

Not sure why adding functionality will add risk of breaking compatibility - if new functionality will be designed wisely then there is no risk of breaking compatibility. Adding 16 bit audio may be done without loosing original functionality - there is at least two ways to do such extension and not loose any previous one. And old Protracker for sure will be not able to use 16 bit but new ones should have no problem with this.
I bet that some people will be happy to write new Protracker or perhaps MilkyTracker can be used for this. More important is to create standard 16 bit extension and later use it in all HW (this of course will not remove possibility to add different audio extensions beyond plain 16 bit capability).

But from this thread this is less relevant - i understand your idea - providing alternate source of the spare parts for old/legacy HW.
Adding extension's is nice to have but less important.

adding functionality. like when we got AGA. not a single software broke before that. yeah. I remember that..

and as software would need to be reprogrammed. why not do it with AHI and suddenly old soundcardsolutions would be supported aswell. a massive win-win so again totally pointless to add stuff to "chipset" that can break stuff..

so doingit "chipsetstyle" is just pointless. totally pointless

[pandy71]

Originally Posted by Chucky

adding functionality. like when we got AGA. not a single software broke before that. yeah. I remember that..

Well - named 3 important applications for Amiga where AGA introduce incompatibility so serious that Amiga loss something permanently.
Lot of incompatibilities was introduced for example by new Kickstart and new OS rev - if you not intend to use new HW extension then you can order to shut up and pretend it doesn't exist.

Originally Posted by Chucky

and as software would need to be reprogrammed. why not do it with AHI and suddenly old soundcardsolutions would be supported aswell. a massive win-win so again totally pointless to add stuff to "chipset" that can break stuff..

so doingit "chipsetstyle" is just pointless. totally pointless

But what prevent to add new HW extension so it can be used trough AHI and trough "chipsetstyle" ? I see no contradiction in this...

Take for example AAA extension to chipset - it will fit in "chipsetstyle" and provide new functionality - for example 16 bit audio add 4 new channels to already existing ones - there is lot of 'reserved' chipset location and as you analyze their structure it looks quite obvious that some functionality was not implemented on ICS/OCS/ECS/AGA but somehow planned to be implemented. Trivial thing - flexible Audio channel allocation between Left and Right with 'panorama' - easy to implement, trivial from programmer, significant functionality improvement - another topic Audio sample period - for now it is simple divider so sample rates are very coarse at usable range and very fine where there is no sense (like 150Hz sample rate) - replace simple divider by NCO and sample period resolution will be way more functional and it will allow Amiga to play for example 22050Hz samples without significant error - easy to implement and should not ruin anything as software may choose between old and new.
Same for serial port - replace divider by NCO (single core can be reused between audio and UART), add buffer (FIFO) to serial port - if this brake some software compatibility?
From my perspective no difference between chipset and non-chipset (except possibility to use Copper) - same HW and can be available trough API's or directly.
Key is to create standard and follow standard - chipset or not - it will be same.

[Chucky]

Originally Posted by pandy71

Well - named 3 important applications for Amiga where AGA introduce incompatibility so serious that Amiga loss something permanently.
Lot of incompatibilities was introduced for example by new Kickstart and new OS rev - if you not intend to use new HW extension then you can order to shut up and pretend it doesn't exist.

you clearly have forgotten how many programs just screwed up when AGA was releaed... I haven't forgotten that..

Take for example AAA extension to chipset - it will fit in "chipsetstyle" and provide new functionality - for example 16 bit audio add 4 new channels to already existing ones - there is lot of 'reserved' chipset location and as you analyze their structure it looks quite obvious that some functionality was not implemented on ICS/OCS/ECS/AGA but somehow planned to be implemented. Trivial thing - flexible Audio channel allocation between Left and Right with 'panorama' - easy to implement, trivial from programmer, significant functionality improvement - another topic Audio sample period - for now it is simple divider so sample rates are very coarse at usable range and very fine where there is no sense (like 150Hz sample rate) - replace simple divider by NCO and sample period resolution will be way more functional and it will allow Amiga to play for example 22050Hz samples without significant error - easy to implement and should not ruin anything as software may choose between old and new.
Same for serial port - replace divider by NCO (single core can be reused between audio and UART), add buffer (FIFO) to serial port - if this brake some software compatibility?
From my perspective no difference between chipset and non-chipset (except possibility to use Copper) - same HW and can be available trough API's or directly.
Key is to create standard and follow standard - chipset or not - it will be same.

well AAA was never released so we do not know how it would affect existing software.

still give me ONE reason why you want to change the chipset registers risking incompability instead of doing it via what expansioncards does?

it is utterly pointless to do this. it wold only risc incompability. it would divide the amiga community even more as software needs to be for that specific solution.. instead of doing something that can be adopted to already existing solutions AND new.

change serialport. change serial.device to somethingh else THAT is exacly what I want. you change a device and you are done with it. instead of some weird chipset-thing that noone supports..


pointless is the word. totally pointless..

the chipsety as we have it now should be taken as STATIC. do not change, modify or so. not even bugfix.. all to keep compability.

[torsti76]

Well, Chucky, the Amiga world is already divided in wedge box users with one real expansion slot at most and bigbox users with lots of expansion slots.

So, while I agree that incompatibilities are a bad thing to introduce, I can see the point of low-end Amiga users to also want some new features without stacking a pile of RPis into the sockets... ;-)

Anyway, I think the proper way to accomplish this is by expanding the capabilities of remade boards, like you did with your ReAmiga. Enhancements for the chips themselves should be limited to fixing known bugs.

If they are verilog, you can let the user decide if he wants the bugfixed version or not.

[pandy71]

Originally Posted by Chucky

you clearly have forgotten how many programs just screwed up when AGA was releaed... I haven't forgotten that..

This is not about "many programs" - this is about affecting Amiga as overall - i can accept loss of some demos and games (and conditional if sane mechanism of disabling extension exist).

Don't get me wrong - after AGA even more programs was created to replace those that no longer works and AGA is in general a good extension when compared to ICS/OCS/ECS. Could be of course better but... it could be like ECS.

Originally Posted by Chucky

well AAA was never released so we do not know how it would affect existing software.

Well - after so many years this looks like something worth to be verified...

It is a shame that Commodore had no will to introduce some of those things in ECS/AGA.

Originally Posted by Chucky

still give me ONE reason why you want to change the chipset registers risking incompability instead of doing it via what expansioncards does?

Because some things should available as standard for everyone...
Create unified HW with basic capabilities and allow those who are unsatisfied to add even better extension trough external expansion boards.
Beside - today Amiga is a hobby not business (at least for most of us)

Originally Posted by Chucky

it is utterly pointless to do this. it wold only risc incompability. it would divide the amiga community even more as software needs to be for that specific solution.. instead of doing something that can be adopted to already existing solutions AND new.

Same as community will be divided by external cards... even more than by taking IC and replace it.

Originally Posted by Chucky

change serialport. change serial.device to somethingh else THAT is exacly what I want. you change a device and you are done with it. instead of some weird chipset-thing that noone supports..

Or ... create trap to catch call to default UART and provide better functionality by using external serial (nowadays there is not to many devices using serial anyway so this is less relevant). But still such exception is better to be implemented in HW than in SW and HW.

Originally Posted by Chucky

pointless is the word. totally pointless..

the chipsety as we have it now should be taken as STATIC. do not change, modify or so. not even bugfix.. all to keep compability.

For first step yes but as you introduce it trough programmable logic (FPGA) then next step will be add functionality - this is quite obvious.

[robinsonb5]

Originally Posted by Chucky

you clearly have forgotten how many programs just screwed up when AGA was releaed... I haven't forgotten that..

To be fair in the vast majority of cases that breakage was due to the more stringent memory alignment requirements and (for non-system-friendly software at least) could be fixed with a small wrapper utility. With the exception of fmode, the mere existence of other registers wasn't the source of the problem.

still give me ONE reason why you want to change the chipset registers risking incompability instead of doing it via what expansioncards does?

For many years some of us have had strong ideas about what Commodore *should* have done with the chipset - with FPGAs we can actually try it, and say "See - this works and was very little effort", or (more likely) "Huh - that's trickier than I thought, now I see why they didn't do that!"

[Krashan]

Originally Posted by Chucky

why not do it with AHI

Because AHI has serious design flaws and definitely should be replaced by something better.

[TEG]

Originally Posted by Stedy

Consider the A600, you'd need to replicate Agnus, Denise, Gayle, Paula and the VIAs/CIAs. A ballpark number for the hours per device, for a proof of concept, prototype design would be 500-1000 hours per device. For 5 devices, that's 2500-5000 hours, I work 1662 hours a year!

Do we know if the layout of AGA chips exist somewhere?

Because there this technology: Researchers Can Now Reverse Engineer Entire Chips With X-Ray Technology (2019)

AGA photolithography being not very thin is perhaps an advantage here.

I don't know if it's accessible for the public and what is the cost but it could be a step. If the cost is affordable, a financing campaign would eventually do the trick.

Admitting we arrive here, and letting copyright issues aside, do you think we can then go anywhere?

[torsti76]

There's been someone working on this already. Can't find the thread atm.

His approach was: X-ray the different layers of a chip and derive a schematic gate by gate by just looking at it. This is tedious work as well, but having the layout via X-ray as well as the schematic would provide experts with insight on possible quirks of a chip because of crosstalk between different gates and so on.

However, this approach is at least as time consuming and error prone as other ways of reverse engineering the chips, e.g. by looking at which input vector results in which output. This is especially true for the Amiga chipset with its comparably low pin count and many known (good) states of input vs. output.

For some of the chips, however, the schematics are available. That still leaves the issue of ownership and copyright.

Producing the chips in silicon again is out of the question financially. For VHDL versions, on the other hand, how the schematics are derived / obtained is near irrelevant.

[TEG]

Originally Posted by torsti76

For some of the chips, however, the schematics are available.

Do you have more informations?

At least it seems there's one commercial offer for chip reverse-engineering but I'm not sure they would be able to process an old chip: https://www.pcbic-reverse.com/

And to obtain the VHDL, a free software seems to do that: Degate.

Degate can also generate VHDL and Verilog implementation stubs.

If you have a behavioural description of all gates, it is possible to generate rolled out VHDL or Verilog code. From that you can simulate and resynthesize the circuit.

But it's a lot of work for sure.

[kamelito]

You could try Google for github agnus schematics ??

[TEG]

Oh yeah, schematics. Not masks design.

[pandy71]

Originally Posted by Krashan

Because AHI has serious design flaws and definitely should be replaced by something better.

Yes, AHI is not the best but to be honest i dont know anything better that can be used - Linux (open source) solutions are too heavy on the required resources.

Originally Posted by torsti76

There's been someone working on this already. Can't find the thread atm.

His approach was: X-ray the different layers of a chip and derive a schematic gate by gate by just looking at it. This is tedious work as well, but having the layout via X-ray as well as the schematic would provide experts with insight on possible quirks of a chip because of crosstalk between different gates and so on.

IC layout can be captured trough classical decapping - https://siliconpr0n.org/map/csg/

Originally Posted by torsti76

For some of the chips, however, the schematics are available. That still leaves the issue of ownership and copyright.

Not sure on this - seem patents are expired and based on schematics new version can be created without violating original layout/mask/topology.

Originally Posted by torsti76

Producing the chips in silicon again is out of the question financially. For VHDL versions, on the other hand, how the schematics are derived / obtained is near irrelevant.

True but nowadays technology and business models evolving quite quickly - we talking about 2um design.

[Bruce Abbott]

Originally Posted by robinsonb5

For many years some of us have had strong ideas about what Commodore *should* have done with the chipset - with FPGAs we can actually try it, and say "See - this works and was very little effort", or (more likely) "Huh - that's trickier than I thought, now I see why they didn't do that!"

With the emphasis on 'we'. One thing I enjoy doing with retro computers is adding hardware that I have have created, whether it be entirely unique or based on someone else's design. The more minimalist the design and the fewer, cheaper, and more available the parts used the better. Then anyone else with reasonable electronics skill can reproduce my design with whatever parts they can get, without spending a lot of money or having to purchase stuff from me.

Having more knowledge of how the Amiga's custom chips work will help for making compatible 'enhanced' chips, and also for creating 'hacks' that extend their capabilities with minimal extra hardware.

I am not a fan of 'brute force' methods such as decapping a chip and 'resynthesizing' it from a mess of obscure HDL, then throwing the result into an expensive and/or hard to use FPGA. Nor am I impressed by simulating it on a Raspberry Pi. I want to see the original chip schematics and understand the design, then perhaps figure out simple ways to improve it without breaking compatibility.

This is unlikely to produce the ultimate features or performance, but I don't care (If I wanted that I would just use a PC). It's the challenge of 'tweaking' the original hardware to get more out of it that interests me, same as it was 'back in the day' when my machines were new.

[hammer]

Originally Posted by pandy71

Not sure why adding functionality will add risk of breaking compatibility - if new functionality will be designed wisely then there is no risk of breaking compatibility. Adding 16 bit audio may be done without loosing original functionality - there is at least two ways to do such extension and not loose any previous one. And old Protracker for sure will be not able to use 16 bit but new ones should have no problem with this.
I bet that some people will be happy to write new Protracker or perhaps MilkyTracker can be used for this. More important is to create standard 16 bit extension and later use it in all HW (this of course will not remove possibility to add different audio extensions beyond plain 16 bit capability).

But from this thread this is less relevant - i understand your idea - providing alternate source of the spare parts for old/legacy HW.
Adding extension's is nice to have but less important.

Newer Amiga audio software has support for AHI API middleware.

[pandy71]

Originally Posted by Bruce Abbott

Having more knowledge of how the Amiga's custom chips work will help for making compatible 'enhanced' chips, and also for creating 'hacks' that extend their capabilities with minimal extra hardware.

I am not a fan of 'brute force' methods such as decapping a chip and 'resynthesizing' it from a mess of obscure HDL, then throwing the result into an expensive and/or hard to use FPGA. Nor am I impressed by simulating it on a Raspberry Pi. I want to see the original chip schematics and understand the design, then perhaps figure out simple ways to improve it without breaking compatibility.

This is unlikely to produce the ultimate features or performance, but I don't care (If I wanted that I would just use a PC). It's the challenge of 'tweaking' the original hardware to get more out of it that interests me, same as it was 'back in the day' when my machines were new.

Well Ok - have similar attitude but having schematics will not lead directly to Verilog or similar HDL working code - real IC's schematics and HDL's are usually not equivalent as in IC's there is plenty of shortcuts possible (like wired OR and similar tricks) so i would expect a lot of work even with IC schematics after RE.
Side to this i rather doubt that We can improve significantly existing design - i would expect rather well done manual layout optimization so it will be extremely difficult to do things in a simpler / more efficient way but...

Originally Posted by hammer

Newer Amiga audio software has support for AHI API middleware.

More or less this is true and as such adding 16 bit to AGA (as it should be done already by Commodore) should be not a big problem but sill this is hypothetically next phase where first is to create 100% working replacement.

[Mathesar]

Originally Posted by pandy71

More or less this is true and as such adding 16 bit to AGA (as it should be done already by Commodore) should be not a big problem but sill this is hypothetically next phase where first is to create 100% working replacement.

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.

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

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

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.

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