Jumpman 2600 Development

[SeaGtGruff]

IMHO, I could handle it in Ladybug but the flicker here is over the top for what little you gain.

I haven't tried it on the real thing yet, but it looked okay to me in Stella and z26-- even without the phosphor effect (as long as the emulator display is synched with the monitor's refresh rate). However, I did notice that each frame is drawn with only one playfield color. The apparent flickering would be reduced if the two playfields were drawn on alternating lines between the two frames, with the playfield color alternating from line to line. That would take up maybe 6 cycles from each scan line, though-- assuming the two colors were stored in RAM-- so I'd say develop the game with each frame having a solid color, then when it's nearing completion, shuffle the screen data to alternate between two frames, and tweak the scan line loop to alternate the colors, *if* there are cycles available for that.

 

Michael

[Cybergoth]

I fully agree that the amount of flicker is not really tolerable on a TV. Next I want to try something I did with my Tron experiments last year, which is probably exactly what Michael is describing:

 

http://www.atariage.com/forums/index.php?a...;showentry=3071

(Should be the last binary of the entry)

 

I'll see how it will turn out and eventually post a demo later this week

[wrenchien]

IMHO, I could handle it in Ladybug but the flicker here is over the top for what little you gain.

 

nice conversion so far....

[Cybergoth]

Here come two more TV binaries, testing an approach with less flicker and one without flicker. Please have a look at your TVs and give me some feedback which version you do prefer

flicker.zip

[Cybergoth]

Here's a 2nd Version of the "less flicker" approach. In fact, it's almost gone on my TV!

(Someone confirming this? )

lflicker2.zip

[+Nathan Strum]

I'll try to take a look at these on real hardware tonight.

 

BTW - I finally tried out Jumpman. Fun game - but seems a little glitchy here and there, collision-detection-wise. Sometimes I'll step down from a bump in the platform, and tumble to my death, for no apparent reason.

 

But it certainly looks doable on the 2600 (except maybe the crumbling playfield at the end of the game).

[supercat]

But it certainly looks doable on the 2600 (except maybe the crumbling playfield at the end of the game).

 

Some levels might be doable with standard RAM. Others would not. Given sufficient expanded memory, it would probably be possible to do all the levels if one makes a few sacrifices. The Atari 400/800 have four players and four missiles; the 2600 does not. I don't know what the player/missile counts are on the various levels, but 30Hz flicker of everything (including the player) would probably work. If the player doesn't flicker, some levels would probably require 20Hz flicker of other objects.

 

Indeed, if ample RAM is available (as in 4A50) the kernel could be pretty easy. Assuming no object needs to be displayed at more than one X position or with more than one color...

 

  lda PF0a,x
 sta PF0
 lda PF1a,x
 sta PF1
 lda PF2a,x
 sta PF2

 lda ENAMx,x
 sta ENAM0
 lsr
 sta ENAM1
 lda GRP0a,x
 sta GRP0	; Assume delayed
 lda PF0a,x
 sta PF0
 lda PF1a,x
 sta PF1
 lda PF2a,x
 sta PF2
 lda GRP1a,x
 sta GRP1

If I'm counting right, that's 68 cycles. If the loop is unrolled 2x, there would be enough cycles for a dex/bpl loop. There may even be enough space in there to update the missile (another five cycles). As shown, the code will update the missiles mid-line. If they're just used for bullets, this shouldn't pose a problem if they're updated at the same spot on even and odd scan lines. Simply adjust the Y position if the bullet is to the right of the update point.

 

Without expanded RAM, I don't see any realistic way to handle levels like Hotfoot or the mystery mazes.

[TROGDOR]

This game begs to be implemented with a Supercharger. Each level could be loaded in individually, similar to the original game. This would allow 4k per level, and plenty of RAM to handle kernel buffering for fancier features like ropes.

 

That's something that has never been done with a Supercharger (to my knowledge). A game with dozens of levels/loads. Loderunner would be another prime candidate.

 

If you can pull this off with the base 128 bytes RAM, I'll be impressed. But the kernel will be so busy I don't see how you could implement asymmetrical PF graphics.

 

I'll check out the bins later tonight.

[Dave Neuman]

Here's a 2nd Version of the "less flicker" approach. In fact, it's almost gone on my TV!

(Someone confirming this? )

 

 

No flicker for NTSC on Kroko

[supercat]

If you can pull this off with the base 128 bytes RAM, I'll be impressed. But the kernel will be so busy I don't see how you could implement asymmetrical PF graphics.

 

To do the game right, even with 30Hz flicker, would require showing two players and two missiles. With the full width playfield, that's 10 full load/store pairs and a lda#imm/sta pair, though if data is in RAM one load can be replaced by a shift. Using abs,x mode with data in RAM, that works. Use (ind),y mode and there's just no way it could work with a 1lk.

 

Using a 2LK, it might be doable if one is willing to have seriously bloated ROM (e.g. every object preceded and followed by lots of zeroes). If the screen were divided into zones, it might not even have to be too horribly bloated (e.g. using three zones of 64 lines each would reduce padding requirements to 32 bytes). Still pretty tough to work, though.

[+SpiceWare]

I've got all 3 loaded on my Krok cart. Didn't notice a difference between the two flicker routines. They both look better than the initial version, but I do prefer the non-flicker kernel.

Using a 2LK, it might be doable if one is willing to have seriously bloated ROM (e.g. every object preceded and followed by lots of zeroes). If the screen were divided into zones, it might not even have to be too horribly bloated (e.g. using three zones of 64 lines each would reduce padding requirements to 32 bytes). Still pretty tough to work, though.

I did zones for Stay Frosty where each zone maxed at 50 scanlines(zones vary in size, even during a level to create the elevator platforms). I used a mask to eliminate the padding for each image.

 

; in the kernel
  lda (FrostyImageZone1),y
  and (FrostyImageZone1),y; mask the image
  tax
  lda (FrostyColorZone1),y
  sta WSYNC
  sta COLUP0
  stx GRP0
  ...

 

The mask is padded with 50 zeros on both sides:

		repeat 50
	.byte 0
	repend
	repeat 25
	.byte $ff
	repend
FrostyMask:
	repeat 50
	.byte 0
	repend

 

An image is not padded:

		.byte zz__XXXX__; 0
	.byte zz_XXXXXX_; 1
	.byte zzXXXXXXXX; 2
	.byte zzXXXXX_XX; 3
	.byte zzXXXXXXXX; 4
	.byte zzXXXXXXXX; 5
	.byte zzXXXXX_XX; 6
	.byte zzXXXXXXXX; 7
	.byte zzXXXXXXXX; 8
	.byte zz_XXX_XX_; 9
	.byte zz__XXXX__; 10
	.byte zz__XXXX__; 11
	.byte zz___XX___; 12
	.byte zz__X__X__; 13
	.byte zz_X___XX_; 14
	.byte zz_X____X_; 15
	.byte zz_X_XXXX_; 16
	.byte zz_XXX_XX_; 17
	.byte zz__X_X___; 18
	.byte zz___XXX__; 19
	.byte zz__XXXX__; 20
	.byte zz___XX___; 21
	.byte zz___XX___; 22
	.byte zz___XX___; 23
	.byte zz___XX___; 24
FrostyGraphic0:

Edited January 24, 2008 by SpiceWare

[supercat]

I've come up with a new banking idea. I'll post about it in my blog. It should offer some intriguing possibilities for anyone who isn't too totally confused by it.

[Cybergoth]

Without expanded RAM, I don't see any realistic way to handle levels like Hotfoot or the mystery mazes.

 

Properly recreating Hot Foot is totally impossible I think, regardless of the available RAM, since it is terraforming the playfield on a much more granular scope than any other level.

 

I'm currently thinking wether a mystery maze effect could be done using for example 64 RAM bytes as a mask. If it would use only PF1/PF2, than that might offer 512 parts of the screen to uncover. That will use 40 cycles for the playfield each line, so one can still draw Jumpman. (Maybe somehow even some lianas.)

 

It's not so important though, wether a few single levels are possible or not. Jumpman and Jr. combined have 44 original levels (including "Sreddal" and "Fire! Fire!" from the C64). I think even using a 64K ROM would only allow ~ 30 of these, so I can just drop the ones that would loose too much of their original design. Other candidates that may have to be dropped seem to be the two Figurits, Look out Below, Follow the Leader or The Jungle.

 

Using a 2LK, it might be doable if one is willing to have seriously bloated ROM.

 

That is the plan, yes. Using so much ROM as required to eliminate any branching logic, either by providing tables for the full screen height or just for certain zones, and using masks for the sprites.

[Cybergoth]

Some progress, adjusted the structure removal stuff for the new playfield approach and added the lianas.

liana.zip

[Cybergoth]

Added the Jumpman sprite to the kernels. Move him around with a joystick. Looks stable

jumpman.zip

[Albert]

Added the Jumpman sprite to the kernels. Move him around with a joystick. Looks stable

Just fired that up in Stella--looks fantastic! Have I mentioned that Jumpman and Jumpman Jr. are two of my favorite Atari 8-bit computer games?!

 

..Al

[+SpiceWare]

Looks good, though odd to see Jumpman without his red shirt and purple pants.

[Cybergoth]

Looks good, though odd to see Jumpman without his red shirt and purple pants.

 

I agree. The white A8 Jumpman is a lot easier to port though

[+SpiceWare]

Ah - didn't realize the A8's version was done that way.

[Cybergoth]

What would be a good variant for enabling one dot on a single scanline? Preparing/Restoring the stack for the old PHP trick seems to be too much overhead for a single dot, so for a variant I thought of this:

 

CPY scannline
PHP
PLA
STA ENABL

 

13 cycles by my count. Anyone have a better idea?

[vdub_bobby]

If you know where the stack pointer is you can cut that to 12 cycles:

   cpy scanline
  php
  lda ZP
  sta ENABL

But I don't understand the problem - is this really too much overhead?

   tsx
  stx StackTemp
  ldx #ENABL
  txs
...kernel...
  ldx StackTemp
  txs

It's just a byte of RAM and 9 bytes of ROM...?

 

I suppose if you have the cycles to spare, might as well save the RAM.

Edited January 30, 2008 by vdub_bobby

[Cybergoth]

If you know where the stack pointer is you can cut that to 12 cycles:

 

That won't work, since without the PLA it will continually shrink the stack, i.e. kill all RAM

 

But I don't understand the problem - is this really too much overhead?

   tsx
  stx StackTemp
  ldx #ENABL
  txs
...kernel...
  ldx StackTemp
  txs

It's just a byte of RAM and 9 bytes of ROM...?

 

Same thinking error actually as above, or? After each PHP you have to put the stack back in place...

 

Hm... but... this would actually still work though, when framing the kernel as you suggest and then executing this each line:

 

CPY scannline
PHP
PLA

 

Only 10 cycles, you're a genious Bob!

[vdub_bobby]

If you know where the stack pointer is you can cut that to 12 cycles:

 

That won't work, since without the PLA it will continually shrink the stack, i.e. kill all RAM

Oh. Good point.

 

CPY scannline
PHP
PLA

 

Only 10 cycles, you're a genious Bob!

Glad to help.

Edited January 30, 2008 by vdub_bobby

[Cybergoth]

What did you think you did...?

 

I was jammed thinking of doing it this way, which actually only makes sense for displaying 2 particles:

 

CPY scannline
PHP
LDX ENAXX
TXS

 

This would've been a major roadblock, since I don't even have X available in the kernel

[vdub_bobby]

What did you think you did...?

 

I was jammed thinking of doing it this way, which actually only makes sense for displaying 2 particles:

 

CPY scannline
PHP
LDX ENAXX
TXS

 

This would've been a major roadblock, since I don't even have X available in the kernel

Gotcha.