| |
oziphantom
Registered: Oct 2014
Posts: 478 |
load hangs on hardware
So I have a some code loading a file. it won't be there the first time but that is fine.
on VICE it works with TDE 1541 and 1571
I compress it with Exomizer to get it to work on a device and load it via EF3 Easy Transfer
It fails in the LOAD function on my 128D, it just locks up. Load never returns.
If I run the exomized version on VICE it works fine. TDE 1541 and 71
LOAD
lda #$36
sta $01
lda #0
jsr $ff90 ; setmsg off
jsr SetUpFileName
lda #1
sta $d021
LDA #$00 ; $00 means: load to memory (not verify)
JMP $FFD5 ; call LOAD
inc $d021
sta $d020
lda #$35
sta $01
rts
SetUpFileName
LDA #fnameEnd-fname
LDX #<fname
LDY #>fname
SetUpFileName2
JSR $FFBD ; call SETNAM
LDA #$01
; LDX $BA ; last used device number
; CPX #8
; bcs _skip
; BNE _skip
LDX #$08 ; default to device 8
_skip
LDY #1 ; not $01 means: load to address stored in file
JSR $FFBA ; call SETLFS
RTS
.enc "none"
fnameReplace .text "@0:"
fname .text "ffiihs"
fnameEnd
any ideas? |
|
| |
tlr
Registered: Sep 2003
Posts: 1714 |
I would assume that $ffd5 does a cli, so your $35->$01 will probably break unless you have stopped timer IRQs. Insert sei after the load. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
it never returns from FFD5. The IRQ is set to an Empty one, but worth investigating thanks. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
I added this before hand
lda #$7f
sta $dc0d
sta $dd0d
lda $dc0d
lda $dd0d
lda #$00
sta $d01a
lda #$ff
sta $d019
lda $d01e
lda $d01f
jsr LOAD
same issue |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Ok, does you "empty" IRQ acknowledge the CIAs and/or other interrupt sources you have activated? If not, it will lock up in the ISR.
EDIT: mid air collision. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
yeah
EmptyIRQ
pha
lda $dc0d
pla
rti
CCS hangs during load, during the
.C:eea9 AD 00 DD LDA $DD00
.C:eeac CD 00 DD CMP $DD00
.C:eeaf D0 F8 BNE $EEA9 part of the kernal. The lockup also can't be frozen by the FC3... |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
CIA DDR? |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
>C:dc00 7f ff ff 00 16 39 b4 ff 00 00 00 01 20 00 01 01 .....9...... ...
ICR: 00 CTRLA: 01 CTRLB: 01
ICR write: 01 Timer A IRQ: on Timer B IRQ: off TOD IRQ: off Serial IRQ: off Cassette IRQ: off
Port A: 7f DDR: ff
Port B: ff DDR: 00
Timer A: 3916
Timer B: ffb4
TOD Time: 01:00:00.0 (am)
TOD Alarm: 00:00:00.0 (am)
Synchronous Serial I/O Data Buffer: 20
(C:$dc10) io dd00
CIA2:
>C:dd00 c0 ff ff 00 ff ff ff ff 00 00 00 01 00 00 08 08 ................
ICR: 00 CTRLA: 08 CTRLB: 08
ICR write: 00 Timer A IRQ: off Timer B IRQ: off TOD IRQ: off Serial IRQ: off Cassette IRQ: off
Port A: c0 DDR: ff
Port B: ff DDR: 00
Timer A: ffff
Timer B: ffff
TOD Time: 01:00:00.0 (am)
TOD Alarm: 00:00:00.0 (am)
Synchronous Serial I/O Data Buffer: 00 |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
okay doing a JSR $FF84 gets the driving behaving as I would expect... completly trashes my game and the code, but gets the drive working.. |
| |
Giulio/Wolf
Registered: Apr 2016
Posts: 18 |
I don't know if this will help you... though I recall I encountered the same issue of you when I cracked BUDOKAN one year ago. The game and the drive freezed at the same place of you. It was using standard Kernal loading routine like you so I was a bit stuck because it was happening only in particular places of the game, expecially after losing the game and reloading the main title.
I recall I fixed the problem simply setting the VIC-II BANK CIA#2 register to:
LDA #$C7
STA $DD00
This fixed the issue and I blanked the video before doing it to avoid on screen garbage (default VIC-II BANK for the game was another...)
Hope this helps because as you already noticed, call $FF84 makes the drive work again, so hopefully the problem is resetting the CIA#2 register only before call LOAD. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
setting the call back and the doing the load before I call anything causes it to end in BAD SUBSCRIPT ERROR ... it jumps into the AXXX range, does load need BASIC ROM? |
| |
Giulio/Wolf
Registered: Apr 2016
Posts: 18 |
No, $FFD5 can be used without BASIC ROM enabled.
try:
LDA #$C7 STA $DD00
LDA #$0 JSR $FFD5
in your routine.
If you call $FF84, yes it enables again the BASIC ROM so you should not use it because for what I see in your code you are disabling the BASIC at the start... isnt'it? |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
$c7 into $dd00 doesn't help :( |
| |
Giulio/Wolf
Registered: Apr 2016
Posts: 18 |
Well, sorry but I'm out of ideas.At this point I think it could be one of the few cases were there's incompatibility between C64 and C128 in 64 mode. You say it's working on VICE, so my last guess is this.
One last thing you could try is copy and paste the code called by $FF84 and stop before you encounter
LDA #$E7 STA $01
so for example:
JSR COPYROUTINE
LDA #$00 JSR $FFD5
in your routine.....
(obviously COPYROUTINE must be allocated somewhere in your code...) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: $c7 into $dd00 doesn't help :(
For eye of the beholder I do an IOINIT at start up and backups the whole ZP. Then I also make sure the game doesn't touch $0200-$03ff.
When loading I put my IRQs and NMIs into a no-op mode just like you do. Restore the "kernel" ZP and do the loading.
This was the only way I could get it to work in all weird cases. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
I save and restore Kernal addresses as per the IDE64 document. However if it was one of them being wrong, wouldn't it still fail in VICE? This is a hardware only hang.. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
If you, by accident, do something undefined all hell can break loose and very well be dependant on RAM-init pattern. |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
[stupid question]
Using Vice, you tried it on X64 or X128?
With X128 crash or works?
[/stupid question]
Maybe, if crash, X128 will help you to debug... |
| |
soci
Registered: Sep 2003
Posts: 473 |
JMP $FFD5 ; call LOAD
It's not a JSR in the original source, might be a problem. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote:
JMP $FFD5 ; call LOAD
It's not a JSR in the original source, might be a problem.
Haha wtf!!! Didn’t even see it! |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
Quoting soci
JMP $FFD5 ; call LOAD
It's not a JSR in the original source, might be a problem.
(/)_. a ; moment for sure. However it is not the only issue, I still need to do a lot of modifications to the code to get it to work.. |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
Somehow I doubt that Vice emulation is so broken that it makes the code with JMP instead of JSR working on emulator. There must be something else in the way. |
| |
Giulio/Wolf
Registered: Apr 2016
Posts: 18 |
Quote: Somehow I doubt that Vice emulation is so broken that it makes the code with JMP instead of JSR working on emulator. There must be something else in the way.
Exactly. Also, JMP or JSR doesn't make any difference for what he reported in his first post: his real 128D (in 64 mode? it's not specified) hangs and the drive doesn't spin when the Kernal LOAD routine is called when instead it works on VICE (X64? X128? again not specified). He also posted where exactly the load is hanging.
As I already posted, but without the necessary info is only a guess, it could be an incompatibility problem between C128 (in 64 mode?) and C64 (even if emulated on VICE). I perfectly recall the good ol' days when people with 128 were complaining on magazines that some C64 games were not working on their machines... (HE-MAN is the first game that comes in mind now...) |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
The hang happens on
C128D with 1571 booting from an EF3 cart - so it boots to C64 mode, as it detects the EF3 cartridge
C64C (don't know the model rev) loading from SD2IEC, Taptino with and without a FC3 cart connected, in both D64(only SD2IEC) and raw PRG loading.
Tested on X64sc 3.2,3.1 TDE with 1541 and 1571
2.4,2.4OSX, C64 Debugger latest - works fine in all cases
CCS64 3.x does show a hang on loading
So its not a 128 only issue, nor a 1571 only issue.
It happens if it is direct loaded ( on methods that support it) and loaded then decompressed via Exomizer 3.0 SFX
FUN FACT : FFBA also trashes part of RAM in the FD00-FE00 block... |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
also 02a6 is the correct 1 at time of loading, so that hasn't been trashed. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting oziphantomFUN FACT : FFBA also trashes part of RAM in the FD00-FE00 block... Sounds more like the $fd15 bug? The vector setup routine trashes ram at $fd30 on a stock kernal. |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Try to load it on C128, in 64 mode, pressing the "top" caps lock key (on the first row of keys)...
I recall sometimes it resolve some issues... |
| |
Krill
Registered: Apr 2002
Posts: 2845 |
Could it be stuck in the RSPOFF loop in RSP232 (http://unusedino.de/ec64/technical/aay/c64/romf0a4.htm) due to a faulty value of ENABL = $02a1?F0AA: AD A1 02 LDA $02A1 ; RS232 Enables
F0AD: 29 03 AND #$03
F0AF: D0 F9 BNE $F0AA
.,F0AA AD A1 02 LDA $02A1 RSPOFF LDA ENABL ;WAIT UNTILL DONE
.,F0AD 29 03 AND #$03 AND #%00000011 ; WITH T1 & T2
.,F0AF D0 F9 BNE $F0AA BNE RSPOFF
|
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
LDA #$FF
STA aDD02 ;CIA2: Data Direction Register A
LDA #$00
STA aDD00 ;CIA2: Data Port Register A
If I do this before the load, it works on VICE but fails on hardware... |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: LDA #$FF
STA aDD02 ;CIA2: Data Direction Register A
LDA #$00
STA aDD00 ;CIA2: Data Port Register A
If I do this before the load, it works on VICE but fails on hardware...
In EotB I had problems when I touched the upper bits of DD00. Never touch DD02 and always LDA, AND, OR, STA $dd00. It will be timing dependant. Try:
Lda $dd00
And #$3c
Sta $dd00 |
| |
Krill
Registered: Apr 2002
Posts: 2845 |
Yeah, changing the data direction register is a terrible idea for KERNAL load.
But the upper two bits of $dd00 (incoming DATA and CLK) can be set to anything as long as they're inputs (as is the default), so ANDing with #$fc would be no different than #$3c, #$7c or #$bc. |
