Fixed #1970 (Missing definition for ST on cbm610 with getdevice) #1972

polluks2 · 2023-01-14T12:59:51Z

Also added cbm510 support.

mrdudz · 2023-01-14T15:49:51Z

Please remove the name of other authors from those files (and put your own there instead, if you want)

polluks2 · 2023-01-14T15:58:32Z

okie-dokie

kugelfuhr · 2023-01-15T09:51:51Z

This "fix" is broken. It will make the code compile but not work.

Please have a look at libsrc/cbm610/kreadst.s for enlightenment.

To fix #1970, libsrc/cbm/getdevice.s has to be changed. It is not portable and will not work as is for the CBM-II machines.

polluks2 · 2023-01-15T12:10:49Z

Indeed, I didn't take care of bank switching.

mrdudz · 2023-01-15T18:44:47Z

Indeed, I didn't take care of bank switching.

Are you saying you didn't even bother testing your patch? /o\

kugelfuhr · 2023-01-15T18:56:28Z

A simple test will work. The code clears ST and later checks ST against zero. If - as in the given case - the variable ST is not the one used by the kernal, the code will always return "success". So if you test this with existing devices, it seems to work.

polluks2 · 2023-01-15T21:55:23Z

Indeed, I didn't take care of bank switching.

Are you saying you didn't even bother testing your patch? /o\

Well, I was using BASIC which implies bank switching. I'll do better testing.
By the way why do we have status.s files, just for one symbol..?

mrdudz · 2023-01-15T22:04:46Z

By the way why do we have status.s files, just for one symbol..?

No idea really. I also sometimes wish certain design decisions would have been documented :)

ST is dead, long live the STATUS!

mrdudz · 2023-01-17T21:34:50Z

So is this working correctly now? :)

polluks2 · 2023-01-17T23:10:08Z

The output of enumdevdir for c64 and cbm610 is not the same, maybe this is a VICE issue?

mrdudz · 2023-01-17T23:25:01Z

Different how? :) And did you try with a single-drive (eg SFD)? The dual-drives may work slightly different.

But yes, it could be a VICE issue. The cbm2 emulation isnt really tested well (nor are the tank drives)

WartyMN · 2023-01-22T04:59:39Z

Thanks for fix. I can confirm it worked for me, in the sense that the error has gone away on link.

Not sure where to ask this, but are getfirstdevice() and getnextdevice() and getdevicedir() expected to work on the cbm610 in VICE? I haven't come across any combination that works with drive 8 & 9 in VICE on this machine. The legacy cbm_xxxx functions do work for drive 9.

mrdudz · 2023-01-22T05:04:10Z

Thanks for fix. I can confirm it worked for me, in the sense that the error has gone away on link.

Not sure where to ask this, but are getfirstdevice() and getnextdevice() and getdevicedir() expected to work on the cbm610 in VICE? I haven't come across any combination that works with drive 8 & 9 in VICE on this machine. The legacy cbm_xxxx functions do work for drive 9.

First thing to do would be testing on the real thing :) Generally the cbm2 machines in VICE aren't very well tested, so i wouldn't be surprised if there is something wrong, especially with the disk drives.

Does the same program work correctly in VICE when you compile it for the PET target and use it in xpet?

WartyMN · 2023-01-22T05:32:48Z

Amen to testing on the real thing. Unfortunately, the last working b128 blew its PSU just this morning :( and that curtailed my testing. I haven't compiled for PET, but can try that and see what happens with xpet.
Tested with: samples/enumdevdir.c
Setup: xcbm610: drives 8 and 9 configured, a d80 in both device.
Setup: pet: drives 8 and 9 configured, disk in each.
RESULTS:

CBM2: "Device 1: N/A" over and over stuck.
xpet: "device 8: N/A" ~ "device 30: N/A", program ends. if you run program again, it exits with no message.

so... better? I mean, at least it starts with 8 and stops at 30? It does not actually recognize the disk in either drive, so that's not good. And the fact it can't be run again is also not good.

mrdudz · 2023-01-22T05:40:07Z

And the fact it can't be run again is also not good.

That is normal for cc65 compiled programs though (at least on the CBM targets) - since they use the DATA section in-place. I always found it an odd design decision to even exit to basic for that matter.

polluks2 · 2023-01-22T14:27:58Z

@WartyMN Thanks for testing so far. @bob Andrew We exit to basic for a "?st" if you like.

WartyMN · 2023-01-22T14:47:05Z

One more test, for c64 this time. Setup is similar: 2 d64s in device 8 and 9.
result:
Device 8: Dir 80.
(never gets to drive 9)

I think it should be giving listing of drive 8, then go find drive 9, and list it out too.

mrdudz · 2023-01-22T14:55:33Z

Do you have true drive emulation disabled or something like that? C64 emu should work :)

WartyMN · 2023-01-22T15:04:02Z

Sorry, dumb: I don't really use the 64 emulator much. I hadn't enabled drive 9 in settings. With it enabled, I get:
Device 8:
Dir 80
Device 9:
Dir 90

So I think that means it's just failing on line 38's chdir()? But having never played with chdir etc until this week, I'm not 100% sure what it's supposed to do.

mrdudz · 2023-01-22T15:10:19Z

I'd expect chdir to be either a no-op (since CBM drives do not have subdirs) or to send a CMD style chdir DOS command (like open1,8,15,"cd:foo"), which should give a syntax error on drives that do not support it.

WartyMN · 2023-01-22T15:15:33Z

Am I thinking about chdir() wrong? I thought it was the replacement for setting _curunit, which let you (I gather) say "I want to use posix disk commands now with device 9 (etc)"?

Goodbye _curunit, Hello chdir()
https://cc65.github.io/mailarchive/2012-10/10932.html
"so coding like
_curunit = 9;
has to be replaced with
chdir("9");"

mrdudz · 2023-01-22T15:25:53Z

Am I thinking about chdir() wrong? I thought it was the replacement for setting _curunit, which let you (I gather) say "I want to use posix disk commands now with device 9 (etc)"?

I wouldnt have expected it to work like this. I also find it VERY disturbing that setting _curunit isnt equivalent. sigh

edit: ok at least the latter is not the case, the cbm function sets curunit. using chdir basically sets curunit and calls diskinit, which then sends DOS cmd "I" to find out if there is a disk in the drive. Which is .... questionable, unless you like machine gun rattling when there is no disk =P It should work though. I think.

mrdudz · 2023-01-28T13:36:44Z

Been poking around a bit - and i wonder how/if this ever worked. The problem is that the call to getdevicedir() returns "80" instead of "08".

polluks2 · 2023-01-28T13:39:15Z

Been poking around a bit - and i wonder how/if this ever worked. The problem is that the call to getdevicedir() returns "80" instead of "08".

Indeed!
https://cc65.github.io/mailarchive/2012-10/10932.html says:
On the CBMs the names are "8", "9", ...
this is missing in funcref.

mrdudz · 2023-01-28T13:40:44Z

cbm/initcwd.s

; Convert unit number in A into string representation pointed to by ptr2.

devicestr:
        jsr     pusha0
        lda     #10
        jsr     tosudiva0
        ldy     #0
        lda     sreg
        beq     @L0             ; >=10
        add     #'0'
        sta     (ptr2),y
        iny
@L0:    lda     ptr1            ; rem
        add     #'0'
        sta     (ptr2),y
        iny
        lda     #0
        sta     (ptr2),y
        rts

this is the offending code.

mrdudz · 2023-01-28T14:10:12Z

8ac5e2f fixes that code - please check if its now working correctly on cbm2 (it works for c64 with drive 8-11 in VICE now)

polluks2 · 2023-01-28T14:28:15Z

Thank you fixing my 18 years old bug, finally enumdevdir works.
Maybe we can save one clc?

mrdudz · 2023-01-28T14:34:36Z

Maybe we can save one clc?

yeah, perhaps it can be moved up before the branch. I'd try to get rid of the division call first though :)

mrdudz · 2023-01-28T14:56:29Z

In any case, please check if this works on cbm2 machines now (i guess if it works in VICE thats enough of a proof) so i can merge this

polluks2 · 2023-01-28T14:59:00Z

Right now it doesn't work, getfirstdevice() is broken.

mrdudz · 2023-01-29T11:09:42Z

Right now it doesn't work, getfirstdevice() is broken.

so fix it! :)

mrdudz · 2023-02-24T15:30:39Z

I'd really like to merge this - is there a way to test only the things that this fixes?

mrdudz · 2025-06-14T22:34:58Z

So whats the status of this now?

mrdudz · 2025-06-23T13:18:47Z

So what is even a good test case for this? One of the sample programs?

We should get this into the lib now :)

mrdudz · 2025-06-25T22:53:00Z

@polluks ping? how can i test this? :)

Fixed cc65#1970

0f98e59

polluks2 added 3 commits January 14, 2023 16:54

Update status.s

c92c27e

Update status.s

af5484d

Update status.s

178861d

mrdudz added enhancement need info / extra work More info and/or extra is needed from the OP to proceed libs labels Jan 15, 2023

polluks added 2 commits January 16, 2023 03:27

Big STATUS clean-up

fe205f1

ST is dead, long live the STATUS!

Fixed dangling spaces

a99f239

mrdudz changed the title ~~Fixed #1970~~ Fixed #1970 (Missing definition for ST on cbm610 with getdevice) Jun 14, 2025

Merge branch 'master' into status

71b923d

Fixed #1970 (Missing definition for ST on cbm610 with getdevice) #1972

Are you sure you want to change the base?

Fixed #1970 (Missing definition for ST on cbm610 with getdevice) #1972

Uh oh!

Conversation

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!