Indenture

[Zoyx]

Older version by Nukey

[Nukey Shay]

I really like the idea of Indenture on the 2600... Sounds like the idea of a using a 3-line kernel for it was a non-starter, so I took the liberty of trying a 2-line kernel that might work without having to interlace.

 

It's actually a hybrid 4-line/2-line kernel: P1/P0/ball updates each 2 lines + PF updates each 4 lines (of course, 6 PF writes each line since it's asymmetrical.)

 

The pros are it works, and there are actually 20+ cycles free each loop for additional logic. And it's not TOO much of a RAM hog (doesn't require a PF index, for one thing.)

 

The cons are it requires a page per graphic image, which is a huge waste of ROM. On the upside, those 20+ cycles might be used to re-work it so it doesn't have to do that.

 

Thoughts?

The real downside is that it burns 7 bytes of temp ram above the original game. I'm currently trying to figure out a way to save ram among objects. Merging delta with state is one way (which saves 1 byte for each AI object).

 

Saving romspace is not important. Saving ram is essential. Otherwise, there's little chance of putting in all of Indenture's objects without adding ram to the cart.

[e1will]

The real downside is that it burns 7 bytes of temp ram above the original game. I'm currently trying to figure out a way to save ram among objects. Merging delta with state is one way (which saves 1 byte for each AI object).

 

Saving romspace is not important. Saving ram is essential. Otherwise, there's little chance of putting in all of Indenture's objects without adding ram to the cart.

 

Seems like there are probably still some opportunities for combining RAM bytes, at the expense of some outside-the-kernel cycles to manipulate them. For example, all 5 gate states could probably be combined into two bytes, freeing up 3:

 

BYTE 1

bit 7 = yellow gate open

bit 6 = white gate open

bit 5 = black gate open

bit 4 = green gate open

bit 3 = flashing gate open

bits 0-2 = which gate is currently being opened or closed (000 = none, 001 = yellow... 101 = flashing)

 

BYTE 2

bits 0-2 = state for currently opening/closing gate (8 positions)

bits 3-7 = free

 

You could then use bits 3-7 of the second byte to store CarriedObj, since there are (I think) less than 32 objects that can be carried.

 

Or maybe you've made some of these optimizations already... I'm just going off the Adventure(asymmetrical).asm.

 

--Will

[e1will]

Also, there might be just enough free cycles in that kernel to combine PF0_L and PF0_R, and/or combine PF_BANK with something.

 

The best bet for merging PF_BANK would probably be to structure the PF data so that each playfield definition starts aligned with its bank number. For example, data in bank 0 would start at $Fxx0 or $Fxx8, data in bank 1 would start at $Fxx1 or $Fxx9, so you could just AND #$07 the PF_PTR to get the bank # for bankswitching.

 

So that's another 2 RAM bytes saved (assuming PF0_L and PF0_R could be combined without using all the extra cycles; I have tried that yet.)

 

And since bits 5-7 of the high bytes of OBJ0_GR_PTR, OBJ1_GR_PTR, PF_PTR and ENABL_PTR are insignificant, you could store a byte and a half in there, prior to entering the kernel, and that wouldn't use any kernel cycles. For example, CarryX and CarryY might fit nicely in there, if you can confirm that bits 5-7 of those will always be the same. You could then use CarryX and CarryY as PF1_L and PF1_R, and then restore their original values from the PTRs after the kernel's done. That frees up another 2 bytes.

 

--Will

[e1will]

And you could use PlayerY as PF2_L, since PlayerY could be recalculated after the kernel is done by subtracting ENABL_PTR from ball_enable.

 

EDIT: Looks like combining PF0_L and PF0_R into PF0_LR and pulling the bank # from PF_PTR only used up 4 cycles, leaving 21 cycles free including the WSYNC.

 

--Will

Edited September 9, 2009 by e1will

[Lord Thag]

 

Damn.

 

I am SO there when this gets done!

[yorgle]

Oooh. I've been away too long. This looks great, guys.

[Godzilla]

woot! awesome, guys, awesome

[e1will]

I've been making some progress on a 2600 port of this. Some work-in-progress binaries posted here.

 

--Will

[NE146]

So... which one of you guys made this site? Just curious.

 

http://home.comcast.net/~eichler2/indent/Indent.htm

 

====================

 

On that note, anyone ever check out PIXA on ios? I'm debating whether it's worth the 99 cents.. hmmm

https://itunes.apple.com/us/app/pixa/id826977016?mt=8

 

 

Edited May 13, 2014 by NE146

[+Gemintronic]

No idea. All I can add to this topic is that I was given permission by the author of Indenture to make a port. Haven't done much with it, though.

[bradhig]

I would love to see it on an atari 2600 ,but the map might be too big for 4K.

[SeaGtGruff]

I would love to see it on an atari 2600 ,but the map might be too big for 4K.

 

I don't think all of the mazes would be possible on the 2600, because some of them have too high of a horizontal resolution. Those screens would need to be redesigned for the 2600.

[+Gemintronic]

I think there's no way I'd constrain myself to 4k. The internal debate I've always had is to go procedural and retain the Indenture extras or go for strict authenticity.

[Nukey Shay]

All of the screens can be done on the 2600 AFAIK, there doesn't appear to be any that exceed 40 pixels horizontally. Movement collision would need to be handled slightly different than Adventure's code, tho...because you run into problems wherever there is only a 1-pixel playfield gap to move along (which is probably why W.R. made all of his passages at least 2 pixels wide).