Jump to content
edyensid

Indenture

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 by e1will

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...