Jump to content
IGNORED

Bouncy's obstacle course


Asmusr

Recommended Posts

I want to give feedback to my last post, the now latest version is working smooth on my console. ;-) :thumbsup:

Very nice and entertaining game!

 

Thanks. I haven't done anything to account for the change in smoothness. After your last feedback I also tried the previous version on real hardware without noticing anything.

Link to comment
Share on other sites

Obligatory. Remember: cut on the waste side of the line.

 

The label I endorse is the one ti99iuc posted. This one is missing the correct copyright notice and has a Texas Instruments logo instead. TI would probably have tried to block a game like this as they did for the Atarisoft titles.

Edited by Asmusr
Link to comment
Share on other sites

 

The label I endorse is the one ti99iuc posted. This one is missing the correct copyright notice and has a Texas Instruments logo instead. TI would probably have tried to block a game like this as they did for the Atarisoft titles.

 

My apologies.

  • Like 1
Link to comment
Share on other sites

  • 3 months later...
  • 2 years later...
  • 1 year later...

@Asmusr, As you know from the Assembly Language thread, I'm trying to basically accomplish the same thing you have done with Bouncy for my platformer game project. I'm trying to grok your bank-switching scheme used in Bouncy as it seems like the same approach would do what I need for my project. Unfortunately, it's a bit beyond my newbie comprehension what is really going on just looking at the source-code. I see you use a kind of header template presumably for the two designated bank files:

 

*********************************************************************
*
* Trampoline code for executing bank 1 routine
*
* r13: address of bank 1 routine
*
bank_1_exec:
       .proc
bank_1_branch:
       seto @bank_1
       bl   *r13
       seto @bank_0
       .endproc
*// bank_1_exec

 

And you have 2 source files named "bank0.a99" and "bank1.a99", each without any header applied statically in the source code.  The make.bat seems to use a 16-bit windows program called "pad.exe" to create the bank .bin files(?)

tools/pad.exe obstacle-course_b0.bin obstacle-d.bin 8192
tools/pad.exe obstacle-course_b1.bin obstacle-c.bin 8192

 

..but there is no specific documentation on what's going on there (as expected, it was for your own project, not mine!).

 

So questions:

 

1. Are you bank switching between 2 ROM banks, or 1 ROM and 1 GROM?  I see the following routine in one of the source files:

*********************************************************************
*
* Read character set from GROM
*
read_grom_chars:
       .proc
       li   r0,ptrntb+>300
       li   r3,8
read_grom_chars_1:
       bl   @vwad
       li   r4,charset
       li   r5,32
read_grom_chars_2:
       clr  r1
       movb *r4+,@r1lb
       ai   r1,-32
       mov  r1,r6
       sla  r1,3
       s    r6,r1
       ai   r1,1716
       movb r1,@grmwa
       movb @r1lb,@grmwa
       clr  *r15                       ; Top line
       li   r2,4
read_grom_chars_3:
       movb @grmrd,r1
       srl  r1,1
       movb r1,*r15
       dec  r2
       jne  read_grom_chars_3
       li   r2,3
read_grom_chars_4:
       movb @grmrd,*r15
       dec  r2
       jne  read_grom_chars_4
       dec  r5
       jne  read_grom_chars_2
       ai   r0,>800
       dec  r3
       jne  read_grom_chars_1
       .endproc
*// read_grom_chars

 

2. Why are you (apparently) applying the bank headers after assembly, instead of just including them in the static source files?

 

3. Did you create the pad.exe program? If so, would you be able to create a 64-bit version that *might* have a hope of running under wine on my Mac?  If not, where did it come from?  Failing that, what does it do, maybe I can craft something similar myself.

 

4. Ditto for the lz4.exe program. I'm going to need some good compression for my maps.

 

Link to comment
Share on other sites

Okay, after a bit more studying and referencing another ROM bank switching example from @PeteE I think I understand how this is working now.

 

To answer my own questions from above:

 

1. Are you bank switching between 2 ROM banks, or 1 ROM and 1 GROM?

A: You are bank switching between 2 8K ROM banks, no GROM.

 

I see the following routine in one of the source files:

Why are you using a function to copy chars from GROM if you aren't using a GROM?

 

2. Why are you (apparently) applying the bank headers after assembly, instead of just including them in the static source files?

A: You are not. You are defining your banks in 'obstacle-course.a99' and including the other source files into them there.

 

3. Did you create the pad.exe program? If so, would you be able to create a 64-bit version that *might* have a hope of running under wine on my Mac?  If not, where did it come from?  Failing that, what does it do, maybe I can craft something similar myself.

A: I can readily combine the bank files myself, so should have no use for pad.exe.

 

4. Ditto for the lz4.exe program. I'm going to need some good compression for my maps.

A: I could still use the lz4.exe program though, is that available as as 64-bit app (or better yet, a Java version)?

 

 

Link to comment
Share on other sites

One note on GROM: just because the cartridge contains no GROM does not mean it has no use for existing GROM. The console has three GROMs that "may" have assets in them that you want to use, like the standard character set.

 

Sometimes, folks also put the trampoline code for bank switching into the scratchpad RAM, as that may help conserve space in individual banks. There are a lot of optimization tricks that various folk here have used to speed up their code, compact the space required for routines (rollup/unroll routines to push large amounts of data), or just to make a cartridge implementation possible. It's all good.

Link to comment
Share on other sites

19 minutes ago, Ksarul said:

The console has three GROMs that "may" have assets in them that you want to use, like the standard character set.

Yeah, when John Plaster wrote Tombstone City he said that he stored the graphics in GROM and a linked list for 9 monsters in scratchpad ram. The rest was 9900 code on the cartridge.  

Link to comment
Share on other sites

4 hours ago, retrodroid said:

A: I could still use the lz4.exe program though, is that available as as 64-bit app (or better yet, a Java version)?

I didn't create that. I don't remember where I got it from, but lz4 is a standard compression format,

Link to comment
Share on other sites

8 hours ago, Asmusr said:

To save space I'm copying the standard character set from the system GROM. 

Ah okay, makes sense.

8 hours ago, Asmusr said:

I didn't create that. I don't remember where I got it from, but lz4 is a standard compression format,

Fair enough. A simple search turns up many options. I'm trying to avoid implementing my own RLE scheme, at least for now.

 

Btw, your code is a thing of beauty!  

Edited by retrodroid
  • Like 1
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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