Jump to content

deater78

Members
  • Posts

    35
  • Joined

  • Last visited

Posts posted by deater78

  1. 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
  2. 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
  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).

    • Like 2
  4. 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
  5. 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

    tc_cake.png

    tc_bubs.png

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

     

     

     

    cheat_title.png

    tc_blue.png

    tc_pit.png

    tc_stick.png

    tc_strongbadia.png

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

     

     

    • Like 1
  8. 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.

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

  10. 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?

×
×
  • Create New...