FPGA Replay Board

[matthey]

I was under the impression we were in the business of re-implementing existing  Commodore computers. Not inventing new APIs for which there is no software for. Let the existing Commodore models be the "standard".

There is software available for the ColdFire! Add ColdFire instructions to the 68k and this software will run with a very high degree of compatibility on the new 68k + CF.

The problem shows when you alter instruction sets, register structure, etc.. which will kill the capability to run existing software. Increasing memory, frequency, caches, etc..

Well, Mike better go back to the 68000 and throw out all the 68020 changes because he's killed compatibility with 68000 code, right? This is blatantly wrong! The 68000 to a 68020 was a very radical change, was not 100% compatible and made a few mistakes in my opinion but it was still a big enhancement in a positive direction. Adding CF instructions would be much more compatible than 68000 to 68020. It would be more compatible than enlarging the caches. Maybe you should stick with the MiniMig and ECS so you have all that compatibility. Oh wait, they enlarged memory and added new storage devices. There went compatibility. I guess your only option is an original unexpanded Amiga 1000 so you can enjoy your compatibility.

If you want updated performance, try Intel Core (MIPS for freedom, or ARM for efficiency might be alternatives), Intel graphics (free API), it ends up being a PC. Though ARM + Graphics is becoming more common as well. However any compatibility goes out the window. Also modern systems use memory protection, preemptive multitasking, virtual memory, and user accounts which asfair AmigaOS doesn't support.

I think an updated 68k processor has more potential than ARM. I think with a few relatively minor additions the 68k can have...

+ better performance
+ better code density (I think 68CF+ can have 5-10% better code density than 68020)
+ easier to program

with the negatives of...

- higher power requirements (but still good and better than x86 derivatives)
- more gates (cost not really a problem today, power requirements higher)

I'm sorry if you can't see the potential.

[freqmax]

There is software available for the ColdFire! Add ColdFire instructions to the 68k and this software will run with a very high degree of compatibility on the new 68k + CF.

I guess that ColdFire software won't make use of the graphics.

Well, Mike better go back to the 68000 and throw out all the 68020 changes because he's killed compatibility with 68000 code, right? This is blatantly wrong!

I didn't say that.

The 68000 to a 68020 was a very radical change, was not 100% compatible and made a few mistakes in my opinion but it was still a big enhancement in a positive direction.

68020 was in some aspects a requirement for AGA.

Adding CF instructions would be much more compatible than 68000 to 68020. It would be more compatible than enlarging the caches. Maybe you should stick with the MiniMig and ECS so you have all that compatibility. Oh wait, they enlarged memory and added new storage devices. There went compatibility. I guess your only option is an original unexpanded Amiga 1000 so you can enjoy your compatibility.

I didn't say that.

It's interesting that you seem to know what my feature plans are
Adding storage or memory doesn't affect compatibility in any serious way.

I think an updated 68k processor has more potential than ARM. I think with a few relatively minor additions the 68k can have...

I can see the potential in up to date technology. ARM have a tendency to send 3vil lawyers all over the place. But their approach to performance per gate, power consumption, etc.. is worthwhile to sneak at. And FPGA gates are at a premium.

[desiv]

68020 was in some aspects a requirement for AGA.

There's a youtube vid showing FPGA Arcade (early proto I believe) running AGA software with a 68000 core...
Lion King AGA I believe...

desiv

[freqmax]

Yeah, I know. But there's likely other software that exploit the 68020 capability. One program won't prove it for all software. The larger memory bitwidth might be needed on occasion perhaps as well

[desiv]

Yeah, I know. But there's likely other software that exploit the 68020 capability. One program won't prove it for all software. The larger memory bitwidth might be needed on occasion perhaps as well

True, although they run a few in yaqube's vid.

But, I think I heard that the 68000 FPGA in use had memory tweaks (full 32-bit bus?)..
So I think it was a core that was somewhere in between a 68k and a 68020.

Could be wrong tho..  I was once..

..

Actually, no I wasn't..  Got that wrong, sorry.. :angry:

desiv

[billt]

The problem shows when you alter instruction sets, register structure, etc.. which will kill the capability to run exisiting software. Increasing memory, frequency, caches, etc..

Adding new features doesn't necessitate breaking old stuff. Removing old things will be a bigger problem. So add new things and don't remove old things. Do testing to see if ckock rates or something else causes problems. If a problem is found, we have the situation where with FPGA we can have a version with the new stuff, and an old version for certain things that don't like the new stuff. We can progress without breaking compatibility in many ways, and we can progress in incompatible ways, but still able to use finicky software with a reboot to a more compatible mode. Not  big deal IMHO.

[freqmax]

All features use gate capacity.

[madcrow]

Now that these boards are starting to become available is the source for the AGA core going to be available? Awhile ago it was said that the code would not be released until the Replay boards were available. Will the AGA plus pseudo 68020 core ever show up as FOSS or has the project "gone closed"

[mikej]

Now that these boards are starting to become available is the source for the AGA core going to be available? Awhile ago it was said that the code would not be released until the Replay boards were available. Will the AGA plus pseudo 68020 core ever show up as FOSS or has the project "gone closed"

Open source. It is not a case of waiting for the boards to be available, a few people have bits of the code already.

/MikeJ

[psxphill]

I'm sorry if you can't see the potential.

I can see the potential, but it doesn't look good.
 
If they can't make it faster without forcing people to change their code then it's pointless. They might as well just sell a PC and an emulator.

[pampers]

I can see the potential, but it doesn't look good.
 
If they can't make it faster without forcing people to change their code then it's pointless. They might as well just sell a PC and an emulator.

Some ppl doesn't want a pc with an emulator, don't you get it?

[freqmax]

Some software like cycle accurancy. Thus software emulation won't cut it.

I still rememeber the people that said Minimig is IMPOSSIBLE!!
Oh and AGA.. are you NUTS!?
Mike.. oh forgett it

[kolla]

They might as well just sell a PC and an emulator.

A PC that is umteen times bigger, pulls a heck lot more power, and still is uncapable of cycle exact emulation? We already got those.

[mikej]

I've added mechanical data and schematics to the website.
Mouse / Keyboard is now working with new softCPU core (picoblaze) to save space and add some flexibility.
It's now easier to change the keymap and you can have two mice (or keyboards) if you fancy.
I'm also trying to support native Atari/Amiga mice in the joystick port.
Best,
MikeJ

[Greg.0]

I'm also trying to support native Atari/Amiga mice in the joystick port.
Best,
MikeJ

It will be nice for use with the stick mouse emulation of the Paul Willinghams's code (PSX/PS2 Adapter) !

[mikej]

I've had to pop back to China for a brief trip, so I won't get any boards shipped out until early November.

On the plus side, I am sourcing parts for the daughter board and working on the new AGA core. I getting some ATX IO shields made, and one board has been sent for EMC testing (CE/FCC etc).

So, it's all coming together ....

/MikeJ