UltiMem: don't INC/DEC bank registers

[pixel]

Hi there,

found an inconsistency that makes code work in VICE but fail on real hardware. With VICE, incrementing the bank number of BLK5 for example, can be done this way:

Code: Select all

    inc $9ffe
    bne n
    inc $9fff
n:

But the real Ultimem seems to require a longer pause between reads and writes. A standard addition resolves the issue:

Code: Select all

    lda $9ffe
    clc
    adc #1
    sta $9ffe
    lda $9fff
    adc #0
    sta $9fff

There's probably more coming…

[tokra]

I seem to vaguely remember that using inc and dec on any IO-register (instead of memory) is never really a good idea. Maybe because of ghost-reads or ghost-writes. The details elude me right now.

[Mike]

AAY64 has the following to say in this matter (link):

Code: Select all

6510/65816 Addressing mode: Absolute (R-M-W) -- a

 (ASL,DCP,DEC,INC,ISB,LSR,RLA,ROL,ROR,RRA,SLO,SRE,TRB,TSB)
 (3 bytes)  (6 and 8 cycles)

    +---------------+------------------+-----------------------+----------+
    |     Cycle     |   Address Bus    |       Data Bus        |Read/Write|
    +---------------+------------------+-----------------------+----------+
    |           1   |  PBR,PC          | Op Code               |    R     |
    |           2   |  PBR,PC+1        | Absolute Address Low  |    R     |
    |           3   |  PBR,PC+2        | Absolute Address High |    R     |
    |           4   |  DBR,AA          | Data Low              |    R     |
    |       (1) 4a  |  DBR,AA+1        | Data High             |    R     |
    |   (12)(3) 5   |  DBR,AA+2        | Internal Operation    |    R     |
    |       (1) 6a  |  DBR,AA+1        | Data High             |    W     |
    |           6   |  DBR,AA          | Data Low              |    W     |
    +---------------+------------------+-----------------------+----------+
    (1) Add 1 cycle for M=0 or X=0 (i.e. 16 bit data).
    (3) Special case for aborting instruction. This is the last cycle which
        may be aborted or the Status, PBR or DBR registers will be updated.
   (12) Unmodified Data Low is written back to memory in 6502 emulation
        mode (E=1).

    See also: Abbreviations

In short: after INC/DEC have read opcode and address, the following sequence reads the value in memory, then - while internally modifying the value! - writes back the original value *), and finally, writes the modified value.

If this fails on original hardware and works on VICE, this is something both Jim Brain and the VICE team should be notified of.

I seem to vaguely remember that using inc and dec on any IO-register (instead of memory) is never really a good idea.

At least that method should be used with caution, yes. Though, some routines use these ghost-writes to an advantage (opening side-borders on the C64 in the presence of sprites comes to my mind), likewise I use INC $9110 (VIA #1 port B) to cycle the colour RAM bank in my VFLI display routine with no adverse effects.


*) on the later CMOS versions of the 65xx, this was changed to do a read on the (opcode-)byte following the INC/DEC instruction instead, so there are not anymore stray accesses on possibly even read-sensitive I/O locations

[pixel]

If this fails on original hardware and works on VICE, this is something both Jim Brain and the VICE team should be notified of.

Told them on the VICE mailing list. Perhaps your contribution should just follow. Need some sleep...

[majikeyric]

I never noticed this kind of bug in my Ultimem apps...

In the Menu program source by Marko Makela,
INC ultimem_blk5_bank / BNE / INC ultimem_blk5_bank+1 is used and works well on real hardware.

Code: Select all

;;; Code for copying an image from flash (BLK5) to RAM
copy_
INPOS = $101
copynext= INPOS-1
                *   = INPOS+2
OUT_HI = *+2
copy            sta     $ff00,y     ; PARAMETER
                .(      
                inc     INPOS
                bne     inc_in
                inc     INPOS+1
                bit     INPOS+1
                bvc     inc_in      ; INPOS < $c000
                lda     #>$a000
                sta     INPOS+1
                inc     ultimem_blk5_bank
                bne     inc_in
                inc     ultimem_blk5_bank+1
inc_in          iny
                bne     inc_out
                inc     OUT_HI
inc_out         cpy     bend
                .)      
                bne     copynext
                lda     OUT_HI
                eor     bend+1
                bne     copynext
                sta     ultimem_blk5_bank   ; A=0
                sta     ultimem_blk5_bank+1 ; A=0
                stx     ultimem_mem_config2     ; ROM at BLK5
                rts

[pixel]

I never noticed this kind of bug in my Ultimem apps...

Had a non-working app on two different UltiMems until fixed the way I described it.

[pixel]

Here's the proof filed in the VICE bug tracker – actually the whole planet has just been alarmed.

[groepaz]

Like i already said on the ml - i find it odd this would actually be a problem... requiring a "pause" really seems unlikely, and if those registers are readable, even RMW instructions should work just fine. Someone might want to try this program on a different ultimem cartridge and see if it really reproduces the problem

Incase it does, the next thing to find out would be the conditions that make this happen... does it happen only for BLK5, do other registers/settings matter, etc. Probably Mr.Brain could tell this exactly from looking at the cpld code (it uses one, right?)

(and VICE does of course carry out those dummy writes, incase someone was wondering)

[pixel]

Someone might want to try this program on a different ultimem cartridge and see if it really reproduces the problem

Already happened.

Incase it does, the next thing to find out would be the conditions that make this happen... does it happen only for BLK5, do other registers/settings matter, etc.

OK, I'll extend that test code a bit.

[groepaz]

what would also be interesting... can you produce the same misbehaviour by using regular stores? ie produce the access pattern that INC would produce with something like lda/tax/inx/sta/stx - if that produces the same problem, there is really something buggy in the cpld Another thing to test would be: when the problem occurs, what is the actual value of the bank register? is it predictable from the previous value? It could be something like oldvalue AND newvalue, for example, which would hint on a bustiming issue. Maybe only certain bits are affected, which would hint on it depending on the distribution delays in the cpld perhaps.

[pixel]

Maybe only certain bits are affected, which would hint on it depending on the distribution delays in the cpld perhaps.

Hmm. Perhaps it's a really good idea to ask Jim Brain first before poking around any further. Already cost me a couple of nights.

[majikeyric]

Here's the proof filed in the VICE bug tracker – actually the whole planet has just been alarmed.

In your program you test that the flash ROM bank $0400 is reached to exit the loop and conclude you use a non faulty Ultimem, but the biggest bank number is $03ff.
maybe only bits 0 and 1 of $9fff are writeable/readable. Because when you exit the routine on real hardware, content of $9fffe/$9fff is well $03ff.

This test on real hardware displays : "VICE DETECTED"

Code: Select all

l:  dec cnt
    bne n
    dec cnt+1
    beq got_ultimem

n:  inc $9ffe
    bne l2
    inc $9fff
l2:
    lda $9ffe
    cmp #$ff
    bne l
    lda $9fff
    cmp #$03
    bne l

    lda #<txt_got_vice
    ldy #>txt_got_vice
    jmp printstr

[pixel]

maybe only bits 0 and 1 of $9fff are writeable/readable. Because when you exit the routine on real hardware, content of $9fffe/$9fff is well $03ff.

Oh dear. I'm a complete tard again. Thanks for pointing that out. And for the bit thing, too. :p