Jump to content

Recommended Posts

Since 2600 Millipede was one of the games recently modded to include Trak-Ball support, I thought I'd briefly mention something I just came across...

 

There's a claim that Dave Staugas created a 1.1 version of 2600 Millipede after it had already been commercially released. Supposedly, Steve R. Hastings has a copy of it… 5 spiders can attack at once.

 

...there's also a GCC version of the game based upon what AtariProtos reported...

 

Interesting about a 1.1 version, although it is insane enough with four spiders and two bugs all crowded at the bottom coming from both sides!

 

The GCC Millipede proto I've always liked. The one with the big mushroom made of tiny mushrooms as the title screen.

It has a different feel. I haven't played that for too long so I wonder how complete it is.

Link to comment
Share on other sites

^^I would be excited to purchase a CX-22 Millipede in the AA store. That game is crazy addictive.

 

Get a CX-80 as the build quality is superior. The fast majority of CX-80s function identical to a CX-22 unless they were factory modded.

I haven't posted the latest builds of Millipede yet, but there are some bug fixes for the Amiga and ST versions. I'm also toying with the idea of making the Y axis half as sensitive as the X axis. This was the way it originally was, but was too jerky. Now I'm smoothing it a little bit it should be better. We'll see...

Link to comment
Share on other sites

I haven't posted the latest builds of Millipede yet, but there are some bug fixes for the Amiga and ST versions. I'm also toying with the idea of making the Y axis half as sensitive as the X axis. This was the way it originally was, but was too jerky. Now I'm smoothing it a little bit it should be better. We'll see...

I had a bit of trouble originally with my ship bouncing up and into the millipede or other obstacle while attempting to slide along the bottom rail, so making the Y axis less sensitive wouldn't hurt. I've been following the conversation but haven't tried the "updated" ROMs yet. Too busy playing with other toys in my Video game collection over the holidays, namely NES, Turbografx, and Wii-U...

Link to comment
Share on other sites

^^I would be excited to purchase a CX-22 Millipede in the AA store. That game is crazy addictive.

 

Get a CX-80 as the build quality is superior. The fast majority of CX-80s function identical to a CX-22 unless they were factory modded.

 

I don't think so. All games exist in all variations.

 

Maybe you got confused by the speed experiments and resulting updates for CX22?

 

Ok guys thanks for the information, I just bought a new CX-80 from eBay.

  • Like 1
Link to comment
Share on other sites

The GCC rom has been available for awhile, but it doesn't like real hardware.

The GCC version I have says (PAL), and with improvements to Stella now alternates between color and B&W. I don't remember it doing that before.

 

My opinion is it is too unfinished, and would need some regular game code, polishing, and then if it turns out great, added Trak-Ball. (Even "finished" commercial games sometimes have poor coding like odd VSYNC and WSYNC and varying total scan lines.)

 

Although some objects look better, I think the official Millipede sacrificed some of that detail for more onscreen objects and faster, more arcade-like play. Or maybe it is just the 50Hz PAL rate, but it seems far slower.

Link to comment
Share on other sites

Some of the ROMs of the prototype are labeled as PAL because of the unstable display, but from what I read and tried on Harmony, I'm more under the impression that the game is unstable simply because it's unfinished. When I play on Harmony, colors seem to be correct, but the game flips after the title screen.

Link to comment
Share on other sites

CCG Millipede display 295 scan lines on title and 314 scan lines in game. The latter is clearly PAL.

 

I'd like to thank everyone who's been discussing the GCC prototype. Is there a date or version listing for the known GCC prototype?

 

Even if it wasn't "finished", it would be worth making playable just for the historical nature of it. Of course, that also implies Trak-Ball support. Call it GCC's Millipede Prototype or something to that effect.

 

Knowing the version/date number may come in handy especially if a different hardware-based NTSC version is discovered in the next few months.

 

As for Dave Staugas' version 1.1, I suppose someone could probably find him on LinkedIn or somewhere and inquire with him about it. He'd probably be happy to know his commercially released version has been improved upon and enthusiasts are still enjoying it today. That's speculation on my part based upon the reactions from other ex-Atarians I've met in person over the past couple of years. :) I did search for him in the Facebook Atari Museum group - since there's several ex-Atari Inc and ex-Atari Corp people there - but he doesn't appear to be a member. He's definitely notable as having been a talented 2600 coder in Atari Inc's heyday who went on to work at Atari Corp on the ST.

 

Woah…just saw a Jeff Minter tweet from October pondering what happened to Dave Staugas' 2600 emulator for the Jaguar. I didn't know he stayed at Atari [Corp] that long…or if it was on a contract basis. I wonder if it's the same emulator that Bryan worked on… Dave doesn't seem to be on Facebook at all, for the record.

Edited by Lynxpro
Link to comment
Share on other sites

I had a closer look at GCC's Millipede. It clearly is a prototype which would require some polishing. Getting the scan lines constant seems not to be a major problem. But getting the scan lines down to NTSC standard does not work easily. The calculations (e.g. DDT bomb) take too much time. Also I found some unused and some debug code (e.g. endless branches), which sometimes seems to trigger.

 

So, to make this a finished game, the game has to be disassembled (I have a coarse disassembly now) and understood first. Then optimizing and debugging could happen. This is not a simple task. And with the excellent Atari Millipede existing, I doubt it is worth it.

  • Like 2
Link to comment
Share on other sites

I haven't posted the latest builds of Millipede yet, but there are some bug fixes for the Amiga and ST versions. I'm also toying with the idea of making the Y axis half as sensitive as the X axis. This was the way it originally was, but was too jerky. Now I'm smoothing it a little bit it should be better. We'll see...

 

Speaking of…someone over in the Trak-Ballers group mentioned wanting to have an inversion option done - or a separate version - on Star Wars the Arcade Game.

Link to comment
Share on other sites

 

Speaking of…someone over in the Trak-Ballers group mentioned wanting to have an inversion option done - or a separate version - on Star Wars the Arcade Game.

I believe that could be accomplished with an external adapter fairly easily: a little surgery on a 9 pin extension cable could get that done.

Or, they could cut and re-route circuit board traces for an all internal mod.

Link to comment
Share on other sites

I believe that could be accomplished with an external adapter fairly easily: a little surgery on a 9 pin extension cable could get that done.

Or, they could cut and re-route circuit board traces for an all internal mod.

 

I'm sure that's not what they had in mind. :)

Link to comment
Share on other sites

 

Speaking of…someone over in the Trak-Ballers group mentioned wanting to have an inversion option done - or a separate version - on Star Wars the Arcade Game.

I'm really surprised about this, as most people seem to hate the inverted controls of the original. Nonetheless I made an inverted control version, and attached it to the first post.

  • Like 2
Link to comment
Share on other sites

I had a closer look at GCC's Millipede. It clearly is a prototype which would require some polishing. Getting the scan lines constant seems not to be a major problem. But getting the scan lines down to NTSC standard does not work easily. The calculations (e.g. DDT bomb) take too much time. Also I found some unused and some debug code (e.g. endless branches), which sometimes seems to trigger.

 

So, to make this a finished game, the game has to be disassembled (I have a coarse disassembly now) and understood first. Then optimizing and debugging could happen. This is not a simple task. And with the excellent Atari Millipede existing, I doubt it is worth it.

I have tried to convert it to NTSC at least two times over the past 6 years or so. The sorting routine it does takes a terrible amount of time. It also has a routine that shifts the playfield down in ram that takes a while when it runs.

 

 

I think I got it down to ~ 288 or so lines. I don't remember and it's on another hard drive. I agree though it needs to be more disassembled to really convert it.

  • Like 1
Link to comment
Share on other sites

I'm really surprised about this, as most people seem to hate the inverted controls of the original. Nonetheless I made an inverted control version, and attached it to the first post.

So, people want just the Y axis reversed? I totally misunderstood that. Is that how the arcade game played?

If you roll the ball "forward" it's like pushing an airplane stick forward which noses the craft down?

  • Like 1
Link to comment
Share on other sites

So, people want just the Y axis reversed? I totally misunderstood that. Is that how the arcade game played?

If you roll the ball "forward" it's like pushing an airplane stick forward which noses the craft down?

I don't know how the arcade game reacts as I have never played it. By original I meant the Atari 2600 game, which just has the Y axis reversed.

Link to comment
Share on other sites

I have tried to convert it to NTSC at least two times over the past 6 years or so. The sorting routine it does takes a terrible amount of time.

Indeed. I counted between 764 and 1512 cycles. That alone is 20 scan lines in worst case! Also due to the BCC, identical values are sorted again and again. I haven't found out yet, for what the sorting is used for. Do you know?

 

The algorithm used is a classic Bubble Sort. Not sure if a complete resorting is required each frame.

 

It also has a routine that shifts the playfield down in ram that takes a while when it runs.

True, but I think with some clever scheduling this problem can be eliminated.

 

I think I got it down to ~ 288 or so lines. I don't remember and it's on another hard drive. I agree though it needs to be more disassembled to really convert it.

How far did you get? Maybe we should exchange our disassembled code.
Link to comment
Share on other sites

Indeed. I counted between 764 and 1512 cycles. That alone is 20 scan lines in worst case! Also due to the BCC, identical values are sorted again and again. I haven't found out yet, for what the sorting is used for. Do you know?

I didn't find out. I think some of the bits in the values are related either to the type of enemy falling (like the wasps) or an event of the enemy falling.

 

 

 

The algorithm used is a classic Bubble Sort. Not sure if a complete resorting is required each frame.

Yes it is. I thought about spreading the sorting over a few frames, and at the time it seemed very overwhelming as I didn't even know where to begin in disassembling this game.

 

 

 

How far did you get? Maybe we should exchange our disassembled code.

I'll send you what I have. I don't want to derail this thread.
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...