| |
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 !!! |
|
... 12 posts hidden. Click here to view all posts....
|
| |
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: 474 |
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: 107 |
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: 107 |
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: 1568 |
Extreme necroposting is going to be so 2013! |
| |
Count Zero
Registered: Jan 2003
Posts: 1825 |
@soci: completely diffeerent topic, but kernal replacement via expansion port without HW modification is possible nowadays - see EF3.
|
| |
soci
Registered: Sep 2003
Posts: 474 |
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: 447 |
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. |
| Previous - 1 | 2 | 3 - Next |
