The online community for MiSTer FPGA enthusiasts
https://misterfpga.org/
Not fully. Multiplication and division are not cycle accurate. Their behaviour is documented, but the creator of the CPU module went for ease of implementation rather than accuracy. See viewtopic.php?p=60688#p60688 (and the next two posts).
As a bit of a C64 geek.. what's missing from the C64 core?
pgimeno wrote: ↑Sun Sep 24, 2023 4:25 pmNot fully. Multiplication and division are not cycle accurate. Their behaviour is documented, but the creator of the CPU module went for ease of implementation rather than accuracy. See viewtopic.php?p=60688#p60688 (and the next two posts).
These sorts of things are true for almost all of the FPGA CPU implementations that we use in cores, Microlabs wrote his CPU implementation years before the documentation you linked to was even completed. 'Cycle accurate' just generally means the CPU executes commands in the same number of cycles as original hardware. FPGA implementations that implement the hardware all the way down to the precise same algorithms that the original chips used are generally referred to 'cycle exact' which is probably a lot of people in this thread assume 'cycle accurate' to mean.
But that's not true for [I]MUL and [I]DIV. This fragment won't execute in the PCXT core in the same number of cycles as in a real 8088:
Code: Select all
SUB AX,AX
MOV BX,AX
MUL BX
The problem is that these two instructions vary their timing depending on their operands, so you'd have to implement the original algorithm, or some kind of lookup table, to determine the cycle count; using a constant number of cycles, like MCL86 does, won't reproduce the right timings.
Fair enough. I notice the aurhor of MCL86 cleverly mentions the CPU is "cycle accurate but nof cycle exact" 
But then I wonder how many emulators are cycle exact for the same CPU (if any).
The truth often comes in shades of gray though. Would it be fair to say that cycle accuracy is a spectrum? With that metric, are FPGA cores in general leaning nore towards accuracy than software implementations?
(that's probably hard to answer)
Newsdee wrote: ↑Sun Sep 24, 2023 11:14 pmFair enough. I notice the aurhor of MCL86 cleverly mentions the CPU is "cycle accurate but nof cycle exact"
The truth often comes in shades of gray though. Would it be fair to say that cycle accuracy is a spectrum? With that metric, are FPGA cores in general leaning nore towards accuracy than software implementations?
(that's probably hard to answer)
They sort of have to be. Because of the way signals execute massively parallel in an FPGA core the more signals deviate from the original hardware the less things will work correctly.
woaw , i seem to have hit a hot spot here, let me start by thanking everyone for the many and very elaborate replies that was a lot more than i hoped for.
@ Xbytez , armakuni, rhester72 (but also everyone else) : yes, i suppose in a way i was misled by youtubers looking for facebook likes and the thing you (and the others) said here cleared out a lot for me . I got one because of the atari ST and amiga (and hopefully Falcon) i cant possibly afford or if i could place here (that goes for most other consoles, i simply wouldnt have the space)
After a week of checking it i cant say i regret it tho, the psu eats 10 watts, compared to running something like Hatari on a pc that eats an easy 150 to 300 with and 850w peak psu in it thats already a massive bonus, the fact that its about the size of one soapbar box is another and it seems to slot wireless dongles without asking questions or drivers it is a bit of a magic box to me.
One thing is tho (and i see someone claim there the A1200 runs faster than the real thing, which is a bit sad imo ...) for instance trying my hand at final fantasy ( one ) on a NES i was playing something in pal mode and only found out when i saw a youtube video playing the battle music that the system ran the whole thing at about 90% speed compared to the real one, it also took me quite some tinkering to get rid of the top and bottom 2 centimeter tearing on my HD screen (dont have a crt back ... yet , i hope)
So the bonus is having a box of emulators the size of a soap bar that eats only 10 watts, which is fair enough but they might say that on youtube while hyping their toy too lol , its fairly young and hard to say what will happen if newer boards gain traction (tho i assume not everyone has the dough ready to fork out every new revision as if you were following up on Nvidia or AMD to keep your pc at 140 fps every year)
I took it on me to start collecting "post 2020" amiga and atari ST(e) demos in mister-supported formats (or convert them where i can) b/c the main idea for me was programming on the old machine (ST) i used to have and always wanted an Amiga and definitely a falcon. Being able to finally have an authentic experience (close to) playing stuff like FF1 on a "real NES" is a bonus and i finally saved madonna from the skinheads after 35 years at what would have been the equivalent of 1000s of francs (for all the money the kid put into it they might as well send me an original arcade for free) and i'll put up the list to the webpages later when there's at least 20-50 on it, but i still dont have a means to compare to the original (just like i was playing NES at 90% speed and i didnt even know it, i just though that was how it must have felt back then
any more comments and elaborations on the topic would be greatlly appreciated but so far its already more than i could ask for and i can position it a lot better now. I also thought up the silly notion that what i have here is a thing that allows me to get into electronics and breadboarding without the need to spend my meagre funds on components, expensive soldering kits and leftover throwaway garbage, 6502 and other chips and can just try to create virtual ghosts inthere (once i wrap my head around it a little better) so i can do "HEY look at the blinking led !" and feel like a hi schooler
and i wondered how possible it would be to have the thing do an android or ithing you can use to get on the crAppstore(s) and as a chatterbox that runs line, wechat and all those other things you use once and then leave on it to take up space and say to yourselg omg this thing has so many applications (lol) tho i assume that would take some kind of usb2sim slotter or some kind of phone-number spoofing device or software
at any rate, my enthusiasm hasnt been curbed and im looking forward to see how this thing evolves, its the closest ill get to 10 or 100 thousands of euros in real hw anyway
THANKS, heartfelt, for all the very clear and useful replies, i can see this community has drive, which points at longevity.
(the only hard machine i have is an original c64 btw, sid6581 kernel rev3 sideways fuse) "the breadbin" b/c thats the exact same one the kid had in the 1980s , i saw A1200 go for $5500 earlier , an ST "not tested" for $1000 + and a Falcon for around $3200 , as much as id like that those prices are absurd to me and realistically not doable anyway
So i'll be on this train, thanks everyone again, i really didnt expect this kind of explosion in replies, my heart is warmed 
Syntax Error wrote: ↑Mon Sep 25, 2023 2:26 amI also thought up the silly notion that what i have here is a thing that allows me to get into electronics and breadboarding without the need to spend my meagre funds on components, expensive soldering kits and leftover throwaway garbage, 6502 and other chips and can just try to create virtual ghosts inthere (once i wrap my head around it a little better) so i can do "HEY look at the blinking led !" and feel like a hi schooler
Au contraire! That is not a silly notion, the DE-10 is very literally a development board designed to teach FPGA to newcomers. So you digging into FPGA development, even to make a single LED blink, is fulfilling the very purpose of the board existence!
I'm sure the ST core is solid enough for development, although even back in the day it was common to develop in a more powerful machine. Of course the core can still be a good check to estimate if something will work on real hardware
The ST gets a bad rep from Amiga lovers but there are some unique games on it (I personally like Sundog); wish you the best of luck to make some cool new stuff for it! (we are getting off topic, maybe best to go to am
n ST thread)
PCEm is cycle-accurate. It correctly implements the MUL and DIV algorithm and cycle count.
I think one major aspect of MiSTer that doesn't get much attention is its user experience. It's so painless and simple, Update All literally does everything for you as far as setup goes. Starting a game is as simple as turning it on and selecting a game, and another thing... that startup is instant. There's no lengthy bootup process, there's no hefty OS to load in the background. It's just like your console of old, you turn it on and away you go.
Especially when combined with something like a MiSTercade, this makes MiSTer the absolute most ideal product available for use in a multi-game arcade cabinet, it turns on as soon as you start the cabinet, and functions just like the original arcade PCB.
And MiSTer is also incredibly flexible too. Things like Super Attract Mode are a Godsend for people sticking these things inside arcade cabinets; you can have the MiSTer auto-load a specific game on startup without ever going into the menu, and even have the cabinet automatically cycle between games! There are even solutions that let you use NFC cards to swap games without ever showing a single menu (https://www.reddit.com/r/fpgagaming/com ... e_edition/)! It's amazing! You just can't get that kind of experience with any other solution out there.
You can use any controller you want (be it wired, wireless, or even original hardware via SNAC), and there is basically no setup required to get it working. You can run the thing on a modern HDMI display, or even an old CRT, or even both at the same time! And there's no lag whatsoever.
It all Just Works. And that's an experience you cannot get anywhere else.
So even though software emulation may be able to match the accuracy of an FPGA core, its MiSTer counterpart still offers value that cannot be replicated elsewhere.
There is nothing really missing apart from Easy flash saves and cycle accurate 1541 emulation (this is not that important imho)
The core has some edge case issues still in the VIC-II for example but are really only evident in some scene demos
This is not quite correct though. An FPGA is a real-time computing platform. A CPU, even without an OS, will never be a true real-time platform. True, you can get very, very close with software running on a CPU (even with an OS). I cannot tell the difference between bsnes / higan and MiSTer SNES. But the MiSTer will always be "more accurate" in the respect that all of its operations will always complete in a pre-determined amount of time -- the PC CPU is just approximating the same thing (very well in the case of bsnes and some other "cycle-accurate" software emulators).
mcf81 wrote: ↑Mon Sep 25, 2023 10:44 pmThis is not quite correct though. An FPGA is a real-time computing platform. A CPU, even without an OS, will never be a true real-time platform. True, you can get very, very close with software running on a CPU (even with an OS). I cannot tell the difference between bsnes / higan and MiSTer SNES. But the MiSTer will always be "more accurate" in the respect that all of its operations will always complete in a pre-determined amount of time -- the PC CPU is just approximating the same thing (very well in the case of bsnes and some other "cycle-accurate" software emulators).
This is also not quite correct. The fitter has to make certain compromises at compile time to produce something "close enough" to what the VHDL specified that doesn't violate timing constraints - but the timing is never exact (except with dead-simple circuit simulations).
Given that software emulators with enough horsepower spend a considerable amount of their time just waiting and have nanosecond precision, timing accuracy in software is actually very rarely a problem at all.
Please witness smooth scrolling on any given PC with CRU in play and you will immediately see exactly what I mean. That isn't possible with variable timing down to the microsecond level, which is way more than necessary for 80s and 90s hardware.
I would just say, that FPGA simulation of hardware does have it's place, and would boil it down to SNAC and controller latency, and display output lag.
This is more true especially on older systems and arcade machines. No PC emulator could possibly eliminate controller input lag, and that drastically reduces playability of some titles to the extent of being completely unplayable or very annoying.
The question for me is not about being 100% cycle exact and accurate, because that is very often not possible, and depends on the extent how you look at the subject and on need to implement it on FPGA. That being said, there are critical components, parts of cores and whole cores, which are exact and true to hardware, and that contributes to fantastic compatibility of majority of cores.
rhester72 wrote: ↑Tue Sep 26, 2023 12:19 ammcf81 wrote: ↑Mon Sep 25, 2023 10:44 pmThis is not quite correct though. An FPGA is a real-time computing platform. A CPU, even without an OS, will never be a true real-time platform. True, you can get very, very close with software running on a CPU (even with an OS). I cannot tell the difference between bsnes / higan and MiSTer SNES. But the MiSTer will always be "more accurate" in the respect that all of its operations will always complete in a pre-determined amount of time -- the PC CPU is just approximating the same thing (very well in the case of bsnes and some other "cycle-accurate" software emulators).
This is also not quite correct. The fitter has to make certain compromises at compile time to produce something "close enough" to what the VHDL specified that doesn't violate timing constraints - but the timing is never exact (except with dead-simple circuit simulations).
Given that software emulators with enough horsepower spend a considerable amount of their time just waiting and have nanosecond precision, timing accuracy in software is actually very rarely a problem at all.
Please witness smooth scrolling on any given PC with CRU in play and you will immediately see exactly what I mean. That isn't possible with variable timing down to the microsecond level, which is way more than necessary for 80s and 90s hardware.
On top of this, the architecture of the FPGA used in the MiSTer is never going to 1:1 represent any of the original logic in any physical sense anyways.
See page 18-19 of the datasheet for the ALM description and Figure 8 for the simple block diagram:
https://mm.digikey.com/Volume0/opasdata ... ew_Web.pdf
There are no tri-state buffers, but you can write in a tri-state buffer's behavior in VHDL, just it won't ever physically become that in synthesis.
There are no true asynchronous latches, but you can write in asynchronous latches in Verilog, but synthesis will make it an approximation that tries to work on FPGA (async latches aren't great to use on FPGA though, so a lot of devs avoids using them when possible, even if the original hardware used them).
This thread so far has been one of the most informative on the forums.
It's nice to read a thread full of technical discussion with no petty arguments.
It's a bit like overhearing a really interesting conversation that you learn lots from 
Even hardware revisions of OG consoles and computers were not cycle or behavior accurate to their predecessors
Famous examples are the SiD chip revisions (the original ASIC was never remade exactly), 8088 and x86 clone CPUs, Megadrive/Genesis sound chips, etc.
This is why projects like Artemio's MDFourier are important. It's an analysis tool comparing the audio output of your device to pre-tested patterns from real hardware: https://junkerhq.net/MDFourier/
Taking that approach shifts the focus from a dubious "is it equal to the picosecond" to "is there any actual measurable difference" (and if so, what) .
Newsdee wrote: ↑Thu Sep 28, 2023 12:40 amEven hardware revisions of OG consoles and computers were not cycle or behavior accurate to their predecessors
Famous examples are the SiD chip revisions (the original ASIC was never remade exactly), 8088 and x86 clone CPUs, Megadrive/Genesis sound chips, etc.
This is why projects like Artemio's MDFourier are important. It's an analysis tool comparing the audio output of your device to pre-tested patterns from real hardware: https://junkerhq.net/MDFourier/
Taking that approach shifts the focus from a dubious "is it equal to the picosecond" to "is there any actual measurable difference" (and if so, what) .
The 8580 SID is merely a fixed version of the 6581. The analogue filters are the same on every chip and they fixed the flaw that allowed sample playback on the 6581.
The samples still play but at very low volume this can be restored via the simple digifix
HerrBerzerk wrote: ↑Sat Sep 23, 2023 8:17 amFoxbatStargazer wrote: ↑Mon Sep 04, 2023 7:12 amMostly agree for Mister overall but the A1200 example is well outside the bounds of "good enough." Its much faster than the real thing, like a turbo switch you can't shut off, which causes much software to run very differently.
In another thread it is written that the Amiga1200 core is running too fast... somebody know if that is true?
It doesn’t matter that the 68020 is faster than the original, no games or productivity software requires cycle accuracy from the 32-bit Amigas. Also remember that that generation of Amigas also shipped with the faster 68EC030 and 68040 CPUs in the Amiga 4000. The bigger problem is that there are still some unresolved bugs in the ECS/AGA chipsets, but these are pretty rare. Mostly triggered by demos pushing the hardware in unexpected ways.
If you switch it to the Amiga 500 (68000) implementation, it should be (close to) cycle accurate on the CPU front, but again — there are still some unresolved bugs in the custom chips, as far as I can tell.
Then there’s the issue of some WHDLoad containers still having bugs, but this would reproduce on original hardware too. This is the more common issue.
If you switch to e.g. the “Amiga 500” MGL preset we have in AmigaVision, you get an extremely accurate Amiga that runs most games/apps that don’t use the AGA chipset, the downside being that you have to run them from floppy images. Personally, I only use this for demo scene productions.
Cycle accurate is not really an important benchmark in and of itself. Compatibility, feature-completeness and experience fidelity of the whole setup are much more relevant to focus on.
E.g. while minimig core is close to cycle accurate for the most common of the amiga chipsets, the MiSTer framework doesn’t support all of the io features of the original hardware. For example you can’t use applications that require multi-mouse input (like multiplayer Lemmings and Settlers).
Speed might not be the most important factor but it is still important. I'd like to be able to fire up A1200 and have it run at exactly the same speed as original hardware, just for the sake of it in the first place, but also for historical accuracy.
ToothbrushThreepwood wrote: ↑Thu Oct 05, 2023 7:29 amE.g. while minimig core is close to cycle accurate for the most common of the amiga chipsets, the MiSTer framework doesn’t support all of the io features of the original hardware. For example you can’t use applications that require multi-mouse input (like multiplayer Lemmings and Settlers).
Agreed that features like this are more important for the Amiga core. That some games cannot be played as intended is a much more important thing to focus development on.
There is really no “one true” A1200 speed anyway. Did you add extra RAM (which a large contingent of people did, similar to the Amiga 500)? Massively faster computer. Did you add an accelerator card with that RAM? Massively different again. Did you have the HD built-in or not? Very different. It’s an academic exercise at best. 
Of course there is - it's the speed of bare bones A1200. Any add ons people used later are completely different matter, just like it'd be with any other machine and subsequent MiSTer cores.
That's not to say other features are not important, of course, but they don't have to be mutually exclusive.
Speaking of cycles, this is another benefit of FPGA: all games run at full original hardware speed, regardless how many graphics effects and hardware tricks they use. The cycles are executed all the time in realtime, with real clock signals to the emulated chips, even if nothing important happens. Everything keeps running in lock step.
With FPGA I don’t have to worry that maybe I will find a game with MORE slowdown than original hardware. It is guaranteed by the architecture that all games run accurately just like on real hardware, regardless how much they tax the original hardware.
With software emulators, on the contrary, performance is game dependent.
Software emulators don’t normally execute every cycle on every chip, even if they are cycle accurate. They normally skip many cycles if nothing important happens during them, allowing them to run fast even though they have no parallelism like an FPGA. This works great for most games. But when a game makes use of every cycle of cpu and custom chip effects available, the emulator’s usage of the host CPU shoots up because it can’t skip so many cycles. It might not be able to keep up, especially on handhelds and small computers. For example, try Yuzu with Fast RMX. It slows down even the fastest computer. Most other games run perfectly.
On software emulators, often most games run great or perfect, but some games that use many graphics effects will cause the emulator to slow down, because the CPU usage becomes too high to emulate those games at full speed. For example, on my Vita most SNES games run at full speed, but Yoshi’s Island has slow down. On my Raspberry Pi, most Amiga games run at full speed, but Jim Power causes slowdown, because it uses many of the graphical capabilities of the Amiga and is coded bare metal to take advantage of the custom chips. On my Windows PC Overkill on the Amiga requires enabling sub pixel accuracy for accurate scrolling and causes huge slowdown of the emulator. With software emulators I can often find such one or two games that bring the emulator to its knees. Sometimes a game runs fine but when you ignite a smart bomb, suddenly there’s more slowdown than in the original game, because the smart bomb visual effect is hard to emulate and causes more host CPU usage.
With FPGA there’s no such worries that maybe a certain game will bring it to its knees.
It is not a fundamental issue, but it is important for me psychologically that I don’t have to constantly worry “will this or that game slow it down beyond the original hardware slow down that might exist, but is accurate”.
rsn8887 wrote: ↑Fri Oct 06, 2023 4:24 pmSpeaking of cycles, this is another benefit of FPGA: all games run at full speed, regardless how many graphics effects and hardware tricks they use. The cycles are executed all the time in realtime, with real clock signals to the emulated chips, even if nothing important happens. Everything keeps running in lock step.
With FPGA I don’t have to worry that maybe I will find a game with slowdown. It is guaranteed by the architecture that all games run perfectly, regardless how much they tax the original hardware.
...
Erm...no. So much no.
If a game/software you are executing on FPGA wants/requires more resources than the simulated processor, it's going to choke and slow down, just like original hardware. Metal Slug 2 on Neo-Geo is a fantastic example of this, but there are hundreds of others.
FPGA has a lot going for it...this is NOT one.
rhester72 wrote: ↑Fri Oct 06, 2023 7:53 pmErm...no. So much no.
If a game/software you are executing on FPGA wants/requires more resources than the simulated processor, it's going to choke and slow down, just like original hardware. Metal Slug 2 on Neo-Geo is a fantastic example of this, but there are hundreds of others.
FPGA has a lot going for it...this is NOT one.
If a poorly-written game cannot complete its processing on the original hardware within the given time window of a television display field, then that's an issue with the game. A properly-written core will behave the same way as the original hardware in such case, resulting in the same issues. It is possible to write a core with additional CPU power to compensate for the poorly-written game, but this would not match the spec of the original system, and may have side-effects which are unwanted on that game or any other game (because it would no longer be "cycle accurate" in that configuration).
There are indeed cores with features that never existed on the original hardware, but I believe that is outside the scope of the original purpose of this thread.
I suppose I should clarify, in that rhester72's response was referring to a statement:
"With FPGA I don’t have to worry that maybe I will find a game with slowdown. It is guaranteed by the architecture that all games run perfectly, regardless how much they tax the original hardware."
rhester72 was indeed correct to say that there are indeed games which don't work properly but were released anyway.
rhester72 wrote: ↑Fri Oct 06, 2023 7:53 pmrsn8887 wrote: ↑Fri Oct 06, 2023 4:24 pmSpeaking of cycles, this is another benefit of FPGA: all games run at full speed, regardless how many graphics effects and hardware tricks they use. The cycles are executed all the time in realtime, with real clock signals to the emulated chips, even if nothing important happens. Everything keeps running in lock step.
With FPGA I don’t have to worry that maybe I will find a game with slowdown. It is guaranteed by the architecture that all games run perfectly, regardless how much they tax the original hardware.
...
Erm...no. So much no.
If a game/software you are executing on FPGA wants/requires more resources than the simulated processor, it's going to choke and slow down, just like original hardware. Metal Slug 2 on Neo-Geo is a fantastic example of this, but there are hundreds of others.
FPGA has a lot going for it...this is NOT one.
Sorry, I was using confusing wording. With "slowdown" I meant MORE slowdown compared to original hardware. I edited my post to clarify that. Of course, games on FPGA will slowdown the same way as on original hardware. I love that. I just wanted to say that software emulators sometimes, with certain games, slow down even more than original hardware, depending on if you run them on a small computer like RPi. My main point was that this additional slowdown can happen with software emulators in a game-dependent way. So 100 games can run perfectly fine just like on original hardware. But then you launch one certain game and it slows the whole emulator down, so audio starts to crackle, it all slows down, a lot more compared to real hardware. THIS annoying effect doesn't happen on FPGA, and I love that this doesn't happen on FPGA.
I think we all have launched some game on a software emulator, and suddenly with this one game the audio started crackling, the whole software emulator slowed down because the software emulator couldn't keep up with the game. While other games ran probably fine. Then you have to go into the settings, maybe disable vsync, disable runahead, maybe increase max_swapchain, increasing lag, just to make this one game run at the original hardware speed. This annoying experience doesn't happen with FPGA cores. I love that. There's less fiddling/optimizing options the user has to do on FPGA. "It just works," and especially, and this was the point I tried to make, the user doesn't have to optimize options for certain specific games.
@rsn8887 points well taken and agreed, to a degree. PSX, for example, still experiences limited issues related to the FPGA switching just not being able to keep up with reality, causing interesting artifacts like failed replays in Gran Turismo. Those are edge cases, for sure, but really no different than processing power limits on the RPi 3 (for example) causing other minor breakage on a small subset of games.
The point I'm driving at here is that, due to gate switching delay, it's actually more or less the same issue on traditional CPUs and software and FPGA, just manifested differently. (The same can and does happen, for example, with RAM latency...and that's the whole reason for the dual RAM stick shenanigans.)
There are some cores that overclock (e.g. SNES with SuperFX) or that allow removing some hardware limitations (hardware sprite flickering).
So yes, there are some cases where an FPGA core can enhance the original.