Best way to do SuperAGA in Apollo core

[eXeler0]

I know BigGun's teams has most of the ideas already, but those of you who have first hand experienced the limitations of AGA, what parts would you improve without breaking compatibility.
We all know the blitter and copper didn't quite got the worthy upgrades from ECS to AGA...

[Amiga1992]

Wouldn't any upgrades break compatibility?? Like if you put in a more powerful Blitter, I am sure it's going to take down the whole compatibility with it (for a test, take WinUAE and make the blitter run faster, see all your games go to shit)

[eXeler0]

Originally Posted by Akira

Wouldn't any upgrades break compatibility?? Like if you put in a more powerful Blitter, I am sure it's going to take down the whole compatibility with it (for a test, take WinUAE and make the blitter run faster, see all your games go to shit)

I'm not really qualified to answer that.. but I don't think so.. think x64 extension to X86-32 bit
Not saying it's a perfect analogy but the x64 cup:s ran 32 bit apps just fine, and the magical brain of BigGun probably has a decent idea about this.
I mean... the Apollo-core is actually a 64 bit 68k CPU, yet it's more compatible with old software than a 060.
Also, I'm at peace with the idea that you can't magically improve the old implementation.. you could however probably recompile /patch some old games to take advantage of a better blitter for example.

[ovale]

Just enable superaga if a magic sequence is performed on the registered.
This is all you need for running 'bang the metal' software.
The OS will abstract superaga for all the other software.

[NorthWay]

I'm not sure there is much you can do without breaking _something_. Just check the whdload patches to see how many games that expect the blitter to be finished before the cpu gets around to updating the blitter registers. Likewise I'm pretty sure there are programs expecting the blitter not to be finished when writing to it.

The general answer is to clock things faster and have more memory slots free. That would be within the scope of traditional AGA. Next up would be a scandoubler then flickerfixer. If they could manage some heuristics to detect interlace and natively present it as progressive then it would be coolio. If not then a separate monitor driver that adds it to the DBL modes.

For other "added functionality" stuff there has been plenty of discussion over at amigacoding.de.

[eXeler0]

@NorthWay ye I saw some of those, but those threads tend to be a bit too technically specific for my taste.. like two guys arguing over 6 pages about dma cycles in a specific scenario or something like that. ,-)

This text below is from the good old Natami page. No idea who wrote this but st least it was someone with better knowledge about AGA than me ;-) (which isn't that hard, btw) .

8>< -------

COPPER: including original AGA copper

BLITTER:
Fully compatible with AGA-AMIGA
Speed of SuperBlitter is many times faster than AMIGA AGA blitter
comparisons will follow.
2D Enhancements:
In Chunky/Hicolor/ or Truecolor pixel mode the Super Blitter can "cookie cut" copy BOBs.
Like the AMIGA Sprites, a "cookie cut" copy needs no blitting mask.
This enabled the blitter to use less memory and to work at double speed compared to planar blits.

3D Accelerator:
Texturemapping Blitter enhancement.
Provides Mipmapping, Subpixel 4 way interpolation, Light sources, Antialiasing, Alpha blending.

--------><8

[Foebane]

Originally Posted by eXeler0

We all know the blitter and copper didn't quite got the worthy upgrades from ECS to AGA...

Of COURSE they did! Are you saying Lew Eggebrecht didn't do his job so well?

[eXeler0]

Originally Posted by Foebane

Of COURSE they did! Are you saying Lew Eggebrecht didn't do his job so well?

Do I sense sarcasm? 😉
Who designs a chipset for a 32-bit computer but leaves practically everything @16-bit except for the bare minimum upgrade of 32-bit data fetch to accommodate for the bandwidth required for bit-plane increase to 8-planes.
It has "half-assed" written all over it..
But we know about the AAA delays and why marketing wanted "something better" before AAA was done (and looking back at the ultimate demise, can't really blame them)....

[ptyerman]

I don't know if upgrading the blitter would break compatibility, some one more knowledgeable on that subject would have to answer that and enlighten us if a work around was possible.
More Chip RAM would be a great asset from any upgrade though, and that shouldn't break compatibility with anything. As much chip RAM as possible, the more the better.

[Mrs Beanbag]

are we just talking graphics, or sound as well? More channels would be nice, as well as the option to use 16 bit samples, and to set the volume independently on left and right speakers. Perhaps the upper byte of the volume register could be used to set the volume for the opposite side? We could maybe use a bank switching scheme to select banks of four channels each, like AGA uses to select palette register banks.

As for the blitter... well one thing that would be nice is if you could use the C source during line drawing, as well as to use the Bresenham (line drawing) circuitry for other things such as image scaling.

[eXeler0]

Originally Posted by Mrs Beanbag

are we just talking graphics, or sound as well? More channels would be nice, as well as the option to use 16 bit samples, and to set the volume independently on left and right speakers. Perhaps the upper byte of the volume register could be used to set the volume for the opposite side? We could maybe use a bank switching scheme to select banks of four channels each, like AGA uses to select palette register banks.

Well..Paula was never changed so barely qualifies as an aga specific part 😆 anyway, they've already "promised" 16-bit audio as a future Apollo-core update.
Don't know if this will be seen purely as an AHI device or if it's going to be an improved Paula.
The way Gunnar described Picasso96 as a "chunky mode" of the SAGA makes me think he likes to extend integrated stuff, rather than glue something on that exists as it's own isolated entity... (meaning, it *might* be an extension to Paula rather than a "new standalone sound card" so to speak)

[SkulleateR]

Originally Posted by ptyerman

I don't know if upgrading the blitter would break compatibility, some one more knowledgeable on that subject would have to answer that and enlighten us if a work around was possible.
More Chip RAM would be a great asset from any upgrade though, and that shouldn't break compatibility with anything. As much chip RAM as possible, the more the better.

This sounds like an awesome idea

[TjLaZer]

I want sex and free beer mode! Can we have that?

[eXeler0]

Originally Posted by TjLaZer

I want sex and free beer mode! Can we have that?

Not sure this thread is the best place to seek help for your sex and alcohol issues 😉

Let's try to be grownups and wait for at least 5 pages before derailing the topic ☺

[hooverphonique]

Originally Posted by eXeler0

Not sure this thread is the best place to seek help for your sex and alcohol issues 😉

Let's try to be grownups and wait for at least 5 pages before derailing the topic ☺

try looking it up, and you will find, it is actually an amiga-related thing

[pandy71]

Originally Posted by ptyerman

More Chip RAM would be a great asset from any upgrade though, and that shouldn't break compatibility with anything. As much chip RAM as possible, the more the better.

You don't need more CHIP ram as with UMA border between CHIP and FAST can be overworked in a plain software.

[Meshuggah]

Chip could go up to 8 MB without breaking much if anything. AGA implementation should be set to most compatible by default IMHO, with extensions hidden from view if not explicitly unlocked. I don't think a fast blitter is needed as the CPU is so fast you won't need it.
Heck, you could do whatever you want in pure software with that much speed. (Way more than a Neo Geo ever could)
Some high color chunky modes would be nice tho. (I'm not talking P96 here, but bare metal accessible modes)
We'll see how it'll turns out
Edit: what about Paula implementation, is that even on the roadmap?

[eXeler0]

Originally Posted by Meshuggah

Chip could go up to 8 MB without breaking much if anything. AGA implementation should be set to most compatible by default IMHO, with extensions hidden from view if not explicitly unlocked. I don't think a fast blitter is needed as the CPU is so fast you won't need it.
Heck, you could do whatever you want in pure software with that much speed. (Way more than a Neo Geo ever could)
Some high color chunky modes would be nice tho. (I'm not talking P96 here, but bare metal accessible modes)
We'll see how it'll turns out
Edit: what about Paula implementation, is that even on the roadmap?

If the team had no ambition to improve current AGA then yes CPU blit would suffice.. however, if the old Natami specs are anything to go by (and I think they are) then the blitter will be improved with stuff like 3d functions with maintained backward compatibility..

P96 mode would be considered as a chunky mode controllable by the (improved) copper.

As for Paula.. see post #11

[daxb]

If you have P96 and AHI support, a super fast CPU and even faster bandwidth (bus), is there really a need for more chipram, extended AGA, better Paula, ...?

[ptyerman]

Originally Posted by pandy71

You don't need more CHIP ram as with UMA border between CHIP and FAST can be overworked in a plain software.

More chip RAM is needed so existing software can take advantage of it, not just software that is written to ignore the chip/fast RAM divide.
You can already increase the amount of chip RAM with WinUAE, and it does wonders for software that is chip RAM hungry such as paint programs and scanner software. (Yep, some of us DO still use the Amiga for scanning documents).
I haven't noticed it break compatibility with any software yet either which is a good thing.
I agree that getting rid of the chip/fast RAM divide altogether would be a good thing, but only if existing software ran fine with it.