Number Blaster & Generic Shump Game

[GroovyBee]

If you want to use the memory map where the ECS normally lives you need to have code at $4800 that maps out the ECS ROMs at $2000, $7000 and $E000. Take a look at cart.mac in the sdk1600 to see how its done.

[+DZ-Jay]

 

Question...

 

Looking at this: http://spatula-city.org/~im14u2c/intv/jzintv-1.0-beta3/doc/programming/memory_map.txt

 

If I use the areas $2xxx or $4000-$47FF or $7xxx or $Exxx in a game (ROM), will the game fail if an ECS is plugged in? Note that I don't want to use any ECS features; it's just a standard game.

 

No. It won't fail, that's what I keep saying that it's not "incompatible." What you are doing is swapping the ECS ROM code with your own. As long as your game doesn't use any ECS ROM code (which I keep asserting, no home-brew ever does), it won't matter.

 

If you want proof, plug in a Christmas Carol cartridge in your ECS and play it. Christmas Carol uses almost 40K of the 42K, including swapping the ECS ROM memory as described there.

 

-dZ.

 

P.S. Note that this works because home-brewed games hi-jack the normal Master Component's boot up sequence to run their own code, therefore bypassing the ECS boot as well.

Edited February 28, 2015 by DZ-Jay

[+DZ-Jay]

Also, I want to point out that swapping the ECS ROM memory does not prevent you from using the ECS hardware itself: you can take advantage of the extra hand-controller ports, the text keyboard, or the synth keyboard, as well as the extra RAM and sound chip.

 

I'm sure that IntyBASIC will eventually mature to abstract all this, if it hasn't already.

 

-dZ.

[freewheel]

So I guess the initial question still isn't answered, fully - can a person create a game that uses the full 42K word memory map with IntyBASIC? Because from what I can tell, I'm already using address space reserved for the ECS ($C100 and onwards) and I'm not having to use any tricks from cart.mac.

[Kiwi]

IntyBASIC converts all basic commands to assembly, and then AS1600 is able to compile it. If it works for Christmas Carol, then it should be fine with IntyBASIC. Right now, the project is about 25.5KB ~12.25K. So I'll be using the 42K cartridge for this game.

[intvnut]

So I guess the initial question still isn't answered, fully - can a person create a game that uses the full 42K word memory map with IntyBASIC? Because from what I can tell, I'm already using address space reserved for the ECS ($C100 and onwards) and I'm not having to use any tricks from cart.mac.

 

IntyBASIC converts all basic commands to assembly, and then AS1600 is able to compile it. If it works for Christmas Carol, then it should be fine with IntyBASIC. Right now, the project is about 25.5KB ~12.25K. So I'll be using the 42K cartridge for this game.

 

If you

• want the largest possible ROM space
• don't need any additional RAM
• want to remain compatible with the ECS (meaning your code won't crash when someone attaches an ECS)
• do not want to deal with page-flipping on the fly to get to additional ROM space
• you don't mind some boot up code that does some page flipping but you can just treat as a black box...

then you can use up to 50K of address space if you do the following:

• Add a small bit of code at $4800 to switch out ECS ROMs if present and switch in your ROMs
• Use the following memory map if you're using a board design that supports page flipping:

$2000 - $2FFF  PAGE F   ;  4K words
$4800 - $4FFF           ;  2K words
$5000 - $6FFF           ;  8K words
$7000 - $7FFF  PAGE F   ;  4K words
$8040 - $BFFF           ; 16K words, minus 64 words.
$C040 - $DFFF           ;  8K words, minus 64 words
$E000 - $EFFF  PAGE F   ;  4K words
$F000 - $FFFF           ;  4K words

.

Now, I have observed weird behavior occasionally with code near $C040. (In principle something similar should happen with code near $8040.) I really don't know what's up with that. Also, the Intellicart and CC3 map memory in multiples of $0100, and don't support page-flipped memory. So, if you don't have support for page-flipping, but do have support for Intellicart/CC3 memory mapping granularity, then you can use this slightly more conservative memory map that still gives you 49K words total:

.

$2100 - $2FFF           ;  4K words, minus 256 words
$4800 - $4FFF           ;  2K words
$5000 - $6FFF           ;  8K words
$7100 - $7FFF           ;  4K words, minus 256 words
$8100 - $BFFF           ; 16K words, minus 256 words.
$C100 - $FFFF           ; 16K words, minus 256 words

.

To make this work seamlessly with the ECS, you do need to add some code to either intybasic_prologue.asm or intybasic_epilogue.asm to add code at $4800 to switch out the ECS ROMs and (if the board you're using supports page flipping) switch in yours. I use this code sequence in cart.mac:

.

        ORG     $4800
        ; Disable ECS ROMs so that they don't conflict with us
        MVII    #$2A5F, R0
        MVO     R0,     $2FFF
        MVII    #$7A5F, R0
        MVO     R0,     $7FFF
        MVII    #$EA5F, R0
        MVO     R0,     $EFFF
        B       $1041           ; resume boot

.

(Side note: I don't think the ECS switches in its ROM at $E000 - $EFFF during early boot, which is why freeweed's probably fine with his current strategy of just assembling the overflow starting at $C100. I tend to be a bit more belt-and-braces in my code and explicitly switch out the $Exxx ROM just in case.)

 

Now, in the specific case of IntyBASIC, you do need to do some additional work to get your game spread out among the different ROM segments. The current hack (and I emphasize that I feel it's a hack) is to throw inline "ASM ORG $xxxx" statements at strategic places in your IntyBASIC program to push ROM into different ranges of memory.

 

The reason I feel this is a hack is that it's very brittle. You add, remove, or move code, and the appropriate place for the ASM ORG statement shifts. To

 

That's not to say that the state of the art on the assembly side with AS1600 is all that much better, but it is slightly better with cart.mac and the ROMSEG macro, and really, you'd like a higher level of abstraction in IntyBASIC.

 

The real problem is that IntyBASIC (and the Intellivision in general) would benefit from a proper linker, and that's currently missing.

 

 

As for 50K vs. 42K ROM: That really comes down to whether you want additional RAM. On JLP I made the design decision to map 8K words of extra RAM at $8040 - $9F7F. So, if you need extra RAM, that's one great place to put it.

Edited March 1, 2015 by intvnut

[+Tarzilla]

As a person that will probably never own an ECS, A question or two that I haven't seen answered:

 

Is it a big deal that a game won't work if an ECS is plugged in if it states that in the manual and on the box?

How many people actually have an ECS among the 100 to 200 people that frequent here and buy homebrews?

 

 

To me it makes more sense to target a pcb with ram on it rather than require an ECS.

[freewheel]

As a person that will probably never own an ECS, A question or two that I haven't seen answered:

 

Is it a big deal that a game won't work if an ECS is plugged in if it states that in the manual and on the box?

How many people actually have an ECS among the 100 to 200 people that frequent here and buy homebrews?

 

 

To me it makes more sense to target a pcb with ram on it rather than require an ECS.

 

Agreed. And, quite frankly, I don't see the majority of games needing extra RAM either (although this may just be how I think in terms of coding, ie: where I waste the most space ). Pretty easy to aim real high if you don't need either.

 

And yeah, it's a hack to make this happen in IntyBASIC but to be honest, unless you're coding right up against these limits it's pretty easy to plan for and work around. You'll notice pretty quick when your code suddenly assembles but won't run, so you take 5 seconds to look at the assembler output and just juggle some code. It's really only tedious when you're trying to squeeze the last few hundred words out.

 

Thanks again to intvnut for the most comprehensive answer to this topic to date (and I'm gonna archive this somewhere so I stop having to ask about the little details!), and apologies to Kiwi for the thread-jack.

[+DZ-Jay]

As a person that will probably never own an ECS, A question or two that I haven't seen answered:

 

Is it a big deal that a game won't work if an ECS is plugged in if it states that in the manual and on the box?

How many people actually have an ECS among the 100 to 200 people that frequent here and buy homebrews?

 

 

To me it makes more sense to target a pcb with ram on it rather than require an ECS.

 

I don't think it's a big deal to not have ECS compatibility, but given that these are known problems with known solutions... why? The good thing about the ECS is the extra PSG chip. You really start dreaming in colour when you try to play music and sound effects simultaneously in your game, and realize what you could do with those additional three channels.

 

To me that's the only advantage of the ECS: the chiclet keyboard sucks, and the extra bits of 8-bit RAM pale in comparison to a PCB with on-board RAM.

[intvnut]

As a person that will probably never own an ECS, A question or two that I haven't seen answered:

 

Is it a big deal that a game won't work if an ECS is plugged in if it states that in the manual and on the box?

How many people actually have an ECS among the 100 to 200 people that frequent here and buy homebrews?

 

 

To me it makes more sense to target a pcb with ram on it rather than require an ECS.

 

 

I personally don't really enjoy plugging / unplugging my ECS. I'd rather leave it plugged in if I can. I guess it's really a nicety / quality of implementation detail for a game to clean things up and work with the widest range of deployed hardware seamlessly. It's hardly a requirement, though. I don't think anyone's superglued their ECS into their Intellivision.

 

As dZ-Jay noted above, the ECS brings a second PSG to the party, which is nice. Check out Space Patrol sometime with the ECS enabled. It really does sound much better. (You can do this in jzIntv since you don't have a physical ECS.)

 

I don't think I've ever used the ECS for extra RAM in a game, although I did enable its use in cart.mac for completeness. Since 16-bit RAM is so much more convenient, I've just always used the extra RAM JLP provides when I do need extra RAM. That also means the ECS remains optional. Again, notice Space Patrol doesn't require it, falling back to simpler sound effects if it's absent. (SP also didn't need extra RAM.)

 

I don't think IntyBASIC has support for the ECS's extra PSG. It doesn't seem like it should be difficult for nanochess to add, though. It's got the same registers in the same layout, just at $F0 - $FF instead of $1F0 - $1FF.

Edited March 1, 2015 by intvnut

[Kiwi]

It is very interesting to read about the cart mapper. I'm about to remap some of my data. Right now, I have the main engine, enemy actions. in $5000-$6FFF, which is almost full. $D000 have more functions and F000 has the data strip and cards in it. I will do testing with help to see how the game works on real hardware once it is completed.

I just finished making the first area of the game. The enemies takes 0-31 card slot while the bggraphics takes 32-63 slots. Now I will remake the 2nd level. Then third level will be next.

 

-click to animate.

[+DZ-Jay]

Looks really good!

 

The only thing that I find distractingly klunky is the "rapid fire" missile. I don't know if it is an artifact of the animated GIF dropping frames, but it looks like the missiles show for only a frame or two, making it hard to visually connect the missile to the enemy explosions.

 

-dZ.

[+Tarzilla]

Looks really good!

 

The only thing that I find distractingly klunky is the "rapid fire" missile. I don't know if it is an artifact of the animated GIF dropping frames, but it looks like the missiles show for only a frame or two, making it hard to visually connect the missile to the enemy explosions.

 

-dZ.

I actually thought it was Gorf style firing that kills the current in motion shot. Likely it he is just using the defaults when converting the .imv file to gif. Joe talked about the gif issue and enhanced the Imv tools in another thread.

http://atariage.com/forums/topic/234067-jzintv-2015-01-20-build/

Edited March 1, 2015 by Tarzilla

[+nanochess]

Cooool!

[+DZ-Jay]

I actually thought it was Gorf style firing that kills the current in motion shot. Likely it he is just using the defaults when converting the .imv file to gif. Joe talked about the gif issue and enhanced the Imv tools in another thread.

http://atariage.com/forums/topic/234067-jzintv-2015-01-20-build/

 

That's why I was asking. I thought it could be the GIF movie dropping frames, but if it is on purpose, i.e., killing the missile every time the player hits the fire button, then it looks crappy. Even older space-shooter games still limit the number of bullets you could re-fire. There may be a better way of doing it. I think the biggest problem is that it's not just a little pixel-bullet, but a fully formed missile sprite. Having it disappear in mid-shot is distracting. At least from the game-play videos.

 

-dZ.

Edited March 1, 2015 by DZ-Jay

[freewheel]

I really like how Gorf's firing works. It always drove me nuts to play games where you had to sit and wait for a bullet to disappear off-screen before you could fire again - incredibly unrealistic (insofar as space shooter realism goes, sure ) and all it did was point out hardware limitations. The Gorf designers at least got creative with the h/w.

[Kiwi]

I used gifcam to capture footage using Nostasia emulator. The player's shots are multiplexed 3 times, so it doing the flickering at 20hz. Kinda like how D2K flicker the enemies to make more of them. I used 16.6 fps option in gifcam to record the entire level. So frames are dropping and 30 fps would make the gif bigger. The gif in the OP has the missiles and that one is 30 FPS.

[intvnut]

What you have looks really, really cool. I mean that sincerely!

 

I do share the reservations, though, on how the player's 'bullets' get multiplexed. Have you considered trying to multiplex over a larger subset of the moving objects, so no individual object is blanked out for too long?

 

I remember hating the original Atari 2600 Pac-Man whenever I'd play it at someone else's house, because I could never really see the ghosts. Turns out, they'd used one hardware sprite for all four ghosts, which is why they were so dim on the screen. Using one MOB for 3 bullets is nearly as bad.

 

From what I've seen in D2K (and Carl can correct me if I'm wrong), each object gets its own MOB, until there needs to be more objects on screen than MOBs, at which point one of them 'splits' and multiplexes. For example, if too many barrels need to be on-screen, one or more MOBs will get split between pairs of barrels.

 

In Space Patrol, I divided my sprites into two groups. Group 1 had sprites associated with space ships and aliens, and Group 2 had sprites associated with bullets. There could be up to 5 sprites in the first group and 7 sprites in the second group (total of 12). The two groups had to fight for 6 hardware MOBs. Each group got 3 MOBs by default, and if either group wasn't using all of its allocation, it gave MOBs to the other group. 2 MOBs were reserved for the player's vehicle.

 

This scheme tended to penalize bullets more than flying saucers in terms of flicker, but overall kept things looking pretty good. And since many sprites (esp. bullet sprites) were short-lived, flicker also tended to be short lived. You can see that in the clip below.

 

 

 

(Note: the front-facing bullet on the tank isn't a sprite / MOB. It's handled with a card in BACKTAB.)

[+DZ-Jay]

I used gifcam to capture footage using Nostasia emulator. The player's shots are multiplexed 3 times, so it doing the flickering at 20hz. Kinda like how D2K flicker the enemies to make more of them. I used 16.6 fps option in gifcam to record the entire level. So frames are dropping and 30 fps would make the gif bigger. The gif in the OP has the missiles and that one is 30 FPS.

 

One MOB for three bullets at 20 Hz is not going to look very good in practice. The rest does look very good.

 

-dZ.

[Kiwi]

SSUv5.rom

Catsfolly pointed out that there was a bug that freezes your player in place and stuck-on firing. I was able to get jzintv with the frontend to help run the program. I was able to reproduce the bug. The mixer had bit 7 and 6 on so now I changed these bits to 0 and the problem is resolved. Thank you Catsfolly.

Here's the latest ROM with first area and second area linked.

I will experiment with MOB multiplexing towards the end of the project.

[catsfolly]

This new version looks very nice. It reminds me of Xevious with its colorful detailed backgrounds.

 

I have no trouble with the flickering shots on dark backgrounds, but they are sometimes hard to see with the bright backgrounds.

 

Probably eventually going to something like the Space Patrol scheme would be good - spread the multiplexing out among several sprites so that all the sprites are drawn most of the time.

 

I think the game currently has 10 "virtual sprites" one player, 6 sprites for the enemies and their shots, and 3 sprites for the player shots. Currently, the player and enemy ships are drawn every frame, and the 3 player shots are drawn with one sprite, so each player shot is drawn on the screen 33 % of the time.

 

If (for example) you decide to draw the player's ship every frame (dedicate one sprite to it) and dedicate one sprite for an enemy ship/boss, then you would have 8 virtual sprites left to draw with 6 real sprites. So you could set up a four frame pattern where each frame 2 virtual sprites are not drawn. That way each of the 8 virtual sprites would be drawn on the screen 75 % of the time.

 

frame 1

 

players ship -> sprite 0

enemy prime -> sprite 1

player shot 0 -> not drawn

player shot 1 -> not drawn

 

player shot 2 -> sprite 2

enemy/shot 1 -> sprite 3

enemy/shot 2 -> sprite 4

enemy/shot 3 -> sprite 5

 

enemy/shot 4 -> sprite 6

enemy/shot 5 -> sprite 7

 

frame 2

 

players ship -> sprite 0

enemy prime -> sprite 1

player shot 0 -> sprite 2

player shot 1 -> sprite 3

 

player shot 2 -> not drawn

enemy/shot 1 -> not drawn

enemy/shot 2 -> sprite 4

enemy/shot 3 -> sprite 5

 

enemy/shot 4 -> sprite 6

enemy/shot 5 -> sprite 7

 

frame 3

 

players ship -> sprite 0

enemy prime -> sprite 1

player shot 0 -> sprite 2

player shot 1 -> sprite 3

 

player shot 2 -> sprite 4

enemy/shot 1 -> sprite 5

enemy/shot 2 -> not drawn

enemy/shot 3 -> not drawn

 

enemy/shot 4 -> sprite 6

enemy/shot 5 -> sprite 7

 

frame 4

 

players ship -> sprite 0

enemy prime -> sprite 1

player shot 0 -> sprite 2

player shot 1 -> sprite 3

 

player shot 2 -> sprite 4

enemy/shot 1 -> sprite 5

enemy/shot 2 -> sprite 6

enemy/shot 3 -> sprite 7

 

enemy/shot 4 -> not drawn

enemy/shot 5 -> not drawn

[catsfolly]

My best score so far:

 

 

 

Catsfolly

 

 

[+DZ-Jay]

SSUv5.rom

 

Catsfolly pointed out that there was a bug that freezes your player in place and stuck-on firing. I was able to get jzintv with the frontend to help run the program. I was able to reproduce the bug. The mixer had bit 7 and 6 on so now I changed these bits to 0 and the problem is resolved. Thank you Catsfolly.

 

Here's the latest ROM with first area and second area linked.

 

I will experiment with MOB multiplexing towards the end of the project.

 

 

 

I'll try to get give your game some luvin' this week and provide some feedback. I know you're dying to know what I think, sitting at the end of your seat.

 

-dZ.

[Kiwi]

*falls off seat* Ouch.

I played around with multiplexing enemies just out of curiousity. Only problem is the collusion detection. It probably possible with software collusion. At least I got some sorta of Megaman 2 thing going where if there's more than 64 sprite in a screen then sprites start flickering. I think I'll keep what I have so far even if the weapon is a bit hard to see.

[+DZ-Jay]

*falls off seat* Ouch.

 

I played around with multiplexing enemies just out of curiousity. Only problem is the collusion detection. It probably possible with software collusion. At least I got some sorta of Megaman 2 thing going where if there's more than 64 sprite in a screen then sprites start flickering. I think I'll keep what I have so far even if the weapon is a bit hard to see.

You are right in that logical sprites require logical collision detection. How do you solve this with the current 20hz multiplexing you do right now? It should pose the same problem.