Msx1 race engine

Page 2/4
1 | | 3 | 4

By Sandy Brand

Master (190)

Sandy Brand's picture

09-08-2020, 21:54

Hmm, so what about backwards compatibility on MSX 2 then?
Was there no software written for MSX 1 that directly wrote to the VDP? I guess everyone had to use BIOS on MSX 1 with all the different access timings for differently produced display processors?

I think someone mentioned somewhere that only for MSX 2 did it become part of the standard to allow for directly writing to the VDP? I wonder why that was decided for MSX 2 then. Maybe they though it would not be feasible to do more advanced trickery that the V9938 could do (e.g.: screen-splits) if the BIOS was in the way?

By Grauw

Ascended (9272)

Grauw's picture

09-08-2020, 22:16

Sandy Brand wrote:

Hmm, so what about backwards compatibility on MSX 2 then?
Was there no software written for MSX 1 that directly wrote to the VDP?

You’re supposed to set a VRAM read/write address in a two-byte pair (a 14-bit address). That undocumented TMS9918 implementation detail I mentioned is when you output only the LSB of the address and omit the MSB. I do not think any commercial software would do that.

Sandy Brand wrote:

I guess everyone had to use BIOS on MSX 1 with all the different access timings for differently produced display processors?

Afaik the VRAM access timings of all TMS VDPs and clones are the same, and documented by Texas Instruments. Those of the Yamaha V9938 are lower and thus backwards compatible.

Sandy Brand wrote:

I think someone mentioned somewhere that only for MSX 2 did it become part of the standard to allow for directly writing to the VDP?

Direct access to the VDP was always allowed, also on MSX1, as long as you read the I/O address from the BIOS and do not hardcode it. ASCII must’ve recognised that without direct access to the VDP it would be hard to get competitive performance, and made an exception to their BIOS policy for the VDP.

By pgimeno

Master (230)

pgimeno's picture

09-08-2020, 23:32

Grauw wrote:

On TMS9918, iirc changing VDP registers also alters the VRAM pointer address, because the VRAM pointer low byte is also used by the VDP to store the register value temporarily.

And the high byte (bits A8-A13) is also used to store the VDP register number!

Tested with this program:

?VDP(2)
 0
' I'll use that in line 50 below
10 SCREEN 0:WIDTH 40:DEFUSR=&HD000 ' SCREEN 0 needed for AX-150
20 FOR N=&HD000 TO -1:READ A:POKE N,A:NEXT N
30 DATA 251,118:'EI, HALT (EI needed for AX-150)
35 '62 = LD A,N; 211 = OUT (N),A; 201=RET
40 DATA 62,39,211,&H99,62,&H40,211,&H99
50 DATA 62,0,211,&H99,62,&H82,211,&H99
60 DATA 62,33,211,&H98,201
RUN ' ignore Out of DATA
?USR(0)

On a TMS9129 and on a YM2220, the ! is written to VRAM address 0x200, not to 39.

Looks like the YM2220 has a very high degree of compatibility. Also, it seems they were aware of this effect and decided to remove it on the V9938.

By bsittler

Resident (55)

bsittler's picture

09-08-2020, 23:44

I tested YM2220 with the "Hello World!" test (vramlsb) and it behaves like TMS9918

By Grauw

Ascended (9272)

Grauw's picture

10-08-2020, 00:10

Thanks for testing bsittler! Indeed YM2220 seems to be very compatible from all the tests I’ve seen so far. Looks like Yamaha acquired the blueprints from Texas Instruments.

By Sandy Brand

Master (190)

Sandy Brand's picture

10-08-2020, 14:16

Aaaaah okay we are talking about THAT specific issue. For a moment I was really confused there Smile

Yes, clearly you need to make sure that if you set the VRAM address that no interrupts will occur when writing the 4 bytes to VDP register 14. I assumed that was sort of implied.

smx's original question was if it is allowed to change a VDP register (in an interrupt handler) while writing to VRAM on port 0 of the VDP. And that should be perfectly fine, even on MSX 1, if you always adhere to proper interrupt handling protection while writing data to port 1 of the VDP, right? Smile

By Grauw

Ascended (9272)

Grauw's picture

10-08-2020, 14:40

Sandy Brand wrote:

smx's original question was if it is allowed to change a VDP register (in an interrupt handler) while writing to VRAM on port 0 of the VDP. And that should be perfectly fine, even on MSX 1, if you always adhere to proper interrupt handling protection while writing data to port 1 of the VDP, right? Smile

Nope, because writing to a TMS9918 register changes the VRAM pointer as I mentioned in my first post. (Nothing to do with V9938 register 14.)

The V9938 does not have this limitation but it does not affect backwards compatibility since nobody should rely on this undocumented implementation detail of the TMS9918.

Sorry if it was confusing to bring up another implementation detail (incomplete VRAM pointer changes), it’s related because it’s the same underlying mechanism, but not related to the topic of this thread.

By Sandy Brand

Master (190)

Sandy Brand's picture

10-08-2020, 14:36

Grauw wrote:

Afaik the VRAM access timings of all TMS VDPs and clones are the same, and documented by Texas Instruments. Those of the Yamaha V9938 are lower and thus backwards compatible.

Hmmm, I remember there being discussions for the game Uridium, whereby it has some settings specifically for controlling the write speed to the VDP because it was different for some of the hardware versions? (Maybe this is only related to writing to VDP port 0)?

By Grauw

Ascended (9272)

Grauw's picture

10-08-2020, 14:57

Sandy Brand wrote:

Hmmm, I remember there being discussions for the game Uridium, whereby it has some settings specifically for controlling the write speed to the VDP because it was different for some of the hardware versions? (Maybe this is only related to writing to VDP port 0)?

Uridium afaik only has VDP-specific code to deal with a difference in pattern table mirroring in screen 2 between the Texas Instruments TMS9918 and the Toshiba T6950 VDP.

The TI (and Yamaha) VDPs mirror the pattern table when the lower two bits of register 4 are set to 0, allowing you to use a single pattern table across the entire screen (instead of three). But this does not work on the T6950, so Uridium has a workaround for that.

Grauw wrote:

Nope, because writing to a TMS9918 register changes the VRAM pointer as I mentioned in my first post. (Nothing to do with V9938 register 14.)

Addendum: Simply put, internally the TMS9918 has a single 14-bit internal pointer for the VRAM address. When you set a VRAM read or write address this pointer is changed.

However because register writes are done with two OUTs, the VDP needs to remember the value of the first OUT. The TMS9918 re-uses the VRAM pointer address buffer for this (to reduce silicon space), so when you set a register the VRAM address pointer is also modified as a side-effect.

By Sandy Brand

Master (190)

Sandy Brand's picture

10-08-2020, 14:48

Grauw wrote:

Sorry if it was confusing to bring up another implementation detail (incomplete VRAM pointer changes), it’s related because it’s the same underlying mechanism, but not related to the topic of this thread.

Hahaha, okay fair enough Smile

It just goes to show it is not easy to write fast and efficient assembler code. It requires quite a bit of domain specific knowledge.

So smx: ignore all that I said Smile

Page 2/4
1 | | 3 | 4