CBM DOS: How to read directory in raw format?

[pixel]

Hi there,

am trying to read a directory but I don't want to process the BASIC listing version. Using a secondary address of $60 was supposed to help with that but I still get the BASIC thing. Any ideas?

Code: Select all

.proc _cbm_opendir
    lda #1
    ldx s
    ldy s+1
    jsr SETNAM

    ldx #8
    ldy #$60    ; secondary address.
    lda #$02    ; logical file number.
    jsr SETLFS

    jsr OPEN
    bcs error

    ldx #$02
    jsr CHKIN
    bcs error

    ; Skip load address.
    jsr read
    bcs error
    jsr read
    bcs error

    ;; Skip first three lines.
    ldx #3
    ; Skip load address, first address of next line and line number.
m:  ldy #6
l1: jsr read
    bcs error
    dey
    bne l1

; ... Etc. still BASIC

[srowe]

I think you want a secondary address of $01, $60 gets ORed with the SA by OPEN anyway.

[Mike]

I think you want a secondary address of $01, [...]

A secondary address of 2 will do the job.

First, the sector with disk title and BAM will be read in, then follow the blocks with all the directory entries:

Code: Select all

1 OPEN2,8,2,"$"
2 GET#2,A$:A=ASC(A$+CHR$(.)):IFA<32ORA>=128ANDA<160THENA$="."
3 PRINTA,A$
4 IFST=0THEN2
5 CLOSE2

[...] $60 gets ORed with the SA by OPEN anyway.

Those are the KERNAL routines LISTEN($FFB1), TALK($FFB4), SECOND($FF83) and TKSA($FF96) which combine the value given in A automatically with bit 5 and bit 6 to signify device number/secondary address and talk/listen action, respectively. Thus, these two bits only appear on the bus - and the four routines only expect 4..31 for the device number and 0..30 for the secondary address.


Edit: the VIC PRM states that SECOND expects $60 to be ORed in by the calling program for a LISTEN action on the serial bus. An OPEN command in conjunction with CHKOUT to redirect output should do this automatically. Anyhow, those four functions are mainly used together with ACPTR($FFA5) and CIOUT($FFA8).

[pixel]

Thanks, guys!

A secondary address of 1 just caused an error (in VICE). Meanwhile I threw that code away and now I am using the cc65 lib… which is doing a BASIC directory read as well. I must say that this issue is badly documented, to say the least...

But while we're at it: any idea how to enter a directory on a virtual device in VICE!? Could it be that raw directory reads won't work with these anyway?

[malcontent]

Isn't the directory format in basic by default? I did a kernel load directory listing in ML on 64 and had to strip data to display what I wanted, maybe because I just used kernel routines to get the data, perhaps a rawer form is available more directly.

[Mike]

Isn't the directory format in basic by default?

Of course it is.

I did a kernel load directory listing in ML on 64 and had to strip data to display what I wanted, maybe because I just used kernel routines to get the data, perhaps a rawer form is available more directly.

Please note: we were at that point already.

The floppy has CBM DOS running over there. It is just a matter of what secondary address is used how the drive organizes its directory output (in BASIC form or "raw") and that has nothing to do with how the I/O routines on the computer's side look like.

any idea how to enter a directory on a virtual device in VICE!? Could it be that raw directory reads won't work with these anyway?

It's quite likely that you won't get the desired result, yes. The 1581 already has a different output format by nature (bigger BAM) and neither a SD2IEC (unless a *.d%% is mounted) nor VICE VDrive deliver anything that could be regarded as valid BAM header.

So, for maximum coverage, you'd possibly have to parse the standard (BASIC) directory output anyway. Like I do in my filecopy program (link) - and of course that one only works as well as long you don't encounter disks with fancy directory art ...

Even if the directory is 'just' supposed to be displayed (and not processed), you'll have to guard the display routine against over-length lines and non-standard characters. That cost me some extra code in the directory viewer of MINIPAINT (note: if you're actually running MP on real h/w, you can't just easily open the pop-up window of "VICE attach disk image" to view a *.d64's contents - that's the very reason I included this function ... )

In a related matter, most directory organizer programs of the time just did direct sector access on the directory track. Most time these only worked on one type of drive: 1541 single-sided, *possibly* 1571 double-sided - and I once wrote such a program for the 1581 which even supported CBM partitions. Sadly that one got lost due to the track-write bug of the 1581.

[groepaz]

as for VICE: dont use the virtual drives (directory access) for testing. ever. its barely working, and a lot of things work at least slightly different than on real drives. and anything that involves raw data doesnt work at all (as seen here) just use true drive emulation and it will work as expected.

[Forbidden64]

Hi there,
am trying to read a directory but I don't want to process the BASIC listing version. Using a secondary address of $60 was supposed to help with that but I still get the BASIC thing. Any ideas?

My advice would be to stick with the block commands themselves. In addition, I have heard it mentioned that some fictitious drives don't return a valid result. Well, both of these have a cure.

As a reference, I point you to Anatomy of the 1541 Disk Drive' by Abacus Software.
Specifically, sections 3.3 and sections 2.1 to 2.4 allow you to accurately identify the exact drive you are working with, as well as read the buffer and send direct block access commands to the disk drive. Read and identify free space in the BAM, calculate how many free blocks are free in the bitmap of the drive...In addition, I recommend for further reading as a code example, section 4.6 which gives clear examples of how to change and display individual blocks. All examples are given in basic, but can be easily translated to ML. You can read the buffer as well using these sections and then parse using the information provided.

Given the breadth of the question, I find it would be somewhat silly to post at least 4 sections of a large book in a thread post.
I'll give you a link to the book instead. You will be well rewarded for reading it!

Also for manually moving the heads around there is another book called '1541 User's Guide' which in spite of it's pedestrian name was written by a PH.D. and contains a wealth of knowledge and useful programs including the above mentioned, and an Unscratch tool, alignment tool which uses the demo disk as a known good starting point etc.

The Anatomy of the 1541 Disk Drive:
http://69.60.118.202/books/commodore/bo ... _Drive.zip

1541 Users Guide:
http://69.60.118.202/books/commodore/bo ... _Guide.zip

There is another one here that is newly added that I haven't read...it comes with a disk image!
For that I'll just put the download page for all these books...
'Inside Commodore DOS'
http://69.60.118.202/commodore/books.htm
I don't know about that latter, but 511 pages has to have something in it. Regardless, the resources I supplied ought to be enough for you to
turn your floppy drive into a friggin' spaceship already with specific sections already cut out from my own reading.

Byte 02 by the way, tells you the drive type starting with byte 0 of course, being the 3rd byte. Just so there is no confusion. I have read references to byte 2 in this thread, which is byte 01.

[pixel]

Phew! What a thorough reply. Thank!