catsfolly Posted December 23, 2014 Share Posted December 23, 2014 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 ofusing 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. What can be done with such a low res display? Well it turns out that his favorite childhood game was Super Mario Brothers, sohe 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, thanksto 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... 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 8 Quote Link to comment Share on other sites More sharing options...
pimpmaul69 Posted December 23, 2014 Share Posted December 23, 2014 sweet! another game. i can never complain about that. 1 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted December 23, 2014 Share Posted December 23, 2014 Wow! simply amazing 1 Quote Link to comment Share on other sites More sharing options...
+5-11under Posted December 23, 2014 Share Posted December 23, 2014 I'm wondering if it's possible post the BIN+CFG files, rather than the ROM file? Thanks! Quote Link to comment Share on other sites More sharing options...
+nanochess Posted December 23, 2014 Share Posted December 23, 2014 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 Quote Link to comment Share on other sites More sharing options...
+5-11under Posted December 23, 2014 Share Posted December 23, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
catsfolly Posted December 23, 2014 Author Share Posted December 23, 2014 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 $ Quote Link to comment Share on other sites More sharing options...
+nanochess Posted December 23, 2014 Share Posted December 23, 2014 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. 3 Quote Link to comment Share on other sites More sharing options...
+wongojack Posted December 23, 2014 Share Posted December 23, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
+5-11under Posted December 23, 2014 Share Posted December 23, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
+5-11under Posted December 23, 2014 Share Posted December 23, 2014 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). Quote Link to comment Share on other sites More sharing options...
freewheel Posted December 23, 2014 Share Posted December 23, 2014 There's clearly something technical that I'm failing to grasp. How the hell does a game like this require extra RAM? Quote Link to comment Share on other sites More sharing options...
+nanochess Posted December 23, 2014 Share Posted December 23, 2014 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. Quote Link to comment Share on other sites More sharing options...
catsfolly Posted December 23, 2014 Author Share Posted December 23, 2014 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. Quote Link to comment Share on other sites More sharing options...
catsfolly Posted December 23, 2014 Author Share Posted December 23, 2014 There's clearly something technical that I'm failing to grasp. How the hell does a game like this require extra RAM? 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 1 Quote Link to comment Share on other sites More sharing options...
+5-11under Posted December 23, 2014 Share Posted December 23, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
freewheel Posted December 23, 2014 Share Posted December 23, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
catsfolly Posted December 23, 2014 Author Share Posted December 23, 2014 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 2 Quote Link to comment Share on other sites More sharing options...
intvnut Posted December 23, 2014 Share Posted December 23, 2014 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. 1 Quote Link to comment Share on other sites More sharing options...
intvnut Posted December 23, 2014 Share Posted December 23, 2014 (edited) 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. And lo and behold... Edited December 23, 2014 by intvnut 1 Quote Link to comment Share on other sites More sharing options...
+5-11under Posted December 23, 2014 Share Posted December 23, 2014 Here are new versions of the program: spb.rom Catsfolly Thanks!! I will give those a try soon... . Quote Link to comment Share on other sites More sharing options...
pimpmaul69 Posted December 24, 2014 Share Posted December 24, 2014 (edited) 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 December 24, 2014 by pimpmaul69 Quote Link to comment Share on other sites More sharing options...
intvnut Posted December 24, 2014 Share Posted December 24, 2014 (edited) 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 December 24, 2014 by intvnut Quote Link to comment Share on other sites More sharing options...
pimpmaul69 Posted December 24, 2014 Share Posted December 24, 2014 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 Quote Link to comment Share on other sites More sharing options...
intvnut Posted December 24, 2014 Share Posted December 24, 2014 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.