Jump to content
IGNORED

(WIP) Super Pixel Brothers


catsfolly

Recommended Posts

Warning: This game is really blocky. If you absolutely hate blocky games, this is not the game for you. Might as well quit reading now.
Catch you next project. Later! Bye...

Still here? Good.

Here's the story - Back around 2010-2011, some guy who calls himself RetroBrad designed his own portable game system. Instead of
using a boring ol' LCD panel for his display, he used an 8 by 8 array of multicolor led lights. So the whole display was 64 pixels.

 

post-14916-0-81156800-1419347284_thumb.jpg

What can be done with such a low res display? Well it turns out that his favorite childhood game was Super Mario Brothers, so
he wrote a platform game for his system that he called "Super Pixel Brothers". Despite the low resolution, it is quite fun to play.

 

https://www.youtube.com/watch?v=7sEUDSz9XuY

"So what?" you ask. "What do we care?"

Here's the deal - Super Pixel Brothers was written in Basic, and the source code was released as open source. And now, thanks
to Nanochess and friends, Intellivision has its own basic compiler - IntyBasic!

So, all we have to do is slap the Super Pixel Brothers Basic source into IntyBasic, hit compile, and we can enjoy Mario style platform goodness?

Unfortunately, it's not that simple...

First, RetroBrad's portable system has a unique architecture, with red, green, and blue, bit planes combining to form each pixel.
The Intellivision has its own unique design, with gram and grom and backtab and the like... The controls and sound systems are completely different, too.

Second, not all basics are created equal. For example, the Basic RetroBrad used (Swordfish Basic) had mult-line "if then else endif" statements, whereas IntyBasic has single line if statements.

In short, it was a lot of work.

But now, you can enjoy low res platforming goodness on your Intellivision.

 

One catch. - The game requires extra cartridge ram to work. Currently (Dec 23, 2014), the only way to enable cartridge ram in an IntyBasic

program is to use the --jlp extension when compiling. The resulting program will only run under the jzintv emulator with the --jlp switch enabled.

In short, the command to run the game needs to look something like this:

jzintv  --jlp -z1  spb.rom

The game will also theoretically work on a LTO flash card, but I don't have one to try it on...

 

Currently, it doesn't work on a cuttle cart 3 or Intellicart. In theory, the assembly file generated by IntyBasic could be hacked to run on a cuttle cart 3 (since the game only uses the extra ram and not any other jlp features). But I haven't succeeded in doing that yet. Perhaps in the future more elegant solutions will arise...

 

In the meantime, give Super Pixel Brothers a try in the jzintv emulator. It is more fun than it looks. Think of it as 20 levels of platforming fun to enjoy while you wait for Princess Quest to come out...

 

post-14916-0-10873300-1419348257.gif

 

spb.rom

 

spb.bas

 

The original source code can be downloaded from this page:

http://www.bradsprojects.com/super-pixel-bros/

 

Have fun! Send comments!

 

Catsfolly

 

 

 

  • Like 8
Link to comment
Share on other sites

 

It's not showing me the RAM in the cfg file (typing rom2bin spb.rom). Maybe I'm doing something else wrong... will try again.

No, for some reason this game (compiled with the --jlp switch) works differently - the ram doesn't show up in the config file.

 

The extra ram used by the game is:

0x8040                  SYSTEM:	ORG $8040, $8040, "-RWBN"
0x8040                  STACK:	RMB 24
0x8058                  V58:	RMB 1	; #BTADRS
0x8059                  V78:	RMB 1	; #DCTEMP
0x805A                  V79:	RMB 1	; #DCTEMP2
0x805B                  V53:	RMB 1	; #DINDEX
0x805C                  V29:	RMB 1	; #HISCORE
0x805D                  V52:	RMB 1	; #INDEX
0x805E                  V27:	RMB 1	; #SCORE
0x805F                  V28:	RMB 1	; #SCOREOLD
0x8060                  V54:	RMB 1	; #SLTEMP
0x8061                  V55:	RMB 1	; #SLTEMP2
0x8062                  V80:	RMB 1	; #TEMP
0x8063                  V77:	RMB 1	; #TEMPDATA
0x8064                  Q1:	RMB 1024	; #LEVELBUFFER
0x8464                  _SYSTEM:	EQU $

Link to comment
Share on other sites

Oh! yes, intvnut said that the --jlp option in jzintv is incompatible with putting RAM mapper in the cfg file, so IntyBASIC doesn't generate the mapping.

 

Talking about that, using the --jlp option in IntyBASIC also activates use of multiplication/division accelerator, I've plans to put a --cc3 switch that only activates RAM but not the usage of multiplication/division accelerator.

  • Like 3
Link to comment
Share on other sites

Oh! yes, intvnut said that the --jlp option in jzintv is incompatible with putting RAM mapper in the cfg file, so IntyBASIC doesn't generate the mapping.

 

Talking about that, using the --jlp option in IntyBASIC also activates use of multiplication/division accelerator, I've plans to put a --cc3 switch that only activates RAM but not the usage of multiplication/division accelerator.

 

Can I assume that if you're multiplying by 240 or 960 it'll use the accelerator? How about 11 or 10 or 3 or 5 or 6 or 7?

 

Yes, a switch for RAM but not acceleration would be great. ;)

  • Like 1
Link to comment
Share on other sites

 

Can I assume that if you're multiplying by 240 or 960 it'll use the accelerator? How about 11 or 10 or 3 or 5 or 6 or 7?

 

Yes, a switch for RAM but not acceleration would be great. ;)

 

For almost everything except the simplest multiplications, like x2, x4, x8 and so.

Link to comment
Share on other sites

catsfolly, could you provide the required sticdefs.bas file? I'm trying to re-compile using only bit-shifting multiplication and division (and trying to cheat with the /10 by changing that to /8, at least for now).

Oops, I forgot to include that.

 

Here it is:

 

sticdefs.bas

 

 

The game only does multiplication the normal CP1600 way.

Link to comment
Share on other sites

There's clearly something technical that I'm failing to grasp. How the hell does a game like this require extra RAM? :P

The player can destroy any block on the level that they can collide with, and they can scroll back to any area in the current level that they have previously been to.

 

So, to maintain the state of the world requires:

 

120 columns in a level * 8 bits vertical * 4 bits per pixel (rgb and collision) = 3840 bits = 480 bytes of storage. to store one level.

 

So extra ram is required for a straightforward storage of the level data.

 

I could try just storing 1 bit per level block in memory (to indicate the existence of the block) and then use the level data in the rom image to determine the characteristics of the block if it exists. This would require only 120 bytes per level, but it might be slow at scrolling the level and colliding, etc.

 

Catsfolly

  • Like 1
Link to comment
Share on other sites

The player can destroy any block on the level that they can collide with, and they can scroll back to any area in the current level that they have previously been to.

 

So, to maintain the state of the world requires:

 

120 columns in a level * 8 bits vertical * 4 bits per pixel (rgb and collision) = 3840 bits = 480 bytes of storage. to store one level.

 

So extra ram is required for a straightforward storage of the level data.

 

I could try just storing 1 bit per level block in memory (to indicate the existence of the block) and then use the level data in the rom image to determine the characteristics of the block if it exists. This would require only 120 bytes per level, but it might be slow at scrolling the level and colliding, etc.

 

Catsfolly

 

Ahhhhhhhhhhhhhhh. In the original SMB you couldn't go backwards, so there was never a need to store an entire level data (other than in ROM, which we have gobs of). Obviously this is a quirk introduced into the handheld.

 

I love ports of ports. You end up with this wonderful mish-mash of features. A little from column A, a little from column B, with everyone leaving their own stamp on the project.

  • Like 1
Link to comment
Share on other sites

Thanks for the file. I was able to run it on my new PCB, although I'll need to spend some time to review the lines of code with "/10", because I started at level 0... it played normally, though, and loaded some proper level data into RAM.

That's great news!

 

I reviewed the code generated by IntyBasic, and it turns out there was exactly one place where I was using the accelerated multiply - in the "write lcd" code.

 

If I replace this line:

 

PRINT (WhichLevel/10%10+16)*8+0,(WhichLevel%10+16)*8+0

 

with this line:

 

print <2>WhichLevel

 

Then all the multiplies are done by the regular Intellivision processor (as far as I know).

 

Here are new versions of the program:

 

spb.rom

 

spb.bas

 

Catsfolly

  • Like 2
Link to comment
Share on other sites

The player can destroy any block on the level that they can collide with, and they can scroll back to any area in the current level that they have previously been to.

 

So, to maintain the state of the world requires:

 

120 columns in a level * 8 bits vertical * 4 bits per pixel (rgb and collision) = 3840 bits = 480 bytes of storage. to store one level.

 

So extra ram is required for a straightforward storage of the level data.

 

I could try just storing 1 bit per level block in memory (to indicate the existence of the block) and then use the level data in the rom image to determine the characteristics of the block if it exists. This would require only 120 bytes per level, but it might be slow at scrolling the level and colliding, etc.

 

Catsfolly

 

Folks often underestimate the cost of mutable level state.

 

The original SMB only allowed forward scrolling, and only kept track of about one screen's worth of off-screen detail, which help keep things bounded. As I recall, the offscreen state basically corresponded to the double-buffer allocated to hardware scrolling on the NES's PPU.

 

The Intellivision equivalent would be to store the flags in the 'extra bits' in BACKTAB, and once something went offscreen it was forgotten. That seems a bit too far beyond the spirit of the original Super Pixel Bros.

  • Like 1
Link to comment
Share on other sites

That's great news!

 

I reviewed the code generated by IntyBasic, and it turns out there was exactly one place where I was using the accelerated multiply - in the "write lcd" code.

 

If I replace this line:

 

PRINT (WhichLevel/10%10+16)*8+0,(WhichLevel%10+16)*8+0

 

You know, it's funny. One of my main motivations for adding the MPY/DIV accelerators to jzIntv was decimalization. :D And lo and behold...

Edited by intvnut
  • Like 1
Link to comment
Share on other sites

nm. new one works in jlp. for whatever reason the first rom when i first put it on with --jlp - z1 it worked. replaced with the new one it wouldnt work. replaced with old one again still wouldnt work. had to remove -z1

 

Hmm... -z1 shouldn't have anything to do with the price of fish. It should have no bearing whatsoever on the --jlp flag.

Edited by intvnut
Link to comment
Share on other sites

 

Hmm... -z1 shouldn't have anything to do with the price of fish. It should have no bearing whatsoever on the --jlp flag.

it gives an error on pi saying something like: cannot find z1.rom z1.bin z1.int etc. etc. it didnt say this until i tried to use the new rom. Then i couldnt get it to stop saying that until i removed the -z1. Strange
Link to comment
Share on other sites

it gives an error on pi saying something like: cannot find z1.rom z1.bin z1.int etc. etc. it didnt say this until i tried to use the new rom. Then i couldnt get it to stop saying that until i removed the -z1. Strange

 

Ok, that's not a jzIntv error. Somehow the flag isn't getting conveyed to jzIntv correctly.

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