The Southsider

The stairs look good. It's amazing how much can be accomplished with so little graphics capability as long as you exercise a little creativity. The mind really fills in the rest.

The stairs look good.  It's amazing how much can be accomplished with so little graphics capability as long as you exercise a little creativity.  The mind really fills in the rest.

 

Thanks - I also think the stairs turned out well. I'm not sure about the closed final door, but it can always be tweaked later.

 

Chris

Hi there!

 

Great update!

 

So once this game is done, you can recycle larger parts of the engine for Castlevania 2600.

 

I completely see your problems described above. I ran into all sorts of computing brickwalls with Star Fire back then, which constantly forced me to balance things out. Move tasks from the overscan to the VBLANK and back, optimize here, optimize there, trade ROM for cycles here, trade RAM for ROM there and vice-versa... all until the final balance/compromise is found

 

Greetings,

Manuel

Great update!

So once this game is done, you can recycle larger parts of the engine for Castlevania 2600.

I completely see your problems described above. I ran into all sorts of computing brickwalls with Star Fire back then, which constantly forced me to balance things out. Move tasks from the overscan to the VBLANK and back, optimize here, optimize there, trade ROM for cycles here, trade RAM for ROM there and vice-versa... all until the final balance/compromise is found

 

Hi Manuel,

 

Thanks - by the time this game is finished I think I will need a long break from 2600 programming I have now convinced myself that everything about the game is feasible on the 2600, but I can see that it is going to be a real struggle to fit it all in!

 

Chris

One thing that might help is to create macros for "sbeq", "sbne", "sbcs", "sbcc", etc. which generate the indicated branch but provide a warning if the instruction following the branch is not in the same page as the target. In many spots in your code, this won't matter (so just use ordinary branches) but where it does matter, you can use the macros and be warned if things shift in a bad way.

Some tips for avoiding some of the problems you've run into:

 

1. Magic numbers - use equates, document them & only use them for the one purpose. Same thing goes for zero page variables.

 

2. Shifting code or data - figure out what code & data needs to be at one spot (i.e. on a single page) and lock it down with an ORG. For both Skeleton/Skeleton+ and Leprechaun, the main kernel starts at $1000, just so as I added to the rest of the game it wouldn't move.

One thing that might help is to create macros for "sbeq", "sbne", "sbcs", "sbcc", etc. which generate the indicated branch but provide a warning if the instruction following the branch is not in the same page as the target.  In many spots in your code, this won't matter (so just use ordinary branches) but where it does matter, you can use the macros and be warned if things shift in a bad way.

 

Sounds like an interesting idea - you don't happen to already have these macros defined as I find the DASM macro language rather cumbersome to use. Could the same technique be used for loads, as this is where I seem to have the most problems (when the data wraps over page boundaries)?

 

Some tips for avoiding some of the problems you've run into:

1. Magic numbers - use equates, document them & only use them for the one purpose.  Same thing goes for zero page variables.

2. Shifting code or data - figure out what code & data needs to be at one spot (i.e. on a single page) and lock it down with an ORG.  For both Skeleton/Skeleton+ and Leprechaun, the main kernel starts at $1000, just so as I added to the rest of the game it wouldn't move.

 

Thanks for the tips. I find ORGs to be a bit of a pain when changing the code as I often have to go through and renumber a load of them by hand.

 

Chris

Thanks for the tips.  I find ORGs to be a bit of a pain when changing the code as I often have to go through and renumber a load of them by hand.

I'll assume you already know about the "align" assembler command.

 

What I generally do when writing 2600 code is to start out by putting *everything* in subroutines. Everything. It makes debugging, editing, and moving stuff around so much easier.

 

Of course, eventually you run out of time/room and you have to move things out of subroutines, but I have found that starting out that way makes things much much easier.

 

Just my two cents.

Sounds like an interesting idea - you don't happen to already have these macros defined as I find the DASM macro language rather cumbersome to use.

 

It's pretty straightforward.

               mac     sbpl
               bpl     {1}
               if (* ^ {1}) & $FF00
               echo "PAGE CROSSING","WARNING ",{1}," at ",*
               endif
               endm

For checking data, use

               mac     pcheck
               if (* ^ {1}) & $FF00
               echo "PAGE CROSSING","WARNING ",{1}," at ",*
               endif
               endm

and, after each data item, do a pcheck with a label to the start. The warnings are a little less than helpful as simply output, but you can search for them easily in the .lst file.

I'll assume you already know about the "align" assembler command.

 

Instead of using 'align', I like to use a macro. The macro can take an argument for how much space is needed (so it doesn't advance a page if it doesn't have to), and can output to the screen/list file how much space it's skipping.

Really enjoying the Blog so far. Best of luck!

What I generally do when writing 2600 code is to start out by putting *everything* in subroutines.  Everything.  It makes debugging, editing, and moving stuff around so much easier.  Of course, eventually you run out of time/room and you have to move things out of subroutines, but I have found that starting out that way makes things much much easier.

Just my two cents.

 

I tend not to use subroutines very much as I always think of them as an expensive operation, particulay when you are using the stack pointer for other things and you have to save/restore. However, I probably should make more use of them in my code to eliminate duplication ... it is the old cycles vs memory tradeoff

 

It's pretty straightforward <snip>. For checking data, use <snip> and, after each data item, do a pcheck with a label to the start.  The warnings are a little less than helpful as simply output, but you can search for them easily in the .lst file.

 

Thanks - these look like some really useful macros! I do use ALIGNs a lot, but they get in the way when you want to shift things around. The macro approach should make code reorganization much less tedious.

 

Chris

Really enjoying the Blog so far.  Best of luck! 

 

Thanks - I'm always surprised that people are actually reading this stuff! I'm getting a bit frustrated by the project recently as you can probably tell, but hopefully this will pass.

 

Chris

Thanks - these look like some really useful macros!  I do use ALIGNs a lot, but they get in the way when you want to shift things around.  The macro approach should make code reorganization much less tedious.

 

Another thing I sometimes do with macros: include all the .DB statements within macros (rather than having them operate directly), so that then I can rearrange the order in which items appear in the code without having to rearrange the .DBs themselves. This is especially handy if, as in many of my projects, some of the DBs are in separate .include files. I can .include all of the DB-containing macros at the start of my source file, and then arrange the actual data as I see fit.

 

Another way I use this technique is to produce an "initialized data" segment. After the minigame contest, I'll post my code to SDI to show how that works. It's very easy in many 2600 projects to waste a lot of code with "lda #this/sta here/lda #that/sta there" etc. Four bytes for each location that needs to be initialized. Using an "initialized data" segment reduces this to one byte per byte plus a small "loader":

 ldx #IDATA_END-IDATA_START-1
lp:
 lda IDATA_ROM,x
 sta IDATA_START,x
 dex
 bpl lp

Nine bytes. So if there are four or more bytes that need initialization to different values, it's a win (13 bytes vs. 16). Even if two of the bytes need the same value, it's still a win. And of course, if more data need to be initialized, it's an even bigger win.

 

Indeed, if ZP RAM is abundant, it can make sense to put small tables of constants into ZP RAM since doing so will save a byte of code space for every access to one of them. And if an address is used three or more times with abs,y addressing mode, it can be changed to (zp),y saving a byte per instance at a total cost of two bytes.

 

Of course, in most cases ZP RAM won't be more plentiful than code space. But knowing how to take advantage of initiailized data is still very useful.

Another thing I sometimes do with macros: include all the .DB statements within macros (rather than having them operate directly), so that then I can rearrange the order in which items appear in the code without having to rearrange the .DBs themselves.  This is especially handy if, as in many of my projects, some of the DBs are in separate .include files.  I can .include all of the DB-containing macros at the start of my source file, and then arrange the actual data as I see fit.

 

Another way I use this technique is to produce an "initialized data" segment.  After the minigame contest, I'll post my code to SDI to show how that works.  It's very easy in many 2600 projects to waste a lot of code with "lda #this/sta here/lda #that/sta there" etc.  Four bytes for each location that needs to be initialized.  Using an "initialized data" segment reduces this to one byte per byte plus a small "loader":

 

Thanks for the suggestions. I did something similar to the initialized data segment in Hunchy 2 (on your suggestion). I haven't done this in PoP yet, but I will be doing a big reorganisation as soon as I have a free evening.

 

Chris