Image Map Image Map
Results 1 to 9 of 9

Thread: Another World Apple II port

  1. #1
    Join Date
    Jan 2011
    Location
    Vancouver, BC
    Posts
    4,658
    Blog Entries
    3

    Default Another World Apple II port

    Have you guys seen this? Pretty impressive given the limitations of the machine! I can't imagine what would be involved programming something like that.

    https://www.youtube.com/watch?v=ccQqD_4CXgI

  2. #2
    Join Date
    Jun 2013
    Location
    Montevideo, Uruguay
    Posts
    402
    Blog Entries
    1

    Default

    Yes i tested it on my apple IIc, and its quite amazing.
    I wish they don't have use such a low resolution.

  3. #3
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    6,151
    Blog Entries
    1

    Default

    It's more correct to call this a conversion, rather than a port, since the author did not attempt any reverse-engineering of the original code or data -- he did it all by watching gameplay. That's a level of dedication you normally don't see, which makes the end result that much more impressive.

    I'm reminded of the Apple II (and, by nature of the 6502->8088 transcoding process they used, IBM PC) conversions of Robotron. Those were done all simply by going to an arcade and playing the game for a few hours.
    Offering a bounty for:
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  4. #4

    Default

    Looks like he took the time to get the colors to work correctly. I'm probably remembering it incorrectly, but I seem to recall there were 2 different color palettes composed of similar colors (or maybe they were different colors? I don't remember.) If you use the "correct" color, you could have colors adjacent to each other without having the anti-aliasing affect. Or whatever it was called. So if you had blue next to white, it'd insert pink between the adjacent colors. But if you used the "correct" one from the other palette, then you could have them adjacent to each other without it adding additional colors between them.

    I can't recall any games or programs that actually did this correctly outside of demos or proof-of-concepts. Certainly no commercial games that I've ever played.

    Edit: Not that it was incorrect to do it the other way, it's just that the Apple II was capable of much more crisp graphics that no one really took advantage of. I'm not a programmer, so maybe it was much more difficult to swap between color palettes to make sure the graphics looks nice. Then again, as a kid, I didn't care. I thought it was awesome.

    Edit 2: https://en.wikipedia.org/wiki/Apple_II_graphics

    Hah! I remember correctly! Well, sort of.

  5. #5

    Default

    Yeah, it's an artifact of the Apple II's ultra-minimalist approach to color graphics - have too many 1 bits in a row, and the TV gets confused into thinking you just wanted white.
    Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
    Synthesizers: Roland JX-10/SH-09/MT-32/D-50, Yamaha DX7-II/V50/TX7/TG33/FB-01, Korg MS-20 Mini/ARP Odyssey/DW-8000/X5DR, Ensoniq SQ-80, E-mu Proteus/2, Moog Satellite, Oberheim SEM
    "'Legacy code' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup

  6. #6
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    6,151
    Blog Entries
    1

    Default

    Quote Originally Posted by olePigeon View Post
    Looks like he took the time to get the colors to work correctly.
    Actually he used low-res, which is why the game is rendered in 40x50. This was done in an attempt to keep the size down, and he didn't want to use dbl-low-res or dbl-hi-res for extra colors because he wanted to maintain Apple II+ compatibility.
    Offering a bounty for:
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  7. #7

    Default

    Since there seems to be vague interest in this, reasons to use the various graphics modes:

    lores benefits:
    + 40x48, 15 colors (two greys) (which is fine, as I use one for sprite transparency)
    + hardware page flipping
    + each display only 1kB (leaving lots of room for code) (also fast to clear screen)
    + (software) sprites and animations are relatively small

    lores downsides:
    + blocky
    + pixels are rectangular
    + framebuffer is non-linear (to get to next line requires a lookup table, not a simple add)
    + odd/even lines are high/low nibble in a byte, so to draw sprites properly need
    a lot of shifting an masking (I cheat and only allow sprites on even lines)
    + framebuffer has "memory holes" between lines. These are areas of memory reserved for expansion card use, so you can't just load a 1kB image straight to the framebuffer as it could break things.
    + NTSC artifact fringing between colors
    + lores PAGE2 is not frequently used so is broken in some emulators and on some early IIgs models

    hires benefits:
    + 140x192 6 colors
    + hardware page flipping

    hires downsides:
    + non-linear framebuffer even worse than lo-res
    + 8kB per page. two pages of hires takes 1/3 of total RAM in an Apple II+
    + NTSC artifact color. If the bit patterns in adjacent pixels is 00 it makes black, 11 makes white, so if you join two different colors you get lines between them
    + you get 7 pixels per 2-bytes. Which means a lot of dividing by 7, slow on 6502
    + each 3.5 pixels has a bit indicating palette (black,white,green,purple) or (black,white,orange,blue). You get zx-spectrum like color clash if you try to mix colors too close together
    + to get fast software sprites usually you make a set of 7 pre-shifted versions of the sprites, which takes up a lot of room

    double-lores
    + 80x48, 15 colors
    + requires IIe or newer (80 column card)
    + requires drawing extra 1kB of data to bank-switched AUX RAM
    + AUX ram colors are shifted one bit to left from main bank colors
    + while it's possible to get hardware page flipping, it's really complex

    double-hires
    + 140x192, 15 colors!
    + requires IIe or newer and 128k of RAM
    + requires drawing 8k of additional data to bank-switched AUX RAM
    + again, page flipping is complex


    In any case, I chose lo-res for the Another World conversion for 3 reasons
    1. Another World traditionally has 16 colors (and I like the lo-res colors)
    2. I wanted to fit levels in 48k, and as many as possible on a 140k disk
    3. I am too lazy to implement a full hi-res sprite library


    The recent C64 Another World conversion looks much more impressive and hi-res, but I think they use a 1MB cartridge just for the intro movie alone (which is possible larger than the size of the original game for the Amiga).

  8. #8
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    6,151
    Blog Entries
    1

    Default

    Thanks for the clarification on all of the video modes possible. (Double hires in particular is difficult to find info on for some reason.)

    You wrote that pageflipping in double-hires is complex, but it's doable, yes? (Otherwise I can't see how Airheart runs so fast)
    Offering a bounty for:
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  9. #9

    Default

    Quote Originally Posted by Trixter View Post
    Thanks for the clarification on all of the video modes possible. (Double hires in particular is difficult to find info on for some reason.)

    You wrote that pageflipping in double-hires is complex, but it's doable, yes? (Otherwise I can't see how Airheart runs so fast)
    It's amazing that people made games in double-hires considering the pain it can be. For example, while you can have 16 colors (4-bits per color) the hi-res graphics framebuffer is still in chunks of 7 bits so the colors span byte boundaries in a sort of irregular fashion, and in addition they span two different areas on bank-switched memory.

    If you just want one page of double-hires it's fairly straightforward. Half the bytes are in PAGE1 which is 8k starting at $2000, the other half of the bytes are in AUX PAGE1 which is bank-switched $2000. So to draw a full screen, you have to bank-switch from the regular 64k memory map to the auxiliary 64k one. This is a pain, because it means you have to have code in the same place in both banks to keep executing after the switch, and also the zero-page and stack are different in the two banks.

    To make this easier, there's a soft-switch that lets you remap AUX PAGE1 to regular PAGE2 ($4000) and then you don't have to worry about bank switching to do double hires. It does mean you can't use PAGE2 anymore.

    If you don't use the above trick, I think you can still do PAGE1/PAGE2 pageflipping as normal, it's just you have to do the thing where you manually switch banks. Apple provides a routine that will do a memcpy between the two banks for you but I think it's possibly not all that fast so you'd likely want to do it manually.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •