New TI Game: Sneak peek

[+Lee Stewart]

It should work the same on MESS; but, I guess it should be verified.

 

...lee

[+adamantyr]

Missing Link uses this when in the 2 color mode. There are three pattern tables for a total of 6k and one 2K color table that controls all of them. All the bytes in the color table are set to the same foreground color and background color so there are only two colors possible on the screen. This mode works fine on a real TI and on Classic99. It is not compatible with Win994a. I don't know about Mess or any of the others emulators.

 

That's what I'm asking, has someone confirmed that half-bitmap mode with only one pattern and color table messes up sprites on an actual TI? And has anyone dug into why?

 

It sounds like the bitmask is being inadvertently used for the sprite attribute table... but if that was the case, I'm a bit surprised that Thierry didn't notice this in his rather extensive write-up on the VDP9918A... VDP registers 5 and 6 (sprite attributes and patterns) have no relationship whatsoever to VDP registers 3 and 4 (color and pattern table locations.) Also, why would it be okay with the top 8 sprites, but not the bottom 24?

 

If you're trying to use full interupt-driven sprite motion, THAT won't work in half-bitmap, but that was always well known and documented... and if you don't disable full-motion prior to entering bitmap mode, it will try and access data at >0300 (attribute table) and >0780 for sprite motion data... That would definitely make things very glitchy and obvious though; and NO sprites would work quite right.

 

Adam

[senior_falcon]

 

That's what I'm asking, has someone confirmed that half-bitmap mode with only one pattern and color table messes up sprites on an actual TI? And has anyone dug into why?

Sorry, from your response "Has this been tested extensively with real hardware AND emulation?", I thought that you were asking about the mode that uses 6K for the pattern tables and 2K for the color. I've never tried sprites and the half bit mapped mode using 2K pattern and 2K color tables.

[+adamantyr]

Sorry, from your response "Has this been tested extensively with real hardware AND emulation?", I thought that you were asking about the mode that uses 6K for the pattern tables and 2K for the color. I've never tried sprites and the half bit mapped mode using 2K pattern and 2K color tables.

 

Not a problem, dude.

 

I may throw together a test program tonight to see this glitch myself... Very curious. And limiting too; hard to write a Zelda-game with only 8 sprites!

[TheMole]

It has been verified to occur on real hardware, see this post by Tursi (who wrote a test program to reproduce the effect): http://atariage.com/forums/topic/168968-f18a/page-11?gopid=2219848&do=findComment&comment=2219848

[Tursi]

 

Hm, that is not documented anywhere, not even on the TI Tech pages... Kind of sucks, you're wasting 4k of space!

 

Has this been tested extensively with real hardware AND emulation? I wonder why the position of the pattern table is impacting the sprite attribute table... theoretically the two registers should not impact one another.

 

I wrote a bitmap test program ages ago that let you go through the various bitmasks, in part hoping to understand the sprite masking. Many of the settings made sense but research on the web (the MSX guys knew about this ages ago) claims it's not consistent.

 

But if you want to see the sprite weirdness (not emulated anywhere as far as I know. BlueMSX tried and had to take it out again), check here: https://www.youtube.com/watch?v=XJljSJqzDR0&feature=player_detailpage&list=UUOu3RaDgL-1HlEBEUrEmF1w#t=553

[Tursi]

 

If you're trying to use full interupt-driven sprite motion, THAT won't work in half-bitmap, but that was always well known and documented... and if you don't disable full-motion prior to entering bitmap mode, it will try and access data at >0300 (attribute table) and >0780 for sprite motion data... That would definitely make things very glitchy and obvious though; and NO sprites would work quite right.

 

Half bitmap versus full bitmap won't be any different in this respect. But it's worth noting that /only/ the console auto-motion table at >0780 is fixed. You can put the sprite attribute table elsewhere in VRAM to avoid conflicts with bitmap mode. Also, the console sprite auto-motion is software, it's not any kind of a hardware feature, and the code isn't really all that efficient. You are just as well off doing it in your own code anyway.

[senior_falcon]

 

Half bitmap versus full bitmap won't be any different in this respect. But it's worth noting that /only/ the console auto-motion table at >0780 is fixed. You can put the sprite attribute table elsewhere in VRAM to avoid conflicts with bitmap mode. Also, the console sprite auto-motion is software, it's not any kind of a hardware feature, and the code isn't really all that efficient. You are just as well off doing it in your own code anyway.

I had to do this in The Missing LInk. The attribute table is moved and the motion table is (as I recall) in low memory. I could probably dig out the code and post it if anyone is interested. This way is probably best, but another work around might be to just not use the characters whose definitions are located where the sprite tables are. I can't remember if the sprite auto motion requires the attribute table to be at >0300. If so, you would lose 32 characters out of 256; otherwise it would only be 16. And of course, if you use fewer sprites then fewer characters would be affected.

(edit)To use auto motion the attribute table must be at >0300, so you'd lose 32 characters.

Edited October 9, 2014 by senior_falcon

[+OLD CS1]

 

Also, the console sprite auto-motion is software, it's not any kind of a hardware feature, and the code isn't really all that efficient. You are just as well off doing it in your own code anyway.

 

This right here. I am working on a project and have been doing over-lapping sprite mock-ups in XB with motion... OH EM GEE!

[+adamantyr]

Well nuts. Looks like I have to waste 4k of VDP RAM for repeat pattern tables then... Bah!

[+OLD CS1]

I had a conversation about this recently. It seems you can overcome the sprite limitation using a rotation/flicker routine.

[Asmusr]

 

That's what I'm asking, has someone confirmed that half-bitmap mode with only one pattern and color table messes up sprites on an actual TI? And has anyone dug into why?

 

 

I ran into this problem when programming Titanium and the solution to have 3 pattern tables solved it. On real old hardware that is - the F18A doesn't have this issue and none of the emulators either. The problem for me was that the solution reduced the screen update speed by 50% because I had to update 4 2K tables instead of 2.

[+adamantyr]

 

I ran into this problem when programming Titanium and the solution to have 3 pattern tables solved it. On real old hardware that is - the F18A doesn't have this issue and none of the emulators either. The problem for me was that the solution reduced the screen update speed by 50% because I had to update 4 2K tables instead of 2.

 

Fortunately I wasn't relying upon rapid character set shifts, my plan is to have one character set for Overworld and another for Underworld, so loading 8k of data (6k pattern, 2k color) won't be a huge detriment when doing the switch.