FPGA Replay Board

[psxphill]

I know that the MMU was required on the '040 and '060 to be able to use DMA-based hard drive controllers. I don't know if that even applies to the current Replay board designs.

You don't need an MMU, the ATC registers are enough.
 
There are limitations to this approach and that is that all of Zorro II space has to be set to cache-inhibited serialized.
 
It's nothing to do with DMA, it's Zorro II IO cards and chipram that causes the problem. If you have nothing in Zorro II space then it's largely irrelevant.
 
The same thing would happen with the Replay if it used an 060 without an MMU.

[Dozer]

Wow, my last post just goes to show that the world is indeed small. Got a textmessage from an friend back in the "old days", telling me that he actually HAS a board that I can borrow to test stuff with.

Awesome, I just hope the core he has is somewhat more stable than my (now sold) A4000

[psxphill]

The Amiga rarely needs cycle exact as it relies more on custom chip timing but the Atari is more reliant on CPU timing. I would think a cycle exact 68000 and 68020 would be all that is needed for game consoles, Atari and a few old Amiga games. In my opinion, a cycle exact 68040 or 68060 is wasting time and resources that would be better spent on making a faster fpga CPU.

There is very little software that relies on cycle accuracy on the Amiga, because software ralely used delay loops for timing anything. There are however some exceptions. Some demos started the blitter in hog mode and assumed that the CPU wouldn't be able to run until the blitter had finished, this falls down when you are running from instruction caches. Alot of the soundtracker players used a software delay loop for waiting until it was safe to write to some registers. Also some old software relies on 68000 stack frame formats & MOVE SR.
 
I can see the argument for a 7mhz 68000 profile, but anything other than that should just run as fast as it can. Even a 68020 is a waste.

[Dozer]

 I can see the argument for a 7mhz 68000 profile, but anything other than that should just run as fast as it can. Even a 68020 is a waste.

No it is not; demos bang the hardware quite bad.

Try watching TBL-Tint on ANYTING but an A1200 with a 50 MHz 68030. Most likely it will crash and burn (even with the 040/060 patch)
http://www.pouet.net/prod.php?which=701

Most demos nowadays are timed exactly on an A1200 with 50MHz 68060, if you use the Apollo Boards with a 66 MHz, the sync is lost quite often.

So, yes, we NEED proper settings, with cpu-selection and speed-setting to be able to watch the demos as intended

As a minimum:
7.14 MHz 68000
14.28 MHz 68020
50 MHz 68030
50 MHz 68060
66 MHz 68060 (some demos actually rely on this... )

Then again, this is to watch demos.. If all you want is to fire up the good old games, then "stock" settings would probably be enough.

[matthey]

No it is not; demos bang the hardware quite bad.

Banging the hardware doesn't have to mean incompatible. Frank Wille's SqrxzOCS game port bangs the hardware but works on 68000-68060, OCS-AGA, AmigaOS 1.x-3.x, is hard drive installable and properly exits.

So, yes, we NEED proper settings, with cpu-selection and speed-setting to be able to watch the demos as intended

As a minimum:
7.14 MHz 68000
14.28 MHz 68020
50 MHz 68030
50 MHz 68060
66 MHz 68060 (some demos actually rely on this... )

Then again, this is to watch demos.. If all you want is to fire up the good old games, then "stock" settings would probably be enough.

So we need settings for every possible 68k processor at every possible speed of every possible accelerator with every speed of memory with OCS, ECS, or AGA on an Amiga 500, 600, 1000, 1200, 1500, 2000, 2500, 3000, 3000T, 4000, 4000T, CDTV or CD32 and cycle exact in both CPU and all custom chips so we can watch poorly programmed old demos. Mike might be busy for awhile. We could have new and better demos (as well as apps and games) on a faster and enhanced CPU and custom chips in a fraction of the time. Basic compatibility is good but supporting every poorly written program is ludicrous. We can patch what is important and make videos of troublesome demos.

[Dozer]

Banging the hardware doesn't have to mean incompatible. Frank Wille's SqrxzOCS game port bangs the hardware but works on 68000-68060, OCS-AGA, AmigaOS 1.x-3.x, is hard drive installable and properly exits.

I stand corrected, and need to clarify: "Demos aren't made to work on every hardwarecombination. They are made to work on the programmers computer, and will quite often not work as intended on other combinations"
Yes, democoders are somewhat lazy and in a timesqueeze, they make shortcuts. Just ask the guys behind the MindCandy DVD's (notably: http://www.demodvd.org/blog  

So we need settings for every possible 68k processor at every possible speed of every possible accelerator with every speed of memory with OCS, ECS, or AGA on an Amiga 500, 600, 1000, 1200, 1500, 2000, 2500, 3000, 3000T, 4000, 4000T, CDTV or CD32 and cycle exact in both CPU and all custom chips so we can watch poorly programmed old demos. Mike might be busy for awhile. We could have new and better demos (as well as apps and games) on a faster and enhanced CPU and custom chips in a fraction of the time. Basic compatibility is good but supporting every poorly written program is ludicrous. We can patch what is important and make videos of troublesome demos.

Not what I said. Most (still, not all) demos will run on either A500, A1200, A1200 with 68030@50MHz, A1200 with 68060@50MHz and A1200 with 68060@60MHz. (all with various ram-configs)

Patching and messing with the demos isn't something that should be done. If the hardware aims to be 100% cycle-exact, then this won't be a problem.

Again, don't get me wrong, cycle-exact is a proper troll to mess with, and I do see the problems. These are all dreams, and if I'm able to watch (and capture) some demos on the ReplayBoard, I'll be a happy camper, and my money will be well spent. Every single demo (and game or other software) that runs is a victory.

[Methanoid]

So, yes, we NEED proper settings, with cpu-selection and speed-setting to be able to watch the demos as intended

As a minimum:
7.14 MHz 68000
14.28 MHz 68020
50 MHz 68030
50 MHz 68060
66 MHz 68060 (some demos actually rely on this... )

Then again, this is to watch demos.. If all you want is to fire up the good old games, then "stock" settings would probably be enough.

We shall all look forward to you coding that then

[Dozer]

Anyway, getting back on track...

What's the latest core available for the boards already out? Mine is shipped, but according to the owner, it has a rather old core and is "just a tad unstable".

It might be the latest one publicly available, but ..

[mikej]

All the boards in the field are running the same core, which is quite old now.
I have been holding off pushing out any intermediate versions during the re-write, and the new core addresses most if not all of the stability issues. It may introduce more bugs of course, but these will be quickly squashed

/Mike

[freqmax]

Different CPU speed should be no problem but different CPU cores might be..

Oh and don't forget that the FPGA has the m68k databus by their balls, and thus can do some quite brutal "MMU"

[wrath of khan]

This is interesting me more and more. Will be fun to play around with this in the daddys case.

[Dozer]

I have been holding off pushing out any intermediate versions during the re-write, and the new core addresses most if not all of the stability issues. It may introduce more bugs of course, but these will be quickly squashed

This is rarely said, especially by me.

Mike, you are an awesome individual, thankyou for all your work :-)

[psxphill]

Different CPU speed should be no problem but different CPU cores might be..

Rough CPU speeds are not a major problem. To even begin to attempt to model every type of accelerator out there however is a huge problem. Not only do you have to simulate the cache of the CPU, but each memory board design has a different ram speed. The problem with cycle exact in this regard is that nobody really has a concept of what it means.
 
If the demo is really that timing sensitive then you have no chance at all of the Replay board to 100% accurately behave like the machine that each demo was written for, so it's not worth the effort to even try. I'd suggest either getting a video taken from the authors computer, or get them to fix the software.

[mikej]

I see the following options :

7.14 MHz 68000 (cycle accurate with original CPU and chipset)
14.28 MHz 68020 (")

xxx MHz enhanced 68020 FPGA mode - single cycle as much as possible, cache, ~100MHz
xxx MHz 68060 (>100MHz) or until it blows up.
??
/MikeJ

p.s. I'm in Beijing but I'm told a whole load of chips for Replay production just landed at my place

[NovaCoder]

Just to add my 2c

I have a real Amiga 1200 with an 060 and even I can't run all 060 demos so I don't see how anyone could expect an FPGA based system to run everything.

[freqmax]

The FPGA is the magic pill
It allows you to phase lock, manipulate bit-by-bit in realtime etc.

I think the big machines to really implement is A500 and A1200 which I suspect are the ones that are most widespread. The rest has to be configure your setup and pray (tm).

And the talk about how hard it is to code for all weird combinations of hardware is just a limitation of the number of willing coders. But with a baseline to work with it's way easier. It's easier to improve a specific chip to do something than to have to create a whole system from scratch as when you do that you have no working startpoint to work from. But rather have to make a theory and try.