in case you are interested to test new fpga accelerators for a600/a500

[Kremlar]

Wow, why?? Have you been paying attention? If all you want is to run old games, then there is already _plenty_ of cheap and compaible hardware around, an FPGA accellerator is total utter overkill for that. On the other hand, if insisting on running ports of 15-20 year old PC games on your Amiga s your interest, them FPGA accelerator is perfect choice. Hopefully it will also make sense to use FPGA accelerator for legacy productivity software.

One of the biggest driving factors of FPGA hardware will be replacing aging Amiga systems.  Accelerators are nice but won't help fix failing Amigas due to leaking batteries, failing capacitors, careless users, etc...

How popular would WinUAE be if it didn't handle old misbehaving software so well?

Why is WHDLoad so popular?

A standalone FPGA solution should have excellent compatibility options (even different cores would be OK), or it's popularity will be limited.

[kolla]

Stand alone FPGA solutions have existed for years already - there are myrads of boards and systems available, and for which variants of Minimig implementation runs fine already, with and without AGA support. The Apollo project is not about this.

[ferrellsl]

One of the biggest driving factors of FPGA hardware will be replacing aging Amiga systems.  Accelerators are nice but won't help fix failing Amigas due to leaking batteries, failing capacitors, careless users, etc...

How popular would WinUAE be if it didn't handle old misbehaving software so well?

Why is WHDLoad so popular?

A standalone FPGA solution should have excellent compatibility options (even different cores would be OK), or it's popularity will be limited.

Some enterprising soul could always port UAE over to Apollo/Vampire accelerated systems for those temperamental hardware banging games.  Wouldn't that be ironic?  Running an emulator for 68K classic Amigas on accelerated classic Amigas!  Sort of like DosBox on PCs.

[kolla]

It should not be a problem to tell the Apollo core to "slow down" though, or just use a different core, like TG68, or MikeJ's core, that aim for compatibility and accuracy rather than superfastestest

[guest11527]

I'd like to see a technical explanation of why you can emulate a CPU but not an MMU with an FPGA.

You *can* if you want to, but you probably do not *want to*. The current (small) Phoenix core does not implement the bitfield instructions, to give you an example. It could, but it does not because the complexity of these instructions is too high to make this feasible. A single bitfield instructions accesses between one and five bytes, dynymically, depending on register values. That's nothing the current pipeline can do. In the 68K, this is a microcoded instruction, i.e. it is slow.

Pretty much the same goes for the MMU table walk. It is a pretty complex algorithm, it requires to access an even larger number of bytes in a completely serial fashion, testing several conditions on the way. Yes, you can probably implement that on the FPGA and spend a lot of gates for that, but in reality, you probably simply do not want to. This part of MMU handling is also microcoded on real hardware, so you can now either add more complexity to add a microcode interpreter into the FPGA, or you can have it interpreted by the CPU core that is there anyhow, i.e. you can do it completely in software.  

One way or another, it makes a lot of sense to split off the complex algorithms belonging either to instructions or CPU internals to eliminate complexity in the core. If you look at the current small core, a lot of the complex less used instructions are in software: ABCD and friends, MOVEP and friends, 64x64->64 arithmetic (the double-sized MULx and DIVx), and bitfields. And these are rather harmless compared to *some* of the MMU functions, namely the table walk.

I personally don't have to decide, but if I would have to, I would offload this stuff also to the CPU and build something simpler underneath.

[guest11527]

Well, question is really, can I set up a 1-2GB partition to use as raw swap to increase the ammount of system "Fast RAM", which Lightwave, DPaint etc can benefit from when I do longer high-res animations? It's really all I want and need, and why I use VMM.

No, in the same way it does not work today. It may "appear to work" for you, but in reality, you only have been lucky. The problem with that is that "virtual memory" as delivered by VMM, or the memory library for that matter, does not satisfy an important contract physical memory does: Namely, you can access it no matter whether your task is in Forbid() state or not.

Thus, I do not even attempt to provide the impossible simply because virtual memory as implemented by VMM is "contradiction in terms". Given the current Amiga system, this cannot be made working reliably. It can be made working if applications know about the constraints when to access the memory and when not, and if there is a clear separatation between system memory and virtual memory. In reality, VMM is just guessing what programs probably ask for (virtual or real memory), and then probably get away with this in your case, but that's really it.

[guest11527]

Wow!  That's quite a statement.

I do believe most people buying FPGA hardware are looking to run old games.  Switching off the FPGA is not a solution for people wanting standalone FPGA hardware to replace aging Amigas.

I don't think that then the FPGA solution or the Phoenix/Apollo core is then really what you are looking for. Yes, it can be turned off so the system runs then on a plain 68K CPU with native speed... In the same sense a fast 68060@50 is not really helpful for running old games. If I want to, I disable the turbo board and run the stuff on the 68000 in my A2000.

Same as for the 68060, the FPGA speed is probably too much for many badly written games in first place. The general guideline is that if the game is Os-friendly, it should usually run. But only few games are, and most authors did not really know well enough what they were doing.

WHDload is a combination of patching techniques, both into the game and into the Os, to fix the most obvious bugs the games had, but it seems very likely that *if* you want to make games run on the FPGA with WHDLoad (why? just use the 68K in the system anyhow...) then WHDLoad would have to support the whole FPGA core natively by a couple of support functions. As said, I would rather believe that the MMU is then probably the least problem.

[Kremlar]

Stand alone FPGA solutions have existed for years already - there are myrads of boards and systems available, and for which variants of Minimig implementation runs fine already, with and without AGA support. The Apollo project is not about this.

OK.  Right, and compatibility with other FPGA solutions is excellent and/or improving.  Compatibility with older software is high priority, with good reason.

This statement does not say Phoenix, it is about FPGA solutions in general:

Thus, I would believe that the FPGA-solution is probably not quite right for just running this type of software in first place, i.e. it does not address the use case. If you want to run such games that simply go directly to the hardware, I believe you would require the old hardware directly, or rather, would disable the FPGA, and *then* run WHDLoad.

I don't think that then the FPGA solution or the Phoenix/Apollo core is then really what you are looking for. Yes, it can be turned off so the system runs then on a plain 68K CPU with native speed... In the same sense a fast 68060@50 is not really helpful for running old games. If I want to, I disable the turbo board and run the stuff on the 68000 in my A2000.

Same as for the 68060, the FPGA speed is probably too much for many badly written games in first place. The general guideline is that if the game is Os-friendly, it should usually run. But only few games are, and most authors did not really know well enough what they were doing.

WHDload is a combination of patching techniques, both into the game and into the Os, to fix the most obvious bugs the games had, but it seems very likely that *if* you want to make games run on the FPGA with WHDLoad (why? just use the 68K in the system anyhow...) then WHDLoad would have to support the whole FPGA core natively by a couple of support functions. As said, I would rather believe that the MMU is then probably the least problem.

Right.  Again, you can't "switch off" the FPGA in a standalone FPGA product.  As I mentioned above, having the options for a performance (less compatible) core, and an option to choose an accurate (more compatible) core is fine - but for the product to be successful I believe a standalone FPGA product needs high compatibility one way or another.

Counter to your original statement, I think an FPGA solution is PERFECT for a scenario like this where you have the ability to switch cores depending on what you need at a given time.

[guest11527]

Counter to your original statement, I think an FPGA solution is PERFECT for a scenario like this where you have the ability to switch cores depending on what you need at a given time.

Sorry, I don't quite understand what you are saying here. Currently, we are talking about an FPGA-based Turbo-Board for some Amigas. Thus, if you want compatibility, why would I want to load another core on the FPGA core? I'd rather disable the FPGA expansion in first place, and run the software by the native CPU. I don't need an FPGA to do that.

Plain simple 68K are available in the market, no problem. The problem is that the high-end processors (68060) are impossible to find, and *those* are out of production. Not the 68000. These are still available as new parts.

[psxphill]

I'd rather disable the FPGA expansion in first place, and run the software by the native CPU. I don't need an FPGA to do that.

Only on an a500/a600/a1000/a2000. Anything else and you don't have a 68000, some of them will only have the fpga and to use the original cpu would require you to swap cards.

[Kremlar]

Sorry, I don't quite understand what you are saying here. Currently, we are talking about an FPGA-based Turbo-Board for some Amigas. Thus, if you want compatibility, why would I want to load another core on the FPGA core? I'd rather disable the FPGA expansion in first place, and run the software by the native CPU. I don't need an FPGA to do that.  

Sorry, you are right.  I lost track based on how the discussion was moving and forgot this thread is supposed to be about the A500/A600 expansion board only.  My comments are more general, I am considering the standalone FPGA product which I would be more interested in.

[Blizz1220]

Okay , this thread has gone to the abyss so I will stick my
neck out waiting for assembler axe to fall.

I suspect that this board WILL indeed be able to use WHDLoad
to play games without it's owners having to resort to cavemen
year of loading games from floppies.

1.Because WHDLoads runs 99.5 % of games on 060 at normal
speed because good old Amiga chipset is still used for that and
the fact that cpu just got 100 times faster doesn't matter

2.If it isn't so then it will be possible by using :

C:INeedWHDLoadNowTnx >NIL:

That new command will make mighty Phoenix return to ashes
of something like the speed of 10 Mips (it will allow us also
to use 128 MB memory as 1 MB isn't enough for WHDLoad)
and no disabling of card will be needed

Somebody tell me I'm right :hammer:

[Hattig]

If I was to get one of the Vampire boards for my A500, I would want it to be compatible with all the software that runs on the A500!

I would also like to benefit from getting 50fps in 3D games like Gunship 2000, Frontier, Wing Commander, etc. In this scenario, disabling the FPGA isn't an option. However for other games, it is.  I would also not like to reboot to switch between FPGA and native 68k, but that might be asking too much!

But people are definitely looking in the future to buy FPGA Amigas to replace broken Amigas, and to run their existing software, and benefit from faster performance (if only to play Alien Breed 3D II at full frame rates).

If implementing an existing 68k MMU model is too difficult in an FPGA due to whatever factors, and in 90% of cases using a new model that does work well isn't a problem (handled by the OS), then maybe the issue is getting the remaining MMU-using software patched. This is just a matter of time, and people have been waiting a long time already, so what's the problem here really?

Also, IMO, the admins should split this topic into two threads - "FPGA 68k Design Considerations" and "Testing Vampire on the A500/A600"

[kolla]

Only on an a500/a600/a1000/a2000. Anything else and you don't have a 68000, some of them will only have the fpga and to use the original cpu would require you to swap cards.

Kind of silly to expect an FPGA accelerator card to give your A1200, A3000 or A4000 compatibility with A500 - go buy a minimig already.

[psxphill]

Kind of silly to expect an FPGA accelerator card to give your A1200, A3000 or A4000 compatibility with A500 - go buy a minimig already.

It's silly to think that an FPGA can't be used to run a 68000 core.
 
 A minimig doesn't give you the real Amiga keyboard, real Amiga floppy drive etc.
 
 Your suggestion is silly.

[guest11527]

It's silly to think that an FPGA can't be used to run a 68000 core.

It can, but why? New 68Ks can be bought for cents, so if you really want a 68K only, why not just get one?