FPGA Replay Board

[psxphill]

Yes, I must admit that I am getting almost excited about this project finally being ready for sale to the masses.

Yeah, ten years on and the spiritual successor to the BoXeR is nearly here.
 
http://www.amigahistory.co.uk/boxer.html
 
It would be cool if the 060 board was renamed to BoXeR

[psxphill]

Surely any core the Natami uses in FPGA (and thus performance) could also be used by the bare FPGA Arcade?

Depends on the speed and size of the FPGA ( which also affects the cost ). Without the source code it will be tricky to adapt as well.

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

[psxphill]

You misunderstand what I was describing. I was describing a purely software solution similar to a JIT (just in time compiler)

JIT may work, but it'll be slower & need more ram. Dealing with self modifying code is especially tricky.
Code accessed through jump tables are also difficult to find until you actually get to it.
 
There is a difference between writing a JITing for a language that was designed for it & one that isn't.
 
While I don't think it's as easy or good as you think, I'd love to see how it works out.

[psxphill]

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

self modifying code is fine as long as you clear the cpu caches afterwards, so as long as you ditch the jit cache when the caches are cleared then it'll work.
 
How about pushing an address on the stack and then returning?
 
Although rts will need to cope anyway as the code you're returning to might have been flushed if your jit cache fills up. So it will have to always do a lookup to find the real code.

[psxphill]

There would be no "jit cache" - that's the entire point of how to make it fast and simple - you'd patch the live code directly, so no, it doesn't need to do any lookups because to pushed address would be the address of the real code.

So all you're going to do is patch at load time? You might find some software that works for, but you can't get 100% coverage of all opcodes on all software at load time. Even worse you might patch some data, because you can't be guaranteed that you'll figure out which is code and which is data (technically it can even be both).
 

Frankly, I haven't seen self modifying code used for any good purpose since my Commodore 64 days (and then for cycle exact timing for raster effects, not for performance)... I'd be very interested in seeing a good example of it being used in a way where it couldn't easily be avoided without sacrificing a lot of performance.

Is copy protection a good purpose?

[psxphill]

No. At runtime. It wouldn't be a JIT if it tried to do it all at once.
 
Which is why you trace the execution until each branching point and JIT trace by trace rather than the whole thing at once,

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.

[psxphill]

Does that mean that in older Amigas there no way past a 512KB limit?

A500 and A2000 are easy.
 
http://www.amiga.org/forums/showthread.php?t=52079
 
A1000 is just as easy to convert to a 42pin rom as it is a 40pin rom, >256mb of WOM is hard.
 
A600 and up support 1mb roms

[psxphill]

Can these AROS 2x 512 kB ROMs be used on an Amiga 500 ?
 
Considering it only has a 256 kB ROM from start.

A500 rev 6+ support 512k roms, earlier versions require a wire added between 1 & 31. To support 1mb roms you need to run some wires to the extra pins on the rom (the socket is 40 pins but a 1mb rom is 42 pins).

[psxphill]

So the rumor that the requirement is 68020 or better is false.
 
Now someone actually tried instead of assuming it doesn't work?

020 is for the picasso driver in UAE-E, the OCS/ECS/AGA driver is not recommended as there has not been much effort put into them yet.
 
Then you need 1mb of ram that doesn't disappear after a reboot to store aros in. So if you only have chip ram then you need 2mb of it, so 1mb of it is used for storing aros and the rest is used as chip ram. If you don't have 2mb of chip ram then you need at least 1mb of local fast.
 
When it's complete you'll be able to burn a rom and then it will be alot simpler, except you'll need to figure out how to add 1mb roms.

[psxphill]

It will make classic Amigas faster too, avoiding the slow ROM chip at runtime except boot.

ROM is only slower than RAM if you have an accelerator with onboard RAM, which will generally have a way of caching it itself anyway.
 
If you only have chip RAM then keeping as much code in ROM as you can is going to be faster too.

[psxphill]

3. That menuloader can be quite nice and show all games and demos on the sdcard and
maybe also show with thumbnails and have lots of nice info on the game like
screenshot. PLus maybe some nice screenshots of the game + gameinfo. And the
trick is then to be able to select the game you want, and have the minimig boot it

The fpga replay board isn't just about amiga though. It would be better to browse through all games and then switch to the correct emulation based on what you selected.
 
So it should probably boot into some custom os or linux (it's got to be good for something other than routers, right?).

[psxphill]

You can't copyright facts, such as a fileformat. You can copyright the *description* of one, but that doesn't prevent re-implementing code to handle it.

unless it's patented, not that I think it is (but it's possible).

[psxphill]

Microsoft has the right to sue people for using the long filename feature (LFN).

The problem is supporting short and long file names at the same time. If you only support one or the other (possibly including making it switchable) then you don't appear to have a problem.

[psxphill]

4 - Yes, with a DVI to HDMI cable. For the audio you will need to run a separate cable from the 3.5mm jack to the RCA inputs on the TV.

is there any chance a future version will have audio over hdmi?