Forums

Hi all,

I'm working on horizontal scrolling and looked through a few roms to see how the professionals implemented it. Of course, most of the time the tile pattern simply repeats itself regularly a la Scooby Doo. Unfortunately, my project requires pretty dramatic redrawing of the game map pretty quickly (ideally down to once in 8 screen redraws), and I'm a bit concerned about the dreaded VRAM garbage.

Does anyone out there have a good idea of the limits of the VRAM - how fast and how much one can write to it to avoid garbage on a real SMS?

Cheers,
Mike

Mike Cukan wrote

Hi all,
Does anyone out there have a good idea of the limits of the VRAM - how fast and how much one can write to it to avoid garbage on a real SMS?

According to the docs:

16 T-states between VRAM access during V-Blank
29 T-states between VRAM access during the active display period

The related instructions are:

16 T-states for OUTI
21 T-states for OTIR when bc !=0, and 16 on the last pass when bc==0
11 T-states for OUT (c), x

In practice, you only get VRAM garbage when writing to VRAM when the screen is turned on, e.g. during the active display portion of the frame. Is this what you need to do?

You can cheat by blanking the screen mid-frame or at the screen edges to 'letterbox' the display and extend the amount of time you have to update VRAM.

On the dev wiki, I wrote about some techniques for the fastest way to write to VRAM using multiple OUTIs instead of OTIR and precomputed sequences of OUT (c), x. These are the kinds of things you'd want to use in your V-Blank routine to write to VRAM as quick as possible (*)

If you are doing calculations between your VRAM writes, you may be able to observe the delay by carefully sequencing the writes and calculation code so that the delay is taken up by preparing the data, and by the time you need to write the necessary amount of cycles have elapsed. But I would store that kind of data in RAM so it could be rapidly uploaded to VRAM in a loop.

* Side note: the OUT (C), x technique will violate the VRAM timing (11 T-states per write instead of 16 required ones) but it seems to work fine for me. Insert a NOP to make it 15 T-states if you want to live dangerously)

I made a demo to test this, which I posted about in 2003. Charles did test it on some other systems but I don't seem to have the results, or the code, any more. Basically, you can go as fast as you like during the VBlank, and during the active display it can take faster accesses than are described but you might want to hold back to allow for hardware variation. Remember that Emukon's emulation of this effect is less forgiving than real hardware, and that plenty of commercial games exceed the official limits.

I am just going to have to try and get my code to be as tight as possible. I actually don't need to redraw the entire screen each time - I should be able to get away with changing a few tiles here and there. But I think this project is probably a bit harder than I thought it was when I started!

Author	Message
Mike C Joined: 10 Oct 1999 Posts: 211 Location: Lebanon, New Hampshire, USA	VRAM writing frequency limit (to avoid garbage) Posted: Sun Oct 30, 2005 3:18 am
	Hi all, I'm working on horizontal scrolling and looked through a few roms to see how the professionals implemented it. Of course, most of the time the tile pattern simply repeats itself regularly a la Scooby Doo. Unfortunately, my project requires pretty dramatic redrawing of the game map pretty quickly (ideally down to once in 8 screen redraws), and I'm a bit concerned about the dreaded VRAM garbage. Does anyone out there have a good idea of the limits of the VRAM - how fast and how much one can write to it to avoid garbage on a real SMS? Cheers, Mike

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Posted: Sun Oct 30, 2005 4:47 am
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Mike Cukan wrote Hi all, Does anyone out there have a good idea of the limits of the VRAM - how fast and how much one can write to it to avoid garbage on a real SMS? According to the docs: 16 T-states between VRAM access during V-Blank 29 T-states between VRAM access during the active display period The related instructions are: 16 T-states for OUTI 21 T-states for OTIR when bc !=0, and 16 on the last pass when bc==0 11 T-states for OUT (c), x In practice, you only get VRAM garbage when writing to VRAM when the screen is turned on, e.g. during the active display portion of the frame. Is this what you need to do? You can cheat by blanking the screen mid-frame or at the screen edges to 'letterbox' the display and extend the amount of time you have to update VRAM. On the dev wiki, I wrote about some techniques for the fastest way to write to VRAM using multiple OUTIs instead of OTIR and precomputed sequences of OUT (c), x. These are the kinds of things you'd want to use in your V-Blank routine to write to VRAM as quick as possible () If you are doing calculations between your VRAM writes, you may be able to observe the delay by carefully sequencing the writes and calculation code so that the delay is taken up by preparing the data, and by the time you need to write the necessary amount of cycles have elapsed. But I would store that kind of data in RAM so it could be rapidly uploaded to VRAM in a loop. Side note: the OUT (C), x technique will violate the VRAM timing (11 T-states per write instead of 16 required ones) but it seems to work fine for me. Insert a NOP to make it 15 T-states if you want to live dangerously)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sun Oct 30, 2005 11:15 am
	I made a demo to test this, which I posted about in 2003. Charles did test it on some other systems but I don't seem to have the results, or the code, any more. Basically, you can go as fast as you like during the VBlank, and during the active display it can take faster accesses than are described but you might want to hold back to allow for hardware variation. Remember that Emukon's emulation of this effect is less forgiving than real hardware, and that plenty of commercial games exceed the official limits.

Mike C Joined: 10 Oct 1999 Posts: 211 Location: Lebanon, New Hampshire, USA	thanks for the help Posted: Tue Nov 01, 2005 3:36 am
	I am just going to have to try and get my code to be as tight as possible. I actually don't need to redraw the entire screen each time - I should be able to get away with changing a few tiles here and there. But I think this project is probably a bit harder than I thought it was when I started!

Forums

View topic - VRAM writing frequency limit (to avoid garbage)