File size with IDEDOS READ ($DEF4)

[Pawel Krol]

Hi!

Is it possible to determine an exact file size when using READ routine
from IDEDOS ($DEF4)?

If not, what method of finding an exact file size would you consider to
be the fastest?

Many thanks!

/Pawel

[Comos]

You need to make a routine with a seek command and perform a interval halving method to get a exact file size.

Dne pondělí 4. září 2017 20:06:26 UTC+2 DJ Gruby/Oxyron napsal(a):

[Pawel Krol]

Hi Comos!

Could you please be more specific? I checked IDEDOS documentation, but
unfortunately there are no examples about how to use "seek" command...
There's only BASIC example, which is not very useful, because I want to
do it in Assembler. :(

Many thanks!

/Pawel

[Comos]

a seek command example you can take from IDE64 IFFL routine from https://cadaver.github.io/rants/iffl_ide64.zip
I have made a size check routine some time ago,but I have the src in my IDE64,not here actually.

Dne úterý 5. září 2017 17:46:25 UTC+2 DJ Gruby/Oxyron napsal(a):

[Pawel Krol]

Hi Comos!

So, an interesting fact... If I do seeking *BEFORE* calling a special
IDEDOS routine, e.g. before READ ($DEF4), everything works as expected.
However, if I call seeking procedure *AFTER* executing READ ($def4), it
fails to open a file, e.g. call to OPEN ($FFC0) returns with a carry
set. After flipping the order, i.e. seeking first, reading then,
everything works seamlessly.

Many thanks!

/Pawel

[Comos]

You need to set the seek parameter first,because you define a startup position with this (in case of a file) where to start to read ($DEF4 or byte-by-byte), so it cannot work the opposite way.


Dne úterý 5. září 2017 22:34:05 UTC+2 DJ Gruby/Oxyron napsal(a):

[Pawel Krol]

But to me that sounds more like a bug than a feature. Does it mean that
once a file has been read with IDEDOS read, it cannot be ever opened
again? This is clearly a defect then. Is there a bug tracker for IDEDOS
where this problem could be reported?

/Pawel

Am 05.09.2017 um 22:59 schrieb Comos:
> You need to set the seek parameter first, because you define a startup

[Kajtár Zsolt]

> But to me that sounds more like a bug than a feature. Does it mean that once a
> file has been read with IDEDOS read, it cannot be ever opened again? This is
> clearly a defect then. Is there a bug tracker for IDEDOS where this problem
> could be reported?

I can't figure out what you're doing there from the e-mails, please provide a
code example for both cases.

--
-soci-

[Pawel Krol]

Sure! I have prepared two code examples for you. Please check "HOWTO.md"
file for more information about how to run them. There are basically two
scenarios covered by these examples:

Scenario #1
-----------

1. Open file via KERNAL (`$ffc0`)
2. Load file via IDEDOS READ (`$def4`)

This one works just fine!

Scenario #2
-----------

1. Load file via IDEDOS READ (`$def4`)
2. Open file via KERNAL (`$ffc0`)

But this one results in an error upon an attempt to open file via $ffc0.

Let me know please if you figure out the source of this problem!

Many thanks!

/Pawel

[Comos]

Hi Pawel,

as I check your routine, in shared.inc you have a error:

load_via_def4   lda #FILENAME_SIZE
                ldx #<filename
                ldy #>filename
                jsr $ffbd   ; setup filename
                lda #$01    ; file number (1-255)
                ldx $ba     ; actual device number
                ldy #$00    ; secondary address
                jsr $ffba   ; SETLFS - set logical file, device, and secondary address
                jsr $ffe7   ; CLALL - forget all files, set I/O to keyboard and screen
                jsr $ffc0   ; open file
                ldx #$01
                jsr $ffc6   ; CHKIN - set standard input to the logical file number
                jsr $ffcf   ; CHRIN - get a character from current input
                lda $90     ; check Kernal I/O status
                bne close_file
                jsr $ffcf   ; CHRIN - get a character from current input

                lda #<LOADING_ADDRESS
                sta Z1+0
                lda #>LOADING_ADDRESS
                sta Z1+1

loop            lda #Z1          ; start address is here
                ldx #<BLOCK_SIZE ; block size
                ldy #>BLOCK_SIZE
                jsr $def4   ; READ - IDEDOS read (load data block from IDE64 drive)
                clc
                lda Z1+1
                adc #>BLOCK_SIZE
                sta Z1+1
                bit $90     ; readst
                bvc loop    ; test end of file
                ldx #$01
                jsr $ffc3   ; close file
                jsr $ffcc   ; CLRCHN - set standard I/O to keyboard and screen
                rts

Don't call $FFE7 when you do SETLFS,SETNAM beforehand, because it will discard what you set via those calls.

Dne středa 10. ledna 2018 20:47:27 UTC+1 Pawel Krol napsal(a):

[Pawel Krol]

Hi Comos!

As you suggested I have removed a call to $ffe7 entirely.

Unfortunately that didn't change anything. :(

Maybe it doesn't actually do anything? At least it wasn't really
harmful, because removing it doesn't make any difference...

/Pawel

On 01/10/2018 09:20 PM, Comos wrote:
> Hi Pawel,
>
> as I check your routine, in shared.inc you have a error:
>
> load_via_def4   lda #FILENAME_SIZE
>                 ldx #<filename
>                 ldy #>filename
>                 jsr $ffbd   ; setup filename
>                 lda #$01    ; file number (1-255)
>                 ldx $ba     ; actual device number
>                 ldy #$00    ; secondary address
>                 jsr $ffba   ; SETLFS - set logical file, device, and
> secondary address

> _*jsr $ffe7   ; CLALL - forget all files, set I/O to keyboard and screen*_

> --
> You received this message because you are subscribed to the Google
> Groups "IDE64" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ide64+un...@googlegroups.com
> <mailto:ide64+un...@googlegroups.com>.
> To post to this group, send email to id...@googlegroups.com
> <mailto:id...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/ide64.
> For more options, visit https://groups.google.com/d/optout.

[Comos]

Hi Pawel,

second thing, when I check the rest of your src closely, 1st test is okay, valid OPEN has to be done before READ.If I understand from the 2nd test, you do 1st READ and then OPEN, this will not work.
The READ call is just like a fast get byte-by-byte routine, that needs to have SETLFS,SETNAM, valid OPEN to be done before calling the READ.


Dne čtvrtek 11. ledna 2018 20:46:34 UTC+1 Pawel Krol napsal(a):

[Kajtár Zsolt]

In shared.src:

ldx #$01
jsr $ffc3 ; close file

This is a typo, I see you got the same right on at least 2 other places.

Because of this mistake (x vs. a) you don't close the file and the second open
of same logical file number fails with fault code 2.

--
-soci-

[Pawel Krol]

Why is this a typo?

When I check AAY64 for what $FFC3 does, I get this chain of subroutine calls:

JSR $FFC3 --> JMP ($031C) --> JMP $F291 --> JSR $F314

And here we have the following code:

F30F: A9 00     LDA #$00

F311: 85 90     STA $90       ; Kernal I/O Status Word ST

F313: 8A        TXA

See http://unusedino.de/ec64/technical/aay/c64/romf30f.htm for yourself.

If I had used A as an argument to $FFC3 it would have no effect at all, because it would have been overwritten with "LDA #$00" at $F30F.

So, why do you think this is a mistake?

/Pawel

--
You received this message because you are subscribed to the Google Groups "IDE64" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ide64+unsubscribe@googlegroups.com.
To post to this group, send email to id...@googlegroups.com.

[Kajtár Zsolt]

> Why is this a typo?

Because the interface is defined so that the logical file number must reside
in register A when calling CLOSE.

> When I check AAY64 for what $FFC3 does, I get this chain of subroutine
> calls:
>
> JSR $FFC3 --> JMP ($031C) --> JMP $F291 --> JSR $F314
>
> And here we have the following code:
>
> F30F: A9 00 LDA #$00
> F311: 85 90 STA $90 ; Kernal I/O Status Word ST
> F313: 8A TXA
>
> See http://unusedino.de/ec64/technical/aay/c64/romf30f.htm for yourself.

The subroutine you wanted to look at starts at $F314 further below. Links in
AAY64 do not always point to the code at the top of the page.

--
-soci-

[Pawel Krol]

Ahh, true! That was a confusing bit of AAY64, good to notice it!

I'll check it later when I'm back home and report back here, however
that seems like this might be it.

/Pawel

[Pawel Krol]

And of course you were right! This problem has bugged me for such a long
time, just to turn out to be a bloody typo! Oh boy... Sure, I need to be
more careful next time. Thanks heaps for pointing out the problem!

/Pawel