WIP: Reversi
Re: WIP: Reversi
The starfields are rather chaotic on real hardware, and part of the co-op that we were working on.
Re: WIP: Reversi
speed of copy to vdp can be the source for the error, this can be with my software also because i don't test on real hardware on the moment.
The way the VDP works is a sort of a "best effort" approach. When you write data to the data port, the VDP will copy that data to VRAM when it's ready to, and not before. If the CPU writes a new piece of data before the VDP does the move, there is no error, interrupt, or status bit to check, the old data is replaced and when the VDP comes to get it, the new data is moved instead of the old data.
But this is possible to fix.
The way the VDP works is a sort of a "best effort" approach. When you write data to the data port, the VDP will copy that data to VRAM when it's ready to, and not before. If the CPU writes a new piece of data before the VDP does the move, there is no error, interrupt, or status bit to check, the old data is replaced and when the VDP comes to get it, the new data is moved instead of the old data.
But this is possible to fix.
Re: WIP: Reversi
but in the VBL when the TMS has nothing to display, you can write as fast as possible.
After an address is written, the VDP needs 2uS to retrieve the data. Between reads, the VDP needs 8uS to get the next piece of data.
And now, the variable part - the VDP only provides a CPU access window from every 0 to 6uS.
So the data says that it's fine to write the address and even read the first piece of data immediately on our hardware, because we will take longer than 2uS anyway.
In the vertical blank, and if the blanking bit has disabled the screen, there is no wait for a CPU access window - so you can access VRAM at top
speed. Between reads you need to wait 8uS to guarantee success. Fast code running in zero wait-state memory (scratchpad or modified) may be able to send data faster than every 8uS (indeed this was what I achieved, managing a write roughly every 5uS). This will fail.
After an address is written, the VDP needs 2uS to retrieve the data. Between reads, the VDP needs 8uS to get the next piece of data.
And now, the variable part - the VDP only provides a CPU access window from every 0 to 6uS.
So the data says that it's fine to write the address and even read the first piece of data immediately on our hardware, because we will take longer than 2uS anyway.
In the vertical blank, and if the blanking bit has disabled the screen, there is no wait for a CPU access window - so you can access VRAM at top
speed. Between reads you need to wait 8uS to guarantee success. Fast code running in zero wait-state memory (scratchpad or modified) may be able to send data faster than every 8uS (indeed this was what I achieved, managing a write roughly every 5uS). This will fail.
Re: WIP: Reversi
Hm. I just checked Barry Klein's BIOS disassembly, and the locations where it accesses VDP_Status_Write $3001 or VDP_Data_Write $3000 are not surrounded by any delays. Also, I checked Kurt's Titanic 1.1 demo and there are no delays as well. Then again that one runs with interrupts disabled, which of course I could try as well.
Oh well, I can try to add some delays etc and try again.
Oh well, I can try to add some delays etc and try again.
Re: WIP: Reversi
As i remember Kurt set the screen active bit OFF then write all to the VDP RAM, and when all is finish turn on the screen.
I really think you only have this timing problem outside the VBL.
I really think you only have this timing problem outside the VBL.
Re: WIP: Reversi
yes i am right, i check Kurt`s source, he init the VDP with Screen OFF.
After he is finish with copy he do:
LDA #$E2 ;new value including set screen active bit
STA VDP_Status_Write
LDA #$81 ;write into register 1
STA VDP_Status_Write ;see comments on that BIOS routine above
and set the bit to active, so he have no timing problems.
After he is finish with copy he do:
LDA #$E2 ;new value including set screen active bit
STA VDP_Status_Write
LDA #$81 ;write into register 1
STA VDP_Status_Write ;see comments on that BIOS routine above
and set the bit to active, so he have no timing problems.
Re: WIP: Reversi
Good catch, thanks!
I'll try some new things later tonight and report back.
I'll try some new things later tonight and report back.
Re: WIP: Reversi
My starfield:
download/file.php?id=78
works perfectly in Mess when I tried it.
I use this version of mess (newest): http://www.progettosnaps.net/MESS/bin/p ... _148u4.rar
You also need the roms for creativision, I can send it via email if anyone want it.
download/file.php?id=78
works perfectly in Mess when I tried it.
I use this version of mess (newest): http://www.progettosnaps.net/MESS/bin/p ... _148u4.rar
You also need the roms for creativision, I can send it via email if anyone want it.
Re: WIP: Reversi
I have now made the following changes:
* Screen disabled while setting up the majority of VDP data
* Screen enabled once it is done
* All access to VDP_Status_Write and VDP_Data_Write once the screen is enabled are replaced by subroutines
In those subroutines, I tried to wait for #%10000000 in the status register. It works about once (in emulation), then it hangs. I must have made something wrong.
Instead, I read what Mobsie wrote about microseconds of waiting, and added eight nice NOP's after each time the VDP has been written to. I haven't calculated if that is too few, enough or too many. The result on real hardware however is just a few wrong characters as part of updating the board, which very well could be my mistake that for some reason doesn't show in emulation. The majority of the graphical glitches thus have been eliminated by letting the CPU wait 8*2 = 16 cycles. I know the Creativision runs at 2 MHz, but I'm too tired to figure out how many cycles per second.
When it comes to the starfields, the first type of snow falling actually runs fine on my unit. The Gyruss type runs fine the upper half, the lower half is a bit mashed up. I can take a video of it later on.
* Screen disabled while setting up the majority of VDP data
* Screen enabled once it is done
* All access to VDP_Status_Write and VDP_Data_Write once the screen is enabled are replaced by subroutines
In those subroutines, I tried to wait for #%10000000 in the status register. It works about once (in emulation), then it hangs. I must have made something wrong.
Instead, I read what Mobsie wrote about microseconds of waiting, and added eight nice NOP's after each time the VDP has been written to. I haven't calculated if that is too few, enough or too many. The result on real hardware however is just a few wrong characters as part of updating the board, which very well could be my mistake that for some reason doesn't show in emulation. The majority of the graphical glitches thus have been eliminated by letting the CPU wait 8*2 = 16 cycles. I know the Creativision runs at 2 MHz, but I'm too tired to figure out how many cycles per second.
When it comes to the starfields, the first type of snow falling actually runs fine on my unit. The Gyruss type runs fine the upper half, the lower half is a bit mashed up. I can take a video of it later on.
Re: WIP: Reversi
perfect carlsson,
we are near!
we are near!