FPGA Replay Board

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

[mikej]

The ARM CPU is an atmel sam7s256. It's job is to boot the FPGA, load ROM images into DRAM and sort out configuration by the OSD.
It also acts as a bridge to the SD card, pretenting to be a floppy or hard disk (or tape perhaps).

I'm working on merging my generic boot loader with Jakub's amiga extensions (such as hardfile and floppy support) but there is still some work to do,

I'm in China at the moment, so I won't be online so much.
/Mike

[jj]

I believe some are already in the works. There's an old thread around here somewhere...
 
Once I get my hands on the FPGA Arcade I intend to put together a hard file with a Classic Workbench install and then add as many emulators to that as I can find. Some off the top of my head:
 
VICE: 8bit Coomodores (C64, VIC20, PET, etc)
MAME: Arcade classics!
BBC model B: I have the floppy somewhere, hope it works.
Spectrum: For those who want to play C64 games only with wank graphics and crap sound.
PC Task: MS DOS and Windows 3.x or even Windows 95?
Shape Shifter: I also have the MacOS7.x package that Cammy & friend assembled.
 
It will do until some "native" cores appear. Can anyone think of any more?

Sure can .  Amstrad CPC

[freqmax]

I think Atari-ST, Macintosh 68k, 80386+VGA+SB

[yakumo9275]

Sure can .  Amstrad CPC

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,

[Mathias]

Well, you could just as well ask "why not switch to emulation",

Hahaha, belive me it was asked several (!) times, as we got the real good VM Aranym!

but then I guess most of us here aren't all that rational when it comes to our attachment to the M68k architecture

Well, it seems the Amiga crowd is as crazy as we are Thats exactly the point a dedicated hardware is something completely different.

 
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.  

Exactly! Please spread that informations I had huge problems and was tortured whith the question "why beating a CF to compatibility with 68k". And it was really hard to understand for some people that a CF is much more easy, and that the Atari community is not strong enough any more to get a processor swichth done. Also many people didn´t get the fact that we can produce binaries that run on CF AND 68k. the AHCC compiler/assembler is already able to do so for one year now.

In theory

Well in theory we could even boot a 8-bit machine or a Amiga 500 natively at the FireBee. But it needs to be done by anyone, … It´s always the question of reasonable amount of work compared to the aim. aNd in case of an Amiga, I always said there is no sense as you have the Minimig and soon the X1000 as Natami. For the rest of your posting, volutneers are highly welcome at every time )

[billt]

I think Atari-ST, Macintosh 68k, 80386+VGA+SB

Have you checked out Suska? Anyoen intrested in porting to FPGA Arcade? (It's the Atari equivalent of Minimig core from the sounds of it)

http://experiment-s.de/en/atari-ste-in-a-chip/

[vidarh]

For the rest of your posting, volutneers are highly welcome at every time )

See, the thing is I'm very tempted to write a tracer for M68k, but I've overcommitted myself to way too many projects already that are all proceeding at snails pace, so I'm hoping to trick someone else into doing the work :-P

The Coldfire part isn't really *that* interesting for me (though it'd be kind of cool to get AROS M68k running on Firebee...), because it's not that relevant for Amiga, but there's tons of other cool stuff you could do if someone wrote a generic M68k tracer (e.g. one that's configurable as to which instructions it traps), like building all kinds of funky debugging and analysis tools that'd work even on non-MMU systems.

[Mathias]

See, the thing is I'm very tempted to write a tracer for M68k, but I've overcommitted myself to way too many projects already that are all proceeding at snails pace, so I'm hoping to trick someone else into doing the work :-P

Well thats a very cool plan, even extremely tricky . I like it Just let´s talk more about it, maybe some volunteer will show up.

The Coldfire part isn't really *that* interesting for me (though it'd be kind of cool to get AROS M68k running on Firebee...), because it's not that relevant for Amiga,

Maybe if we tell people as well, that there would even be the whole thankfulness of Dragon- and Coldfusion-team belonging to this volunteer as those two projects could be produced in series afterwards, ... ;-P

but there's tons of other cool stuff you could do if someone wrote a generic M68k tracer (e.g. one that's configurable as to which instructions it traps), like building all kinds of funky debugging and analysis tools that'd work even on non-MMU systems.

Thats also a nice idea I didn´t think about.

[alexh]

Have you checked out Suska?

I've not seen any updates for a while but it will be a good porting opportunity. Moving the BSP (board support package) to FPGA Replay Board will take up the time. It won't be a simple "recompile" but should be possible.

I always wondered why there are so few FPGA projects ported to MiniMig v1.1 PCB?

[psxphill]

because it's not that relevant for Amiga, but there's tons of other cool stuff you could do if someone wrote a generic M68k tracer (e.g. one that's configurable as to which instructions it traps), like building all kinds of funky debugging and analysis tools that'd work even on non-MMU systems.

The major problem is latency. You'll have to sit between the cpu and ram and insert something like a line-a/illegal instruction. However you'll have to wait for the data to settle before you can examine the opcode to patch (which if it's configurable will involve a lookup) and only then can you output the original/replacement opcode to the cpu (which will also have to wait for the data to settle ).
 
You'll also need some hackery to determine which is the opcode and which is the operands, which may also require lookups.
 
As this will happen when the instruction cache is being filled it may only have a small impact (until the exception is taken anyway) and it might be worth the penalty. However an fpga cpu is a much better way to go.
 
CF is fine for new software, you can even make new software that works on CF & 68k. But there are always going to be doubts over old software.

[vidarh]

The major problem is latency. You'll have to sit between the cpu and ram and insert something like a line-a/illegal instruction.

You misunderstand what I was describing. I was describing a purely software solution similar to a JIT (just in time compiler): loadseg() the binary, run a function to decode and process instructions up until the first potential branch, insert a breakpoint, jump into the (possibly modified) instruction stream. Repeat.

*No* hardware support is needed for this.

You'll also need some hackery to determine which is the opcode and which is the operands, which may also require lookups.

This "hackery" for M68k is really easy - as I mentioned, a full instruction decoder for M68k is at most a couple of hundred lines of C.

CF is fine for new software, you can even make new software that works on CF & 68k. But there are always going to be doubts over old software.

JIT of instruction streams that deviate massively from the target can approach compiled C in performance. E.g. Java bytecode JIT's or Lua for example. For M68k => CF getting performance far outstripping the original M68k's ought to be fairly trivial.

[ChaosLord]

You misunderstand what I was describing. I was describing a purely software solution similar to a JIT (just in time compiler): loadseg() the binary, run a function to decode and process instructions up until the first potential branch, insert a breakpoint, jump into the (possibly modified) instruction stream. Repeat.

*No* hardware support is needed for this.

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

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

[vidarh]

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?

Did they ever try? AFAIK most or all attempts at dealing with the CF incompatibilities so far have focused on trapping the instructions, which is horribly inefficient. Most likely they simply never thought about this precise approach, or they didn't have anyone who understood JIT's - you can probably still count the number of people who have ever implemented a JIT worldwide in the low 3 digits.

The tracing JIT mechanism is well tested in far more challenging circumstances (JIT'ing from things like Java and Lua bytecode, which is massively more complicated because it doesn't match the target machine code at all) and have been shown to work well. The new Lua JIT in particular is very impressive.

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

The method you use to load the binary is secondary. The only caveat is that you need to be able to start the translator *before* the code you ant to process, and to have some reasonable guarantee that you can prevent the JIT translator itself from being overwritten, but for modern reimplementations, providing a write barrier shouldn't be a major obstacle.

[ChaosLord]

Ok so start the tracer in the kickstart.

But how can the JIT tracing work inside of interrupts?