FPGA for dummies

[alexh]

WinUAE runs under a defective OS. Windows is a broken OS. it's a broken and immoral OS you're running under the hood anyway. It's NOT how an Amiga looks and feels.

I'm getting the feeling you don't like Windows?

Replace WinUAE with FS-UAE and re-read

It looks and feels exactly the same. Response is the same. It isn't a total and absurd waste of resources like WinUAE solution is.

Maybe a waste of resources but it is a hell of a lot cheaper! (P.S. They don't feel the same...)

[psxphill]

When the possibility exist to model a signal system which is what the electrical circuitry really implement. The design thought process can focus on the modeling instead of explicit response times and time critical signal hooks. And when the model is correct it will "just work(tm)". Instead of having to figure out how to implement this as sequential code. So it is in the essence signal path description vs sequential code equalient.

Actually it's software emulation where you can focus on modelling the original hardware, writing code for an fpga is much harder. Ram access for instance is free with software emulation, but on an fpga you're not only emulating ram but you're having to talk to modern ram as well. Coupled with propagation delays, you might have to do things differently in the fpga than the original hardware did it to achieve the same result.
 
Most software emulation inaccuracies come down to lack of understanding about how the original hardware works. That understanding doesn't magically appear because you're writing code for an fpga.
 
Sometimes it can be due to conscious decisions to keep make it run fast enough, like if you're running an old emulator that was designed for a previous cpu generation. I don't know if that's the case with WinUAE as I haven't looked at the code, but it's been around a long time.
 
An fpga is going to be more efficient than a software emulator, cost and availability are more of an issue though. But there is no magic that means it's going to be more accurate.
 
You could for instance write a software emulator that locks all it's memory so it can't be paged out and run it at a high priority.

[mikej]

Coupled with propagation delays, you might have to do things differently in the fpga than the original hardware did it to achieve the same result.

Perhaps, but the difference is rather minor. The register in the Amiga chipset which used to get the memory contents from a DRAM read still gets exactly the same contents on the same clock cycle. The job of the new memory controller is to deliver the data faster that the original implementation so nothing else notices the difference.
 

An fpga is going to be more efficient than a software emulator, cost and availability are more of an issue though. But there is no magic that means it's going to be more accurate.

In theory perhaps, although usually you are not in control of the entire software stack.
I am curious, your 100% accurate software emulation (tricky as hardware is inherently parallel and I assume you are running a single CPU to do your emulation) - how does it actually get audio or vidio data out to an external device in real time?

/MikeJ

[psxphill]

In theory perhaps, although usually you are not in control of the entire software stack.

No, but that has pro's and con's. You can use any input device (keyboard as joystick or PS3/Xbox 360 gamepad) or any host operating system graphics card or printer driver. But that isn't an emulation accuracy issue.
 

how does it actually get audio or vidio data out to an external device in real time?

Latency is one of the drawbacks of software emulation. Whether it's noticeable is arguable.
 
A lot of modern TV's have worse latency in their up scaling and post-processing, some gamers complain and others don't. Even "game mode" on your TV doesn't guarantee you won't have any latency.
 
If you're worried about it then I'd recommend using a 1084.
 

tricky as hardware is inherently parallel and I assume you are running a single CPU to do your emulation

Today you'd use a single CPU core, but that isn't a big deal. While hardware is parallel, everything gets triggered off clock edges which effectively makes it sequential. Each clock tick might require 100 actual instructions, but think of those as propagation delays. It all works out in the end and nobody notices.

[mikej]

No, but that has pro's and con's. You can use any input device (keyboard as joystick or PS3/Xbox 360 gamepad) or any host operating system graphics card or printer driver. But that isn't an emulation accuracy issue.

As somebody who has just written a USB to Amiga mouse/keyboard interface - believe me there are accuracy issues. Perhaps to many they don't matter, and I can minimize them with a local processor running a dedicated USB stack directly connected into the FPGA which is running a secondary processor to reduce latency as much as possible.

 
 

Latency is one of the drawbacks of software emulation. Whether it's noticeable is arguable.
A lot of modern TV's have worse latency in their up scaling and post-processing, some gamers complain and others don't. Even "game mode" on your TV doesn't guarantee you won't have any latency.

I was more thinking how your software actually produces a stream of data which can be injected into a display device? Your off-the-shelf graphics card will never behave quite the same as hardware your software is emulating. Even if you sync at each horizontal blank interrupt you are not going to stay in sync as the pixel clock is not locked to the "hardware" as it is in the real (and FPGA clone) hardware.

So, there is a real measurable difference between a software emulation and an FPGA implementation.
I would challenge you (given there are no obvious bugs) to tell OR MEASURE the difference between a real A500 and the Replay board in a blind test. Put each one in a black box with the IO ports wired up and try. Now try it with a UAE.

/MikeJ

[psxphill]

Even if you sync at each horizontal blank interrupt you are not going to stay in sync as the pixel clock is not locked to the "hardware" as it is in the real (and FPGA clone) hardware.

Some graphics cards can be configured to produce the correct frame rate when running fullscreen. Otherwise you'd need to transcode it. There is an msx emulator that does 50hz to 60hz transcoding that is supposed to be very good.

[mikej]

It will never be correctly phase locked to the video generation logic though will it?
Maybe this doesn't matter, you can (and need to) emulate the whole frame buffer and calculate where the output pixel is at all times. Then you can pass this frame out once you have computed each pixel - but it will always be more laggy as you need to hold this to the next vsync. Unless the video clock is locked (it won't be) then you will always get tearing - unless you run each frame emulation a bit faster than you need to ensure you have it ready. But, then what happens with the audio?
It's get's really tricky very quickly. Trust me, I used to work designing broadcast systems.


/MikeJ

[psxphill]

but it will always be more laggy as you need to hold this to the next vsync.

Yeah, you'll get a frame of latency, but on modern displays one frame is the least of your problems.
 

Unless the video clock is locked (it won't be) then you will always get tearing

Tearing only comes from frame rate differences, pixel clock is irrelevant. You may be able to get the exact frame rate, depending on the graphics card. But if you can't then you don't have to have tearing, you can use various techniques for generating the number of frames the graphics card wants from the source video. There are people claiming good results for 50fps -> 60fps transcoding, so you can run PAL games on a TV/monitor that only supports 60fps. I don't know how well it looks for
something like 59.9hz -> 60hz (I don't know whether the Amiga outputs NTSC as 59.9fps or 60fps and whether PC monitors that say 60fps actually support 59.9fps).
 
If you need to then Powerstrip can be used to generate custom modes on the fly & it works on most graphics cards
 
Speeding up/slowing down the frame rate is simpler, but then you have to time stretch and then pitch correct the sound. You'll notice with an A/B test as the frame rate will drift eventually, you'd get accuracy issues with things like serial port output or CIA TOD clock.

[freqmax]

One technique could be to let the software emulator draw a complete screen. Once completed it's sent off to a FIFO that will display them. However any difference in frame rate will cause you to have tofew or to many. So you will have to interpolate or morph frames, that will require at minimum 2 frames and the latencies incurred. Not to mention the blurring.
Math is a bitch

So I agree with all of MikeJ:s statements.

[psxphill]

So I agree with all of MikeJ:s statements.

I understand his points, but on most computers you can set the refresh rate so it matches the Amiga's output anyway. For those cases when you can't then there are various techniques that have their own pros and cons.
 
Post processing and latency is something that you have to put up with modern TV's. So unless you're going to use a 1084 then any argument you're going to use against software emulation is going to be equally valid for an Amiga.
 
That isn't something that is generally considered part of the accuracy of the emulation, it's considered part of the human experience.
 
Feel free to say that real hardware or an FPGA based Amiga can offer a better human experience.

[kedawa]

Yeah, everything will have latency on LCD monitors, but the less the better.

I really couldn't care less if the refresh rate matches the real hardware exactly, as long as it syncs up properly.  A speed difference of less than a percent isn't going to be noticeable.

[Linde]

I don't know if it's the sound, graphics or input that is delayed (well, the sound definitely is on my systems) in WinUAE (most likely all three) but I definitely lost an important sense of immediacy when using it instead of a real computer. Of course it has the benefits of scaling in raw processing power with your processor, and the amount of peripherals you can simply emulate, but other than that I can't see any reason to use a software emulator over a hardware one.

Apparently the input delay issue have improved with the last few releases, but I'll happily wait for the Replay board before I use anything other than my A1200 for Amiga stuff again.