Best AGA implementation on FPGA?

[matthey]

Originally Posted by Megol

Any idea how the extra integer registers are encoded? I've asked Gunnar however never got any relevant answer. :/

I'm an "outsider" since I refused to come up with encodings for his extra registers so I don't know for sure. A8 at one point used mostly addressing mode tricks to achieve. The last 3 addressing modes below were undefined on the 68k and may look something like the following.

(xxx).W 111 000
(xxx).L 111 001
(d16,PC) 111 010
(d8,PC,Xn) 111 011
(bd,PC,Xn) 111 011
([bd,PC,Xn]) 111 011
#<data>.Size 111 100
#<d16>.L 111 101
MOVE.L <ea>,A8 111 110
MOVE.L A8,<ea> 111 111

I'm not sure what other tricks he planned to use for (d16,A8) and possibly (d8,A8,Dn) addressing modes. The last he talked about, only a few addressing modes were supported and this register was called BR (Base Register). I would have preferred he left it as BR that call it A8 as it is less orthogonal that A7. We also looked at creating a new stack register and a base register or 2 base registers.

E0-E7 (originally D8-D15) originally used the Address register EA field in some instructions and then had a bunch of new instruction encodings in whatever encoding hole is available to give functionality close to the original data registers (MVS/MVZ were dropped at one point for MOVEQ #d8,En). Of course these registers are still not orthogonal so compilers can't use them as 8 more data registers. At least Gunnar changed the name from D8-D15.

I wasn't completely opposed to having new integer registers in the CPU but I didn't think they were consistently encoded or orthogonal enough to add to the ISA. Gunnar didn't have a complete proposal worked out either but wanted meynaf and me to help with new encodings for En. When we chose not to participate, we became "outsiders". Of course I had previously done a proposal to add 8 more FPU registers which can be done in a consistent and orthogonal way other than FMOVEM but I would prefer to make all 8 new registers scratch registers with a new ABI.

Originally Posted by jbenam

IMHO the first target should be 100% (or at least 98%) compatibility with old hardware.

I agree. Even Gunnar's ISA should have good compatibility until his enhancements are turned on (requires patches and enhancements to AmigaOS and AROS).

Originally Posted by jbenam

Creating a new ISA/Enhanced Architecture (even if it's fast as heck) will just fragment even more the market and only a small fraction of the users out there would end up using it.

That is the great debate. An ISA only used by Apollo processors would fragment but also give a small to moderate increase in speed (big increase in some code like floating point). A simple and more open standard ISA could be adapted to the TG68 and UAE also. You can argue that there would still be fragmentation but the majority of users could use the standard ISA which offers faster and smaller programs. Is it more important to have extra speed for relatively slow FPGA processors or a common code base (we already have the 68000/68020 split)?

Originally Posted by jbenam

If the Minimig required stuff especially compiled for it, you can bet whatever you want that it'd have bombed massively.

No one is going to spend money and time to support something only a niche of a niche would use.

MiniMig didn't offer as much advancement and Apollo should be mostly compatible out of the box. An Apollo only ISA would be a niche of a niche which I don't think developers would fully support. A simpler standard ISA would only be niche but I think would be supported by developers (I would) even if it's success would still depend on popularity and not be guaranteed. The majority of active Amiga users (including more new users) could be using a new standard ISA if the Apollo, TG68 and UAE added support for the same standard ISA.

Originally Posted by alexh

Should you not have given Chaos the benefit of the doubt?

Are you assuming that copying the FPGA Arcade AGA code would be bad? It's open source so could not have been stolen and Mist (open source) AGA would be even farther along now. I don't see anything negative if Chaos had used the FPGA Arcade AGA code. It is more impressive that he wrote Mist AGA based on MiniMig ECS (I have no reason to doubt what he has said) but it is unfortunately based on older sources which forced him to reinvent the wheel.

[Megol]

The reason I asked is that there is no obvious way to add 8 integer registers in a general matter unless using a prefix/postfix/out of band design. Given Gunnars dislike of prefixes and the impracticality of postfix/OOB I couldn't see an orthogonal solution at all.

And the A8 register is an abomination IMHO. Don't see any reason to add it at all.

[matthey]

Originally Posted by Megol

The reason I asked is that there is no obvious way to add 8 integer registers in a general matter unless using a prefix/postfix/out of band design. Given Gunnars dislike of prefixes and the impracticality of postfix/OOB I couldn't see an orthogonal solution at all.

I told Gunnar something like "a prefix would be the most orthogonal way to add more registers but you don't like that" when he was asking me to "participate" in finding encodings for the new registers. I didn't get an answer which is common when Gunnar doesn't want to answer. The StarCore DSP has many similarities to the 68k and has a prefix with more registers as well as flags much as we had discussed (although StarCore is not a good ISA for other reasons IMO). Gunnar's registers would be better for code density but compilers are going to have a very difficult time effectively using and implementing support for non-orthogonal registers.

Originally Posted by Megol

And the A8 register is an abomination IMHO. Don't see any reason to add it at all.

A few more address registers (even one) would be useful. Too bad the 68k didn't have A0-A7 perfectly orthogonal with a separate SP but the way it is now is good for code density (as many trade-offs are on the 68k). A5 for the stack frame link register can be turned off and the stack used (it works in vbcc and SAS/C but GCC has always had problems with this). A4 is what I believe he wants to move to A8/BR as it is often used with simple addressing modes. I think it might be a little easier to use by compilers with a patch but I don't like calling it A8 which infers orthogonality with A0-A7. Actually, A6 might have been the register to move to a LB (Library Base) register which also almost always uses (d16,A6). GCC needs a patch to swap A6 (normally the link register on a 68k) with A5 on the Amiga and some versions have become confused. IMO, there isn't a compelling enough reason to add registers considering compatibility and changes which would be needed to support it (not to mention the encodings are overly creative). More integer registers would probably help performance some but lack of them is not a major bottleneck on the 68k.

[asymetrix]

Great work so far

I really do think these suggestions are worth putting into reality. One cannot work alone or closed source for Amiga to succeed. We do indeed need standards and compatibility.

I suggest let others do what they want to do, its their projects - but we can take charge of our own future legacy as its what we all believe is the best course of action.

I dont know which developer/ engineer wants to take part in this new adventure to bring a standardized AGA2 Amiga to the world, if you can spare time say so here.

I suggest inviting all FPGA developers to this forum to discuss if they wish step by step action plan/goals to achieve.
Once we have these goals listed we could create fixed amount bounties eg 500 euro each for completion.

If for example we have 4 developers wiling to work together on a bounty then split the amount between them evenly to pay for their work is only fair.
I am sure alot of developers on Freelancers.com would be interested in doing some work.

Keep the code Open Source and update once a month with progress.

I think all we need is an FPGA 680xx compatible Amiga with AGA, possibly RTG for retail price no more than £200 would be good to aim for.

A simple base machine we can create stunning apps and games.

[eXeler0]

Wow, Im glad I started this topic if something good can come out of it, eventually.

But its human nature to have everything in at least 2 groups.
History has shown that nothing ever is agreed upon by everyone. So we're looking at one group that wants to unite & cooperate and work towards compatibility and open stards.... and a second group that doesnt....
The reality of the situation is that this antique 68k world is a small nische and while those of us who are left love it passionately we are most likely to be stuck with old software and ports of open source stuff from the late 90's. From that perspective, maintaining compatibility is a big deal and while super AGA or AGA2 would be really neat, the first focus beyond mere compatibility should probably the elimination of some of AGAs obvious bottlenecks.. bandwidth / performance in high res modes.
If we can get there, we'll be playing Quake II in 800x600 on our FBGA enhanced A1200s and what not...
It would also make it much easier to port other stuff so that could quickly grow the 68k Amiga gaming library (and other stuff) without too much effort.

[Megol]

Originally Posted by matthey

I told Gunnar something like "a prefix would be the most orthogonal way to add more registers but you don't like that" when he was asking me to "participate" in finding encodings for the new registers. I didn't get an answer which is common when Gunnar doesn't want to answer. The StarCore DSP has many similarities to the 68k and has a prefix with more registers as well as flags much as we had discussed (although StarCore is not a good ISA for other reasons IMO). Gunnar's registers would be better for code density but compilers are going to have a very difficult time effectively using and implementing support for non-orthogonal registers.

My impression is that he assumes assembly coding.

A few more address registers (even one) would be useful. Too bad the 68k didn't have A0-A7 perfectly orthogonal with a separate SP but the way it is now is good for code density (as many trade-offs are on the 68k). A5 for the stack frame link register can be turned off and the stack used (it works in vbcc and SAS/C but GCC has always had problems with this). A4 is what I believe he wants to move to A8/BR as it is often used with simple addressing modes. I think it might be a little easier to use by compilers with a patch but I don't like calling it A8 which infers orthogonality with A0-A7. Actually, A6 might have been the register to move to a LB (Library Base) register which also almost always uses (d16,A6). GCC needs a patch to swap A6 (normally the link register on a 68k) with A5 on the Amiga and some versions have become confused. IMO, there isn't a compelling enough reason to add registers considering compatibility and changes which would be needed to support it (not to mention the encodings are overly creative). More integer registers would probably help performance some but lack of them is not a major bottleneck on the 68k.

If one wants/needs more address registers then one should do that. But adding one extra register using dirty hacks, making it not only non-orthogonal but also limited in other ways? I maintain that it is an abomination. It requires a lot of work to function while only providing one extra register.

Using a prefix one would not only get 8 extra integer registers but also 8 extra address registers. Or even 24 extra registers of each (though that would severely limit other extensions).

[JimDrew]

Originally Posted by alexh

FPGA Arcade AGA core

Written by Jakub Bednarski (Yaqube) who took over MiniMig core development and probably some input from MikeJ. AFAIK it is legally required to be open source as binaries including MiniMig GPL code have been released but so far I've seen no HDL.

That might be true if that were correct. Mike has created all new chipset VHDL code. Paula, Agnus, Denise, Alice, Lisa, Gale, etc. are all completely new from scratch. Mike has stated that he will at some point release the code to the public, but at the moment it is all new and it is his.

The Paula emulation has support for flux level input, so it supports SuperCard Pro flux images (much like WinUAE does now) which means we could attach a real floppy drive to the Replay board and use it... we just need the interface, which is something that I am looking at making.

Mike also has worked out the 68020+ instruction set emulation, so now I have 57MB of FAST RAM (and 2MB of CHIP RAM) on my Amiga Workbench. There are still some AGA and blitter quirks to resolve, but DPaint V in AGA mode works perfectly except in extended HAM mode and most games play perfectly. Some games require that you slow the CPU down to a A500 - but so is the case with real Amiga hardware.

Mike is busy getting the data/instruction cache timing issues resolved, which will boost the already very fast core to be ridiculously fast.

The hard drive speed of the Amiga core is about as fast as the SD card will handle. I see around 1.8MB per second on every test program. Adding a cache program like Power Cache makes it like everything is coming out of the RAM disk.

There is preliminary RTG support. I have the driver assembled for Mike, and testing shows that the core part is working. Video handling needs to be added.

[lurch]

At the end of the day it comes down to.

MIST - Cheaper, easier to find to purchase.
FPGA - More expensive, hard to find somewhere to purchase. Would love the 060 daughter card but nowhere to be seen.

Would prefer the the FPGA but the MIST is in the right price bracket and can be bought easily.

[JimDrew]

I should finally have the FPGA Aracde Replay boards for the North American market shortly, so supply won't be a problem. The pricing difference is due to the difference in hardware. The FPGA Arcade Replay board was twice the amount of RAM 64MB vs 32MB), bigger FPGA, DVI and/or S-video (instead of VGA), high quality audio DAC, better ARM, etc.

[lurch]

Any news on the daughter boards? If I was to purchase what would it cost with the ATX back plate and adapter?

Would love to put in some sort of ATX/ITX case.

So I'd need to purchase an HDMI to DVI adapter?

[eXeler0]

Lurch, have you seen the FPGA replay mobo? Its probably smaller than you think.
If you put it in an ATX case you'll have 90% empty space. :-)
Edit: (If you meant mini ITX then it will fit nicely on one side and leave about 9cm of space the other way. Dimensions are 17cm x 8cm x ~3.5 cm.)
I once had a thought about buying a broken A1200, rip out everything except the keyboard, mount the replay mobo + keyboard adapter and possibly other stuff supported (original floppy in theory). ;-)
Or a small custom case (retro-look) would be nice.

[JimDrew]

Originally Posted by lurch

Any news on the daughter boards? If I was to purchase what would it cost with the ATX back plate and adapter?

Would love to put in some sort of ATX/ITX case.

So I'd need to purchase an HDMI to DVI adapter?

You would need to chat with Mike about the cost of these items. I only sell to North America (that is our agreement). The daughter board is getting a few small changes (from what I have heard), but the basic board is done and works. I am not sure when they will be available. To me, an 060 makes no sense with the speed we can get now with FPGA.

I have mine in a micro-ATX case, which also fits a 5.25" floppy drive and a 3.5" floppy drive. It's a perfect setup really.

Actually, I goofed when I typed HDMI. The Replay comes with a DVI port, and you can use either DVI analog or digital modes, and use a DVI->HDMI adapter. I have been using a HDMI connection recently for testing which is why I had HDMI on the brain. Normally, I connect it to my DVI monitor.

[alexh]

Originally Posted by JimDrew

To me, an 060 makes no sense with the speed we can get now with FPGA.

What does it use instead? A synthesisable core? Pheonix/Apollo? TG68K?

What is the compatibility like? MMU? FPU?

[eXeler0]

Originally Posted by alexh

What does it use instead? A synthesisable core? Pheonix/Apollo? TG68K?

What is the compatibility like? MMU? FPU?

JimDrew will know all the details but its not the Apollo core, thats a different project, different people.
Im fairly sure its a "020 level" softcore with no FPU or MMU.
However, the beauty of FPGA is that the stuff missing today could be there tomorrow...

[JimDrew]

The CPU core is Mike's, and has separate instruction and data caches (much like the real CPUs), as well as other improvements in the bandwidth. As you know, I am a stickler for cycle exact emulation and compatibility, so the CPU core has full instruction set emulation and can be the exact same speed as a real A1200, or let loose! No FPU or MMU today, however, as pointed out that could change at any time with just a new core file. The FPGA Arcade Replay board has a pretty big FPGA on it, there is plenty of space for a large scale CPU replacement.

I really can't stand the 060. It breaks so many things, and when you kill all of the additional features that make it compatible, you end up with a CPU that is slower than a fast 040. But, Mike does have the 060 daughter board designed, so those that love the 060 will be happy I guess.

[lurch]

Originally Posted by eXeler0

Edit: (If you meant mini ITX then it will fit nicely on one side and leave about 9cm of space the other way. Dimensions are 17cm x 8cm x ~3.5 cm.)
I once had a thought about buying a broken A1200, rip out everything except the keyboard, mount the replay mobo + keyboard adapter and possibly other stuff supported (original floppy in theory). ;-)
Or a small custom case (retro-look) would be nice.

Was thinking ITX.. you're right the ATX would be overkill LOL. Glad to know it fits in an ITX case.

Do I need an adapter to connect it to an ATX PSU?

I have a spare A1200 case and keyboard, not sure if the keyboard still works though. But I can just see it all setup, would be the perfect replacement.

Originally Posted by JimDrew

You would need to chat with Mike about the cost of these items. I only sell to North America (that is our agreement). The daughter board is getting a few small changes (from what I have heard), but the basic board is done and works. I am not sure when they will be available. To me, an 060 makes no sense with the speed we can get now with FPGA.

Will the reply run 060 demos? How does it compare to a real A1200 running a 060@80MHz?

If it can replace my towered A1200 then I'm keen, although I'd miss the Voodoo 5500 and the 320MB RAM :-/

But its aging so I need to replace it with something, temperamental old girl that it is.

Actually, I goofed when I typed HDMI. The Replay comes with a DVI port,

This is good to hear, have a monitor sitting here ready to go :-)

[alexh]

Originally Posted by lurch

Will the replay run 060 demos?

Unlikely without an FPU.

[eXeler0]

Lurch, JimDrew is actually working on the FPGA arcade, Im just following the project (and got to see the actual board a year ago).
Anyhoo, the FPGA is NOT (yet) the ultimate Amiga setup that gives a 060 equipped 1200 a kicking.
It is an attempt to to a very exact reimplementation of the original A1200, improving speed only where it doesnt break compatibility.

Remember, the Amiga will barely boot from a 060 without stuff like cyberpatcher.
So any software that uses the FPU or any specific 040 or 060 instructions is not likely to work with the FPGA arcade, much like a "vanilla" a1200 wouldnt.

[JimDrew]

The CPU core has 020 instruction set implementation. The 030/040/060 are different enough to cause compatibility issues with various software. The 020 has the majority of the extended instructions and fortunately most programs had to be A1200 compatible to be popular. So, the 020 (even if it's 100MHz+ in speed) makes the most sense for main stream compatibility. However, there is adjustable speed and a 68000 fall back mode that really takes it to another level.

The 060 daughter board is an 060, so you will be able to run anything and everything 060 specific with it.

[daxb]

On the other hand in users point of view they use 030/040/060 since 15-20 years and not 020. Maybe it is just an individual choice/experience. E.g. with my 040 (FPU/MMU) almost everything works fine. Hence, for me a 020 system would be less compatible then a 040 system. Hence, I would need to make it 020 compatible.
Only very old software (tools) have problems with 020+. For games/demos there is WHDLoad. A 68000 fall back is nice but I won`t care much. For me FPGA Arcade, Mist, Minimig are more or less the same "toys" that may replace A500(+)/A600. So the specs are ok for that goal. An A1200/A4000 replacement need of course other specs. As you can see that is all about individual.