FPGA Replay Board

[amigadave]

A question for Mike if he happens to drop in:

Are there any plans to include a "boot loader" similar to the C-One where you can select at startup which core you want to run?

I am pretty sure, as the name implies, that MikeJ intends it to run more than just an Amiga core and has planned to have the Replay board run as many Arcade machine cores as are available.  I don't know about such cores, but searching for them on the Internet should turn up more than a few, I would think.

I don't know if you would need a separate SD card for each Arcade machine, or computer system that you are cloning, or if you can fit several onto just one SD card and as you said, choose which one you want to load from a boot loader.

[espskog]

I am pretty sure, as the name implies, that MikeJ intends it to run more than just an Amiga core and has planned to have the Replay board run as many Arcade machine cores as are available.  I don't know about such cores, but searching for them on the Internet should turn up more than a few, I would think.

I don't know if you would need a separate SD card for each Arcade machine, or computer system that you are cloning, or if you can fit several onto just one SD card and as you said, choose which one you want to load from a boot loader.

I aggree. A core-selector from the boot menu would make the board very nice But I suspect this is already in the pipeline, or already implemented.

Espen

[freqmax]

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?)

[nicholas]

Neat!  How did you get the sources?

EmuTOS and FreeMiNT are to Atari what AROS is to Amiga.

[desiv]

EmuTOS and FreeMiNT are to Atari what AROS is to Amiga.

He also said they had the sources to Atari TOS, which I think was more interesting...

desiv

[nicholas]

He also said they had the sources to Atari TOS, which I think was more interesting...

desiv

So he did, I didn't notice that.

Maybe they just disassembled it?

[Mathias]

Neat!  How did you get the sources?

Both Madusa as Milan are involved at the Atari Coldfire Project. And both bought licences for their computers mid of the 90ies. The contracts were done with the original Atari Inc. before it was sold to JTS in 1996. So we have the original TOS sources, not disassembled code.

[nicholas]

Both Madusa as Milan are involved at the Atari Coldfire Project. And both bought licences for their computers mid of the 90ies. The contracts were done with the original Atari Inc. before it was sold to JTS in 1996. So we have the original sources, not disassembled code.

While you are here, can I ask you a question about the Firebee?

Specifically, how do you handle running old 68k binaries with no source available that use instructions that exist on both the Coldfire and 68k CPUs, but behave differently on each?

[JimS]

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?)

If you look at the demo video mike posted on youtube, you can see him selecting demo disk menus from an onscreen display.

[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?

[freqmax]

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

[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.

[Mathias]

While you are here, can I ask you a question about the Firebee?

Of course!

Specifically, how do you handle running old 68k binaries with no source available

I am not a developer, so I doubt I can give you a real satisfying answer. But let´s try; there is - inside our Basis-System – a usermode, supervisormode, and a real hidden supervisormode. This 3rd new mode is unaccessable by the Operating System, and with heavy usage of MMU and illegal instructions handler most applications will work.

that use instructions that exist on both the Coldfire and 68k CPUs, but behave differently on each?

Especially that issue is unsolved recently. We got cf68klib implemented inside the OS, but that few instructions are not done. But as I understood Atari applications make very few usage about them. I have to discuss it again with our OS-gurus, but I belive there are 2 instructions (?) that behave different. There are some ideas/concepts, but work on it will start this summer, as we also plan to do our own 68k handler, once the first series is out to the customers.

[vidarh]

There are some ideas/concepts, but work on it will start this summer, as we also plan to do our own 68k handler, once the first series is out to the customers.

An idea for you guys: Look into a tracing JIT. Effectively you start by putting a breakpoint at the very start of the application. Then when the breakpoint is hit, the trap handler checks each following instruction until a branch point. At the branch point you insert another breakpoint.

If any of the found instructions are "unsafe" (differ between M68k and Coldfire) you rewrite it to an equivalent safe variation or patch in a jump to a tiny dynamically generated function that emulates the right behavior and jumps back (if there's no space to change it inline). Then you let the instruction stream execute until the next trap, and repeat.

Initially things will run slowly, but after each code path has been executed once, it'll have been rewritten and will run *far* faster than having to run a trap handler for every hit.

This approach is what's used by modern Javascript JIT's - there it's complex because they have to do complex code generation, but for M68k => Coldfire most of the code is already valid so the JIT can pass over all safe instruction and only need to recognize the few cases that are not valid Coldfire code and know how to generate code to emulate just those instructions.

You could probably do a decent functioning tracer/JIT for M68k => Coldfire in a couple of thousand lines of code.

[Mathias]

An idea for you guys: Look into a tracing JIT.

Something like this is planned by Fredi Aschwanden. I just avoided the word JIT, because I do not completely understand it myselve, and the next question normally is "why not us a PPC than" ;)Such a "partial JIT" will solve everything except selfmodifying code as far as I understood. I will post your message insiode our development forum. Thanks.

[vidarh]

Something like this is planned by Fredi Aschwanden. I just avoided the word JIT, because I do not completely understand it myselve, and the next question normally is "why not us a PPC than" ;)Such a "partial JIT" will solve everything except selfmodifying code as far as I understood. I will post your message insiode our development forum. Thanks.

Well, you could just as well ask "why not switch to emulation", but then I guess most of us here aren't all that rational when it comes to our attachment to the M68k architecture

And the other thing is that a JIT from M68k to PPC is massively more complicated. A M68k to Coldfire JIT can just skip past most instructions, and so for almost all instructions all it needs to know is how to determine that they fall in the "safe/compatible" category, and how to figure out the length of the operands to skip them. For m68k that's very easy for most instructions - there aren't that many variations of the encoding.  

In theory there's nothing really stopping you from undoing relocation and generating/caching a new fully or partially translated binary through this process either, though it might not be much point adding the complexity.

Looking at the size of M68k instruction decoders, you can do enough of the instruction decode to skip the safe instructions in at most a couple of hundred lines of code (the only one I happen to have sitting on my hd is 457 lines of C to decode instructions fully to text - a decoder that for most cases only needs to figure out the type of instruction and size would be far smaller).

Beyond that it's the code to manage breakpoints and splice in "fixed" instructions, but that shouldn't be huge either.