BitBuster depack in VRAM

Page 7/8
1 | 2 | 3 | 4 | 5 | 6 | | 8

By dvik

Prophet (2176)

dvik's picture

20-02-2008, 18:41

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.

By ARTRAG

Enlighted (5822)

ARTRAG's picture

20-02-2008, 20:10

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).

By PingPong

Prophet (2864)

PingPong's picture

20-02-2008, 21:19

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)

By SLotman

Paragon (1189)

SLotman's picture

20-02-2008, 21:53

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 Sad

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 Smile

By dvik

Prophet (2176)

dvik's picture

20-02-2008, 22:04

@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?

By Arjan

Paladin (694)

Arjan's picture

20-02-2008, 23:53

@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.

By Metalion

Paladin (909)

Metalion's picture

21-02-2008, 18:13

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.

By PingPong

Prophet (2864)

PingPong's picture

21-02-2008, 18:24

@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....

By dvik

Prophet (2176)

dvik's picture

21-02-2008, 19:13

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.

By Metalion

Paladin (909)

Metalion's picture

21-02-2008, 21:04

I'll release the new sources tomorrow evening.

Page 7/8
1 | 2 | 3 | 4 | 5 | 6 | | 8
My MSX profile