Jump to content
IGNORED

Myst (unofficial demake for Atari 2600) (completed)


deater78

Recommended Posts

Hello

I was curious how much of Myst I could fit in a 4k cartridge (I ported all of Myst to an Apple II on three disks a few years back).  It turns out not much, but it was fun to try.

 

[update] Version 2.6 is a 16k E7 ROM with a fully playable subset of Myst.  You can get all 4 endings, solve two puzzles, walk around the main island, and complete the typical speedrun route

 

Web page about the project (including link to source code): http://deater.net/weave/vmwprod/myst_vcs/

You can get the ROM here: http://deater.net/weave/vmwprod/myst_vcs/myst.e7

There's a manual to help you play through here: http://deater.net/weave/vmwprod/myst_vcs/vcs_myst.pdf

 

Plays fine in stella, MAME, and real hardware using harmony cartridge.  Currently does not play on javatari due to a (reported) bug in E7 cart handling.

vcs_myst_clock.png

vcs_myst_book.png

vcs_myst_cleft.png

Edited by deater78
update links
  • Like 18
Link to comment
Share on other sites

the Apple II version has 800 images totaling about 400k of graphics.  Although in the end it's not really the cartridge space that would keep me from attempting a more complete version, for this I was generating a custom kernel for each image to maximize the colors/design and that's a lot more labor intense than drawing 800 bitmaps was.  Game logic wise it might be doable, I was surprised how few bytes of game state there is for the complete game.

  • Like 4
Link to comment
Share on other sites

so you have all convinced me to see if I can expand this.


I'm trying with an E7 bank-switch cartridge (16k ROM/2k RAM).  Data for each screen is about 500 bytes, and I'm going to compress the data with ZX02 compression and then decompress to RAM.  So far the data compresses pretty well.  I got decompression working, it was interesting hacking it to work when the read/write addresses are different.

 

I'm going to try to implement enough of Myst island that you can follow the speedrun route (for those who don't know, you can speedrun the actual game Myst in around 40s or so without leaving the main island)

  • Like 8
Link to comment
Share on other sites

On 7/29/2022 at 9:44 PM, deater78 said:

Hello

I was curious how much of Myst I could fit in a 4k cartridge (I ported all of Myst to an Apple II on three disks a few years back).  It turns out not much, but it was fun to try.

 

You can get the ROM file and the code here: http://deater.net/weave/vmwprod/myst_vcs/

vcs_myst_clock.png

vcs_myst_book.png

vcs_myst_cleft.png

I'm making It's Conner time! on 2600 as a proof of concept in 4K bytes as well. It uses repeated screens to give "Bigger" levels. I'm also using a multicolored 32*12 playfeild (IN RAM!). Honestly, I was worried I was going to run out of RAM, but no. I have a 8 byte stack as well as a pointer in which 12 colors I will use for the playfeild out of a 256 byte list. Wow!

I also want to add music and sound to it as well.

Link to comment
Share on other sites

  • 2 weeks later...

hitting the point where these are spoilers if somehow you've made it to 2022 without playing Myst.

 

Anyway you can get to D'ni now and hang out with Atrus, and even get one of the 4 endings.  Currently a lot of puzzles are being skipped, I'm hoping I'm going to have enough room in the ROM to implement some of them.

myst_dni_n_screen_small.png

myst_dni_e_screen_small.png

myst_atrus_e_screen_small.png

myst_trapped_screen_small.png

  • Like 2
Link to comment
Share on other sites

  • 3 months later...

finally had some time to work on this again.  No gameplay improvements, but I now have the ZX02 image decompression working without glitching.  The problem was decompression was taking more than 262 scanlines.  I managed to split up the decompression code and use timers so VSYNC could be maintained while the decompression was happening.

 

  • Like 1
Link to comment
Share on other sites

  • 5 months later...

have some time to work on this project again.  Plan is to get a speedrun-capable version of Myst to fit on a 16k E7 cartridge.  I'd estimate it's about 75% there currently.

 

as a side effect of this work found a bug in the E7 cartridge support in javatari today, but found a fix and sent it upstream

vcs_myst_dentist_e_screen.png

vcs_myst_dock_s_screen.png

vcs_myst_rocket_s_screen.png

  • Like 2
Link to comment
Share on other sites

7 hours ago, JetSetIlly said:

What was the bug?

when accessing the memory location (on Apple II we'd call this a soft-switch, not sure the right term on vcs) to swap in the RAM to the address space it indicated this with a "ram enabled" flag.  When you later swapped ROM back in, the "ram enabled" flag was never turned off, which as you can imagine caused issues.  All that was needed was a one-line fix to disable the RAM again after swapping the ROM back into place.

  • Thanks 1
Link to comment
Share on other sites

10 hours ago, Cris1997XX said:

Out of curiosity, would it be possible to use the F4 mapper for this? I think 32K is just enough to fit most, if not all, the puzzles in the game

For my game kernel the graphics for each scene take 512 bytes.  For my stripped-down version of Myst there are going to be roughly 64 scenes (plus a bunch of other code for the intro and puzzles and such).  I guess in theory I could maybe squeeze things down to fit in a 32k ROM.

 

Currently I am using ZX02 compression where each level is 256 bytes or less compressed.  This should allow things to fit in 16k.  This does require RAM to hold the decompressed data.  This is why I use the E7 ROM as it includes enough RAM to do this.

 

Having the decompressed data in RAM has other benefits too, as for some of the effects and puzzles I patch the graphics on the fly rather than having separate copies.

 

Doing a "full" VCS version of Myst would be a lot of work.  I did do a full Apple II version with similar graphics limitations (40x48, but only 15 colors, but you have no limitations of colors per line).  This involves roughly 800 scenes, in the end taking three 140k floppies, so roughly 400k or so of data (most of which is compressed).

  • Like 2
Link to comment
Share on other sites

On 6/25/2023 at 9:59 PM, deater78 said:

For my game kernel the graphics for each scene take 512 bytes.  For my stripped-down version of Myst there are going to be roughly 64 scenes (plus a bunch of other code for the intro and puzzles and such).  I guess in theory I could maybe squeeze things down to fit in a 32k ROM.

 

By "graphics for each scene", do you mean the playfield?  Or does that include other data for the kernel like sprites?   I'm not a programmer so I'm genuinely asking as I don't have any practical knowledge as to how much a playfield setup takes on the rom.  I've been tossing around ideas about an adventure rpg but have no idea how much space a typical map grid of screens would take in even the basic batari kernel (let alone any of the more advanced techniques you're using with compression).

Link to comment
Share on other sites

each "scene" is just what's on the screen.  My kernel draws a 40x48 asymmetric playfield.  There is a fixed background color, but each 4-scanline high line can have its own foreground color.  There is then an "overlay" made up of sprite1 that's an 8x48 strip of blocks (each overlay line can be its own color) that overlays the screen to add a bit more detail.  You can also have one vertical line the same color as the pointer (this is missile0) and optionally the background on the right side of the screen can alternate with an additional color.

 

This ends up being 448 bytes per scene (16 bytes used to describe the scene, 6*48 bytes for the playfield, 48 bytes for foreground color, 48 bytes for the overlay, 48 bytes for overlay color).

 

I use compression which squishes things down to 256 bytes per scene (some compress a little better than that).  This means I have room for roughly 60 or so scenes in the game.

 

I'm doing this all in assembly language so I am not sure how this would map to a batari kernel.

  • Like 3
Link to comment
Share on other sites

  • 3 weeks later...

got the fireplace puzzle going

 

seriously low on ROM space here, at least in the small chunk of always-visible ROM on the E7 cartridge.

 

The original implementation of this was really clever, loading values off the zero page using stack instructions and such.  It was much too large though and ran out of scanlines for the logic.  Simplified it a lot to only update one row of the pattern when clicked, rather than re-generating all 6 rows.

 

 

 

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