| |
Majikeyric
Registered: Sep 2002
Posts: 83 |
Problem coding my own loading routine
Hi,
I'm not a loading routine programming guru, in fact in so many years that's the fist time I try myself to this...
I have read a lot of manuals and all say that if an error occurs when calling a kernal routine the carry flag is set but it doesn't seem to be really the case, here is my problem when in this little piece of code, there is an error when calling the OPEN routine, the carry is not set ?!! (e.g when opening a non existing file) and the CHKIN call just behind makes the machine crashes... :-(
How can I check if the file was successfully opened ???
lda FilenameLen
ldx #<Filename --> a non existing file
ldy #>Filename
jsr SETNAM
lda #8
ldx $ba
ldy #0
jsr SETLFS
jsr OPEN
bcs ERROR --> carry not set if an error occured ?!!
ldx #8
jsr CHKIN --> crash !!! :-(
I want my loading routine to run on all kind of drives (1541/CMD HD+FD/IDE64...).
Thank you very much !!! |
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
you have to read the error channel of the 1541 to retrieve information about disk drive errors. |
| |
Majikeyric
Registered: Sep 2002
Posts: 83 |
Thanks Graham I gonna do like you explain in the file not found error topic ;-) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
in basic it's like this:
open15,8,15
input#15,nr,ft$,tr,sk
close15
but why would you want those open/close mania in assembler also? those routines only cause a lot of trouble and make everything complicated like hell. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
some basics in communicating with the disk drive while avoiding all this basic shit:
sending data to the drive:
LDA $BA
JSR $FFB1 ; LISTEN
LDA #$6F ; secondary adress 15 (or $60 is a must!)
JSR $FF93 ; SECLSN
LDY #$00
l:
LDA mw,Y
JSR $FFA8 ; IECOUT
INY
CPY #...
BNE l
JSR $FFAE ; UNLSN
mw:
.text "m-w"
.word $0400
.byte $02
.byte .....
same for receiving data:
LDA $BA
JSR $FFB4 ; TALK
LDA #$6F
JSR $FF96 ; SECTLK
LDY #$00
STY $90 ; clear status
l:
JSR $FFA5 ; IECIN
BIT $90
BVS end ; drive has sent last byte
INY
BNE l
JSR $FFAB ; UNTLK
it's all pretty simple: for reading the error channel simply use the receive routine without sending any command to the drive on that channel before. ofcourse you can still use that open/close routines, but they cause a lot of trouble and crashes... |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
Alternatively, you could avoid a lot of that crap and use the "B-E" drive command to have the drive load up a sector into a buffer and execute it to start your speeder, without having to transfer the data over to the C64 and back. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Hmm.. I guess this topic wasn't about speeders at all?
Anyway, TALK/LISTEN, IECIN/OUT + other direct serial bus access routines are a no-no for IDE64 compatibility. |
| |
Majikeyric
Registered: Sep 2002
Posts: 83 |
I didn't test all that yet but... hooo, doesn't work with IDE64 ?!! humm... What can I do then...
I'm currently working on a project that will require very big files, and the final product won't fit on a single 1541 side, I project to release it on different medias (1541s, FDs, big ZIP archive, maybe CD-ROM for IDE64 card...) and I want it fully compatible with all kind of drives then I won't use any fastloaders... In fact in my loading routine I simply want to test if the file I want to open is here, If not I will send a message like that :
insert disk
for 1541 : #4
for FD : #2
(for HD no problem!) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Quote: Hmm.. I guess this topic wasn't about speeders at all?
Anyway, TALK/LISTEN, IECIN/OUT + other direct serial bus access routines are a no-no for IDE64 compatibility.
talk + listen is the most basic stuff some iec hardware should be able to do, and if ide64 is not able to do it... then just throw it into your dustbin because it sucks. |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
How about resetting ST (lda #$00, sta $90) before you call OPEN. Then after you open, check $90. I can't remember if it is $60 or $40 for file not found. You may need to read a byte. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Well, IDE64 is not an IEC device..
Still, you get most of the same functionality with OPEN,CHKIN/OUT,CHRIN/OUT
This is how I do file open & read with Kernal
lda #filenamelength
ldx #<filename
ldy #>filename
jsr setnam
ldx $ba ;last used device
lda #2 ;file number
ldy #0 ;0 = open for read (1 = for write)
jsr setlfs
jsr open
ldx #2
jsr chkin
No error checking here yet :) as I don't think you'll get the error before trying to read the first byte of the file, so
jsr chrin ;returns file byte in A
ldx $90 ;check status for error/EOF, if zero then everything ok (refer to PRG for status codes)
If you're having crashes, you're doing something wrong :) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
cadaver wrote:
"ldx $90 ;check status for error/EOF, if zero then everything ok (refer to PRG for status codes)"
afaik ide64 does not support the status byte. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Hmm.. though I saw an ldx $90 in the IDE64 manual's programming section :) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
all i heard is that the status byte causes a lot of trouble since ide64 doesn't support it. anyway, i still think ide64 should support talk/listen, since almost all storage device are connected to the iec bus and a small redirection wouldn't slow down anything since iec routines are dead slow anyway. |
| |
soci
Registered: Sep 2003
Posts: 480 |
Quote: all i heard is that the status byte causes a lot of trouble since ide64 doesn't support it. anyway, i still think ide64 should support talk/listen, since almost all storage device are connected to the iec bus and a small redirection wouldn't slow down anything since iec routines are dead slow anyway.
IDE64 does support the status byte. The method cadaver described is correct, and not just for IDE64.
IDE64 could only support talk/listen/etc. if the kernal is replaced. (and this is only with SCPU possible without hardware modifications) |
| |
Majikeyric
Registered: Sep 2002
Posts: 83 |
Thanks Soci ! |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
Quoting Grahamyou have to read the error channel of the 1541 to retrieve information about disk drive errors.
The problem is that reading error channel does bad things. Try this:
10 open 1,8,2,"textfile,s,r"
20 if st then 100
30 get#1, a$
40 print a$;
50 goto 20
100 print st
110 close 1
A simple SEQ text file reading to screen - everything works as expected. But try this (at least on a 64/1541), which is nothing really special for a use case - just opening and closing the command / status channel in addition to data file:
10 open 1,8,2,"textfile,s,r"
15 open 2,8,15
17 close2
20 if st then 100
30 get#1, a$
40 print a$;
50 goto 20
100 print st
110 close 1
The problem with STATUS (and READST) is that it doesn't show anything bad until you start reading from the file and get garbage.. try this:
10 open 1,8,2,"not found file"
20 if st then 100
25 print st
30 get#1, a$
40 print a$;
50 goto 20
100 print st
110 close 1
So the first question of the OP is very valid for me! |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
Forgot to give the answer / solution ;-)
One has to open the status channel and keep it open until done with the main file, check the OPEN success from status channel and then only use STATUS to verify EOF condition _after_ reading.. Bloated and unnecessarily complicated when compared to a simple CARRY return, which CBM forgot to implement in OPEN routine.. |
| |
gregg
Account closed
Registered: Apr 2005
Posts: 56 |
What is going on here? Have you been working on that problem for the last 10 years? |
| |
Scout
Registered: Dec 2002
Posts: 1570 |
Extreme necroposting is going to be so 2013! |
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
@soci: completely diffeerent topic, but kernal replacement via expansion port without HW modification is possible nowadays - see EF3.
|
| |
soci
Registered: Sep 2003
Posts: 480 |
Yes, I know that with careful timing it's possible to find out from the expansion port if it's "safe" to map in external ROM to $e000 using the ultimax configuration. But with the IDE64 hardware available it's only possible to replace the KERNAL with an SCPU or other hacks. Unfortunately this still stands today ;( |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
The original question is how to intercept errors during a file OPEN function.
OPEN don't set carry because in kernal routines are LOAD and SAVE that do this job, checking $90 and setting carry accordingly with value readed.
If we need to use OPEN, we need also to check 90 manually seting carry propely if an error (timeout or others) is detected.
Checking error channel is only to know what kind of error is, because 90 reports generic timeout, eof, or device not present flags.
This works on all devices, including IDE64. |
