WIP: Reversi

Talk about programming of homebrew games only.
User avatar
carlsson
Posts: 507
Joined: Fri Jun 13, 2008 7:39 am
Location: Västerås, Sweden

Re: WIP: Reversi

Post by carlsson » Thu May 09, 2013 3:08 pm

The starfields are rather chaotic on real hardware, and part of the co-op that we were working on.
User avatar
Mobsie
Posts: 708
Joined: Fri Jun 13, 2008 10:38 am
Location: Weinheim, Germany

Re: WIP: Reversi

Post by Mobsie » Thu May 09, 2013 3:18 pm

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.
User avatar
Mobsie
Posts: 708
Joined: Fri Jun 13, 2008 10:38 am
Location: Weinheim, Germany

Re: WIP: Reversi

Post by Mobsie » Thu May 09, 2013 3:22 pm

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.
User avatar
carlsson
Posts: 507
Joined: Fri Jun 13, 2008 7:39 am
Location: Västerås, Sweden

Re: WIP: Reversi

Post by carlsson » Thu May 09, 2013 3:32 pm

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.
User avatar
Mobsie
Posts: 708
Joined: Fri Jun 13, 2008 10:38 am
Location: Weinheim, Germany

Re: WIP: Reversi

Post by Mobsie » Thu May 09, 2013 3:43 pm

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.
User avatar
Mobsie
Posts: 708
Joined: Fri Jun 13, 2008 10:38 am
Location: Weinheim, Germany

Re: WIP: Reversi

Post by Mobsie » Thu May 09, 2013 3:46 pm

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.
User avatar
carlsson
Posts: 507
Joined: Fri Jun 13, 2008 7:39 am
Location: Västerås, Sweden

Re: WIP: Reversi

Post by carlsson » Thu May 09, 2013 4:31 pm

Good catch, thanks!

I'll try some new things later tonight and report back.
User avatar
TBCTBC
Posts: 64
Joined: Wed Mar 13, 2013 1:27 pm
Location: Solna, Sweden
Contact:

Re: WIP: Reversi

Post by TBCTBC » Thu May 09, 2013 6:10 pm

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.
User avatar
carlsson
Posts: 507
Joined: Fri Jun 13, 2008 7:39 am
Location: Västerås, Sweden

Re: WIP: Reversi

Post by carlsson » Thu May 09, 2013 6:40 pm

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.
User avatar
Mobsie
Posts: 708
Joined: Fri Jun 13, 2008 10:38 am
Location: Weinheim, Germany

Re: WIP: Reversi

Post by Mobsie » Thu May 09, 2013 7:10 pm

perfect carlsson,
we are near!
Post Reply