-
Posts
35 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Community Map
Posts posted by deater78
-
-
I've implemented picking up and using the red/blue pages. You can now get all four endings to the game.
nearing completion of this. I need to do a lot of cycle counting to make sure everything stays in 262 scanlines, then some sizecoding as there are two more locations I want to squeeze in.
-
5
-
-
I have the clock puzzle working now. Managed to cram all the sprites for the clock face down to fit in only 80 bytes.
Nearing the end here, I still want to implement the red/blue page handling enough so that all 4 endings to the game are possible.
-
3
-
-
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.
-
3
-
-
I've been working some more on this. I added a bunch more locations and it's now possible to "win" the game. However it's not finished yet as I want to add in two puzzles. Really starting to run low on room though.
Here's an updated video:
-
5
-
-
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.
-
3
-
-
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).
-
2
-
-
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.
-
1
-
-
-
It took a while, but I finally got around to making an NTSC version of this. I mostly just fixed up the resolution and colors, I left the music as-is which means it plays too fast.
NTSC ROM: http://deater.net/weave/vmwprod/demosplash2022/vcs_desire/vcs_desire_ntsc.bin
-
1
-
1
-
-
OK, even though this was mostly meant as a parody, I've fixed things up so now it is actually a full "game" that you can win or lose.
Also added some extra scenes.
I'm going to declare this done for now, although there's about 80 bytes free (on the 8k ROM) that are taunting me wanting some extra content
-
3
-
-
so I made another game of sorts, this one is based on an ancient screenshot the Homestar Runner people made that was a parody of the E.T. game but with their own character, The Cheat.
You can skip the so-so title music and get into the gameplay.
There's a webpage for it here: http://deater.net/weave/vmwprod/cheat/ with a link to the ROM (8k) and source code
Directions: you are The Cheat. Bubs (the orange guy) in the concession stand wants 12 Cheatcakes (little yellow boxes). You can only carry 4 at a time. Find them and bring them back to him. Don't get caught by strongbad (red guy) or he will steal your cakes and send you back to your house. If you fall in a pit, use the joystick button to levitate out. Also watch out for grumblecakes (black boxes) as too many of those are bad for you.
-
6
-
-
The Lovebyte demoparty had a big Apple II presence this year, including a special message from Woz himself
I had 12 entries that were all Apple II (or Apple II related) ranging in size from 8 bytes to 1k. You can see them here, with some descriptions:
http://deater.net/weave/vmwprod/lovebyte_2023/
The 1k entry finished in first place.
Try out the 8-byte entry yourself by running the following at at Applesoft prompt:
CALL -151 B8: 2c ea 20 f4 f3 20 d8 f3 B8G
-
1
-
-
26 minutes ago, Bomberman94 said:
Interesting project! Do you consider a PAL version, too?
it should be relatively straightforward to do a PAL port. It will have to wait until after the NTSC version is finished though.
-
1
-
1
-
-
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.
-
1
-
-
So my entry to Sillyventure 2022 WE was the intro to the Secret of Monkey Island, but on an 8k ROM for the VCS.
You can get get more info here: http://deater.net/weave/vmwprod/monkey_vcs/
Direct link to the ROM: http://deater.net/weave/vmwprod/monkey_vcs/monkey.e0
-
11
-
-
I released a 4k PAL Atari 2600 demo at the Demosplash Demoparty.
http://www.deater.net/weave/vmwprod/demosplash2022/vcs_desire/
ROM image: http://www.deater.net/weave/vmwprod/demosplash2022/vcs_desire/vcs_desire.bin-
12
-
3
-
-
I went back and updated the game a bit, mostly to do some careful scanline counting and that got rid of most of the glitches during scene changes. It now plays a lot smoother on the various video capture cards I have.
Here's an updated video:
-
2
-
-
I made a lot of changes to my code while trying to sort things out, and the Harmony cartridge appears to be working now!
javatari is still broken. I'm not sure if there's a good way to debug it. You can save the game state, but I'm not sure if there's a way to turn that into a hexdump style memory dump to try to figure out what's going on.
-
3 hours ago, deater78 said:
Mame: the ROM and 1k bank switches seem to work, but the 256 byte RAM at $1800/$1900 doesn't seem to work right
OK, after adding a lot of printf()s to the MAME code I figured out that it just ignores "-cartslot a26_e7" on the command line and tries to auto-detect anyway. So I put one of the E7 magic numbers into the rom image and now things work on MAME at least.
I'm using LDA to switch banks, but looking at the MAME code it looks like using STA might be preferred? I can try that I guess, though I thought the r/w signal didn't make it to the cartridge
-
so I've been working on Myst which uses E7 bank-switching. It works great under Stella, but it turns out it doesn't work elsewhere.
Mame: the ROM and 1k bank switches seem to work, but the 256 byte RAM at $1800/$1900 doesn't seem to work right
javatari: works for a bit but at some point things get corrupted, so badly that a power cycle doesn't fix it
harmony cartridge: appears to just lock up on the first bank switch (I've named the rom file with an .e7 extension)
has anyone else successfully used the E7 bank-switch method before?
-
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.
-
2
-
-
I apologize in advance. I'm also sure I'm probably not the first person to do this.
You can get the rom image here: http://deater.net/weave/vmwprod/floppy_rescue/
video of the gameplay:
-
5
-
8
-
-
-
You can now activate 3 marker switches, plus investigate the red and blue books in the library. I'd estimate I've got about half the space on the ROM left.
-
5
-

















Myst (unofficial demake for Atari 2600) (completed)
in Atari 2600 Programming
Posted
I just released version 2.6 and I'm going to call this finished. Seems to play fine on stella, MAME, and also on real hardware with a harmony cartridge.
Here's a longplay video: