+Lee Stewart Posted October 7, 2014 Share Posted October 7, 2014 It should work the same on MESS; but, I guess it should be verified. ...lee Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted October 7, 2014 Author Share Posted October 7, 2014 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 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted October 7, 2014 Share Posted October 7, 2014 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. Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted October 8, 2014 Author Share Posted October 8, 2014 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! Quote Link to comment Share on other sites More sharing options...
TheMole Posted October 8, 2014 Share Posted October 8, 2014 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 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 8, 2014 Share Posted October 8, 2014 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 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 8, 2014 Share Posted October 8, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted October 8, 2014 Share Posted October 8, 2014 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted October 8, 2014 Share Posted October 8, 2014 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! Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted October 8, 2014 Author Share Posted October 8, 2014 Well nuts. Looks like I have to waste 4k of VDP RAM for repeat pattern tables then... Bah! Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted October 8, 2014 Share Posted October 8, 2014 I had a conversation about this recently. It seems you can overcome the sprite limitation using a rotation/flicker routine. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 9, 2014 Share Posted October 9, 2014 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. Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted October 9, 2014 Author Share Posted October 9, 2014 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.