I believe that there's no need to space the outs on $99, there's an address register that holds the data when it's being initialized. You only need to take care of avoid any access to VDP while this data is being sent (usually a pair of bytes). I'm pretty sure I've used things like out (c),e;out (c),d (being c=$99) without flaws...

I've been using closer outs too on 0x99 but then I haven't been using sprites. You only need 29 T-states (be it only on $98) when you have a lot of sprites. 29 T-states is really a worst case that I don't think is that common.

ARTRAG, if you read the spec and find something, let us know. I read one spec earler today (not the TMS one) and it only talked about VRAM access.

Reading the TMS9918 manual
(TMS9918A/TMS9928A/TMS9929A Video Display Processors Data Manual)

You can see that, in order to have effect, a "set address" command (both in read or write) needs two micro secs (1e-6) in any screen mode.
Thus there is no limitation on the speed between the two out(0x99)'s setting the same address.
The sole problem is that you cannot read or write data before 2us (that is about 7-8 T states) after having set the address.

After the 2us, the time for the VDP to
1) access the VRAM and return a result (reading) or
2) take the data and put it in vram (writing)
can vary from 0 to 16*372e-9 secs = 5.952 usecs corresponding to about 22 Tstates.

IMHO this means that after you have set the address once, all you need to wait between two adjacent out (0x98) is 22 T states.
Actually the manual do not say how long the internal VRAM pointer takes to move on one step, but for sure it is less than 2us that applies only when the address value has to be transmitted on the address bus.

Recollecting, IMHO, in the worst case condition, (screen2, plenty of sprite active, access in active area), all you need is to wait 7 Tstates between the second out(0x99) and the first use of port 0x98, and 22 Tstates between two successive accesses to port 0x98

[edit]
I was in error. The manual says also:
"The VDP requires approximately 8 microsecs to fetch the VRAM byte following the last data transfer and 2 microsecs following address setup"
This means that the time to update the internal pointer is 2us even when there is no address setup and the interval between two successive data access is 22+7=29Tstates... sorry!

BTW, it seems that there is no limit on the time between two successive uses of port 0x99 when setting a single address,
while you cannot set new addresses sooner than 7us (that, in any case, is impossible for a plain z80).

about msx2 i can say that during the active area @60hz with sprites enabled it's safe to do a full string of 16 outi even IF DURING THE OUTs there is a HMMC vdp command in progress. No corruptions. No the vdp command, No in the data sent from z80 (NMS 8245)

Yes, MSX2 VDP is much nicer than MSX1 in that, even when using Screen2.

In Time Scanner I had to re-write the routine which scrolls the screen up/down. I got a pretty good speed on MSX2, but when I tested the same routine on MSX1, all I got was screen corruption

The worst thing is that in *some* MSX1 OUTing with less NOPs will work, because they have a "hispeed" vdp (maybe later models?). In others, it won't and all you'll get will be screen/data corruption.

On MSX1 even OTIR or INIR fails due to excessive speeds - which is obvious some hardware failure on MSX - on Coleco this doesn't happen (with the same VDP!) and they use and abuse from it (Jungle Hunt was having some harsh corruption on level 3 due to INIR... it took me quite a while to figure it out)

on MSX2, writing on 99h has no problems at all (that I know of), and you can get away with plenty more "unsafe" OUTs on 98h than on MSX1.

As I said before, if you want to make sure your MSX1 vdp routine works on all MSX1, get BrMSX (version 2.10 works on Windows XP without sound, but you won't need DOSBOX to run it) and test your routine with -vdptiming parameter. Ricbit implemented that pretty well on BrMSX, so if it works there, it will work on all MSX1

@SLotman, so you say its ok to do OTIR on Colecovision? Do you know if thats true for all Colecos (i.e. does all have the same VDP) or only on newer ones?

@PingPong: my previous attempt at a bitbuster depacker which directly depacks to VRAM used the HMMC command to write the data, and normal VRAM access to read data. It works on NLMSX, but not on a real MSX.

Here is what I have decided :

I will put one NOP instruction (and only one) where VDP waiting/timing is required. And I will write as an important notice in the readme.txt file that the NOP instructions may be removed or increased by the user following his needs, his configuration or should he experience VRAM data corruption.

Quote:

@PingPong: my previous attempt at a bitbuster depacker which directly depacks to VRAM used the HMMC command to write the data, and normal VRAM access to read data. It works on NLMSX, but not on a real MSX.

I'm pretty sure that my test work fine. If you want i can send the .com files that do the tests...
They work on a normal nms8245 machine....

Quote:

I will put one NOP instruction (and only one) where VDP waiting/timing is required. And I will write as an important notice in the readme.txt file that the NOP instructions may be removed or increased by the user following his needs, his configuration or should he experience VRAM data corruption.

I think thats fine. I hope that if someone find some problems and may need additional nops, they'll contact you so you can know about it and release an update if you think its needed.

I'll release the new sources tomorrow evening.

The new sources are online.
I added a readme.txt where everything is explained.

BitBuster_v12_VRAM_depacker_(16Kb)
Pletter_v05b_VRAM_depacker_(16Kb)

Quote:

@SLotman, so you say its ok to do OTIR on Colecovision? Do you know if thats true for all Colecos (i.e. does all have the same VDP) or only on newer ones?

I don't know if all colecos have the same VDP, but by looking at Jungle Hunt and Montezuma's Regenge code, they use and abuse OTIR and INIR - with no problems on the Coleco side...

And to Matelion: Thanks for these! I'll sure put it to good use

Quote:

I don't know if all colecos have the same VDP, but by looking at Jungle Hunt and Montezuma's Regenge code, they use and abuse OTIR and INIR - with no problems on the Coleco side...

And I suppose they caused problems on MSX? If you do otir in the border area its ok on MSX as well. I read somewhere (need to check this) that Colecovisions VINT happens on the beginning of the display area, not a the end as on MSX. Do you know if this is correct? If it is, maybe the game developers wrote the code so that the otirs occur in the vblank area....