Jumpman 2600 Development

[supercat]

Can you explain please, why a difference of 8 ns for the whole cycle or 4 ns of one half cycle makes it necessary to have different designs for PAL and NTSC ? The 8 ns seem to be not very important, or ? And of course the timers on the VCS board are not so very accurate as well. Do you think they are better than 0.1% ?

1004671[/snapback]

 

The problem comes if code running from SRAM performs an "STA WSYNC" instruction that causes a 75-cycle delay. The cartridge looks for A0 transitions to determine where each phi1 cycle starts, and assumes that they will run at uniform speed in the absense of A0 transitions. Following a "STA WSYNC" there may not be any A0 transitions for ~75 cycles.

 

The magic writes work by performing a read during each phi1, holding the data loosely on the bus, and the performing a write in each phi2. If the processor wants to write something, it will easily overpower the bus-hold circuitry; if it wants to read something, the bus hold circuitry will easily keep the bus state valid for the ~500ns between the time the RAM chip releases the bus and the processor reads it.

 

If the cartridge's phi1 clock gets out of phase with the processor's clock, it could be asserting /WE while the processor switches to a new address. This would cause RAM to become corrupted. Because the cartridge can't know "in advance" when the processor is going to change addresses following an "STA WSYNC" except by hoping its crystal is running at the same speed as the processor's, there's no good way to deal with disparate clock rates.

 

Actually, if I went to the next larger CPLD it would probably be possible to deal with that situation by disabling writes if I've seen more then seven consecutive cycles with no change on A0, but that would seem overly complicated.

[Kroko]

The cartridge looks for A0 transitions

Ok, now I understand

 

One more question: Which circuitry is going to hold the databus content after you pull down the NWE line ? Are the CPLD inputs going to do that ? And does that mean that a board wanting to support this method would need to connect all 8 data lines to the CPLD ?

 

Can this behaviour of the CPLD be seen somewhere in the Xilinx datasheets ? I fear some µA leakage current could already corrupt the bus content, or ? I would like to get a feeling about this ability to "hold" the bus content.

[supercat]

One more question: Which circuitry is going to hold the databus content after you pull down the NWE line ? Are the CPLD inputs going to do that ? And does that mean that a board wanting to support this method would need to connect all 8 data lines to the CPLD ?

 

The Xilinx CPLD does that. Note that the 5-volt version does not; only the 3.3-volt version. On the 2600's I've tested, the bus seems to pretty much float, while on the 7800 there's a noticeable pullup tendency. Even there, however, the bus keeper can hold the bus in a valid low state for 1.5 cycles which I think is adequate margin.

 

Can this behaviour of the CPLD be seen somewhere in the Xilinx datasheets ? I fear some µA leakage current could already corrupt the bus content, or ? I would like to get a feeling about this ability to "hold" the bus content.

1004858[/snapback]

 

I do wish Xilinx better documented the exact specs for the bus keeper. It is in the 95C36XL data sheets, but the exact capabilities are not given. If you were using a 95C72XL and wanted extra confidence, you could put series resistors on all the data lines going to the CPLD and have it latch and drive them. Alternatively you could use a 74HCT373 along with eight resistors (this was my plan until I found out that the 95C36XL had the bus keeper built in). One caveat in either case: the bus keeper circuit must either be disabled during zero-page fetches, or must be weak enough to allow the TIA to pull D6-D7 high since it's not very strong.

[Kroko]

Even there, however, the bus keeper can hold the bus in a valid low state for 1.5 cycles which I think is adequate margin.

ok, thats sounds like it is long enough ...

 

If you were using a 95C72XL and wanted extra confidence, you could put series resistors on all the data lines going to the CPLD and have it latch and drive them.  Alternatively you could use a 74HCT373 along with eight resistors (this was my plan until I found out that the 95C36XL had the bus keeper built in).  One caveat in either case: the bus keeper circuit must either be disabled during zero-page fetches, or must be weak enough to allow the TIA to pull D6-D7 high since it's not very strong.

I would rather like to keep it as simple as possible

[supercat]

I would rather like to keep it as simple as possible

1004870[/snapback]

 

True, provided the thing works consistently on all machines.

 

One thing that really puzzles me is that someone else has posted that the TIA has always-on pullups on D6 and D7. I don't see how, if the bus-hold circuitry can hold a valid low for 1.5 cycles, those outputs would work at all. On the other hand, my 4A50 demo does use INPT4 and it does work, so I'm confused.

[supercat]

I personally am not at all interested in a "Jumpman-style platformer", I want the real thing!

1004131[/snapback]

 

What do you want to give up to support a 40x88 screen instead of 32x85? The full-size screen might be doable, but it would be rather a nuisance and would probably require dropping to 2lk single-color sprites.

[Shawn]

forgive my ignorance but what is "notBD" if it needs to be a PM so be it.

1004405[/snapback]

notBD = not Boulder Dash

1004419[/snapback]

 

 

But is it not actually being considered as being an offical "First Star" OK'd game or has the kybosh been put on the "offical" part?

[Cybergoth]

I personally am not at all interested in a "Jumpman-style platformer", I want the real thing!

What do you want to give up to support a 40x88 screen instead of 32x85? The full-size screen might be doable, but it would be rather a nuisance and would probably require dropping to 2lk single-color sprites.

 

I rather meant that as in creating a port as faithful as possible and calling it "Jumpman" in the end. Of course, feel free to redesign all of the levels so that they fit

 

To answer your question in detail though, my plan was to customize all kernels individually as much as required. Why shouldn't a mostly mirrored level use the full 40 blocks width for example? (BTW: Thinking of this, Jumpman levels are only 38 blocks wide)

 

I started out converting all layouts as close as possible, writing about 10 different MACRO kernels for all kinds of different situations.

 

Next I tried adding sprites to the most complex kernels and when that didn't work out, I started to simplify the layouts by reflecting at least one playfield column, and so on. I applied all changes in the Jumpman editors for "Jumpman UC" and "Jumpman Lives!", so I could playtest all my changes on those levels, securing the original feel of a level stayed intact.

 

I just got tired somewhere in the process, but I still think it's the right way to do it.

 

Of course, considering sara boards will ever become available, a whole lot of new possibilities will be available, to make it an even better conversion by allowing levels like Figurit for example. (At the time I also didn't know about MaskedDraw, so that might also result in different descissions now than it did back then )

 

Actually, typing all this almost motivates me to continue with this project now!

 

Greetings,

Manuel

[panamajoe]

 

Actually, typing all this almost motivates me to continue with this project now!

 

 

1005764[/snapback]

 

i´d say: go for it!

[Gorf]

Attached in the ZIP are 31 VCS binaries showing those levels who are still "in the game"

(Note: Just the background GFX, no gameplay. Most also won't work on a real TV yet)

 

And here's the list:

 

[right][snapback]748703[/snapback][/right]

 

 

Thanks for supporting Atari fans!

[grafixbmp]

I was giving this game alot of thought lately and had hoped to one day be able to play it on an actual Atari 2600. I saw there had been quite a bit of work done to port many of the levels here and was wondering if I might help some. I do mock up screens quite a bit and was wondering about this concept:

 

having a dual kernal where most of the background objects are displayed at 30 Hz insteadof 60 Hz. like so. 1st pass would consist of ladders (blue BG), down rope (Ball) portion of bombs (player 1) jumpman (player 0) and one bullet (missle 0)

second pass would be platforms (green BG) other portion of bombs (player 1) jumpman (player 0) up rope (missle 1) one bullet (missle 0)

 

This could allow for easier recognition between the ladders and the platforms. Plus they would retain their true colors this way. Jumpman would be the only item on the screen displayed all the time. and since the bombs are stationary, it would be easier to reuse the same sprite without extra flicker given they are usually far enough apart. Also, sometimes even in asymetrical playfields, the ladders are symetrical while the playfield is not. This would give alot more room in the code to accomplish the things needed.

 

The one thing that would be the best thing is if all the objects except for jumpman used the dual scanline method for displaying the graphics and jumpman himself was single scanline pixels.

 

Here is a general mock up screen that I actualy was rather proud of. I have a feeling that this method would free up alot of space for computation and screen accuracy. The flicker would also be minimal as well (hopefully).

 

It has been over a year since anyone posted here. I thought it was high time.

jumpman_2600_screen.bmp

[Cybergoth]

I started reworking the PF layouts with two colors and am also trying to give them a more "grid" like feel as in the original computer versions. Attached is an example showing what I'm trying to go for

robotsi.zip

[SeaGtGruff]

I started reworking the PF layouts with two colors

That looks good!

 

Michael

[Cybergoth]

That looks good!

 

Thanks!

 

I have attached a first level with bombs in place.

(Note: Don't try on a TV!)

easydoes.zip

[+Nathan Strum]

Looks good! I guess I should download the original and play it.

[Cybergoth]

You sure won't regret it, it's an excellent game!

[+SpiceWare]

(Note: Don't try on a TV!)

Looks OK on my C= 1084S, it can handle PAL so the ~269 scan lines is OK, just minor jitter since it's not consistently 269.

[tremoloman2006]

Wow... this looks very promising! Keep up the great work! I know I'll be first in line to purchase a copy if/when this is complete!

[Cybergoth]

Looks OK on my C= 1084S, it can handle PAL so the ~269 scan lines is OK, just minor jitter since it's not consistently 269.

 

I should have a TV compatible version ready later this week. I'm planning to up my test binaries to 8K, so I can have a proper TV frame in the first bank and just call the second bank for the level kernel + display data and level specific logic. That way I can see a levels ROM usage under real conditions.

 

Lets hope a level can fit into less than 2K, so a bank can have two of them

[Cybergoth]

Here come 8K versions for the real thing, PAL & NTSC

8K.zip

[Tempest]

Can someone post screenshots? I can't play around with this at work...

 

Tempest

[Cybergoth]

Hopefully someone can. I neither get a Z26 or Stella version with phosphor effect running on my current dev machine.

[+SpiceWare]

[Cybergoth]

Thanks Darrel!

[mos6507]

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