sometimes99er Posted December 30, 2011 Share Posted December 30, 2011 (edited) I still think Assembly would be best and a cart should be a must as we should be able to code this in 4K just like the original. I can see alot of people wanting it. It's two very different machines. Generally the 9900 code has like twice the footprint, but should also be stronger, faster and maybe more flexible. Fast room swapping is essential if anybody is going to compare it with the original. I'd like to do double buffering to achieve instant swapping, but then this requires just a bit more code. Also I'd like this 4th level in there. I hope 8K will do it. Edited December 30, 2011 by sometimes99er Quote Link to comment Share on other sites More sharing options...
jchase1970 Posted December 31, 2011 Share Posted December 31, 2011 I still think Assembly would be best and a cart should be a must as we should be able to code this in 4K just like the original. I can see alot of people wanting it. It's two very different machines. Generally the 9900 code has like twice the footprint, but should also be stronger, faster and maybe more flexible. Fast room swapping is essential if anybody is going to compare it with the original. I'd like to do double buffering to achieve instant swapping, but then this requires just a bit more code. Also I'd like this 4th level in there. I hope 8K will do it. Double buffering will be needed if we use some type of map compression like I used above. Do you have any example code to show how to do that on the TI. I read about it somewhere but not sure where now????? Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted December 31, 2011 Share Posted December 31, 2011 Having bits unfold into several characters (blocks) on screen might be considered compression. But then one has to ask if the 2600 use compression. Looking at RLE, I think one, maybe at least has to have some kind of counts in the data to call it compression. Whatever. The TMS9918A has a screen location pointer (VDP register 2, Screen Image Table location). So you allocate 2 areas in VDP for screens, display one and update the other, then flip between them from time to time. I guess we can update a room in less than 2 frames (even using the bit compression), so it's probably just one glitch on the screen I'm trying to avoid. Like the eye might catch a glimpse of new room in the upper part and old room in the lower part. Maybe avoiding this glitch is going too far. My original idea was to calculate which exit is the closest and start drawing the next room in the backbuffer, but this is clearly overkill. Adding code and complexity with almost no effect. Quote Link to comment Share on other sites More sharing options...
jchase1970 Posted December 31, 2011 Share Posted December 31, 2011 I got to thinking about just switching the pointer to the screen location. So I guess I was thinking right I was going to code a little something list night and try it, but never got around to it, I was thinking to refresh the screen(all 768 characters) take 2 cycles. Does that still apply when changing the pointer to another screen? I here what your saying about the bits not being compression. I guess in assembly it would not be it would be just reading a line of bits. but in my basic example it was a little more complex to decode the bits. Quote Link to comment Share on other sites More sharing options...
jchase1970 Posted January 1, 2012 Share Posted January 1, 2012 (edited) Well my assembly no how is lacking to say the least so I want to run this by here before I spend the time to code it. I am rewriting the basic example I had using bit packing to store the map. The best way I can figure out to do this in assembly is 1 place word in register 2 add 1 to register to perform operation on it and set status bits 3 do a JOP based on odd or even to draw map section 4 do a SRL to remove bit after done 5 JMP back to 2 and repeat until done I am guessing there might be a better way, but I can find little to tell me how to read bits in a byte or word. So I'll let the gurus set me straight before I proceed. John *edit I guess I could also to a COC and a JEQ to do about the same thing as add 1 and JOP Edited January 1, 2012 by jchase1970 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 1, 2012 Share Posted January 1, 2012 (edited) Yeah, shift into Carry and test is probably the way to go. I was thinking about moving 2 bytes at first, into the "roll" register. Then when 8 shifts have been done, fill with yet another byte. This would keep a steady flow of bits. We could have two routines like BitSetPointer() and BitGetBit(). The first would take a pointer to somewhere in memory (pointing at maybe the castle definition), and reset the 8 shift count (needed for bringing in bytes in a flow). The latter routine returns one bit for testing. Guess the routines could be used unmodified with other parts/games. A simpler way is to just store 10 bits, making up a line section, in a word (16 bits), and just move to the next word when going for the next line section. You loose 6 bits here, but these may then be used for something else (eg. color stuff, exits and port info). Edited January 1, 2012 by sometimes99er Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 1, 2012 Share Posted January 1, 2012 (edited) I got to thinking about just switching the pointer to the screen location. So I guess I was thinking right I was going to code a little something list night and try it, but never got around to it, I was thinking to refresh the screen(all 768 characters) take 2 cycles. Does that still apply when changing the pointer to another screen? I don't think one can update all 768 character locations on screen without a glitch (a visible flick), even though the update is optimized to take less than one frame (the raster catches up). The idea about double buffering (in our version of the game), show one update another, is to avoid the glitch(es). Updates of screen locations takes about the same time (maybe +1%), flipping is done in like no time (relatively). Flipping should of course be done in the vertical blank area (after a VDP interrupt). Another idea/use for double buffering is of course to draw complex screens in the back, while other things are happening (semi multitasking), and when needed, the screen can seem to be updated in a split second (using the flip technique). Double buffering, or at least more than one screen in memory (not necessarily VDP), can be used for different effects. Edited January 1, 2012 by sometimes99er Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 1, 2012 Share Posted January 1, 2012 Back in the day I used Mini Memory. In 2004 I started using TIasm. I think I only picked up on Asm994a when this forum started. Today I tried out Editor/Assembler and I think I figured out what works and what not. Also pasting, and file formats. If we make all things work with both Asm994a and E/A (emulation and real deal) we might please a broader audience (maybe more input and learn something in the process), but doing so takes more time. Okay, if we just stick with Asm994a ? Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 1, 2012 Share Posted January 1, 2012 (edited) Setting all registers in the VDP can be done with a bit of code and 8 bytes of data. I saw Mark Wills do something like this with his "Game of life" thing or was it something else. Quite clever, yet totally obvious. Firing up Classic99 and selecting XB and EA3, produces these codes in the Debugger. 00, E0, 00, 20, 00, 06, 00, 07 00, E0, 00, 0E, 01, 06, 00, F3 Differences in register 3, 4 and 7. Look up the definitions at Thierry Nouspikel's website. We'll simply just force to XB settings for all 8 VDP registers. This will then work along the way for Cartridge, XB and EA. We'll try and do screen updates as fast as we can, and won't worry about double buffering for now. VDP registers will then stay fixed as set until we exit game. Edited January 1, 2012 by sometimes99er Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 1, 2012 Share Posted January 1, 2012 (edited) Well, let's just say, we'll be setting all 8 VDP registers, not to rely on what was before. The assembled EA3 code should then run from both XB and EA. And we can use the same set in a cartridge version. 00, E0, 00, 20, 00, 06, 00, 07 We want sprites to be both 16x16 (double sized) and magnified. 00, E2, 00, 20, 00, 06, 00, 07 We'll leave the Screen Image Table (SIT) at >0000 - >02FF. We'll leave the Sprite Attribute Table (SAT) at >0300 - >037F. We'll set the Color Table (CT) at >0380 - >039F (>0E * >40). 00, E2, 00, 0E, 00, 06, 00, 07 We'll set the Character Pattern Table (CPT) at >0800 - >0FFF (>01 * >800). 00, E2, 00, 0E, 01, 06, 00, 07 We'll set the Sprite Pattern Table (SPT) at >1000 - >17FF (>02 * >800). 00, E2, 00, 0E, 01, 06, 02, 07 And finally we want black border. 00, E2, 00, 0E, 01, 06, 02, 01 Edited January 1, 2012 by sometimes99er Quote Link to comment Share on other sites More sharing options...
jchase1970 Posted January 1, 2012 Share Posted January 1, 2012 I to was thinking about just coding 10 bits per line and wasting the 6 bits. Increasing the screen data from 9 bytes to 14 bytes, but I dont think it is to much. I think the duplicate screens will read the same byte map. Here is how I am thinking to pack the bit 15 bytes per screen Byte 1 FF screen color info. We need it somewhere was going to put it with the screen map but decided to locate it somewhere else cause duplicate screen will be using the same byte map but need a different color. So we need 30 bytes for foreground/background colors. In my demo I didnt set background but the game has different background colors in the black and white castle areas So for the bit packing for the screen I'm going to draw the screen from left to right top to bottom but Im going to read the bits right bit first one Word per line FEDCBA9876543210 There is 2 pieces of info I need for each screen, 1) How does the 2 half of the screen draw, same or mirrored. This will be bit A of the first word, 1=mirrored. 2) Is it a castle map. This I need to know to add the arrow slits and it will help when adding sprite for the gate. The castle is the only screen with "Bling" added to it. This will be bit B of the first word, 1=castle. Words 2-7 (bytes 3-14) will be straight 10 bit of screen info. Doing it this way leaves 4 bits in first word and 6 in next 6 words of space, that is 40 bits. I dont know of anything to use these for atm....... No to the next issue, what to number the screens. I need some kind of order to the layout of the 30 screens to code the data. I'm going off this image here for my work map. So do I start top left and number the screens left to right top to bottom, number them in sets according to the castle they are with, or what? Maybe there is some shortcut logic here that makes it easy to know what screen to load next when you exit a certain spot to the next? Guess I'll look at this for a while and see if I see any pattern. Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 2, 2012 Share Posted January 2, 2012 (edited) So we need 30 bytes for foreground/background colors. In my demo I didnt set background but the game has different background colors in the black and white castle areas Looks to me as if the border is always black and the background is gray. If that's the case then 30 rooms need 15 bytes of foreground color info. So you wanted to have color info all located separately ? Edited January 2, 2012 by sometimes99er Quote Link to comment Share on other sites More sharing options...
jchase1970 Posted January 2, 2012 Share Posted January 2, 2012 So we need 30 bytes for foreground/background colors. In my demo I didnt set background but the game has different background colors in the black and white castle areas Looks to me as if the border is always black and the background is gray. If that's the case then 30 rooms need 15 bytes of foreground color info. So you wanted to have color info all located separately ? Inside the white and black castle the colors are inverted. Foreground is grey and path is orange. These are only in games 2 and 3. Quote Link to comment Share on other sites More sharing options...
jchase1970 Posted January 2, 2012 Share Posted January 2, 2012 So about screen layout. Based on game three which is random item locations. Keys cant be in castles or you might not be able to get in Keys need to appear in first 16 screens outside of castles Screens outside of castles are 1-16 Chalice should be in black castle or white castle 17-24 Black castle room 25 nothing will be in screens higher then 25 3 Castle screens 26,27,27 Inside yellow castle 29 Secret room 30 This will make random locating ranges easy Random locate keys 1-16 Random locate Chalice 17-24 Random locate Dragons,Magnet,Bridge,Bat 1-25 Now 2 screens change, the room in the black castle, which according to this drawing stays in game 2,3 but has 2 exits instead of 1 and 1st of 3 dark maze screens, in game 1 it is just a room. At first I was just thinking relocate memory based on game selection, but if this is a cartridge we cant do that so now I'm thinking add to more screens. 31 black castle single room 32 dark maze single room nothing will random locate in these as they don't exist in game 3. This now gives me a screen map looking like this, Any thoughts. Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 2, 2012 Share Posted January 2, 2012 Oh yes, of course. We gotta watch the original, disassembly here, and numbering of the rooms is important. For example the chalice can only exist in rooms 13-1A for level 3. byte >13,>1A ; Chalice byte >01,>1D ; Red Dragon byte >01,>1D ; Yellow Dragon byte >01,>1D ; Green Dragon byte >01,>1D ; Sword byte >01,>1D ; Bridge byte >01,>1D ; Yellow Key byte >01,>16 ; White Key byte >01,>12 ; Black Key byte >01,>1D ; Bat byte >01,>1D ; Magnet Quote Link to comment Share on other sites More sharing options...
jchase1970 Posted January 2, 2012 Share Posted January 2, 2012 Oh yes, of course. We gotta watch the original, disassembly here, and numbering of the rooms is important. For example the chalice can only exist in rooms 13-1A for level 3. byte >13,>1A ; Chalice byte >01,>1D ; Red Dragon byte >01,>1D ; Yellow Dragon byte >01,>1D ; Green Dragon byte >01,>1D ; Sword byte >01,>1D ; Bridge byte >01,>1D ; Yellow Key byte >01,>16 ; White Key byte >01,>12 ; Black Key byte >01,>1D ; Bat byte >01,>1D ; Magnet That's great, and very close to what I was guessing at, only difference really is the keys. Black key 1st 18 screens White key can be in black maze Yellow key anywhere I can work up a perfect layout from this. Thanks Quote Link to comment Share on other sites More sharing options...
jchase1970 Posted January 2, 2012 Share Posted January 2, 2012 (edited) I was looking at the way they stored the room data and they have another space saver that I never thought of. Rooms are arranged in memory to share the top or bottom line in memory. IE using 2 Hex values for example only *ROOM1 TOP EXIT ROOMS ROOM1 DATA >FE *11111110 DATA >80 *10000000 DATA >80 *10000000 DATA >80 *10000000 DATA >80 *10000000 DATA >80 *10000000 *NEXT LINE SHARED IN 2 ROOMS *ROOM2 BOTTOM EXIT ROOMS ROOM2 DATA >FF *11111111 DATA >80 *10000000 DATA >80 *10000000 DATA >80 *10000000 DATA >80 *10000000 DATA >80 *10000000 DATA >FE *11111110 So anytime a pattern is needed for room type 1 point to ROOM1 and read bytes for 7 rows Same for room 2 point to ROOM2. 13 lines of data drawing 14 rows I'm excited to see how small I can make the room data, lol. Edited January 2, 2012 by jchase1970 Quote Link to comment Share on other sites More sharing options...
jchase1970 Posted January 3, 2012 Share Posted January 3, 2012 (edited) So I came out with 23 different screens and all of them can be linked either top or bottom except 1. That means 22 screens need 12 bytes and 1 screen needs 14 bytes. Making it 278 bytes! Now for the record there is 3 bytes of wasted space per screen, but laying it out this way makes it easier to program. But If I did pack it as tight as possible it could be packed into 209 bytes. Here is a small section, excluding the hex values cause I have not done that yet. SOUTH *0000 0111 1111 1111 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 NORSOU *0000 0111 1111 1100 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 NORTH *0000 0111 1111 1100 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 EWS *0000 0111 1111 1111 Oh and Sometimes you are right the path is always grey, but in the black castle and the dark maze the foreground is also grey. The area lite by your torch is orange. Not sure how we are going to implement that? The torch lights a 9x9 character square around the player showing the path as grey. Edited January 3, 2012 by jchase1970 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 3, 2012 Share Posted January 3, 2012 There are plenty of challenges. Especially the torch effect. Collision detection. Bridge size and crossing. I think we should go by the original room definition, layout etc. Then we won't be caught with trousers down and have to do as much going back and change data and code. Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted November 15, 2013 Share Posted November 15, 2013 This still has my interest. I saw this nice presentation (on YouTube)http://www.youtube.com/watch?v=aNyebnxV9R8Also went to the website of Warren Robinett, designer of this 2600 cartridge, Adventure. There's a nice PowerPoint slideshow there. 1 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted November 15, 2013 Share Posted November 15, 2013 Adventure is a main game mentioned in Ernest Kline's Ready Player One book, which I highly recommend reading if you haven't 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted November 15, 2013 Share Posted November 15, 2013 Well, I'd better get it. http://www.youtube.com/watch?v=NNblOabjyns 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted November 15, 2013 Share Posted November 15, 2013 This still has my interest. I saw this nice presentation (on YouTube) Also went to the website of Warren Robinett, designer of this 2600 cartridge, Adventure. There's a nice PowerPoint slideshow there. I'm coining a new word for this: Kavanism Kavan, this is good natured ribbing. I actually have grown kind of fond of your wild font displays - they certainly highlight your enthusiasm! 3 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted November 16, 2013 Share Posted November 16, 2013 Well, I'd better get it. http://www.youtube.com/watch?v=NNblOabjyns The TI-99/4 is actually mentioned in the book 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted November 16, 2013 Share Posted November 16, 2013 (edited) This still has my interest. I saw this nice presentation (on YouTube) http://www.youtube.com/watch?v=aNyebnxV9R8 Also went to the website of Warren Robinett, designer of this 2600 cartridge, Adventure. There's a nice PowerPoint slideshow there. Any one else notice all the Mirrored mapping of memory in the Atari works very much like the SAMS ability to mirror RAM? A BIG difference is the amount of memory available for the TI SAMs is 1 Meg vs Atari is only 128K. Edited November 16, 2013 by RXB Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.