Previous Thread
Next Thread
Print Thread
Page 2 of 6 1 2 3 4 5 6
Re: FireFly on the ZX Spectrum - Missing graphics [Re: geecab] #112431
02/01/18 10:48 AM
02/01/18 10:48 AM
Joined: Mar 2013
Posts: 252
I
ICEknight Offline
Senior Member
ICEknight  Offline
Senior Member
I
Joined: Mar 2013
Posts: 252
César Hernández, the author of ZEsarUX (which I think is the most compatible Spectrum emulator out there) just told me that, even though he's really busy with his emulator and can't work directly on improving MAME's driver, he'd gladly help you guys with any answers you may need regarding the contended memory.

Any interested parties, just PM me for the email address if you don't have it already.


LCD artwork cleanups: https://mega.nz/#F!uFYSzK7S!U-lJon9jsqyoCX_3y7_KLA
Re: FireFly on the ZX Spectrum - Missing graphics [Re: geecab] #112432
02/01/18 12:40 PM
02/01/18 12:40 PM
Joined: Mar 2001
Posts: 15,988
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 15,988
USA
As I understand it the problem isn't understanding the contended memory so much as needing a cycle-by-cycle Z80 core.

Re: FireFly on the ZX Spectrum - Missing graphics [Re: R. Belmont] #112433
02/01/18 01:12 PM
02/01/18 01:12 PM
Joined: May 2004
Posts: 1,509
H
Haze Offline
Very Senior Member
Haze  Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,509
Originally Posted by R. Belmont
As I understand it the problem isn't understanding the contended memory so much as needing a cycle-by-cycle Z80 core.


Well more to the point, you can't *accurately* emulate the contented memory without a cycle-by-cycle z80 core that can be interrupted / paused during any stage, either either fetching opcodes / oprands or executing them.

MAME doesn't have such a Z80 core, and considering how widely the Z80 is used and the potential for breakage, it would be a tremendous undertaking, it's potentially one of the biggest challenges in MAME.

Until *any* byte access the Z80 makes can be checked if it's a contented address, if it's a contended address, check if the ULA is accessing it, and if it is, stop the z80 in it's tracks before it even reads/writes that address, only resuming when the ULA is not accessing it, the Spectrum can't be accurate.

Since MAME doesn't allow that level of interruption (you'd basically need a speculative 'is the bus at this address available?' read before every regular z80read/write) then we can't do much. (In that sense it's probably even messier than just cycle-by-cycle, because the Z80 doesn't pause until the Z80 actually attempts to access contended memory, if you're running from non-contended addresses and not touching any contended ram / port, you get full speed)

The spectrum is a VERY simple system, but in the architecture MAME has this is a very big issue since it was never considered nearly 20 years ago when MAME started and now good support for it has to be worked in without breaking everything else.

Re: FireFly on the ZX Spectrum - Missing graphics [Re: geecab] #112434
02/01/18 01:28 PM
02/01/18 01:28 PM
Joined: Mar 2001
Posts: 15,988
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 15,988
USA
It wouldn't need to be that complicated, just have the first-level address handler be (0000, ffff) (spectrum_r, spectrum_w) and it can check for ULA interference and then dispatch through a bankdev object for the I/O and stuff.

Re: FireFly on the ZX Spectrum - Missing graphics [Re: R. Belmont] #112435
02/01/18 01:35 PM
02/01/18 01:35 PM
Joined: May 2004
Posts: 1,509
H
Haze Offline
Very Senior Member
Haze  Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,509
Originally Posted by R. Belmont
It wouldn't need to be that complicated, just have the first-level address handler be (0000, ffff) (spectrum_r, spectrum_w) and it can check for ULA interference and then dispatch through a bankdev object for the I/O and stuff.


Right, but you'd still need the speculative read or some kind of 'I'm going to read/write' callback, because you need to stop the actual read from happening until the rest of the hardware is ready.

Even the cycle-by-cycle cores in MAME right now don't give you that afaik, there's no "I'm asserting these address lines" stage before the "I'm reading/writing data using these address lines" and I believe it's in that gap where the Z80 would pause.

At least that's my understanding of it.

Re: FireFly on the ZX Spectrum - Missing graphics [Re: geecab] #112436
02/01/18 02:07 PM
02/01/18 02:07 PM
Joined: May 2004
Posts: 856
Germany
D
Duke Offline
Senior Member
Duke  Offline
Senior Member
D
Joined: May 2004
Posts: 856
Germany
We do have (limited) support for that, see SETOFFSET_MEMBER. It's only used by some TI stuff so far.

Re: FireFly on the ZX Spectrum - Missing graphics [Re: geecab] #112437
02/01/18 02:13 PM
02/01/18 02:13 PM
Joined: Mar 2001
Posts: 15,988
USA
R
R. Belmont Offline
Very Senior Member
R. Belmont  Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 15,988
USA
You don't need to do the TI thing (which performance-penalizes even un-contended accesses), you can just make the Z80 so if HALT gets pulled by a read or write handler it backs up that cycle and halts.

Re: FireFly on the ZX Spectrum - Missing graphics [Re: R. Belmont] #112438
02/01/18 02:17 PM
02/01/18 02:17 PM
Joined: May 2004
Posts: 1,509
H
Haze Offline
Very Senior Member
Haze  Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,509
Originally Posted by R. Belmont
You don't need to do the TI thing (which performance-penalizes even un-contended accesses), you can just make the Z80 so if HALT gets pulled by a read or write handler it backs up that cycle and halts.


but then a write that wouldn't happen has already happened.
or a read that wouldn't happen has already happened.

you can rewind time to before they happened, but they still happened, that's why it needs to be speculative, not the actual operation, the actual operation can't be allowed to happen if the Z80 is frozen.

it might 'work' for most cases, but it's still a hack, and could still have side-effects. I suspect those hacks exist for this reason, because MAME can't handle it properly for the cores where it gets used.

since you're working with screens and raster timings here those things would directly affect how demos run. If you allow a write to happen, then have the CPU pause, that data, used for a screen effect, is going to be in VRAM not next time the ULA frees it, but before/during, which if you're doing accurate ULA timings, means the ULA might pull the incorrect data and the effect will appear a few pixels too early as RAM has already changed.

the fundamental problem, or at least the way I see it, is that the asserting of the address lines, and the actual read/write operation are two separate actions.

it's a similar theory those fast ARM cartridges for old systems work on, they can see the address lines being asserted as a separate operation before the data is read / written, and in those cases the ARM is fast enough to execute an entire block of code to get the data before it needs to be pushed out without slowing down the CPU.

MAME doesn't differentiate between the two stages of the operation. For things like this to work, without hacks, MAME needs to.

So yeah, the SETOFFSET_MEMBER type thing, prior to any access, be it readmem/writemem/readport/writeport/opcode fetch, as a separate instruction stage, including performance hit, absolutely *is* needed. This needs to be in conjunction with another callback to tell the CPU that the address it just tried to access is now free so that it can try again (due to timings, I guess it would need to check again if it was free incase something else stole it in the meantime)

I guess this is also really why you need code generators generating the CPU .cpp code too, because ideally you'd be able to generate fast/slow paths in the Z80 core, because I don't really think you want this level of accuracy for the one embedded in the Dreamcast for instance ;-) You'd want to be able to generate a version with all the checks / callbacks, and one without and pick which codepath to use depending on if the driver attempts to install callback handlers for address accesses.

I suppose you'd call this 'signal accurate' rather than 'cycle accurate' ?


Re: FireFly on the ZX Spectrum - Missing graphics [Re: geecab] #112443
02/01/18 09:19 PM
02/01/18 09:19 PM
Joined: Feb 2018
Posts: 4
C
Cesar Hernandez Offline
Member
Cesar Hernandez  Offline
Member
C
Joined: Feb 2018
Posts: 4
You don’t need an accurate cycle z80 emulation
On my ZEsarUX emulator I don’t have it and a emulate contended memory and hi res color effects
You only need to have a table with contended memory delays and lookup on it every time you do a memory access. It’s really simple
However, there are some opcodes, like ldir, that makes more than 1 lookup in the same opcode, if you emulate them, you will have a perfect emulation. If not, you will have a nearly perfect emulation, which is enough to see the majority of these games without flickering

Re: FireFly on the ZX Spectrum - Missing graphics [Re: geecab] #112444
02/01/18 09:26 PM
02/01/18 09:26 PM
Joined: May 2004
Posts: 1,509
H
Haze Offline
Very Senior Member
Haze  Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,509
I guess it depends how correct you want to do it.

If you want to do it how the hardware works, in a way where there's no way for the emulated software to detect it, I think you would have to do it as I said.

Either way, surely an opcode fetch is a 'memory access' so you'd still need to be able to pause on every opcode fetch if you were running code from contended memory, that alone is an issue for MAME. Unless you're just adding up the cycles for each memory access then pausing for that long at the next given opporunity (which would be after a complete opcode has executed) however I don't see how that would actually be accurate unless it's coincidentally designed that the delays never fall mid-opcode?

If somebody has a solution for MAME which will work for all cases and be undetectable by software running on the Speccy I'd love to see it, maybe I've just over thought the problem and assumed all the worst cases that in reality don't happen. I know the MSX drivers in MAME have a similar 'delay table' approach (machine/msx.cpp actually it just looks like a gross table of custom opcode timings that have added waitstates) but I believe there is demo software that breaks those with ease.

Other drivers like the Sega System 1 driver seem to have to run the Z80 with a multiplied clock in order to do some kind of custom delay thing too, that I don't quite understand (Wonderboy really doesn't have a 20Mhz Z80)


Last edited by Haze; 02/01/18 09:35 PM.
Page 2 of 6 1 2 3 4 5 6

Who's Online Now
1 registered members (Carbon), 46 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
Shout Box
Forum Statistics
Forums9
Topics8,566
Posts111,888
Members4,805
Most Online225
May 26th, 2014
Powered by UBB.threads™ PHP Forum Software 7.6.1.1
(Release build 20180111)
Page Time: 0.044s Queries: 14 (0.024s) Memory: 5.7322 MB (Peak: 5.9546 MB) Zlib enabled. Server Time: 2018-08-17 13:32:13 UTC