Fishing Derby (?)

[+MrFish]

8 hours ago, adam242 said:

It's been done.

Exactly!... no Outrun music though.

 

[+MrFish]

The main thing that needs to be updated in any racing game is the control mechanism. Joysticks make terrible driving controllers, and there are several better ones readily available: the driving controller, of course, is the first choice, and even the paddle would be fine, if programmed properly.

 

[Wrathchild]

@glurk in making an xex wrapper for this cart I noticed a couple of minor things that won't affect the cart running itself but are good to know.

 

Firstly, the Init and Run addresses at $BFFE and $BFFA are both pointing to the same address.

Quite often you'll find that the init vector points to an RTS and the run vector to the entry point.

 

Secondly, you were enabling DLI interrupts before the new screen display list (at $480) was in place.

This works ok as with the cart present the dlist is pointing to $9C20 and this has no interrupt flags.

When making the xex, code is relocated to the cart area but as no cart is present then dlist is at $BC20.

So when before the code can switch over to the new dlist, it begins interpreting cartridge data as the dlist.
This contains DLI flags which cause the interrupt to run and mess things up.

This was circumvented in the wrapper by moving the $BC20 dlist to $9C20 and switching to use that.

 

 

[glurk]

Wrathchild-

 

One of the reasons I like developing for the CAR format is to avoid all that chicken/egg housekeeping stuff.

 

I intentionally set the INIT/RUN addresses like that to avoid the ugly and pointless blue editor screen that seems to pop up when INIT points to an RTS, since the game takes over the screen anyways.  I just think it looks better that way.  Is it a problem?

 

And looking at my code, one of the first things it does (after an SEI) is to copy the display list to RAM at $480, point to it, and then only afterwards, setup up DMA and enable interrupts.  I've never quite figured out the "perfect" way to do all of that.

 

I'm not saying you are wrong, but could you look at the code and tell me what specifically it SHOULD be doing?  I've moved all that initialization stuff around before, and what I have now is the "standard" way I've had it set up for a while.  It seems to work OK, so I haven't messed with it anymore...

 

[Wrathchild]

Sure.

 

INIT/RUN - no problem here as effectively you never return from the INIT and so the RUN won't get executed and so, as you point out, the usual screen initialisation etc aren't executed.

Titles typically in this instance turn the display off in the init and even setup the new display before the RTS was done.

The alternative, and there are carts that do this, is to opt for the diagnostic cart model by setting Bit-7 of $BFFD.

However this will actually not do some of the things you depend on, like initialising the VBI vectors, and so isn't a good option here.

Although providing slimmed down versions of the OS vblank code that can be good, for example where you switch out the OS and use the RAM instead.

 

 

The SEI is not sufficient as the clue is in the name, a VBI is a non-maskable interrupt.

The OS defaults NMIEN to $40 and so VBI's are fired. One option would be to clear that during init.

 

 

For the DLI, you first set NMIEN to $C0 at $AF0A after setting the screen & colour details, and yes the SDLSTL/H pointer is set to $480 and you have copied the dlist instructions there.

Upon returning, having called SETVBV, you again set the NMIEN to $C0 at $A008. However, still at this point the h/w dlist pointer, DLISTL/H, is unchanged until the next vblank is run.

So that was why there was potential in the xex version for the $BC20 dlist to continue to be used and hence cause grief. Again, no problem with your cart because you know the state.

But in other titles you will often see a wait for the next VBI to be done and then enable the interrupts so they are ready for when the first line with it flagged is hit.

 

 

[rdefabri]

Someone else mentioned Kung Fu Master, a game that made it to the 2600 and 7800, as well as the C64, but not the 400/800.

 

I would also say, given the incredible high quality work with Prince of Persia, what about Another World?  That would be cool!

[+Adam+]

On 1/13/2022 at 10:33 PM, glurk said:

Back on topic...  I'm actually at a loss as far as thinking of another port. (...)

 

Maybe "Solaris" or "Haunted House" (mentioned before)?

 

For a moment I was thinking that maybe you could consider a port of some modern homebrew A2600 game - with the permission of original creator(s) of course, probably majority of them would be happy to share the source code - but nowadays most of A2600 games are written in batari Basic I suppose?