FPGA Replay Board

[vidarh]

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.

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.

[vidarh]

MorphOS can handle JIT for a 68K processor, but look at the speed of the processors it runs on.

MOS JIT's from m68k to PPC - a massively more complicated task. Even so, I very much doubt the cost of the actual JIT is particularly noticeable.

There's plenty of research on load time code generation on M68k CPU's that demonstrate that it can be done quickly, for example Michael Franz' doctoral dissertation from 1994 - Code-Generation On-the-Fly: A Key to Portable Software - that achieved speeds on 68020's or 68030's that was fast enough to be hardly noticeable while executing a far more complicated code-generation pass.

Anyway - I'd be happy to continue this discussion, but if so we really ought to create a new thread for it - this is getting rather off topic

[vidarh]

Yep, WinUAE works (pretty well actually). AROS? When is the X86 version going to be at v1.0?
Running, no I want it running correctly. The X86 version has enough faults, the 68K version is no where near as polished.

The 68k version can run Amiga Basic. What more do you want? :lol:

[vidarh]

Why is a kickstart ROM important? Couldn't new hardware use flash memory as a replacement? Obviously, legacy hardware would have limitation with a larger replacement that wouldn't fit in a ROM, but why would you worry about the size of the replacement for new systems?

ROM in the case of AROS is just used as a catch-all phrase for a single binary that contains all the basic functionality needed to get the system to work with apps that expect the same functionality as an original Amiga kickstart ROM, and that *can* be put in a ROM or flash (e.g. they don't try to write to anywhere in the image, and only uses memory that's explicitly been allocated from RAM).

I don't think anyone would try to produce actual ROM chips - you're right that using flash is a better alternative. Even for classics, a ROM replacement holding a flash chip would be better than producing an actual ROM, so it's easily updated.

[vidarh]

So why in the world do I keep seeing posts related to the ROM size limitations of specific Amiga models?

Because those limitations are limitations you'll also run into if you try to replace the kickstart ROM with a tiny "drop-in" board with a flash chip on, as well as limits you'll run into if you use any number of solutions that remap RAM copies of the kickstart. It's also a limitation of Minimig, for example - don't know about the Replay board.

So in other words, if you want to be able to use the kickstart images on real classics or Minimig's without more complicated new expansions you have to restrict the size of the kickstart image whether you want to actually put it in ROM or not.

[vidarh]

I'd always assumed there would be someway to load this to RAM and not have to deal with a size limitation.
Is it an issue of how much space a Kickstart ROM can be mapped to or other problem?

If you put something in the ROM socket, there is no direct way around the space limitation if you want everything in ROM/flash, as the limit is because of the number of address lines available on the various models.

But of course you could put extra ROM/flash/RAM on the Zorro bus etc.

Or you can put some stuff in ROM/flash and a second stage boot loader that'll let you load a larger image from RAM, similar to what is done on the A1000.

So yes, there are ways around it, but the reason for trying to get as much as possible into a 512K or 1M image would be for compatibility with as wide range of classics as possible when booting floppies etc. where there's no convenient way to load another ROM image first (it'd be pretty sucky to put in a replacement ROM/flash on an A500 and have to boot a second stage image from floppy before you can boot a disk that depends on C:loadwb bringing up a Workbench, for example...).

For booting from a harddisk etc. this is pretty much a non-issue, since you pretty much only need enough in the kickstart to recognize the boot device and be able to load files from it.

[vidarh]

Something like what DENEB offers. If I have the power / control to pick and choose binaries (boingbags, whatever) to execute at boot up, why do I need AROS?

You don't "need" AROS on a classic unless you want the improvements that AROS can bring.

The benefit of AROS is in the long term where we can update any OS component without having to resort to piles of SetFunction()'s for example.

[vidarh]

And as far as size limitations, I wasn't suggesting this:
"it'd be pretty sucky to put in a replacement ROM/flash on an A500 and  have to boot a second stage image from floppy before you can boot a disk"

I was thinking more toward a larger banked EPROM that could appear as a 512KB or 1MB ROM but hold more when booting.

If you were to place such a hypothetical board in the ROM socket, it'd need to implement logic for bank switching. Not impossible, but it'd be messy. E.g. you could have some tiny bootstrap logic copy the initial 512K or 1MB to RAM, and have some logic set up so that attempts to read/write a specific address in the ROM address space trigger a change in additional address lines on your card. But if you want to do that, then you *need* to copy the contents to RAM, as there's no way to make the whole image available at the same time via the ROM socket if it exceeds the size limit.

A device on the Zorro bus, like a Deneb for example, is probably a better option then.

[vidarh]

Mumbles something about wires and soldering to CPU address pins... It must be possible, especially with something like that German EPROM board where you can solder the other end to the wire to the spare EPROM pins.

Heh. Actually that might be possible. Back when I had my A500 I had a couple of things soldered straight onto the pins of my 68000 Alternatively moving the CPU to a socket on a board slotting into the CPU socket with a flash tied to it should be doable for a cleaner solution, at least on machines with a 68000 (no idea how sensitive the faster 680x0's are to noise/poor connection from something like that, but with the 68000 at least you can get away with murder).

[vidarh]

directories open within a browser window with a back gadget, which is more convinient than the way workbench does it.

Maybe for some, but personally I prefer a 3.x Workbench over Wanderer any day. I hate how wasteful Wanderer is with space in the drawer windows.

[vidarh]

I've been away from Amiga land for a little while, so please forgive me asking this.

Just to be clear, this FPGA Replay Board is a fast, very highly compatible 020 A1200 on a mini-ITX board, with a possible option for a real 68060 on an expansion board?

Mostly right, except it's much smaller than a Mini-ITX board (less than half the depth, IIRC). It's designed so it can be fitted in a Mini-ITX enclosure, but there'll be plenty of spare room, so a custom enclosure could be even smaller.

[vidarh]

I was also asking myself that very same question. It seems like the biggest selling point is that you can boot it without a valid licensed copy of the original Workbench.

For now, that's probably right. Going forwards it means new functionality as AROS gets improved beyond the 3.x level, without an ever growing list of SetFunction() kludges and similar stuff. We're rapidly closing in on parity with 3.x.

And in some cases we're better. E.g. AROS console.device and console handler has a bunch of KingCON: style functionality already, and will get more (I keep using this example, since it's code I've worked on and know - there are tons of other bits and pieces in other parts of AROS too).

Of course, you can use KingCON and all the other fixes and workarounds instead. The fact that most people do is why a "modern" AmigaOS 3.x system is a heap of kludges and patches and commodities and replacements for OS files.  AROS provides a way out of that, and allows us to create a nice clean foundation and improve that directly instead.

[vidarh]

A Zorro bus would be a complete waste.  Nobody is producing any Zorro hardware and why would you want to connect a 20 yr old Zorro device to this system when you have several other interfaces that are modern and more efficient?

You do realize what community you're part of, right? "Modern" and "efficient" are practically swearwords for a lot of people here :lol:

[vidarh]

I think you're all going a little bonkers. This is FPGAArcade. It is supposed to be a cheap, mass produced hardware emulation platform. Not a replacement PC. Surely if you want addon cards then get a PC/Mac?

Just because a new hardware platform came out the software devs are not going to come back to the Amiga platform. No software devs means no new drivers. No new drivers means no way of using new hardware.

FPGAArcade is surely destined to be a fun hardware emulation platform. Not meant as a replacement computer.

With sufficient expandability it will make a suitable mid-level replacement for classic Amiga hardware for some people.

For my part it won't replace my Linux box, but I'm certainly not intending to relegate it to playing games.

As for drivers, with the 68k AROS port coming along, I can pretty much guarantee that at least a few AROS devs will pick up an FPGA Arcade. If there are any *interesting* cards that aren't too hard to write drivers for, I don't think drivers will be an issue. Given that Natami will have these options as well, there might also be some scope for shared efforts on the driver front.

[vidarh]

Before using the RP9 format, check that it's copyright free.

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.

[vidarh]

Just as I was promising myself to spend less money on electronic gadgets....

Oh well, will have to break that promise.