FPGA Replay Board

[Iggy]

It's your board so you can do what you like, but doesnt it feel a bit of a waste to just use the Replay for BBS?

Leave the PCs for the boring job of serving up data...

That argument sounds really sound to me. Use the Replay board to run other (less boring) software.
This '060 daughter card really makes the system attractive. Frankly, I don't think I'm going to want to pay out the nose for a Natami.
A nice, low cost '060 powered Amiga clone sounds cool though.

[Iggy]

Unless the '060 is used, you'll pay out the nose.
Natami is aiming for more performance and an '050 on the fpga.  Hence it will *probably* cost less than a Replay with a *new* 060 and daughter card.

The Natami is still a step ahead in performance as an Amiga...and that's not an insult to the Replay.  All you have to look at is the fpga used and the memory used.
However, the Natami will not be user-reprogrammable to run alternate platforms and that's where the Replay comes into its own market.

The Replay is going to be a great alternative to the Frankenstein method of accelerating classic Amigas...and run older alternate platforms.  There is no ill will between the two teams.

FPGA technology is advancing the 68k platform.  Minimig, Replay, Natami offer us NEW hardware at the performance and budget of your liking.  This is a win for Amigans everwhere.

I can't picture sourcing an '060 any other way than used.
And of course you're right, the Natami is designed as an enhanced Amiga.
Frankly all I'm really interested in under WB3.X is legacy software.
For new software I'll stick with MorphOS.

[Iggy]

Keeping it submerged in a bucket of icy salt-water will help too.

No,no, no. Salt water is what you use on defective nuclear reactors.

[Iggy]

It has to be pure alcohol or else the ingredients that makes it taste will stick to the circuitboard wires ..

So the tasty variant can be used for other purposes

Is it possible to make 100% pure alcohol? Mineral oil sounds easier.
Say anybody want some Fukushima spring water? 10,000% pure!

[Iggy]

Free from memory. The Action Replay uses an ARM cpu. It's a simple matter of loading the core of choice. Cores are written in VHDL or Verilog.
Cores designed for other board designs should be easy to adapt (wishbone?). So a massive amount of cores should appear soon after the release.
Macintosh 68k and 80386+VGA based demos ought to be quick. All 8-bit variants should pose no problem.

It's unclear weather the default firmware for the ARM will allow programs to be loaded into it and then executed. (mikej?)

Really? Which ARM CPU?

[Iggy]

The ARM CPU that configures the FPGA with bitfiles and fakes floppydisc.

That's not quite what I meant.
What type of ARM CPU?

And Nicholas' question is of particular interest.

[Iggy]

there is a coco3 core iirc in the works.

I'd love to see coco1, coco2, trs80 model 1, ti99, apple ii, dec rainbow, vz200/vz300,

That would be kind of cool. I could run OS9/Nitros9 software on it.

[Iggy]

You make it sound very very very easy.

If it is that easy then why couldn't Elbox get it working at high speed on their Dragon?

What do you do about games that don't use LoadSeg() ?

Chaos bring up something that has bothered me from the start. Not only are Coldfire processors missing some 68K instructions, other instructions don't work exactly the same way as they do on a 68K.
If everything has to run through a JIT interpreter, then the performance hit may nullify the speed advantage.

A real '060 or an FPGA emulated 68K processor may have a performance advantage over a Coldfire processor running 68K code through a JIT interpreter.

[Iggy]

JIT may work, but it'll be slower & need more ram. Dealing with self modifying code is especially tricky.

Frankly, that is a trick I always avoided. A true sign of bad programming.

A few OS' I've worked with essentially forbid self modifying code.

[Iggy]

>Having to clear the cache is another reason why it's seen as bad  practice, beyond being horribly unmaintainable. There's a reason people  pretty much stopped doing it in the mid 80's.

Honestly, self modifying code isn't just a bad practice, its a recourse used by sloppy programmers. For the small improvement you might see in performance you destroy easy traceability and can no longer use re entrant code.

[Iggy]

Well, as soon as you guys have these up you've got to post some impressions.
Replay beats the Natami to the gate!

[Iggy]

What you're suggesting is impossible. You say it won't take more ram and yet you're somehow going to have the entire program in memory and have it patch itself. Just try and code it.

Obviously that approach would take more memory. And you're running additional processes to control the interpretation and execution of the code.
So more memory and a higher CPU load.
MorphOS can handle JIT for a 68K processor, but look at the speed of the processors it runs on.

Available Coldfires just don't run that fast to make JIT practical unless your goal is running 68K code at about 68K speeds and running native Coldfire code at full speed.

[Iggy]

I say it won't take a lot more RAM. For a typical program where only a small percentage of the instructions need to be patched, the growth would hardly be noticeable.

My point was that there's no reason to generate the whole program all over again at a new location in memory.

Right, you're going through the code as it executes so it does take up that much memory. The JIT interpreting code itself would take up more space.
But the CPU cycles used by the JIT software are significant.
And the overhead doesn't completely disappear when running compatible code because each part still has to be checked.

[Iggy]

The FPGA camp doesn't have a fixed color. It's loaded at boot time from another camp.
;-)

Ha!:lol:

[Iggy]

The FPGA color should be that sicking brown/green/grey that you get when you mix all of the playdoh colors together.

Aros isn't going to fear the Replay.  It will end up being the official Amiga compativle OS for the FPGA camp.

,,,when its finished wake me up....zzzzzzz