Hello, Guest the thread was called129 times and contains 3 replays

last post from oziphantom at the

Map and the intial state

  • This was my quest.

    poke 53281,0 changes the background colour.

    Then open monitor

    lda #0

    sta $d021


    this does nothing.

    I watched this video

    when shows me the BASIC SYS needs to have a BANK 0 in front of it and there is a MAP setup

    1. lda #$00 ; offset 0
    2. tax ; lower 32K is not mapped
    3. tay ; offset 0
    4. ldz #%1011000 ; e000-ffff, 8000-bfff, are mapped to RAM, c000-dfff are as per C64 map
    5. map

    the comments are my own. Luckily I made a typo I wrote ldx not ldz because I'm just wired to press x and not z I guess. And all was well. It worked. However BASIC wouldn't return it just hung.

    So I added another

    1. lda #00
    2. tax
    3. tay
    4. taz
    5. map
    6. nop

    to put everything back to 0 and all was good. The nop helps of cause as the first map is a hidden sei.

    So how does this differ from running code in the monitor?

    then I noticed my mistake with the LDX not LDZ and fixed it so it was as shown above, and as per the video.

    It broke, it doesn't do anything anymore.

    So I thought I understood it, but seems I don't.

  • The rabbit hole deepens

    So the Mega65 manual unhelpfully has

    1. C65-style MAP instruction banking

    2. C65-style $D030 banking

    3. C64-style cartridge banking

    4. C64-style $00 / $01 banking

    but then in the text underneath it it points out the priority order is actually

    1. C64-style cartridge banking

    2. C65-style $D030 banking

    3. C65-style MAP instruction banking

    4. C64-style $00 / $01 banking

    It can't find anything that explains what enabled IO at the C64 style cartridge banking level.

    If I disable MAP by setting everything to 0s, $01 works as expected, dropping the 3 from the normal C64 values my experiments shows

    lda #$04

    in this map IO is not visible, a write to D021 does not change the background

    lda #$05

    in this map IO is visible, a write to D021 does change the background.

    As soon as I invoke the MAP opcode, with any value in the upper 32K bank enable bits, IO vanishes. This is because C64 rules are ignored and the MAP only controls RAM. Since the D030 banking only controls C65 ROM, nothing puts IO back in and hence if you put any memory banking in the upper 32K IO becomes invisible.

    moving the Lower 32K banking I can do the following

    MAP A00 XC0 Y00 Z00

    $01 = 04

    IO is not visible

    $01 = 05

    IO is visible

    But then Cart IO would enable you to get it back, but there is no way to get it back? C64 carts don't have the ability to control IO.

    So if you map the upper 32K you then have to use sta [zp](,z) form to manipulate the IO?

  • That's design of C65. And since MEGA65 should be compatible with C65, no wonder. So you basically can MAP the upper 32K, but mark the 8K block unmapped from that area what also contains $DXXX to have your I/O space (which is only 4K, but the MAP notion block is 8K, so you not have too many choices). Then you have the upper 32K area mapped but you can exclude that block which holds the I/O area. With this theory and the right CPU port settings (for C64-style stuff of banking, of course) you can have your I/O too. The other possibility (this is already MEGA65 from now, before this sentence, this applied to both of C65 and MEGA65), is to use that linear addressing mode you also mentioned. Other possibility is to use the DMA to transfer data between I/O space and "normal" memory (actually this is more useful than you think, eg palette needs many register to set, in that case, it's quite a realistic thing to do, especially if you need to do it quick, eg altering palette at a given raster line from a raster IRQ or so). This method would work both with C65 and MEGA65, though, with MEGA65 you can have even two ways to do it (on C65 you can tell DMA to access I/O area instead of memory, on MEGA65 you can also do this, but there you can even access the I/O area at its "high address" range, you know). Btw, also on MEGA65 you actually MAP the MEGA65-high-memory-area-I/O-space with extended MAP method but for sure, it does not help you here too much, since then you loose the ability to MAP anything other different to the upper 32K as there is only one mapping offset for the upper and lower 32K of the CPU address space.