Jump to content
IGNORED

Adventure 2600 to 8bit ?


LYNXGUY

Recommended Posts

Nicely done. Had a quick go on Level 1.

 

Sometimes the object you're carrying (most noticably the bridge) doesn't appear right away when you move onto the next screen. I'm guessing maybe some sort of positioning conversion issue?

 

I'll have to pull the finger out and do my sound engine. I've had the idea for a while to do an engine that allows realistic creation of the LFSR types by using Timer IRQs + forced volume.

Allow 2 or 3 levels of emulation depending on what resources a game leaves, e.g. basic freq/poly conversion, Timer IRQ for low/med frequencies only with high freq by conversion, true emulation with Timer IRQ for everything.

 

I'll have to pull the other finger out and do the conversion I started 3 years ago.

  • Like 1
Link to comment
Share on other sites

Whan was it done? How much it took? Tools used?

 

According to the local filesystem, started Friday, 3:15pm PDT, finished Friday 7:41pm PDT. :D

 

Of course, having the disassembly already done helps out a lot. There is one issue with the original disassembly to be aware of -- there are a bunch of bogus references to VSYNC,X, RSYNC,X, etc. These don't actually refer to hardware registers and are just offset indexing at 0,X, 1,X, etc. used to index into object data arrays in page zero.

 

Tools used: Visual Studio 2015 for text editor, MADS for assembler, Altirra for testing, 800XL on living room floor for cert.

 

The approach was the same as the previous ports: find the VSYNC access to identify the VBLANK routine and use it to lock to ANTIC's frame, drop in the sound and input drivers, and then move over the writes to color and sprite data registers from TIA to GTIA locations to get something on screen. After that, it's the game-specific laborious work of dissecting the display kernel and converting the sprite usage to what ANTIC/GTIA can do. The 2600 can actually display more sprite images and move more sprites per scanline than the 800, so this can get hairy fast if the game pushes the hardware. GTIA also doesn't have the ability to reflect sprites.

 

As noted earlier, Adventure's TIA usage is really basic, probably simpler than Combat. It simply uses the two players directly as object sprites, the ball as the avatar sprite, and the two missiles as side barriers, with no mid-screen use or changes to position/size/color. The one trick is that it uses the VDELAY latches to sync the sprite updates, which doesn't work on GTIA. I went a bit farther this time and removed the entire display kernel, so the game is running entirely on playfield and P/M graphics DMA. Instead, there's a small routine that translates the 7-row TIA playfield to an ANTIC IR mode 8 playfield and two DLIs to vertically clip the sprites. Pre-translating the levels would free up a few dozen scanlines per frame and leave plenty of time for IRQ sound emulation.

 

That having been said, Adventure runs quite slowly with a 3-frame / 20Hz main loop; that's why the sprite multiplexing flickering is so bad compared to even other 2600 games. On a PAL ANTIC, the port skips one out of every 6 frames to equalize the speed with the original NTSC rate.

  • Like 10
Link to comment
Share on other sites

 

The 2600 can actually display more sprite images and move more sprites per scanline than the 800, so this can get hairy fast if the game pushes the hardware. GTIA also doesn't have the ability to reflect sprites.

Can you please elaborate further? I know the TIA can double or triple sprites as well as reflect them. But I was not aware the 2600 could move more sprites per scanline. How is this possible given the TIA only has two players and a ball?

Link to comment
Share on other sites

Can you please elaborate further? I know the TIA can double or triple sprites as well as reflect them. But I was not aware the 2600 could move more sprites per scanline. How is this possible given the TIA only has two players and a ball?

 

TIA allows horizontal position deltas to be preconfigured for each of the five sprites, all of which are triggered by one write to HMOVE. GTIA requires the 6502 to move them one at a time, which costs more cycles than are available in horizontal blank. Add in replication and it's effectively nine sprite images moved per scan line.

  • Like 4
Link to comment
Share on other sites

 

TIA allows horizontal position deltas to be preconfigured for each of the five sprites, all of which are triggered by one write to HMOVE. GTIA requires the 6502 to move them one at a time, which costs more cycles than are available in horizontal blank. Add in replication and it's effectively nine sprite images moved per scan line.

Thanks for the explanation. I wonder why certain cool features were removed from the TIA such as replication and reflection? Guess it came down to the transistor count.

Link to comment
Share on other sites

Yep, they would have been very handy, especially the replicate.

 

Maybe it comes down to display method - doesn't TIA rely on the LFSR sequencing where GTIA has actual counters and comparitors? Though I should think redisplay methods would need some extra trickery regardless of the other methods in use.

Link to comment
Share on other sites

 

According to the local filesystem, started Friday, 3:15pm PDT, finished Friday 7:41pm PDT. :D

 

That's less than 5 hours!!! :-o

 

Probably it'd take more than 5 weeks to me...

 

Thanks for the explanation... I'll take that and try another game from the ones that have sources available.

 

 

Of course, having the disassembly already done helps out a lot. There is one issue with the original disassembly to be aware of -- there are a bunch of bogus references to VSYNC,X, RSYNC,X, etc. These don't actually refer to hardware registers and are just offset indexing at 0,X, 1,X, etc. used to index into object data arrays in page zero.

 

I noticed that your 800 version uses page 0 indexing on low addresses replacing VCS's VSYNC, VBLANK... I guess that's the reason why Altirra locks and crashes when reset key (F5) is pressed.

Link to comment
Share on other sites

Thanks for the explanation. I wonder why certain cool features were removed from the TIA such as replication and reflection? Guess it came down to the transistor count.

 

TIA does sprite positioning and shifting completely differently than GTIA.

 

GTIA runs a single position counter and compares it against each sprite position, whereas TIA runs a position counter per sprite. From what I've heard, HMOVE works by just running a few more or less clocks into the counter for each sprite. GTIA would need an incrementer/decrementer to do the same. However, the TIA's design is also responsible the PITA positioning method where you can't just write the position that you want the sprite to appear at, but instead have to time a strobe write horizontally for coarse positioning and follow it up with a fine adjustment with HMOVE. 2600 games frequently take a whole scanline per sprite to do this, so it's a big waste of time. TIA also can't clip sprites horizontally -- they wrap from one scanline to the next.

 

Shifting is also different. TIA appears to treat each player graphics register as a tiny RAM addressed by a counter, whereas the GTIA copies the player graphics register into a shift register. TIA can just invert the position while GTIA would need to be able to run the shift register backwards or have a crossover in the load logic.

 

Overall, my guess is that the GTIA player logic is simpler than the TIA logic and that was partly what allowed the increase from 2 players + 3 1-bit missiles to 4 players + 4 2-bit missiles. Also, HMOVE is not that useful without a display kernel, which is against the philosophy of having ANTIC mostly handle the per-scanline spoonfeeding.

 

 

I noticed that your 800 version uses page 0 indexing on low addresses replacing VCS's VSYNC, VBLANK... I guess that's the reason why Altirra locks and crashes when reset key (F5) is pressed.

 

Yeah, I forgot to stomp PUPBT1-3 + COLDST this time, so it tries to warm start and blows up.

  • Like 1
Link to comment
Share on other sites

Hi! I'm the author of the incomplete BASIC version. I began writing it as a tribute when I was just starting college. No source code or disassembly was available to me at the time, of course; I just created it from observation of the original game, much as authors of arcade ports did in those days. I also made a room layout and linking editor to aid in creating the original levels which I planned to release along with the game so that others could make their own Adventures from the original building blocks.

 

I always intended to eventually convert some or all of it to assembly language, but college studies and other projects soon took priority. Looks like Phaeron has made short work of it now. Well done!

Edited by El Destructo
  • Like 4
Link to comment
Share on other sites

Maybe we can have Albert or Video61 put Adventure onto cartridges if there is enough people interested. I know either of them will do it if they get enough interested buyers. I did some quick looks at the source code and probably can be further optimized/converted for Atari 8-bit I would personally rewrite the player/missile sections to use all 4 players for the screen objects and missiles for the thin walls. Reduce flickering. Can do some interesting hacks with it also.

Link to comment
Share on other sites

  • 2 weeks later...

Try this -- quick port attached. Start -> Game Start, Select -> Game Select, B -> Toggle B&W, 1/2 -> toggle difficulty 1/2. PAL frame rate compensated.

 

Adventure's TIA usage is very straightforward, so this is a good one to try if you want to give a shot at conversion.

 

I joined the site (been lurking here practically since Day One) just to thank you for doing this. I have been waiting for an A8 version of the game since forever and you got a version up and running in 5 hours - great work!

 

I also agree with whoever said upthread that if someone's going to port Adventure, it has to be Warren's original code, glitches and all - I personally wouldn't want it any other way.

 

The one issue I'm noticing now involves the dragons - it's quite hard to escape them after they bite and you tend to get stuck on them instead of being able to escape. I do realize that it's the first version, just wanted to mention that.

 

Thanks again for the port, I'm looking forward to seeing where this goes...

Link to comment
Share on other sites

  • 2 months later...
  • 4 months later...

Just stumbled on this Adventure 2600 port today. Truly awesome. Blows my mind how you could do it in such a short period of time. I can see how the bulk of the game logic is fairly straightforward, and mapping locations of control inputs, etc. But I can't even imagine how to convert a 2600 display kernel (I know you gave some explanation, but since I haven't done any 800/xl/xe assembly programming since the late 80's, it just went over my head)

 

Anyway, thanks for the port of my favorite 2600 game! And if you're ever bored one day and would like to port Phoenix 2600...... :-)

Link to comment
Share on other sites

  • 7 months later...

I think many people here on AtariAge didn't notice that in this thread in 2015 Phaeron presented an Atari 8-bit port of the famous Adventure game (in the post #24) :)

And in some parts of the world, where Atari 2600 was not sold, this game is almost unknown. So I've published an article on AtariOnline.pl about Adventure and its importance in games history: link

  • Like 9
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...