|
|
Post by Karski on May 13, 2024 21:02:24 GMT
I am encountering random behavior on VICE emulator when trying to use VDC and 1571 disk drive at the same time.
If I interact with VDC chip first, the KERNAL DOS operations crash the machine. Is it related to MMU operations, and how could I avoid the effect?
Here is an example program that should work but doesn't. If I comment out the VDC initialization routine, the open file operation succeeds. Now, jsr $FFC0 (OPEN) causes crash. What's happening?
!to"drivetest.prg",cbm
vcu_address = $d600
vcu_data = $d601
vcu_address_low = $02a7
vcu_address_high = $02a8
* = $1c01
; startup basic code
!by $0b,$08,$01,$00,$9e,$37,$31,$38,$31,$00,$00,$00 ;= SYS 7181
* = $1c0d ;=7181
jsr init_vdc
jsr open_sequential_file_for_write
rts
writeVDC: ; data in accumulator, address in X
stx vcu_address
- bit vcu_address
bpl -
sta vcu_data
rts
readVDC:
stx vcu_address
- bit vcu_address
bpl -
lda vcu_data
rts
setVDCUpdateAddress: ; from vcu_address_low
ldx #18
lda vcu_address_high
jsr writeVDC
inx
lda vcu_address_low
jsr writeVDC
rts
init_vdc:
lda #$80
sta vcu_address_low
lda #$7
sta vcu_address_high
jsr setVDCUpdateAddress
rts
open_sequential_file_for_write: ; OPEN 2,8,2, "0:SARJA,S,W"
ldx #<sequential_filename
ldy #>sequential_filename
lda #11
jsr $FFBD ; call SETNAM
lda #$02 ; file number 2
ldx $BA ; last used device number
bne +
ldx #$08 ; default to device 8
+ ldy #$02 ; secondary address 2
jsr $FFBA ; call SETLFS
jsr $FFC0 ; call OPEN
bcs disk_error ; if carry set, the file could not be opened
rts
disk_error:
lda #2
sta $d020 ; border color
rts
sequential_filename:
!scr "0:sarja,s,w",0
|
|
|
|
Post by xahmol on May 13, 2024 21:11:04 GMT
Why do you store the VDC address at $02A7-$02a8 ?
That is not a free to use address and overwrites the low memory copy of the FETCH routine.
|
|
|
|
Post by xahmol on May 13, 2024 21:20:53 GMT
|
|
|
|
Post by Karski on May 14, 2024 6:33:46 GMT
That's it, xahmol!
The memory area of $02A7-$02FF is unused in C64 memory map, and I was using it out of old habit. For C64, it is the first bigger block of free memory. For C128, KERNAL owns it.
Makes perfect sense now. Thanks for the immediate reply guys, you are a great community.
|
|
|
|
Post by xahmol on May 14, 2024 7:30:06 GMT
Great that I could be of help! The C128 needs this range to place banking code in the first kilobyte of memory, so that it is always visible regardless which bank you are in. Obviously the C64 does not have that issue 😉 Apparently the kernel disk routines are using far fetch to be able to also work regardless the bank you are in. By the way, you might consider also using the SETBNK kernal call to set the bank for disk operations first. Bank 0 is default, so that is probably why it works for you, but if uou did any BLOAD or such before starting your program loading something in bank 1 your code does not work anymore, as disk IO calls do not restore SETBNK. So also do not forget to put SETBNK back at bank 0 after disk IO is finished. cx16.dk/c128-kernal-routines/setbnk.html(funny fact: this is actually a bug in JiffyDOS for C128 in at least unpatched versions. SETBANK is not restored, so after loading anything to the non default bank, file IO goes haywire as obtaining the file name from the wrong bank gets very funky results) |
|
|
|
Post by xahmol on May 14, 2024 7:54:22 GMT
|
|
