Would a special build of WinUAE allow for such kind of implementations be tested for real?

It would be interesting to explore hypothetical scenarios in a time of significant game development and new IDE releases, and with some actual test case figures, and/or games that could take advantage of these advancements.

Last edited by pixie on 05-Aug-2024 at 06:56 AM.
Last edited by pixie on 05-Aug-2024 at 06:46 AM.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

In principle, an "in virtuo" implementation is entirely possible, but the challenge I suspect would be in validating it as you would need cycle exactness and that's not going to be simple. Especially for the new features. You are implementing a concept there and it would be pure guess work how long various things should take.

_________________
Doing stupid things for fun...

One of the fun things I can do with MC64K is just invent new display modes and things because it's all totally virtual and equally doesn't have any notion of cycle correctness to consider.

The closest I get to that is the "copper" workalike (finite interpreted line transfer handler, aka FILTH), which just sits in the virtual pixel to display pixel conversion scanout that happens every time the display is refreshed. But that's not a real "beam", it's just that the conversion of virtual framebuffer to something physically displayable proceeds in a row by row, pixel by pixel fashion.

_________________
Doing stupid things for fun...

@Karlos

Quote:

You are implementing a concept there and it would be pure guess work how long various things should take.

I see... and if one was to use FPGA, would it face a similar challenge in terms of timing considerations when building its logic?

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

I think an FPGA implementation would obviously have it's own challenges. It's not my area of expertise, but I can imagine that at the very least it would have consistent timing behaviour

_________________
Doing stupid things for fun...

@pixie

Quote:

pixie wrote: Would a special build of WinUAE allow for such kind of implementations be tested for real?

Yes, but who'll do it? Toni is out of question: he's not interested (not even to implement the Apollo 68080).
Quote:

It would be interesting to explore hypothetical scenarios in a time of significant game development and new IDE releases, and with some actual test case figures, and/or games that could take advantage of these advancements.

It would be cool, but without software written for it, it's only pure exercise.

Don't get me wrong: there are hardware systems which were defined purely on software side, but without software they are useless. AFAIR there's only one platform like that which is like "retro" / 8-bit, and that it got software (games!) developed for it.

@Karlos

Quote:

Karlos wrote: @pixie In principle, an "in virtuo" implementation is entirely possible, but the challenge I suspect would be in validating it as you would need cycle exactness and that's not going to be simple. Especially for the new features. You are implementing a concept there and it would be pure guess work how long various things should take.

It has some challenges, sure. The good thing is that the proposals are very minimal (I wanted to "mimic" what could have been possible with the technology available at the time) and independent (so, they can be implemented just one at the time).

@Karlos

Quote:

Karlos wrote: One of the fun things I can do with MC64K is just invent new display modes and things because it's all totally virtual and equally doesn't have any notion of cycle correctness to consider. The closest I get to that is the "copper" workalike (finite interpreted line transfer handler, aka FILTH), which just sits in the virtual pixel to display pixel conversion scanout that happens every time the display is refreshed. But that's not a real "beam", it's just that the conversion of virtual framebuffer to something physically displayable proceeds in a row by row, pixel by pixel fashion.

That's another example of software-only platform.

But as long as it's cool for you... enjoy.

@cdimauro

Indeed. The point of it being virtual is the implementation of ideas are only limited by your imagination, not the very real limitations of circuitry, clock speeds, access times, etc.

_________________
Doing stupid things for fun...

@pixie

What improvements to the chipset are you considering?

@bhabbott

Aren't we in the realms of this with SAGA already?

_________________
Doing stupid things for fun...

@bhabbott

Those expressed on cdimauro's threads, or others that fallow the same lines expressed there.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

Personally, I'd consider a few things:

More Paula channels, ideally at least 8, with independent L/R volume and, as you can surely guess, a programmable filter chain per voice.

I'd probably want support for 16 bit per channel ultra linear mode just to appease the angry mob.

_________________
Doing stupid things for fun...

@Karlos

C= gave up on upgrading MOS/CSG fabs and even the Amiga as we know it with Hombre! Gould just wanted to flog A500/CDTV 68000 level tech until retirement! He probably missed selling calculators!

Last edited by BigD on 06-Aug-2024 at 10:13 PM.

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

@BigD

AA's Alice was produced using CSG's 1.5-micron process. The original Agnus has CSG's 5-micron process.

AA's Lisa was produced using 3rd parties 1.5-micron process since there's not enough production capacity from CSG's 1.5-micron fabrication plant.

For C65, CSG has 2-micron process fabs with 500 to 2000 5-inch wafers per month capacity.
6-inch wafer upgrades were proposed.

AAA's Andrea uses a 1.0-micron process from HP.

CGS has upgraded their fabs, but they are not enough.

Companies like ATI used formerly Italian state-owned fabs from ST-Micro.

Last edited by Hammer on 07-Aug-2024 at 03:11 AM.
Last edited by Hammer on 07-Aug-2024 at 03:09 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@pixie

Quote:

pixie wrote: @bhabbott Those expressed on cdimauro's threads, or others that fallow the same lines expressed there.

I think the problem there is basically what I said originally, plus the additional problem of a lack of support. The latter is not a huge problem in that you can write your own proof of concept code that makes use of magic new hardware registers you've managed to smuggle into the system.

There's a guy that has made the fabled AA3000 AGA+DSP design and created a library to support the additional functionality. The number of people that can make use of it, are diminishingly small though.

One of the reasons MC64K exists is to just have fun experimenting with ideas for their own sake. For example, I wanted to create a HAM mode that was well suited to 15-bit. I was able to add that in a lunch break. I'd previously experimented with HAM in YUV space. That was ... interesting, but not very useful as a basic screen mode. There was an exception - taking a limited palette of regular RGB colours and allowing modification of either brightness or saturation, turns out to be great for shading polygons. Brightness is for your basic illumination term and saturation for your specularity. I wonder if this is closer to what Jay Miner originally had in mind when he came up with it.

_________________
Doing stupid things for fun...

@cdimauro

Quote:

without software written for it, it's only pure exercise

I thought one of the points would be compatibility with existing software? How hard can it possibly be to add a few more screen modes and add support to a few more audio channels etc?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Karlos

Quote:

I think the problem there is basically what I said originally, plus the additional problem of a lack of support. The latter is not a huge problem in that you can write your own proof of concept code that makes use of magic new hardware registers you've managed to smuggle into the system.

I know, I answered just to try to clarify bhabbott.

And also the point being like Kolla just referred:
Quote:

I thought one of the points would be compatibility with existing software? How hard can it possibly be to add a few more screen modes and add support to a few more audio channels etc?

Last edited by pixie on 07-Aug-2024 at 10:25 PM.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@Karlos

The $20 DSP3210 audio path allows for a 16-bit stereo and it was a near-official Commodore-Amiga audio upgrade path.

Hese later fabricated the A3000 Plus motherboard with modernized features (e.g. bus board with active PCI slots) and restored the A3000's Amber flicker fixer. A3000 Plus is a motherboard upgrade for the A3000 form factor. A3000 Plus' schematics was supplied by Dave Haynie.

Commodore's AA3000 Plus motherboard is missing the A3000's Amber flicker fixer.

Thomas Winischhofer collected and maintained the DSP3210 software package.

--------

The other Commodore official 16-bit audio upgrade for the Amiga is for CD32 via FMV card which is driven by 40 Mhz MIPS-X based CL-450 SoC (about $50) and 16-bit dual channel DAC.

MPEG FMV functions were demonstrated on the A4000. Commodore's Irving Gould thinks MPEG FMV from CDs was the next big thing.

For Sony, Far East PlayStation models have built-in MPEG FMV functions. VCD wasn't successful in the West when compared to East Asia.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Karlos

Quote:

Karlos wrote: Personally, I'd consider a few things: More Paula channels, ideally at least 8, with independent L/R volume and, as you can surely guess, a programmable filter chain per voice.

Filters... had to be studied first (as I've said, I don't know how they work. I've to take a look at the SID).
Quote:

I'd probably want support for 16 bit per channel ultra linear mode just to appease the angry mob.

That's (and more!) is covered on the next article.


@kolla

Quote:

kolla wrote: @cdimauro Quote: without software written for it, it's only pure exercise I thought one of the points would be compatibility with existing software?

100% compatibility with software which was written following Commodore's guidelines (e.g.: do NOT touch reserved bits on the hardware registers, don't write single bytes on WORD = 2 bytes registers, etc.).

The new features can and should only be enabled on demand. Otherwise the chipset starts with a status compatible with ECS (and AGA if this should be supported as well).
Quote:

How hard can it possibly be to add a few more screen modes

If new screen modes means something like packed/chunky 4 & 8 bits, HiColor (15 & 16 bits), TrueColor (24 & 32 bits), then that's a relatively easy easy task.
Quote:

and add support to a few more audio channels etc?

That's easy (as well as adding more sprites): it's a matter of duplicating internally all audio (and sprites) structures (and "xCON" registers) and then use the internal index to select the bank for accessing them.


@Hammer

Quote:

Hammer wrote: @Karlos The $20 DSP3210 audio path allows for a 16-bit stereo

On FUTURE (well above 1993) machines, according to Eggebrecht. And the cost was $20-$30.
Quote:

and it was a near-official Commodore-Amiga audio upgrade path.

Crap and alien stuff because of the incompetence of Commodore's engineers.
Quote:

Hese later fabricated the A3000 Plus motherboard with modernized features (e.g. bus board with active PCI slots) and restored the A3000's Amber flicker fixer. A3000 Plus is a motherboard upgrade for the A3000 form factor. A3000 Plus' schematics was supplied by Dave Haynie. Commodore's AA3000 Plus motherboard is missing the A3000's Amber flicker fixer. Thomas Winischhofer collected and maintained the DSP3210 software package. -------- The other Commodore official 16-bit audio upgrade for the Amiga is for CD32 via FMV card which is driven by 40 Mhz MIPS-X based CL-450 SoC (about $50) and 16-bit dual channel DAC. MPEG FMV functions were demonstrated on the A4000. Commodore's Irving Gould thinks MPEG FMV from CDs was the next big thing. For Sony, Far East PlayStation models have built-in MPEG FMV functions. VCD wasn't successful in the West when compared to East Asia.

Expensive & alien as well to the Amiga ecosystem. Crap.