293 replies to this topic

[sometimes99er]

jchase1970, on Thu Dec 29, 2011 10:13 AM, said:

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 by sometimes99er, Fri Dec 30, 2011 4:50 PM.

[jchase1970]

sometimes99er, on Fri Dec 30, 2011 2:26 PM, said:

jchase1970, on Thu Dec 29, 2011 10:13 AM, said:

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

[sometimes99er]

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.

[jchase1970]

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.

[jchase1970]

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 by jchase1970, Sat Dec 31, 2011 9:27 PM.

[sometimes99er]

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 by sometimes99er, Sun Jan 1, 2012 4:43 PM.

[sometimes99er]

jchase1970, on Sat Dec 31, 2011 9:20 AM, said:

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 by sometimes99er, Sun Jan 1, 2012 2:49 AM.

[sometimes99er]

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 ?

[sometimes99er]

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 by sometimes99er, Sun Jan 1, 2012 4:44 PM.

[sometimes99er]

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 by sometimes99er, Sun Jan 1, 2012 9:36 AM.

[jchase1970]

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.

[sometimes99er]

jchase1970, on Sun Jan 1, 2012 10:27 AM, said:

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 by sometimes99er, Mon Jan 2, 2012 8:22 AM.

[jchase1970]

sometimes99er, on Mon Jan 2, 2012 8:22 AM, said:

jchase1970, on Sun Jan 1, 2012 10:27 AM, said:

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.

[jchase1970]

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.

[sometimes99er]

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

[jchase1970]

sometimes99er, on Mon Jan 2, 2012 2:54 PM, said:

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

[jchase1970]

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 by jchase1970, Mon Jan 2, 2012 4:32 PM.

[jchase1970]

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 by jchase1970, Mon Jan 2, 2012 10:18 PM.

[sometimes99er]

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.