Previous Thread
Next Thread
Print Thread
Page 3 of 6 1 2 3 4 5 6
#112445 - 02/01/18 09:30 PM Re: FireFly on the ZX Spectrum - Missing graphics [Re: Haze]  
Joined: Mar 2001
Posts: 15,933
R. Belmont Offline
R. Belmont  Offline

Very Senior Member

Joined: Mar 2001
Posts: 15,933
USA
Originally Posted by Haze
but then a write that wouldn't happen has already happened.
or a read that wouldn't happen has already happened.


No, they wouldn't. The read/write handler would simply not commit the actual read or write, set HALT, and bail. When the Z80 resumes it will redo the read/write and it'll actually go through at the right time.

#112449 - 02/01/18 11:16 PM Re: FireFly on the ZX Spectrum - Missing graphics [Re: R. Belmont]  
Joined: May 2004
Posts: 1,498
Haze Offline
Very Senior Member
Haze  Offline
Very Senior Member

Joined: May 2004
Posts: 1,498
Originally Posted by R. Belmont
Originally Posted by Haze
but then a write that wouldn't happen has already happened.
or a read that wouldn't happen has already happened.


No, they wouldn't. The read/write handler would simply not commit the actual read or write, set HALT, and bail. When the Z80 resumes it will redo the read/write and it'll actually go through at the right time.


I'm not following at all.

As soon as the Z80 core is at the stage of knowing which address it's going to fetch / write to, that fetch / write happens, there's no way to halt in the middle of it. By the time you know, it's too late unless you're suggesting returning a dummy value, or noping the write in the handler, then rewinding.. but then we really are into hacks on hacks...

That would also get messy during opcode fetches / decodes.

Maybe I really just am overthinking it and letting the underlying grossness of it all bother me, but returning dummy values and expecting cpu cores to travel back in time sounds like a stack of plates I don't want to be around..


#112450 - 02/01/18 11:33 PM Re: FireFly on the ZX Spectrum - Missing graphics [Re: Haze]  
Joined: Feb 2018
Posts: 4
Cesar Hernandez Offline
Member
Cesar Hernandez  Offline
Member

Joined: Feb 2018
Posts: 4
Originally Posted by Haze
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?






Well I don't know the mame internal code, but I will explain on a simple way what I do on ZEsarUX: I have a t-states counter, every frame (1/50s) of the spectrum means 69888 frames (48k model) and every memory access or opcode fetch sums t-states. For example a NOP operation counts 4 t-states. When I read a memory address which has contention, I sum the value of the contention (values are from 0 to 7 if I remember well). So for example if I that NOP opcode is in contended memory, it could last 4+7 t-states(I'm inventing the 7 value). So that NOP will last 11 t-states instead of the uncontended and normal 4 t-states. Just as simple as that, I'm not adding "pauses" here, just making opcodes last longer (exactly what the z80 on the speccy does)

Cheers

#112451 - 02/01/18 11:49 PM Re: FireFly on the ZX Spectrum - Missing graphics [Re: geecab]  
Joined: May 2004
Posts: 1,498
Haze Offline
Very Senior Member
Haze  Offline
Very Senior Member

Joined: May 2004
Posts: 1,498
right, you're making the opcode last longer

but in that opcode there are multiple stages, does the pattern never mean that the read part of an opcode is contended, but the write never is?

are you executing the opcode actions before or after decreasing the states value? if you're executing the actions of the opcode, then acting as if it took longer than it did, rather than causing a delay in the exection of the opcode due to it not being allowed to access the ram doesn't that mean you're going to be putting a value in ram, or reading a value from ram too early?

maybe the suggested workarounds for the spectrum are already taking all this into account by shifting when the waits happen or something...

I mean I can understand the theory of just adding the extra t-states as a workaround, but in my head at least it's going to cause some slight imperfections in when the actual memory changes compared to the real system.

I believe t-states are what MAME calls icounts anyway, but icount deductions happen after the opcode has been executed which would surely result in premature reads/writes if you consider the whole system. Doing it the way you suggest would actually be really easy in MAME, because we can just burn a few cycles if an access is contended, I'm just not convinced it would be 100% accurate especially not as time wouldn't be advancing as the cycles were burned so any opcode (including fetch) would either be fully contended, or not contended at all with a fully contented one doing a full read/write cycle obviously burning more than a nop that doesn't have any read/write beyond the opcode fetch. It would have no way of working where a read/write opcode fell across the boundary of a contended period.

I'd love to see the Spectrum driver in MAME run all the software and demos more than practically anybody else here, I've just never felt comfortable in adding it because of all these "what if" scenarios in my head for ways in which any code I write might break, however if I have completely misunderstood something, and it can be done without any issues at all I'd absolutely love to see somebody get it right. In part, that's because I'd actually love to try and develop some Speccy stuff of my own, but MAME is the environment in which I'm most comfortable working.

#112452 - 02/02/18 12:36 AM Re: FireFly on the ZX Spectrum - Missing graphics [Re: Haze]  
Joined: Mar 2001
Posts: 15,933
R. Belmont Offline
R. Belmont  Offline

Very Senior Member

Joined: Mar 2001
Posts: 15,933
USA
Originally Posted by Haze
I'm not following at all.

As soon as the Z80 core is at the stage of knowing which address it's going to fetch / write to, that fetch / write happens, there's no way to halt in the middle of it. By the time you know, it's too late unless you're suggesting returning a dummy value, or noping the write in the handler, then rewinding.. but then we really are into hacks on hacks..


You're running the Z80 cycle-per-cycle. It executes a load. Time gets to the exact cycle when the load or store happens. The read/write handler calls m_maincpu->HALT() and returns a dummy value on reads / doesn't write the value on writes. The Z80 immediately exits back to the scheduler and backs the current sub-cycle up 1, and when the ULA is finished you restart the Z80 minus however many cycles the ULA took (I assume the ULA is doing standard DMA where its cycles count against the CPU). It executes the read/write again, and this time they actually happen. For an opcode fetch it's even simpler, although you'd need to track if what got halted was a fetch or not.

#112453 - 02/02/18 12:38 AM Re: FireFly on the ZX Spectrum - Missing graphics [Re: geecab]  
Joined: Mar 2001
Posts: 15,933
R. Belmont Offline
R. Belmont  Offline

Very Senior Member

Joined: Mar 2001
Posts: 15,933
USA
And if what Cesar says works, we can just m_maincpu->adjust_icount(ula_cycles) and get much better compatibility for cheap.

#112455 - 02/02/18 05:39 AM Re: FireFly on the ZX Spectrum - Missing graphics [Re: geecab]  
Joined: Feb 2018
Posts: 4
Cesar Hernandez Offline
Member
Cesar Hernandez  Offline
Member

Joined: Feb 2018
Posts: 4
Of course it works wink
I’m proposing a easy way to have a nearly 95% same spectrum cpu behaviour. I think you need to focus on achieve this 95% as I say on a easy way instead on trying to have a 100% super perfect cpu cycle by cycle

#112456 - 02/02/18 07:39 AM Re: FireFly on the ZX Spectrum - Missing graphics [Re: R. Belmont]  
Joined: Jun 2001
Posts: 387
Olivier Galibert Offline
Senior Member
Olivier Galibert  Offline
Senior Member

Joined: Jun 2001
Posts: 387
somewhere else entirely
Originally Posted by R. Belmont
Originally Posted by Haze
I'm not following at all.

As soon as the Z80 core is at the stage of knowing which address it's going to fetch / write to, that fetch / write happens, there's no way to halt in the middle of it. By the time you know, it's too late unless you're suggesting returning a dummy value, or noping the write in the handler, then rewinding.. but then we really are into hacks on hacks..


You're running the Z80 cycle-per-cycle. It executes a load. Time gets to the exact cycle when the load or store happens. The read/write handler calls m_maincpu->HALT() and returns a dummy value on reads / doesn't write the value on writes. The Z80 immediately exits back to the scheduler and backs the current sub-cycle up 1, and when the ULA is finished you restart the Z80 minus however many cycles the ULA took (I assume the ULA is doing standard DMA where its cycles count against the CPU). It executes the read/write again, and this time they actually happen. For an opcode fetch it's even simpler, although you'd need to track if what got halted was a fetch or not.


And that's essentially what I'm working on making possible sanely with the memory system stuff. With additional "don't return to the scheduler if your icount is big enough" goodness for decent performance.

#112461 - 02/02/18 02:34 PM Re: FireFly on the ZX Spectrum - Missing graphics [Re: geecab]  
Joined: Apr 2013
Posts: 67
geecab Offline
Member
geecab  Offline
Member

Joined: Apr 2013
Posts: 67
Thanks for all the responses, fascinating stuff regarding contented memory!

So do you think there is any point in me testing out my original suggestion (as it sounds like the source code I will be building on will soon be dramatically changing towards a cycle exact approach)??

Just to recap, my original suggestion was:-
Originally Posted by geecab

Currently in mame, there is an ‘m_icount’ variable that keeps track of how many cycles (TStates) have passed since the Interrupt occurred (Note. The spectrum runs 69888 TStates per frame). Once the interrupt occurs m_icount is set to 69888, it is then decremented by a certain amount based on each Z80 opcode processed. When m_icount reaches zero, it triggers the interrupt, the screen is redrawn and m_icount is set back to 69888 and off we go again.

Based on the m_icount, we can predict where raster position would be on a real spectrum. There are 312 lines per frame, thus each time m_icount is decremented by 224 (Which is 69888/312), we’ll know the raster will have finished displaying a line. Mame could keep a history of the display memory at these intervals (Stored in, say, an "display_history[312]" array). Then when the interrupt is triggered, update_screen_spectrum() rather that displaying what is currently in the z80 display memory, would instead go though the display_history[312] array and line by line piece together a more accurate render of the display.


With how Mame currently works, the above seems like quite a 'low impact' change with quite a bit of benefit. I'd imagine this would improve flicking on many games, and make Firefly playable. It wouldn't fix nifty colour effects seen in a few demos that really push the envelope, and it wouldn't fix nifty colour effects seen in a couple of games (To name a few - 'Dark Star' (The pattern drawn in the top border when viewing the hi-score table), 'Uridium' (The title 'Uridium' on the menu screen)) and 'Amaurote' (During the 128K intro sequence)). Actually, does anyone know just how many spectrum titles perform nifty colour effects, it might only be the ones I've mentioned?? :p

Many thanks!

#112462 - 02/02/18 02:38 PM Re: FireFly on the ZX Spectrum - Missing graphics [Re: geecab]  
Joined: May 2004
Posts: 1,498
Haze Offline
Very Senior Member
Haze  Offline
Very Senior Member

Joined: May 2004
Posts: 1,498
a lot of the new Spectrum software does colour effects as it uses some game maker engine that was created and allows for 'multicolour' 'sprites' etc. (basically changing the attributes on each line using raster timing)

there are limits on what people can do with it, but it does look impressive.

there's are some older games doing similar too, but the modern development on the system really pushes the limits, proper smooth 50fps games etc.


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

Who's Online Now
2 registered members (dxl, 1 invisible), 16 guests, and 2 spiders.
Key: Admin, Global Mod, Mod
Shout Box
Forum Statistics
Forums9
Topics8,534
Posts111,541
Members4,793
Most Online225
May 26th, 2014
Powered by UBB.threads™ PHP Forum Software 7.6.0
Page Time: 0.107s Queries: 14 (0.069s) Memory: 5.0309 MB (Peak: 5.2571 MB) Zlib enabled. Server Time: 2018-05-23 09:11:14 UTC