Jump to content

Photo

(WIP) Super Pixel Brothers

blocky IntyBasic fun

70 replies to this topic

#1 catsfolly OFFLINE  

catsfolly

    Dragonstomper

  • 704 posts
  • Location:Japan

Posted Tue Dec 23, 2014 9:37 AM

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.

 

SPBCircuitBoard.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....h?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...

 

mvi_0030.gif

 

Attached File  spb.rom   23.06KB   262 downloads

 

Attached File  spb.bas   128.97KB   224 downloads

 

The original source code can be downloaded from this page:

http://www.bradsproj...per-pixel-bros/

 

Have fun! Send comments!

 

Catsfolly

 

 

 



#2 pimpmaul69 ONLINE  

pimpmaul69

    River Patroller

  • 4,821 posts
  • INTV Brotherhood Technician
  • Location:Colorado

Posted Tue Dec 23, 2014 11:13 AM

sweet! another game. i can never complain about that.



#3 nanochess ONLINE  

nanochess

    River Patroller

  • 4,727 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Tue Dec 23, 2014 12:02 PM

Wow! simply amazing :)



#4 5-11under OFFLINE  

5-11under

    River Patroller

  • 3,202 posts
  • Location:Ontario, Canada

Posted Tue Dec 23, 2014 12:39 PM

I'm wondering if it's possible post the BIN+CFG files, rather than the ROM file? Thanks!



#5 nanochess ONLINE  

nanochess

    River Patroller

  • 4,727 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Tue Dec 23, 2014 1:00 PM

I'm wondering if it's possible post the BIN+CFG files, rather than the ROM file? Thanks!

 

There is a rom2bin utility in jzintv



#6 5-11under OFFLINE  

5-11under

    River Patroller

  • 3,202 posts
  • Location:Ontario, Canada

Posted Tue Dec 23, 2014 1:07 PM

 

There is a rom2bin utility in jzintv

 

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.



#7 catsfolly OFFLINE  

catsfolly

    Dragonstomper

  • Topic Starter
  • 704 posts
  • Location:Japan

Posted Tue Dec 23, 2014 1:44 PM

 

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 $



#8 nanochess ONLINE  

nanochess

    River Patroller

  • 4,727 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Tue Dec 23, 2014 2:00 PM

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.



#9 wongojack OFFLINE  

wongojack

    River Patroller

  • 2,273 posts
  • Location:Texas

Posted Tue Dec 23, 2014 2:19 PM

I'll never really understand the fascination with SMB, but I do understand the desire to do something no one thinks is possible and requires you to bend your brain in half solving problems, so I like this project - a lot.



#10 5-11under OFFLINE  

5-11under

    River Patroller

  • 3,202 posts
  • Location:Ontario, Canada

Posted Tue Dec 23, 2014 2:36 PM

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



#11 5-11under OFFLINE  

5-11under

    River Patroller

  • 3,202 posts
  • Location:Ontario, Canada

Posted Tue Dec 23, 2014 3:09 PM

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



#12 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,880 posts

Posted Tue Dec 23, 2014 3:23 PM

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



#13 nanochess ONLINE  

nanochess

    River Patroller

  • 4,727 posts
  • Coding something good
  • Location:Mexico, Mexico

Posted Tue Dec 23, 2014 4:21 PM

 

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.



#14 catsfolly OFFLINE  

catsfolly

    Dragonstomper

  • Topic Starter
  • 704 posts
  • Location:Japan

Posted Tue Dec 23, 2014 4:24 PM

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:

 

Attached File  sticdefs.bas   2.23KB   121 downloads

 

 

The game only does multiplication the normal CP1600 way.



#15 catsfolly OFFLINE  

catsfolly

    Dragonstomper

  • Topic Starter
  • 704 posts
  • Location:Japan

Posted Tue Dec 23, 2014 4:42 PM

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



#16 5-11under OFFLINE  

5-11under

    River Patroller

  • 3,202 posts
  • Location:Ontario, Canada

Posted Tue Dec 23, 2014 4:45 PM

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.



#17 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,880 posts

Posted Tue Dec 23, 2014 5:20 PM

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.



#18 catsfolly OFFLINE  

catsfolly

    Dragonstomper

  • Topic Starter
  • 704 posts
  • Location:Japan

Posted Tue Dec 23, 2014 5:21 PM

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:

 

Attached File  spb.rom   23.06KB   249 downloads

 

Attached File  spb.bas   129KB   140 downloads

 

Catsfolly



#19 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,761 posts
  • Location:@R6 (top of stack)

Posted Tue Dec 23, 2014 5:25 PM

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.



#20 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,761 posts
  • Location:@R6 (top of stack)

Posted Tue Dec 23, 2014 5:28 PM

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, Tue Dec 23, 2014 5:29 PM.


#21 5-11under OFFLINE  

5-11under

    River Patroller

  • 3,202 posts
  • Location:Ontario, Canada

Posted Tue Dec 23, 2014 5:45 PM

Here are new versions of the program:

 

attachicon.gifspb.rom

 

Catsfolly

 

Thanks!! I will give those a try soon... .



#22 pimpmaul69 ONLINE  

pimpmaul69

    River Patroller

  • 4,821 posts
  • INTV Brotherhood Technician
  • Location:Colorado

Posted Tue Dec 23, 2014 10:02 PM

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 


Edited by pimpmaul69, Tue Dec 23, 2014 10:44 PM.


#23 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,761 posts
  • Location:@R6 (top of stack)

Posted Tue Dec 23, 2014 10:56 PM

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, Tue Dec 23, 2014 10:58 PM.


#24 pimpmaul69 ONLINE  

pimpmaul69

    River Patroller

  • 4,821 posts
  • INTV Brotherhood Technician
  • Location:Colorado

Posted Wed Dec 24, 2014 12:47 AM

 
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

#25 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,761 posts
  • Location:@R6 (top of stack)

Posted Wed Dec 24, 2014 1:34 AM

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.







Also tagged with one or more of these keywords: blocky, IntyBasic, fun

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users