| |
oziphantom
Registered: Oct 2014
Posts: 478 |
EF 3 hardware crash
So I have this Easy flash cart that I'm flashing to the EF3 in the normal way. Nothing special.
In VICE it works perfectly fine, no issues.
However on hardware it crashes.
The structure is a little odd.
the lo bank is mirrored across all lower banks, i.e bank 0 8000-9FFF = 1 8000-9FFF = 2 8000-9FFF etc the upper 8K is unique, kind of the reverse of a NES mapper I guess.
When the code changes the bank, there is a routine that takes A and does
and #$3f
sta $DE01
rts
on hardware this kills it, as far as I can tell a BRK occurs. It should be fine because that routine is in every lower bank in the same spot. That fact that it works in VICE tells me this is true.
But is there a case where on hardware ( I'm running it on a Commodore 128, it has also been shown to fail on a 1541U11+ with identical behavior ) the read of the RTS can fail? It gets garbage data for the next clock, the latch hasn't settled in time or something?
Or any other ideas? |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
I'd check if the same happens on C64 first, the C128 can be odd in many subtle ways.
Do you have a minimal testcase? |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
For EotB I never execute code in ROM while bankswitching, it was flakey on C128. I always jump to a common RAM area before bankswitching. This is fully implemented in macros so I have a JSRF (F=far) which JSRs from one bank into another via a RAM-trampoline. |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting JackAsserFor EotB I never execute code in ROM while bankswitching, it was flakey on C128. I always jump to a common RAM area before bankswitching. This is fully implemented in macros so I have a JSRF (F=far) which JSRs from one bank into another via a RAM-trampoline. Indeed, having bankswitching thunks in common RAM is best practice, even for stock C-64 without any cartridges. =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
It should work the way described though - and sometimes its the preferred way too (if you can not afford to run in RAM) - eg AR/RR (and likely most other freezers) uses this technique all over the place. |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Also, unreleated, EF3 emulation in 1541U2 does NOT work on C128 when in 2Mhz mode. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
The 1541-U11+ was connected to a C64, but I don't know which revision it was.
But I just tested on a E rev with my EF3 cart, and identical behavior.
I will try and make a simple test case. |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: The 1541-U11+ was connected to a C64, but I don't know which revision it was.
But I just tested on a E rev with my EF3 cart, and identical behavior.
I will try and make a simple test case.
Very interesting. I’d love to test it on my custom EotB carts. |
| |
Martin Piper
Registered: Nov 2007
Posts: 631 |
Have to agree, bank switching code in RAM is the way to go. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
Yup it crashes here is the complete code and pre-built ef cart https://www.dropbox.com/s/qh5bt265xcx2dpt/ef_crashtest.zip?dl=0 it has a batch file, but it is trivial to convert to anything else. assembles with 64tass
but for those that just want to snoop the code
; upper bank
.logical $a000
* = $bfd8
coldStart
sei
ldx #$ff
txs
cld
lda #8
sta $d016
_coldStart_wait_for_ram:
sta $0100, x
dex
bne _coldStart_wait_for_ram
ldx #$40
_coldStart_l1:
lda _startUpCode+$4000, x
sta $0100, x
dex
bpl _coldStart_l1
jmp $0100
*= $BF98
_startUpCode
lda #$87
sta $de02
lda #$7f
sta $dc00
ldx #$ff
stx $dc02
inx
stx $dc03
lda $dc01
stx $dc02
stx $dc00
and #$e0
cmp #$e0
bne _startUpCode_kill
ldx #0
stx $d016
jsr $ff84
jsr $ff87
jsr $ff8a
jsr $ff81
jmp $8000
_startUpCode_kill:
lda #4
sta $de02
jmp ($fffc)
_startUpCode_end:
*= $BFFA
.word $FFFE
.word coldStart+$4000
.word $4040
.here
;lowerBank00.asm
.logical $8000
start
lda #1
sta $0400
jsr changeBanks
lda #2
sta $0400
- inc $d020
jmp -
changeBanks
and #$3f
sta $de01
rts
.here
;makeBin.asm
*=$0000
Bank0Lo .binclude "lowerBank00.asm"
*=$2000
Bank0Hi .binclude "upperBank.asm"
*=$4000
Bank1Lo .binclude "lowerBank00.asm"
*=$6000
.fill $2000,$EA
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
despite its a bit irritating that the ROMH bank base address is set to $a000 and not $e000 as it should be, this should work just fine. will test on the real thing later :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Worked fine on my C128D using my custom EotB-carts. They are a direct clone of the logic in an EF1-cart but implemented using a CPLD. A 'B' is shown and the border is inc'd, like the code. Also works fine on the 1541U2+ EF-emulation (firmware 3.3(112)), again running on the same C128D. Will test with a plain C128 tonight. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
One thing that comes to mind - did you try setting the irq vector to something valid? Perhaps you are getting a spurious interrupt for some reason. |
| |
sailor
Registered: Jan 2002
Posts: 90 |
start
sei ; reset/init
ldx #$ff
txs
cld
lda #$2f
sta $00
lda #$e7
sta $01
lda #$00 ;fd50. memclr+test
tay
Ifd53 STA $0002,Y
STA $0200,Y
STA $0300,Y
INY
BNE IFD53
ldx #<($8000)
ldy #>($8000)
jsr $FD8D
jsr $e3bf ;reset basic vectors
jsr $e453 ;reset 0300-030b
jsr $ff81
jsr $ff84
jsr $ff8a ;reset 0314-0330
This is what I have for booting an EF, for C64 atleast. I remember that $00/$01 had to be set or it could/would crash, worked flawlessly in emu tho. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
Quote:I remember that $00/$01 had to be set or it could/would crash
that should not be the case (unless broken hardware/PLA/pullups) as long as regular ROMs are being accessed. |
| |
tlr
Registered: Sep 2003
Posts: 1702 |
Quoting sailor
start
sei ; reset/init
ldx #$ff
txs
cld
lda #$2f
sta $00
lda #$e7
sta $01
This is what I have for booting an EF, for C64 atleast. I remember that $00/$01 had to be set or it could/would crash, worked flawlessly in emu tho.
Isn't that $00/$01 ordering risky? You set the DDR before setting the actual value in $01. IIRC $00 is cleared on reset effectively making all bits output 1's which is a safe state. You'd want the $01 value to be correct before changing that or else your ROM might go away below your feet. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
the JSR $FF84 in the "$100" code sets $00 and $01 explicitly.
If I put the inc border in infinite loop the line before the "change cart" bank then it works. And thus the code is easily making it past, past the move to $100, swiching the cart to 16K from ultimax mode and thus remove the $40,$40 from being the IRQ vector. |
| |
sailor
Registered: Jan 2002
Posts: 90 |
Right!
That is wrong,
this is the correct order
start
sei ; reset/init
ldx #$ff
txs
cld
lda #$e7
sta $01
lda #$2f
sta $00
|
| |
tlr
Registered: Sep 2003
Posts: 1702 |
Quote: Right!
That is wrong,
this is the correct order
start
sei ; reset/init
ldx #$ff
txs
cld
lda #$e7
sta $01
lda #$2f
sta $00
This sound very strange to me. The Kernal does it the other way round for instance.
Note that if you are in Ultimax mode the banking bits do nothing so then either way is ok. I'm not familiar with the Easyflash HW so don't know if it's applicable here. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
the kernal sets $01 first, its the only correct way to do it
http://unusedino.de/ec64/technical/aay/c64/romfda3.htm
anyway, that is not the problem here :) |
| |
sailor
Registered: Jan 2002
Posts: 90 |
Sorry for confusion, trying to sort my notes, but having $00 before $01 for easyflash caused it to crash, worked in emu.
The code above is mainly from kernal boot seq,
.C:fdd5 A9 E7 LDA #$E7
.C:fdd7 85 01 STA $01
.C:fdd9 A9 2F LDA #$2F
.C:fddb 85 00 STA $00
|
| |
tlr
Registered: Sep 2003
Posts: 1702 |
Quoting sailorSorry for confusion, trying to sort my notes, but having $00 before $01 for easyflash caused it to crash, worked in emu.
The code above is mainly from kernal boot seq,
.C:fdd5 A9 E7 LDA #$E7
.C:fdd7 85 01 STA $01
.C:fdd9 A9 2F LDA #$2F
.C:fddb 85 00 STA $00
And sorry for my confusion too, I missed that you acknowledged the error when I wrote my previous comment.
Anyway, as gpz says not likely the problem oziphantom is seeing. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
anybody else been able to run the test? |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: anybody else been able to run the test?
I’ll try on my c128 tonight with my own ef1 clone, the ef3 and 1541u2+. What firmware on the u2+ Are u running? Chances are it’s a unique EF3 bug. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
Works for me (EF3, assy 250469) |
| |
sailor
Registered: Jan 2002
Posts: 90 |
Works here with EF1 and EF3 on both C64 and C128. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
okay trick found.
It just so happens that you were putting it in slot 1 right?
So Millfork's code was using DE01 to change the bank, somehow I didn't twig this was wrong. After doing EF-128 and modifying things left right and centre I really should have but I didn't and just went with it, it works in VICE after all...
So if you just so happen to flash it into slot 1, my test code does
set up border
change to EF cart in slot 1, which is NOP
continues the code in the same bank
which works because it just sets it self to its self.
This also works fine in VICE as the EF1 doesn't care about DE00 vs DE01 and hence on an EF1 it will work regardless. But on an EF3 DE01 changes the Cart slot and yes it is perfectly active once you have selected a slot. Thus on EF3 hardware if you put it in a slot other than 1, I put my on 4 by chance, then it fails horribly as it will randomly jump into what I had in slot 1 and crash. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
doh :=) |
