Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: amiga1084 on March 24, 2018, 09:52:44 AM
-
Hi All,
With today’s advances in technology with Vampire Accelerators Miming FPG cpus and chip sets cloning!
Why hadn’t anyone succesufuly been able to clone AGA gfx and just gone straight to 16 & 24 bit!
What’s so hard about it! It’s really an extension of ECS!
Vampire keeps promising after every up date! But hadn’t happened so far!
What’s the problem?
Love to know! Merv
-
Hi All,
With today’s advances in technology with Vampire Accelerators Miming FPG cpus and chip sets cloning!
Why hadn’t anyone succesufuly been able to clone AGA gfx and just gone straight to 16 & 24 bit!
What’s so hard about it! It’s really an extension of ECS!
Vampire keeps promising after every up date! But hadn’t happened so far!
What’s the problem?
Love to know! Merv
https://www.youtube.com/watch?v=2hTJHSKPXR8
https://www.youtube.com/watch?v=hz8C9Mfzfzk
https://www.youtube.com/watch?v=FfHi9H_Gaac
https://www.youtube.com/watch?v=pvLPbLKSYuw
https://www.youtube.com/watch?v=82SR8bTr8X8
-
I might sound rude: but.. if you ask. do it yourself and you will notice that it is not that easy.
first of all.. it is an extension to ECS.. still you FIRST need to implement OCS and ECS. and stuff can be harder than you think.
-
It is way more easy to implement a own RTG 24bit system. as you do not need to think about chipsetregisters and strange beaviours etc that you must implement to have software behave right.
-
I might sound rude: but.. if you ask. do it yourself and you will notice that it is not that easy.
It is kind-of rude, but kind-of not. What people who understand things often fail to understand is there are those out there who see things at a different level and while they may have a basic grasp, the leap from one level to another level is a larger task than that for others. As such, we often defer to those who understand better to shed light on the matter.
While I like to encourage others to learn for themselves, sometimes it might be the nudge of information that helps. The "do it yourself and find out" answer is off-putting to those who are genuinely curious.
I, too, wonder why AGA has not yet been replicated, and considering the minds which have been lent to the task I postulate there must be a stumbling block somewhere which has yet to be surmounted or possibly, like you say, maybe RTG is just easier. My limited understanding of the matter leads me to believe that replicating AGA may not be all that desirable in the first place considering the obvious and observable limitations of the AGA chipset compared to what is possible with RTG.
Anything more in-depth and technical than that, well, Amiga is a beloved hobby of mine but I have to spend the majority of my day earning a living so deeper investigation, while tempting and tantalizing, is simply not practical, and if someone knows more than I do why re-invent the wheel?
-
Well, this is not "so" hard about it.
UAE have it.
Minimig/Mist/Replay have it.
Vampire AGA is work in progress.
There were also other implementations never released.
All those implementations are differents and works rather good.
For example, Pinball Illusion is running quite perfect on a AGA Vampire summer 2017 core.
RTG is easier, yes, but also faster.
That said, with chipram mapped to fastram like there was on some proof of concept shown that AGA can be super fast. On that core, Metropolice demo was running even better than in RTG.
The difficulty is always same, the last 5% compatibility issues can need infinite work to find the perfect implementation, this because AGA was never 100% documented. And this takes also some room in a fpga.
-
What’s the problem?
Basically the hw you run it on. You need memory that can fetch 64 bits every OCS cycle. You know, the actual basic difference between OCS and AGA.
The rest is implementing the logic that was in AGA. Compared to making the Minimig in the first place that is not a big job. And it has been done already as others here have said.
AFAIK the Minimig hw was not designed for anything but OCS and I am guessing that it can't give you enough memory bandwidth.
But your question seems to be more about the Vampire - that opens a whole different can of worms...
Note how all the other solution implements _everything_ in an Amiga. The Vampire has to work together with the innards of your 500/600/XXXX. I am still curious about how they will implement floppy drive access as that is physically wired to the native chips but somehow the data will need to end up in the Vampire memory.
-
Why hadn%&$#?@!%&$#?@!%&$#?@!8217;t anyone succesufuly been able to clone AGA gfx and just gone straight to 16 & 24 bit!
Because there is no OS support for 16/24 bit AGA.
People see that they can emulate one of the dumb PC graphics chips that were used on RTG cards and get software support for free.
Adding a chunky 8 bit indexed mode and 16 bit direct colour to minimig AGA would be relatively easy. 8 bit indexed (AKA chunky) would run in the same bandwidth as AGA 8 bitplanes, you'd need double the bandwidth for 16 bit direct. So if bandwidth was limited then you could restrict the resolution, but as the data is sequential then you could likely burst it as modern ram has huge rows.
It would be awesome for texture mapping.
-
Beyond 8 bits per pixel, planar doesn't really make sense. Minimig-AGA on the MiST, FPGA Replay etc. work fine, excellent in fact. Just the other day I transferred a huge number of AGA WHDLoad games to my MiST and they all ran without issues. So I would say regular 8 bpp AGA has already been "cloned" successfully. 8 bpp planar is really all that's required for backwards compatibility with everything written for AGA. At 16-bit or 24-bit, chunky pixels make a lot more sense, and since nothing was written for 24-bit with bitplanes, it makes more sense to just use RTG modes with chunky pixels instead of trying to "emulate" something that never existed in the first place.
-
but then as already mentioned: AGA is already implemented.. like in the FPGA Replay etc..
but I do not understand those who wants to ADD stuff to AGA.. why. there is simply no reason whatsoever to do that.
-
but I do not understand those who wants to ADD stuff to AGA.. why. there is simply no reason whatsoever to do that.
Because of....
https://en.wikipedia.org/wiki/Commodore_AA%2B_Chipset
-
Good info. Some of which I was unaware. Thanks, all.
-
but I do not understand those who wants to ADD stuff to AGA.. why. there is simply no reason whatsoever to do that.
It's possible to add things to AGA without breaking how software access and see AGA - faster chip RAM access, de-interlacing, new modes (like HighGfx is already doing), better HAM implementations etc. Ideally I want an improved AGA for doing animations using old tools like DPaint, Briallance etc. Old AGA _can_ do 1280x720 HAM8 animations, but it is borderline within chip ram limits and annoyingly sluggish. More and faster ChipRAM can help with this (as demonstrated using UAE and for that matter, FPGA Arcade).
-
Because of....
https://en.wikipedia.org/wiki/Commodore_AA%2B_Chipset
that exactly ZERO software will use anyway.. so.. no reason
-
Beyond 8 bits per pixel, planar doesn't really make sense.
Mh. Depends on your definition of planar.
Byteplanes have been tossed around several times - one pointer for R/G/B each, saving 25% bandwidth. But yes, I agree with your sentiment.
(Ok, one last option: 10 bits planar for HAM10?)
-
that exactly ZERO software will use anyway.. so.. no reason
I believe it's possible to write software.
Mh. Depends on your definition of planar.
Byteplanes have been tossed around several times - one pointer for R/G/B each, saving 25% bandwidth. But yes, I agree with your sentiment.
I suspect that causes more problems than it solves for bandwidth. RAM is really fast if you only read sequentially. As soon as you start reading from three different places in RAM it will slow down or you would need to implement burst caches. Which will add a small amount of latency.
I agree it would save RAM when using 24 bit displays, but 16 bit is pretty good at saving RAM too. Just say the extra 8 bits are alpha when using a genlock and move on.
-
Mh. Depends on your definition of planar.
Byteplanes have been tossed around several times - one pointer for R/G/B each, saving 25% bandwidth. But yes, I agree with your sentiment.
(Ok, one last option: 10 bits planar for HAM10?)
Why, in 2018? Sure, back in the day HAM10 could have been really nice (256 base colours, and true 24-bit (albeit fringed) imagery). But today, memory is cheap, bandwidth is cheap.
It seems to me that an AGA extension today should take advantage of modern memory's burst modes (just like AGA itself increased bandwidth/clock over OCS), and even in an FPGA implementation with limited DDR2/3 memory controller, you could get order of magnitude bandwidth improvements for the graphics system over AGA. Which would mean existing AGA would be unleashed, but also you can implement higher resolutions and higher bit-depths (and if you like: more, larger, more colourful sprites; or more, higher-resolutions, more colourful playfields).
-
I believe it's possible to write software.
well.. yes. but then we are in the situation that most sources is gone. so completly NEW software must be made.. and why do it to a small platform. better support RTG and lots of different hardware is supported directlty.. so pointless thing to do simply...
-
That is only a matter of pleasure for a coder to play with new stuff. It can be seen as nonsense or not. But a hobby do not needs excuses. For larger audience, indeed RTG is better choice. For the fun, one can appreciate.
-
... in an FPGA implementation with limited DDR2/3 memory controller, you could get order of magnitude bandwidth improvements for the graphics system over AGA.
Actually with Vampire it's two orders of magnitude. Roughly 600MB/s. :)