Category Archives: CoCo

Tandy/Radio Shack TRS-80 Color Computer (CoCo)

EXEC versus USR: Who called me?

3 Replies

NOTE: I originally started writing this in November 2025, but kept thinking I’d do more work on it. I haven’t gotten around to it, so here you go…

Here is a Color BASIC 6809 assembly quickie… (That ended up not being very quick by the time I finished working through all of this…)

Recently I began working on an assembly language Color BASIC extension that makes certain characters move the cursor around the screen rather than just printing those characters (similar to what my VIC-20 could do). Initially, I created the 6809 assembly routine you could load into memory and EXEC. Next I decided to let it be called from DEF USR so I could pass in parameters and return a status code like A=USR0(-1). Next next I decided I wanted it to still work with EXEC so the user could use it either way–just use defaults with EXEC, or customize things using USR.

Then I ran into a snag…

USRx(n) or EXEC?

If the USR routine ONLY expected a number parameter, the code to handle both USR and EXEC seems easy. When calling a routine with EXEC, the D register will be zero (it seems). If it wasn’t zero, I could then do the JSR INTCNV call which would process the parameter in BASIC and put it in the D register.

My startup code looked something like this:

; lwasm execdreg.asm -fbasic -oexecdreg.bas --map
; decb copy -2 execdreg.bin drive0.dsk,EXECDREG.BIN

; Show if routine is being called with USRx(n) or EXEC

ORGADDR     equ     $3e00       ; Where program loads in memory.

; Absolute addresses of ROM calls.
CHROUT      equ	    $A002
INTCNV      equ     $B3ED
GIVABF      equ     $B4F4

            org     ORGADDR

; This code expects to have been called by USRx(x) or EXEC xxxx.
start       cmpd    #0          ; called from EXEC?
            beq     fromexec    ; if yes, goto fromexec
fromusr     jsr     INTCNV      ; else, get USR number parameter in D
            pshs    d           ; save D
            leax    usrmsg,pcr  ; display "called from USR" message
            bsr     print
            puls    d           ; restore D
            addd    #1          ; add one to D
            jmp     GIVABF      ; return back to USR call.

fromexec    leax    execmsg,pcr ; display "called from EXEC" message
            bsr     print
            rts

; PRINT subroutine. Prints the 0-terminated string pointed to by X plus CR.
print       lda     ,x+
            beq     printdone
            jsr     [CHROUT]
            bra     print
printdone   lda     #13
            jsr     [CHROUT]
            rts

usrmsg      fcc     "CALLED FROM USR"
            fcb     0

execmsg     fcc     "CALLED FROM EXEC"
            fcb     0

            end

When the routine starts, it checks to see what D is set to. If 0, it assumes it was called from EXEC and jumps to code that just prints “FROM EXEC” then ends.

If not 0, it assumes it was called from USR and the code calls the ROM INTCVT routine to parse the parameter and place it in D, then it prints “FROM USR”, increments D (just so we can verify it passed something back), and returns it back to BASIC.

Here it is in operation:

And all was right in the world… Until I tried just using EXEC by itself. After using it first with the address (“EXEC &H3E00”) BASIC will remembers that address so when you just type “EXEC” next it uses the previous address:

EXEC &H3E00
FROM EXEC

EXEC
?TM ERROR

Making the user always have to provide the EXEC address each time is not optimal. My solution was clearly not a solution.

But wait! There’s more…

I also learned about Sean Conner documenting how USR can also take a string parameter instead of just a number. If you are interested in USR, be sure to check out that link. He also has a cool 6809 compiler (“a09”) I just started playing with. It has some unique features not available in other compilers I have tried.

USRx(n) or USRx(“STRING”)

With this new knowledge, I had an idea to make my USR routine also be able to take a string for a special configuration function. I could let the user specify the four characters that will move the cursor by doing something like A=USR0(“udlr”). But, if you pass in a string and it calls INTCNV, that routine will check the parameter type and, if not a number, return with a ?TM ERROR (type mismatch).

This required me to learn how to tell whether USR was being called with a number or a string.

Under Extended Color BASIC (the original Color BASIC did things differently, see Sean’s page for details), the ROM code sets up some registers when calling the USR function. Sean documented these in his excellent blog post on USR. Basically, register A would be 0 if the USR parameter was a number, or 255 if it was a string. If it was a string, register X would have the address of the string descriptor (the location in memory that VARPTR returns) and register B would be the length of the string.

That is really convenient. Now you can have code that detects if it is being called from USR with a number or a string. My test code looked like this:

; lwasm execdreg2.asm -fbasic -oexecdreg2.bas --map
; decb copy -2 execdreg2.bin drive0.dsk,EXECDRG2.BIN

; Show if USR is being called with a number or a string.

ORGADDR     equ     $3e00   ; Where program loads in memory.

; Absolute addresses of ROM calls.
CHROUT      equ	    $A002
INTCNV      equ     $B3ED
GIVABF      equ     $B4F4

            org     ORGADDR

; This code expects to have been called by USRx(x) or USRx("STRING")
start       tsta                    ; A=0 is USR(0), A=255 is USR("...")
            bne     usrstring       ; if not 0, goto usrstring
usrnumber   pshs    d,x             ; save D and X
            leax    numbermsg,pcr   ; display "number" message
            bsr     print
            puls    d,x             ; restore D and X
            jsr     INTCNV          ; else, get USR number parameter in D
            addd    #1              ; add one to D
            jmp     GIVABF          ; return back to USR call.

usrstring   leax    stringmsg,pcr   ; display "string" message
            bsr     print
            ldd     #123            ; load D with return value
            jmp     GIVABF          ; return back to USR call.

; PRINT subroutine. Prints the 0-terminated string pointed to by X plus CR.
print       lda     ,x+
            beq     printdone
            jsr     [CHROUT]
            bra     print
printdone   lda     #13
            jsr     [CHROUT]
            rts

stringmsg   fcc     "STRING"
            fcb     0

numbermsg   fcc     "NUMBER"
            fcb     0

            end

And here it is in operation:

Now I know how to detect a USRx(number) versus EXEC, and how to detect a USRx(number) versus a USRx(string). But, this has the same problem if called by EXEC with no address:

EXEC &3E00
NUMBER

EXEC
NUMBER
?TM ERROR

It appears that using EXEC with the address after it sets registers up differently than using EXEC with no address (where it uses the last address EXEC used). While both end up at the code path for USRx(number), is seems that plain EXEC thinks it is returning an invalid type and the ?TM ERROR is displayed.

EXEC or EXEC xxxx or USRx(n) or USRx(“STRING”)

Can both routines be combined? On the CoCo mailing list, this all started when I asked: Is there a way to tell if a routine was called from USR versus EXEC? It was Sean’s reply that got me going down this rabbit hole:

Maybe.

Address $9D contains the address EXEC uses to jump to your code, so that
should be called address.  Also, X will also be this address (implementation
detail).

For Color BASIC, you need to know you are running under Color BASIC. 
Address $112 is the address for USR, so this should point to your code. 
Also, upon calling, X should be equal to $AA2F and B should be 6 (both are
implementation details).

For Extended Color BASIC, you need to know you are running under Extended
Color BASIC (16 bits at $8000 are $4558).  Addresses $013E through $0150
contain the USRn addresses, so one of these 10 addresses should point to
your code.  Also, A will equal the contents of address $06.  If A=0, then
X=$4F; if A=255, then X is pointing elsewhere (the string descriptor).

For Disk Extended Color BASIC, you need to know you are running under Disk
Extended BASIC (16 bits at $C000 are $444B).  The USRn addresses are now
$095F through $0971, but other than that, it’s the same as Extended Color
BASIC.

Based on all that, I think the best method might be (completely untested):

mycode cmpx #mycode
beq called_by_exec
; otherwise, assume called by USR/USRn

Good luck.

-spc

– Sean Conner via the CoCo Mailing List

This gave me a lot of think about. I did some tests to see what register X looked like when being called by EXEC with or without an address, as well as looking at what was stored in the $9D memory location which is the address EXEC (with no address after it) will use. I created a simple program that would print the value of the X register and the value of $9D so I could test it and see what the pattern was. This code uses an undocumented ROM call that will print the value of the D register. (I learned about this call from Sean’s pages.)

; lwasm showstuff.asm -fbasic -oshowstuff.bas --map
; decb copy -2 showstuff.bin drive0.dsk,SHOWSTUF.BIN

ORGADDR     equ     $3e00       ; Where program loads in memory.

; Absolute addresses of items in RAM variables.
EXECJP      equ     $9d         location of jump address for EXEC

; Absolute addresses of ROM calls.
REGDOUT     EQU     $BDCC       ; Convert the value in ACCD into a decimal
                                ; number and send it to CONSOLE OUT.

            org     ORGADDR

start       tfr     x,d         ; X=D
            jsr     REGDOUT
            lda     #32         ; space
            jsr     [CHROUT]
            ldd     EXECJP      ; load D with EXEC address
            jsr     REGDOUT
            rts

            end

Now I could load this into memory, set up a DEFUSR0=&H3E00 and do some tests:

15872 ($3E00) is the start of my user program. EXEC with that address will have both X and the $9D memory location containing that value.

EXEC without an address will have 43947 ($ABAB) in X, and 15872 ($3E00) as the address of the last EXEC address specified. But what is $ABAB? Looking at the Color BASIC Unravelled book, that address is where the EXEC token is:

ABAB     FDB EXEC

I did not dive into this, but I expect X was is used for the token scanning and since that was the last thing it found (no address after it to parse) that is what was in the register when it jumps to the user code.

When I tested A=USR0(0), I got a 79 in register X, and $9D still had the last EXEC address used. It then errored out with a ?TM ERROR due to this code not setting up a clean return back to a USR call.

And lastly, A=USR0(“STRING”) put 425 in register X, and $9D was still the last EXEC address used.

Now, had I done the USR calls first, that $9D would not be set up yet and it would look like this:

46154 ($B44A) appears to be the default value EXEC will use. By default, EXEC points to the routine that prints ?FC ERROR:

B44A     FDB LB44A   ARGUMENT OF EXEC COMMAND - SET TO ‘FC’ ERROR

So on a power cycle, typing EXEC is the same as typing EXEC &HB44A:

EXEC &HB44A
?FC ERROR

Having this value there is not useful for any of my checks since all that means is that the user has not done an EXEC with an address yet.

BUT, now that I see what happens with register X, I should be able to check it, and the $9D exec location and determine if I am being called by EXEC, EXEC xxxx, or a USRx command. Here is my test program:

; lwasm whocalled.asm -fbasic -owhocalled.bas --map
; decb copy -2 whocalled.bin drive0.dsk,WHOCALLD.BIN

ORGADDR     equ     $3e00       ; Where program loads in memory.

; Absolute addresses of items in RAM variables.
EXECJP      equ     $9d         location of jump address for EXEC

; Absolute addresses of ROM calls.
CHROUT      equ	    $A002

            org     ORGADDR

; This code expects to have been called by USRx(x).
start       cmpx    #start      ; called by "EXEC xxxx"?
            beq     fromexec    ; if yes, goto fromexec
            cmpx    #$abab      ; called by "EXEC"?
            bne     fromusr     ; if no, must be USR. goto fromusr
            ldx     EXECJP      ; get EXEC address
            cmpx    #start      ; called by "EXEC xxxx"?
            beq     fromexec    ; if yes, goto from exec
fromusr     leax    usrmsg,pcr
            lbsr    print
            rts
fromexec    leax    execmsg,pcr
            lbsr    print
            rts

; PRINT subroutine. Prints the 0-terminated string pointed to by X plus CR.
print       lda     ,x+
            beq     printdone
            jsr     [CHROUT]
            bra     print
printdone   lda     #13
            jsr     [CHROUT]
            rts

usrmsg      fcc     "FROM USR"
            fcb     0

execmsg     fcc     "FROM EXEC"
            fcb     0

            end

And here is what it does:

I now have code that can properly (?) detect if it was called from EXEC xxxx, EXEC, or USR. This demo does not handle detecting a string parameter to USR, but … I think it proves it is possible to do it.

With a few more lines of assembly, I came up with this test program:

; lwasm whocalled2.asm -fbasic -owhocalled2.bas --map
; decb copy -2 whocalled2.bin drive0.dsk,WHOCALL2.BIN

ORGADDR     equ     $3e00       ; Where program loads in memory.

; Absolute addresses of items in RAM variables.
EXECJP      equ     $9d         location of jump address for EXEC

; Absolute addresses of ROM calls.
CHROUT      equ	    $A002
INTCNV      equ     $B3ED
GIVABF      equ     $B4F4

            org     ORGADDR

; This code can be called by USRx(n), USRx("STRING"), EXEC addr or EXEC.
start       cmpx    #start      ; called by "EXEC xxxx"?
            beq     fromexec    ; if yes, goto fromexec
            cmpx    #$abab      ; called by "EXEC"?
            bne     fromusr     ; if no, must be USR. goto fromusr
            ldx     EXECJP      ; get EXEC address
            cmpx    #start      ; called by "EXEC"?
            beq     fromexec    ; if yes, goto from exec
fromusr     tsta                ; A=0?
            beq     donumber    ; if yes, number passed in. goto donumber.
            inca                ; inc A so if 255 (string) it will be 0 now.
            beq     dostring    ; if A=0 (was 255), string. goto dostring.
            bra     unknown     ; else, goto unknown (this should never happen).
            
donumber    leax    numbermsg,pcr ; show "number" message
            bsr     print
            jsr     INTCNV      ; get number that was passed in
            addd    #1          ; add 1 to D
            jmp     GIVABF      ; return new number back to BASIC

dostring    leax    stringmsg,pcr ; show "string" message
            bsr     print
            ldd     #12345      ; load D with a return value
            jmp     GIVABF      ; return that number back to BASIC

fromexec    leax    execmsg,pcr ; show "from exec" message
            lbsr    print
            rts

unknown     leax    unknownmsg,pcr ; this should never happen
            lbsr    print       ; show "unknown" message
            rts

; PRINT subroutine. Prints the 0-terminated string pointed to by X plus CR.
print       lda     ,x+
            beq     printdone
            jsr     [CHROUT]
            bra     print
printdone   lda     #13
            jsr     [CHROUT]
            rts

execmsg     fcc     "FROM EXEC"
            fcb     0

numbermsg   fcc     "FROM USR(NUMBER)"
            fcb     0

stringmsg   fcc     "FROM USR(STRING)"
            fcb     0

unknownmsg  fcc     "UNKNOWN"
            fcb     0

            end

And here is what I get after loading this into memory:

DEF USR0=&H3E00
OK

A=USR0(42)
FROM USR(NUMBER)
PRINT A
43

A=USR0("STRING")
FROM USR(STRING)
PRINT A
12345

EXEC &H3E00
FROM EXEC

EXEC
FROM EXEC

I think we may have a winner! The important parts are:

start       cmpx    #start      ; called by "EXEC xxxx"?
            beq     fromexec    ; if yes, goto fromexec
            cmpx    #$abab      ; called by "EXEC"?
            bne     fromusr     ; if no, must be USR. goto fromusr
            ldx     EXECJP      ; get EXEC address
            cmpx    #start      ; called by "EXEC"?
            beq     fromexec    ; if yes, goto from exec
  • If X is the address of the user program, it was called by “EXEC xxx”
  • If not, then if X is NOT $ABAB, it was called by USR
  • Else, it was $ABAB, so the EXECJP ($9D) is checked to see if it is the address of the user program. If it is, it is from EXEC.

I hope that makes sense. If not, think of it like this:

  • X=program start – it was called from EXEC xxxx
  • X=$ABAB and EXECJP=program start – it was called by EXEC.
  • Anything else is USR.

Now what I need from you is to double check my work and tell me if I got this right, and if this method can be relied on.

Comments if ya got ’em!

Until next time…

Color BASIC, Juan Castro and “forbidden” variables

13 Replies

Over the years I have shared many tidbits about Color BASIC.

This is another one.

A recent post by Juan Castro to the Groups.IO Color Computer mailing list caught my attention, mostly because he called me out by name in the subject line:

https://groups.io/g/ColorComputer/message/312

Color BASIC variable name limits

As a reminder, Color BASIC allows 1 or 2 character variable names. They must start with a letter (A-Z) and the second character can be either letter (A-Z) or number (A-0). BUT, the BASIC interpreter does let you type longer names for variables, but it only honors the first two characters. Here is a screenshot from a past blog post here (which I’d link to if I was not so lazy):

Color BASIC variables may be very long, but only the first two characters are used.

This is a reminder that, if you try to use variables longer than two characters, you have to make sure you always keep the first two characters unique since “LONGVARIABLE” and “LOST” and “LO” are all the same variable to BASIC.

…but not all variable name limits are the same.

To break the rule I just said, in Color BASIC, some variable names are forbidden. A forbidden variable is one you cannot use because it is already reserved for a keyword or token. For example, FOR is a keyword:roar

FOR I=1 TO 10
PRINT I
NEXT I

Because of this, even though BASIC only honors the first two characters of a variable name, you still cannot use “FOR” as a variable.

FOR=42
?SN ERROR

But you can use “FO”, since that is not long enough to be recognized as a BASIC token or keyword.

FO=42
PRINT FO
42

There are a number of two-character tokens, such as “TO” in the FOR/NEXT statement (“FOR I=1 TO 10”), and “AS” in the Disk BASIC FIELD statement (“FIELD #1,5 AS A$”), as well as “FN” which is used in DEF FN.

AS=42
?SN ERROR

FN=42
?SN ERROR

TO=42
?SN ERROR

This means if you wrote something for Color BASIC or Extended Color BASIC that uses “AS” as a variable, that would not work under Disk Extended Color BASIC.

BASIC ignores spaces

In recent years, someone pointed me to the fact that when scanning a BASIC line (either type in directly or when parsing a line of code in a program), spaces get ignored by the scanner. This means:

N M = 42
PRINT N M
42

That one surprised me when I learned it. This is probably why, when printing two variables, a semicolon is required between them:

N = 10
M = 20
PRINT N;M
10  20

And if you had done this (remember to CLEAR between these tests so variables are erased each time):

N = 10
M = 20
NM = 30
PRINT N M
30
PRINT N;M;N M
10  20  30

By the way, if you have ever wondered about that space printed in front of numeric variables when you do things like “PRINT X”, I covered why this happens in an earlier blog and included a simple patch to BASIC that removes that feature.

How to turn a forbidden variable into a non-forbidden one for fun and profit

Well, Juan Casto showed that using this “BASIC ignores spaces” quirk as a way to use forbidden variables. From his post:

Now it seems obvious. BASIC’s interpreter looks for keywords like “FOR” and will not recognize “F O R” or “FO R” as that token. The detokenizer honors the spaces.

But when it comes to variables, the spaces are ignored by the parser, so “T O” will not match as a token for “TO”, but will be processed as a variable “TO”.

Go figure.

Admittedly, space in two-character variable names look silly, but now I can finally update my old *ALLRAM* BBS to use the variable “TO$” for who a message is to:

FR$="ALLEN HUFFMAN"
T O$="JUAN CASTRO"
SB$="THAT'S REALLY COOL"

Though why would you want to do that… (Please click on that link. That’s a web domain I own… ;)

Not invented here

I suspect this was discovered by the early pioneers of BASIC, likely soon after the original Color Computer was released in 1980. If you know of a reference to this behavior from some early newsletter or magazine article, please let me know.

And as to Juan … thanks for sending me down a BASIC rabbit hole again…

Until next time…

Interfacing assembly with BASIC via DEFUSR, part 8

Leave a reply

See also: part 1, part 2, part 3, part 4, part 5, part 6, part 7 and part 8.

Just when I thought I was out, they pull me back in.

In part 3 I showed a simple assembly language routine that would uppercase a string.

In part 5, this routine was made more better by contributions from commenters.

Today, I revisit this code and update it to use “what I now know” (thank you, Sean Conner) about being able to pass strings into a USR function without using VARPTR.

First, here is the code from part 5:

* UCASE.ASM v1.01
* by Allen C. Huffman of Sub-Etha Software
* www.subethasoftware.com / alsplace@pobox.com
*
* 1.01 a bit smaller per Simon Jonassen
*
* DEFUSRx() uppercase output function
*
* INPUT:   VARPTR of a string
* RETURNS: # chars processed
*
* EXAMPLE:
*   CLEAR 200,&H3F00
*   DEFUSR0=&H3F00
*   A$="Print this in uppercase."
*   PRINT A$
*   A=USR0(VARPTR(A$))
*
ORGADDR     EQU     $3f00

GIVABF      EQU     $B4F4   * 46324
INTCNV      EQU     $B3ED   * 46061
CHROUT      EQU     $A002

            opt	    6809    * 6809 instructions only
            opt	    cd      * cycle counting

            org     ORGADDR

start       jsr     INTCNV  * get passed in value in D
            tfr     d,x     * move value (varptr) to X
            ldy     2,x     * load string addr to Y
            beq     null    * exit if strlen is 0
            ldb     ,x      * load string len to B
            ldx     #0      * clear X (count of chars conv)

loop        lda     ,y+	    * get next char, inc Y
;	        lda     ,y      * load char in A
            cmpa    #'a     * compare to lowercase A
            blt     nextch  * if less, no conv needed
            cmpa    #'z     * compare to lowercase Z
            bgt     nextch  * if greater, no conv needed
lcase       suba    #32     * subtract 32 to make uppercase
            leax    1,x     * inc count of chars converted
nextch      jsr     [CHROUT] * call ROM output character routine
;           leay    1,y     * increment Y pointer
cont        decb            * decrement counter
            bne	    loop    * not done yet
;           beq     exit    * if 0, go to exit
;           bra     loop    * go to loop

exit        tfr     x,d     * move chars conv count to D
            jmp     GIVABF  * return to caller

null        ldd     #-1     * load -2 as error
return      jmp     GIVABF  * return to caller

* lwasm --decb -o ucase2.bin ucase2.asm -l
* lwasm --decb -f basic -o ucase2.bas ucase2.asm -l
* lwasm --decb -f ihex -o ucase2.hex ucase2.asm -l
* decb copy -2 -r ucase2.bin ../Xroar/dsk/DRIVE0.DSK,UCASE2.BIN

In the header comment you can see an example of the usage, and that it involved using VARPTR on a string to get the string’s descriptor location in memory, then pass that address into the USR function.

See also: Color BASIC and VARPTR

Now that I know we can just pass a string in directly, I thought it would be fun (?) to update this old code to use that method. Here is what I came up with. Note that I changed the “*” comments to “;” since the a09 assembly does not support those. If you wanted to run this in EDTASM, you would have to change those back.

; UCASE3.ASM v1.02
; by Allen C. Huffman of Sub-Etha Software
; www.subethasoftware.com / alsplace@pobox.com
;
; 1.01 a bit smaller per Simon Jonassen
; 1.02 converted to allow passing a string in to USR
;
; DEFUSRx() uppercase output function
;
; INPUT:   string
; RETURNS: # chars converted or -1 if error
;
; EXAMPLE:
;   CLEAR 200,&H3F00
;   DEFUSR0=&H3F00
;   A$="Print this in uppercase."
;   PRINT A$
;   A=USR0(A$)
;   PRINT "CHARS CONVERTED:";A
;   A=USR0("This is another test");
;   PRINT "CHARS CONVERTED:";A
;
ORGADDR     EQU     $3f00

CHROUT      EQU     $A002
CHKSTR      EQU     $B146       ; Undocumented ROM call
INTCNV      EQU     $B3ED       ; 46061
GIVABF      EQU     $B4F4       ; 46324

            org     ORGADDR

start       jsr     CHKSTR      ; ?TM ERROR if not a string.
            ; X will be VARPTR, B will be string length
            tstb
            beq     reterror    ; exit if strlen is 0
            ldy     2,x         ; load string addr to Y
            ldx     #0          ; clear X (count of chars conv)

loop        lda     ,y+	        ; get next char, inc Y
            cmpa    #'a         ; compare to lowercase A
            blo     nextch      ; if less, no conv needed
            cmpa    #'z         ; compare to lowercase Z
            bhi     nextch      ; if greater, no conv needed
            suba    #32         ; subtract 32 to make uppercase
            leax    1,x         ; inc count of chars converted
nextch      jsr     [CHROUT]    ; call ROM output character routine
            decb                ; decrement counter
            bne	    loop        ; not done yet

            tfr     x,d         ; move chars conv count to D
            bra     return

reterror    ldd     #-1         ; load -1 as error
return      jmp     GIVABF      ; return to caller

            end

; lwasm --decb -o ucase3.bin ucase3.asm -l -m
; lwasm --decb -f basic -o ucase3.bas ucase3.asm -l -m
; lwasm --decb -f ihex -o ucase3.hex ucase3.asm -l -m
; decb copy -2 -r ucase3.bin ../Xroar/dsk/DRIVE0.DSK,UCASE3.BIN
; a09 -fbasic -oucase3_a09.bas ucase3.asm

Here are the changes… In the original version, I have this:

start       jsr     INTCNV  * get passed in value in D
            tfr     d,x     * move value (varptr) to X
            ldy     2,x     * load string addr to Y
            beq     null    * exit if strlen is 0
            ldb     ,x      * load string len to B
            ldx     #0      * clear X (count of chars conv)

That first jsr INTCNV expects a number parameter and, if not a number, it exits with ?TM ERROR. If it gets past that, the number is in the D register and it gets transferred over to X. In this case, the number is the value returned by VARPTR:

A=USR0(VARPTR(A$))

That value is the address of the 5-byte string descriptor that contains the address of the actual string data and the length of that data. Y is loaded with 2 bytes in from wherever X points which makes Y contain the address of the string data.

After this is a bug, I think. Looking at the comments, I think that “beq null” should be one line lower, like this:

start       jsr     INTCNV  * get passed in value in D
            tfr     d,x     * move value (varptr) to X
            ldy     2,x     * load string addr to Y
            ldb     ,x      * load string len to B
            beq     null    * exit if strlen is 0
            ldx     #0      * clear X (count of chars conv)

That way, Y is loaded with the address of the string data, then b is loaded with the length of that data, and the branch-if-equal check is now checking B. If the length is 0, it is an empty string so no processing can be done on it. (That’s a bug, right?)

The new code is this:

start       jsr     CHKSTR      ; ?TM ERROR if not a string.
            ; X will be VARPTR, B will be string length
            tstb
            beq     reterror    ; exit if strlen is 0
            ldy     2,x         ; load string addr to Y
            ldx     #0          ; clear X (count of chars conv)

The first line is something I learned from Sean Conner‘s excellent writeup on USR. That is an undocumented ROM call which checks is a variable is a string. If it isn’t, it will return back to BASIC with a ?TM ERROR. By having that check there, if the user tries to pass in a number, that error will be seen. As a bonus, if you try to EXEC that code, that, too, will show ?TM ERROR.

After that, B should be the length of the string so tstb checks that to be 0 (empty string) then the rest of the code is similar.

As I write this, I could have altered the order of my new code to do the tstb/beq after the ldy and then it would be closer to how the original worked. But since the original appears buggy, I won’t worry about that.

Now if I load this and set it up, I should see this:

DEF USR0=&H3F00

A=USR0(42)
?TM ERROR

A=USR0("This is a test")
THIS IS A TEST

Also, I notice that the value I return can be -1 if you pass in an empty string…

A=USR0("")
OK
PRINT A
-1

…and if it is non-empty, it is only the count of the characters that had to be converted. So “Hello World” converts the “ello” and “orld” for a return value of 8. It does not touch the uppercase “H” and “W” or the space.

I am not sure that is really useful. The code could be modified to return the length of the string it processed, but at least this way you know that a positive non-zero return value means it did do some work.

Spot any bugs? Comment, if you will.

Until next time…

Did you ever register CoCo software?

2 Replies

In a Discord discussion with Wayne Campbell, the topic of software registrations came up. Did you ever register any CoCo stuff?

Here is the one we sent out with our stuff…

            /) Sub-Etha Software Registration/Information Sheet (\

       Information aquired from this questionaire will be used for product
       registration, free software drawings, and informational mail outs.


Product ........... ___________________________________  Serial # ___________


Name .............. _________________________________________________________

Address ........... _________________________________________________________

City, State, Zip .. _________________________________________________________

Telephone Number .. ( ______ ) ______ - ________


Computer(s)         Memory              Storage             Monitor
[_] CoCo 1/2        [_] 64K/Less        [_] Cassette        [_] Television
[_] CoCo 3          [_] 128K            [_] Disk Drive      [_] Clr Composite
[_] MM/1            [_] 512K            [_] Hard Drive      [_] RGB Color

Other(s) .......... __________________________________________________________


Expansion
[_] RS-232 Pak      [_] MultiPak        [_] ______________  [_] ______________


Accessories
[_] Printer ....... ___________________ [_] Modem ......... __________________
                    (Type)                                  (Baud)


What do you use your computer for?
[_] Word Processing [_] Businesss       [_] Games/Fun       [_] Telecom
[_] Programming     [_] Home Apps.      [_] Music/MIDI      [_] Graphics

[_] Other(s) ...... __________________________________________________________


Which Operating System/Language(s) do you use?
[_] RS-DOS          [_] Basic           [_] Assembly        [_] 'C'
[_] OS-9/OSK/Etc.   [_] Basic09         [_] OS9 Assembly    [_] Pascal

[_] Other(s) ...... __________________________________________________________


What type of software would you like to see for the CoCo or OS-9?

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

Sub-Etha Software -/- P.O. Box 152442 -/- Lufkin, TX  75915 -/- (815) 748-6638

The next time I go through my Sub-Etha Software archives, I am going to see if I can find any of these that folks actually sent in.

CoCo Disk BASIC disk structure – part 4

2 Replies

I did a thing.

I wrote a BASIC program which will create 68 files named “0.TXT” to “67.TXT”. Each file is 2304 bytes so it takes up a full granule. (That is not really important. It just helps makes things obvious if you look at the disk with a hex editor and want to know which file is at which sector.)

After making these files, it uses code from some of my other examples to scan through the directory and display it (FILEGRAN.BAS code, shown later in this post) and then it scans the directory and prints which granule each 1-gran file is using.

I can start with a freshly formatted disk then run this program and see where RS-DOS put each file.

Will it match the order RS-DOS used when making one huge file that takes up all 68 grans? Let’s find out…

10 '68FILES.BAS
20 PRINT "RUN THIS ON A BLANK DISK."
30 INPUT "DRIVE #";DR
40 'SWITCH TO THAT DRIVE
50 DRIVE DR
60 'GOTO 140
70 'MAKE FILES 0-67
80 FOR G=0 TO 67
90 F$=MID$(STR$(G),2)+".TXT"
100 PRINT "MAKING ";F$;
110 OPEN "O",#1,F$
120 CLOSE #1:PRINT
130 NEXT
140 'FILEGRAN.BAS
150 'DIR WITHOUT FILE SIZES
160 CLEAR 512:DIM SP$(1)
170 ' S - SECTOR NUMBER
180 FOR S=3 TO 11
190 ' SP$(0-1) - SECTOR PARTS
200 DSKI$ DR,17,S,SP$(0),SP$(1)
210 ' P - PART OF SECTOR
220 FOR P=0 TO 1
230 ' E - DIR ENTRY (4 P/SECT.)
240 FOR E=0 TO 3
250 ' GET 32 BYTE DIR ENTRY
260 DE$=MID$(SP$(P),1+E*32,32)
270 ' FB - FIRST BYTE OF NAME
280 FB=ASC(LEFT$(DE$,1))
290 ' SKIP DELETED FILES
300 IF FB=0 THEN 440
310 ' WHEN 255, DIR IS DONE
320 IF FB=255 THEN 470
330 ' PRINT NAME AND EXT.
340 'PRINT LEFT$(DE$,8);TAB(9);MID$(DE$,9,3);
350 ' FIRST TWO CHARS ONLY
360 PRINT LEFT$(DE$,2);"-";
361 'PRINT #-2,LEFT$(DE$,2);",";
370 ' FILE TYPE
380 'PRINT TAB(13);ASC(MID$(DE$,12,1));
390 ' BINARY OR ASCII
400 'IF ASC(MID$(DE$,13,1))=0 THEN PRINT "B"; ELSE PRINT "A";
410 ' STARTING GRANULE
420 PRINT USING("##  ");ASC(MID$(DE$,14,1));
421 'PRINT #-2,ASC(MID$(DE$,14,1))
430 CL=CL+1:IF CL=5 THEN CL=0:PRINT
440 NEXT
450 NEXT
460 NEXT
470 END

I modified this program to output to the printer (PRINT #-2) and then capture that output in the Xroar emulator in a text file. That gave me data which I put in a spreadsheet.

 68 Files
FILE  GRAN
0     32
1     33
2     34
3     35
4     30
5     31
6     36
7     37
8     28
9     29
10    38
11    39
12    26
13    27
14    40
15    41
16    24
17    25
18    42
19    43
20    22
21    23
22    44
23    45
24    20
25    21
26    46
27    47
28    18
29    19
30    48
31    49
32    16
33    17
34    50
35    51
36    14
37    15
38    52
39    53
40    12
41    13
42    54
43    55
44    10
45    11
46    56
47    57
48     8
49     9
50    58
51    59
52     6
53     7
54    60
55    61
56     4
57     5
58    62
59    63
60     2
61     3
62    64
63    65
64     0
65     1
66    66
67    67

Next, I used a second program on a freshly formatted disk to create one big file fully filling up the disk. (The very last PRINT to the file will create a ?DF ERROR, which I now think is a bug. It should not do that until I try to write the next byte, I think.)

10 '1BIGFILE.BAS
20 PRINT"RUN THIS ON A BLANK DISK."
30 INPUT "DRIVE #";DR
40 'SWITCH TO THAT DRIVE
50 DRIVE DR
60 'MAKE ONE BIG 68 GRAN FILE
70 OPEN "O",#1,"1BIGFILE.TXT"
80 FOR G=0 TO 67
90 PRINT G;
100 T$=STRING$(128,G)
110 FOR T=1 TO 18
120 PRINT ".";
130 PRINT #1,T$;
140 NEXT
150 PRINT
160 NEXT
170 CLOSE #1
180 END

I ran another test program which would read the directory, then print out the granule chain of each file on the disk.

10 ' FILEGRAN.BAS
20 '
30 ' 0.0 2025-11-20 BASED ON FILEINFO.BAS
40 '
50 ' E$(0-1) - SECTOR HALVES
60 ' FT$ - FILE TYPE STRINGS
70 '
80 CLEAR 1500:DIM E$(1),FT$(3)
90 FT$(0)="BPRG":FT$(1)="BDAT":FT$(2)="M/L ":FT$(3)="TEXT "
100 '
110 ' DIR HOLDS UP TO 72 ENTRIES
120 '
130 ' NM$ - NAME
140 ' EX$ - EXTENSION
150 ' FT - FILE TYPE (0-3)
160 ' AF - ASCII FLAG (0/255)
170 ' FG - FIRST GRANULE #
180 ' BU - BYTES USED IN LAST SECTOR
190 ' SZ - FILE SIZE
200 ' GM - GRANULE MAP
210 '
220 DIM NM$(71),EX$(71),FT(71),AF(71),FG(71),BU(71),SZ(71),GM(67)
230 '
240 INPUT "DRIVE";DR
250 '
260 ' FILE ALLOCATION TABLE
270 ' 68 GRANULE ENTRIES
280 '
290 DIM FA(67)
300 DSKI$ DR,17,2,G$,Z$:Z$=""
310 FOR G=0 TO 67
320 FA(G)=ASC(MID$(G$,G+1,1))
330 NEXT
340 '
350 ' READ DIRECTORY
360 '
370 DE=0
380 FOR S=3 TO 11
390 DSKI$ DR,17,S,E$(0),E$(1)
400 '
410 ' PART OF SECTOR
420 '
430 FOR P=0 TO 1
440 '
450 ' ENTRY WITHIN SECTOR PART
460 '
470 FOR E=0 TO 3
480 '
490 ' DIR ENTRY IS 32 BYTES
500 '
510 E$=MID$(E$(P),E*32+1,32)
520 '
530 ' NAME IS FIRST 8 BYTES
540 '
550 NM$(DE)=LEFT$(E$,8)
560 '
570 ' EXTENSION IS BYTES 9-11
580 '
590 EX$(DE)=MID$(E$,9,3)
600 '
610 ' FILE TYPE IS BYTE 12
620 '
630 FT(DE)=ASC(MID$(E$,12,1))
640 '
650 ' ASCII FLAG IS BYTE 13
660 '
670 AF(DE)=ASC(MID$(E$,13,1))
680 '
690 ' FIRST GRANUAL IS BYTE 14
700 '
710 FG(DE)=ASC(MID$(E$,14,1))
720 '
730 ' BYTES USED IN LAST SECTOR
740 ' ARE IN BYTES 15-16
750 '
760 BU(DE)=ASC(MID$(E$,15,1))*256+ASC(MID$(E$,16,1))
770 '
780 ' IF FIRST BYTE IS 255, END
790 ' OF USED DIR ENTRIES
800 '
810 IF LEFT$(NM$(DE),1)=CHR$(255) THEN 1500
820 '
830 ' IF FIRST BYTE IS 0, FILE
840 ' WAS DELETED
850 '
860 IF LEFT$(NM$(DE),1)=CHR$(0) THEN 1480
870 '
880 ' SHOW DIRECTORY ENTRY
890 '
900 PRINT NM$(DE);TAB(9);EX$(DE);"  ";FT$(FT(DE));" ";
910 IF AF(DE)=0 THEN PRINT"BIN"; ELSE PRINT "ASC";
920 '
930 ' CALCULATE FILE SIZE
940 ' SZ - TEMP SIZE
950 ' GN - TEMP GRANULE NUM
960 ' SG - SECTORS IN LAST GRAN
970 ' GC - GRANULE COUNT
980 '
990 SZ=0:GN=FG(DE):SG=0:GC=0
1000 '
1010 ' GET GRANULE VALUE
1020 ' GV - GRAN VALUE
1030 '
1040 GV=FA(GN):GM(GC)=GN:GC=GC+1
1050 '
1060 ' IF TOP TWO BITS SET (C0
1070 ' OR GREATER), IT IS THE
1080 ' LAST GRANULE OF THE FILE
1090 ' SG - SECTORS IN GRANULE
1100 '
1110 IF GV>=&HC0 THEN SG=(GV AND &H1F):GOTO 1280
1120 '
1130 ' IF NOT, MORE GRANS
1140 ' ADD GRANULE SIZE
1150 '
1160 SZ=SZ+2304
1170 '
1180 ' MOVE ON TO NEXT GRANULE
1190 '
1200 GN=GV
1210 GOTO 1040
1220 '
1230 ' DONE WITH GRANS
1240 ' CALCULATE SIZE
1250 '
1260 ' FOR EMPTY FILES
1270 '
1280 IF SG>0 THEN SG=SG-1
1290 '
1300 ' FILE SIZE IS SZ PLUS
1310 ' 256 BYTES PER SECTOR
1320 ' IN LAST GRAN PLUS
1330 ' NUM BYTES IN LAST SECT
1340 '
1350 SZ(DE)=SZ+(SG*256)+BU(DE)
1360 PRINT " ";SZ(DE)
1370 '
1380 ' SHOW GRANULE MAP
1390 '
1400 C=0:PRINT "  ";
1410 FOR I=0 TO GC-1
1420 PRINT USING"##";GM(I);
1430 C=C+1:IF C=10 THEN PRINT:PRINT "  ";:C=0 ELSE PRINT " ";
1440 NEXT:PRINT
1450 '
1460 ' INCREMENT DIR ENTRY
1470 '
1480 DE=DE+1
1490 NEXT:NEXT:NEXT
1500 END
1510 ' SUBETHASOFTWARE.COM

Since there is only one big file on this disk, fully filling it, it only has one 68-entry granule chain to print. I modified the code to PRINT#-2 these values to the virtual printer so I could then copy the numbers into the same spreadsheet:

 68 Files  Big File
FILE  GRAN  GRAN
0     32    32
1     33    33
2     34    34
3     35    35
4     30    36
5     31    37
6     36    38
7     37    39
8     28    40
9     29    41
10    38    42
11    39    43
12    26    44
13    27    45
14    40    46
15    41    47
16    24    48
17    25    49
18    42    50
19    43    51
20    22    52
21    23    53
22    44    54
23    45    55
24    20    56
25    21    57
26    46    58
27    47    59
28    18    60
29    19    61
30    48    62
31    49    63
32    16    64
33    17    65
34    50    66
35    51    67
36    14    30
37    15    31
38    52    28
39    53    29
40    12    26
41    13    27
42    54    24
43    55    25
44    10    22
45    11    23
46    56    20
47    57    21
48     8    18
49     9    19
50    58    16
51    59    17
52     6    14
53     7    15
54    60    12
55    61    13
56     4    10
57     5    11
58    62    8
59    63    9
60     2    6
61     3    7
62    64    4
63    65    5
64     0    2
65     1    3
66    66    0
67    67    1

Now it seems clearly obvious that RS-DOS does something different when making a new file, versus what it does when expanding an existing file into a new granule.

I wanted a way to visualize this so, of course, I wrote a program to help me create a full ASCII representation of the granules, then edited the rest by hand.

                           68    1 Big
                           Files File
Track  0 +------------+
         | Granule  0 |    64    66
         | Granule  1 |    65    67
Track  1 +------------+
         | Granule  2 |    60    64
         | Granule  3 |    61    65
Track  2 +------------+
         | Granule  4 |    56    62
         | Granule  5 |    57    63
Track  3 +------------+
         | Granule  6 |    52    60
         | Granule  7 |    53    61
Track  4 +------------+
         | Granule  8 |    48    58
         | Granule  9 |    49    59
Track  5 +------------+
         | Granule 10 |    44    56
         | Granule 11 |    45    57
Track  6 +------------+
         | Granule 12 |    40    54
         | Granule 13 |    41    55
Track  7 +------------+
         | Granule 14 |    36    52
         | Granule 15 |    37    53
Track  8 +------------+
         | Granule 16 |    32    50
         | Granule 17 |    33    51
Track  9 +------------+
         | Granule 18 |    28    48
         | Granule 19 |    29    49
Track 10 +------------+
         | Granule 20 |    24    46
         | Granule 21 |    25    47
Track 11 +------------+
         | Granule 22 |    20    44
         | Granule 23 |    21    45
Track 12 +------------+
         | Granule 24 |    16    42
         | Granule 25 |    17    43
Track 13 +------------+
         | Granule 26 |    12    40
         | Granule 27 |    13    41
Track 14 +------------+
         | Granule 28 |    8     38
         | Granule 29 |    9     39
Track 15 +------------+
         | Granule 30 |    4     36
         | Granule 31 |    5     37
Track 16 +------------+
         | Granule 32 |    0     0 <- both start the same
         | Granule 33 |    1     1
Track 17 +------------+
         | FAT &      |
         | Directory  |
Track 18 +------------+
         | Granule 34 |    2     2
         | Granule 35 |    3     3
Track 19 +------------+
         | Granule 36 |    6     4 <- then big file continues
         | Granule 37 |    7     5    writing to the end
Track 20 +------------+
         | Granule 38 |    10    6
         | Granule 39 |    11    7
Track 21 +------------+
         | Granule 40 |    14    8
         | Granule 41 |    15    9
Track 22 +------------+
         | Granule 42 |    18    10
         | Granule 43 |    19    11
Track 23 +------------+
         | Granule 44 |    22    12
         | Granule 45 |    23    13
Track 24 +------------+
         | Granule 46 |    26    14
         | Granule 47 |    27    15
Track 25 +------------+
         | Granule 48 |    30    16
         | Granule 49 |    31    17
Track 26 +------------+
         | Granule 50 |    34    18
         | Granule 51 |    35    19
Track 27 +------------+
         | Granule 52 |    38    20
         | Granule 53 |    39    21
Track 28 +------------+
         | Granule 54 |    42    22
         | Granule 55 |    43    23
Track 29 +------------+
         | Granule 56 |    46    24
         | Granule 57 |    47    25
Track 30 +------------+
         | Granule 58 |    50    26
         | Granule 59 |    51    27
Track 31 +------------+
         | Granule 60 |    54    28
         | Granule 61 |    55    29
Track 32 +------------+
         | Granule 62 |    58    30
         | Granule 63 |    59    31
Track 33 +------------+
         | Granule 64 |    62    32
         | Granule 65 |    63    33
Track 34 +------------+
         | Granule 66 |    66    34
         | Granule 67 |    67    35 <- then big file continues
         +------------+                at Track 16

Interesting! For small files, it alternates tracks starting before Track 17 (FAT/Directory) then after, repeating. For a big file, it starts like that before Track 17, then after and continues to the end of Track 35, then goes before Track 17 and works back to the start of the disk.

Do I understand the sequence correctly?

To be continued…

DS-69 digitizer revisited

5 Replies

The Micro Works Digisector DS-69 / DS-68B digitizers were really cool tech in the 1980s. Looking back, I got to play with video digitizers, the Super Voice speech synthesizer that could “sing”, and even the E.A.R.S. “electronic audio recognition system” for voice commands. All of this on my Radio Shack Color Computer 3 in the late 1980s.

How many decades did it take for this tech to become mainstream in our phones or home assistants? We did it first ;-)

The DS-69 could capture 128×128 or 256×56 photos with 16 grey levels (4-bit greyscale). It also had a mode where it would capture 64 grey scales, though there was no viewer for this and I cannot find any attempts I made to use this mode.

I did, however, find some BASIC which I *think* I wrote that attempted to read a .PIX file and print it out to a printer using different ASCII characters to represent 16 different levels of grey. For example, a space would be bright white at level 0, and a “#” might be the darkest at level 15.

First, GREYTEST.BAS just tried to print blocks using these characters. I was testing.

5 DIM GR(15):FORA=0TO15:READGR(A):NEXT
10 PRINT#-2,"Grey Scale Printer Test:":PRINT#-2
15 FORA=0TO10:FORB=0TO15:PRINT#-2,STRING$(5,GR(B));:NEXT:PRINT#-2:NEXT
99 END
100 REM * Grey Scale Characters (0-15)
105 DATA 32,46,58,45,105,43,61,84,86,37,38,83,65,36,77,20

I asked the Google search engine, and its Gemini A.I. answered:

Dec.  ASCII
Value Character
----- ---------------------------
32    Space (invisible character)
46    . (period or full stop)
58    : (colon)
45    - (hyphen or minus sign)
105   i (lowercase i)
43    + (plus sign)
61    = (equals sign)
84    T (uppercase T)
86    V (uppercase V)
37    % (percent sign)
38    & (ampersand)
83    S (uppercase S)
65    A (uppercase A)
36    $ (dollar sign)
77    M (uppercase M)
20    NAK (Negative Acknowledge - a non-printable control character)

I must have been manually counting how many “dots” made up the characters and sorting them. I recall starting with the HPRINT font data in ROM (which is what my MiniBanners program used) to count the set dots in each letter, but the printer fonts would be different so I expect this table came from trial and error.

The 20 NAK (non printable) is an odd one, so I wonder if my printer DID print something for that – like a solid block graphic.

Proving memory is not always faulty, I also found TEST.BAS which appeared to open a .PIX file and print it out using this code:

0 POKE150,44:PRINT#-2,CHR$(27)CHR$(33)CHR$(27)CHR$(77)CHR$(27)CHR$(64)CHR$(15)
1 PRINT#-2
5 DIM GR(15):FORA=0TO15:READGR(A):NEXT
10 OPEN"D",#1,"SMILE.PIX",1:FIELD#1,1ASA$
11 PRINTLOF(1)
15 FORA=1TO64:PRINTA:FORB=0TO127:GET#1,A+B*64:GR=ASC(A$)
20 PRINT#-2,CHR$(GR(GR AND15));
25 NEXT:PRINT#-2:NEXT:CLOSE
99 END
100 REM * Grey Scale Characters (0-15)
105 DATA 32,46,58,47,62,63,61,84,86,37,38,90,65,69,77,35

I see line 10 opens the file with DIRECT mode with a field size of 1 assigned to string variable A$. This means doing a GET #1,X (where X is a byte offset in the file) would get that byte into A$ so I could get the ASCii value of it (0-15) and use that to know which character to print.

I have no idea if this worked… So let’s give it a try.

I see the program print “8192”, which is the Length Of File. A 128×128 image of bytes would be 16384 in size, so I am guessing each byte has two pixels in it, each 4-bits.

I see I am ANDing off the upper bits in line 20. It looks like I am throwing away every other pixel since no attempt I made to read those other 4-bits. This is likely because this was printing on an 80 column printer, which would not print 128 characters on a line. Instead, 64 would fit.

And, wow! It actually works! I had to reduce the font size down for it to display in the WordPress blog, but here is the output. Step back from the monitor if you can’t see it.

################################################################################################################################
################################################################################################################################
///////////::/:/:::.:::::..:.:: ::/.:://///>>=%V%%V%TT===>>>//?>::.. :. .  .. . :.. . ::: . :::.:::::::://:::/:::://////////////
///////:////:://::::.::::...:::.::////>/>?=%EAEMAMEEEMEAAME&%VT=?>//::::.  .: . .::.. :::.. .. .::::::::.//:://///////////>/////
//////://///:://::::.:::::.:::://>/??TV%%&EMMMMMEEMMMMMAEMMEEAA&ZVT=?>::.. .: . ...   :::...:.:.::::.:::..:::////://////////////
///////:///:::./.::...:::::////??V%AEEMM##MM###MMMMMMMMMMEAEMMMEEZZZ&V=>//:::    :... :::  .:::.::..:::::/::////////////////////
//////:://::::/:::::   :::///?T%AAM#MMMM#M########M#MMM#MMAEMAEMMAAA&ZZ&V=/:: .  :..   :: . ..:.::  :::::/:::////://////////////
/////:::://:::./ .:. :.::?/?T%ZEMEMMMMM###########M#MM##M#MMMAAAEEMEEMMAZZZT>/:. :: .  :  . ... :: :::::.:::::://://////////////
/////:::::::::.. ::. ./?>?T&AAEMMMMMMM#MM########MMMMMMM###MMMAAAAAAEMMMMMEA&=//:::   ... .  .:..   .:::...::::/:://////////////
/////::::.:::::   :: :?=T%MEEEEMMMMMMMMMM#####M#MMMEAEAMM##MMMMMEEEAAEMMEM#MAMT>/:::.  .: .  .. .    ::... :::::/:::////:///////
/://::::...::. . .::>=V%AEMEAEEMMEMMEMEMMMMM#M#MEEAZZ&%&ZEEMMAEMMMMMMMMMMMMMMEAZT>//:. .  .  . ..    :::.. :::.::::://:::///////
:::::::::. .:.   :?TT&AEEEZAEEEEZEZZZEEMEEEMMMM#MAAZ&&V&V&ZAMMMAMM###MMMM#M#MEMAAT?//: :. .  .  .    :::.  ::...:::/:/:::////://
:::. :::   :: .:/?T%&EM#AAEMMAEZA&ZAZZEAAZAMMMMMMAAAZAVVVV%&AM#MMEMM##MMM####MMMAZ%>//::  .  .  . .  :::.. :. ..:::::/:::///:://
:::: :::   ::.:>?VZAEMMAZEMMEAAAZZAZAZEAAEAAZEAMEMAA&&%VVVV&AMM#MMMMM#######M###M&V?//::: .  .  .    :: .  :... :::::/:::///:://
.::. .:.    ::/?%AAAMMEAEMMEMAAZAAAZAAEAAZZ%%%ZAEEAA&Z&%V%%&AAM#MMMMM#######MM#M#ZTV>//:: .   . .    ..:   :. . :::::/:::////://
.:.  .:: . .:/>%EEAEMEEE#MMMMAAAEAZZZEA&ZZZVVVVZZAZAZAZZ%V&&AMEMMM##MM#M######M#MM&T?//:::.  .  .    ...   :... :::::::::///:://
.::.. .: . .:=VZMZEMEMMMM#MEEAAMAZZ&AA%&&Z%TVTTV&&&&ZEEZZZV&ZA#MMMM#############MEZ=T>/::/.  .  .    :: .  :..../:::./:::/.::::/
.::.  .. .  :T%MEAMEEMMMMMEMAAEA&%%ZZ%VV&&TTTTTTTV&&ZAEAZAE&&ZAEMM########M#M#M#MMMM&?/::/.  .  .    .:    :. . .:: ..:::///:::/
 ..   .: .  /T&EZEEMMMMMMMEAZEZ%VV&&&%VVZVTTTTTTTTVT%&EAMEEMAZAME#M#M######MMMM##MMMZT?/:/. ..  .    .:    :.   :.:..::::///::/:
 ..   .. .  :T&&&EMMMMM##MMEMA&%VVTVTVT%%VTTTTTTTT=TTTVZZAMMME&VTTTVZEM#ZAM########MM%?///:...  .    ...   .... .:: ..::::..:::/
 :.    .   .:T&&AEAMM#####MME%V%VVTTTTTT%VTTTTTTTTTTTTV%TVV&VV=.  .>=T%ZMZAEM##MMMMMZ&VV?///::  .    .:    ::   :.:  ::::/:/:::/
 :..  .  .  :?%&AM#MM#####EMZVVTVTTTTTTVV&TTTTTTTTT%&VTTTTTTTTTTTTTTTTTT%&EEE#####MMA&%T?///:::..    :.    :. . :::: .:::://:::/
 :.    .   ../=VZMM#######MEAAEZ%VTTTVVVV%%VVTT=T=TTTTTTTT=>TTTTTTTTTTVTT&TT&E######MEV=/////::.:.   :: .  :. . .::.:.:::://:::/
 :.   .. ...::/VZMM#######E%TTTTVVTTTTVTTTTTEVT===ZTTTVTV%? ?VZZ%V%&VVVT=VTTTTZM#######MZVTT=>::::   :.    :: . ..: ..:::::::://
 .. . .. . ..: =ZMM##VZEEEZ&TVVTTTTTTTVTTTVV&M#TZE#%TTTV%ZV&EEEATTTTTTTTTVTTTTT&MEAAEE#M#MZTT?>?>//:.::.   ::.. ..:   :::/.::::/
 :.   .     :..?&E###MMM#MZ%VTTTTT/ .=T&V&V%%EZT=T%ATTTTTTTTTT=TTTTTTTTTTVTTT=TVZMEAZZZEM##M&=>/:/::.:: .  :: .  .: .::::::/:://
 :.   .   .....>%M#M##M##MZ%TTVVZZAEA##ZVTTV&ET=>>=%ETTTTTTTTTTTTT===TTT=%TTTTTTZEE&&&%A&###M%=>>///::::.  :: .  .: . ::::/::://
 :    ..    :::=VZ#M#####MZTTVV%VTTTTTVVTTV%&ZT===?=TA%T=TTTT=====??=TTTVVTTTTTV&AAAEZZVVAMM#E&T>///:::.  :::   ..: ..::://::://
 :.    :    .://VA#M#####E%TTTTTTTTTTT=TTTTTATT=>=?=??%Z%TTTT==??>/??TV%TTTTTTTTAE#MAAE&VE###EA&?///:::.   :: . ..: ..:::::/:://
 : .  .  . ....>VE#M####METTTTTTTTT==TTTTTTZZTT==>?=?T==TZZZV=TV%%%EZ%TTT=TTTTTTV&%%&ZAZZ####EAZT>///::.. ::. . ..: . :::.:::://
.:     : .  .::V&M#######ATTTTTTTTT===?==VAE%T==>??=??==TTTTTTT======TTT=T=TTTTTTTVVTT&EM###M#EAV>///:::. :::    .: .:::://:/://
 :.   .. . .::=&E########EETTTTTTTT===T%&T%%TVVTTTVVZE%==TTTTT=T=?====?====TTTTTT=?TTTTAMMMMEMAZVT??//://:::: .  .. ..:::..::://
.: .  .: .::/?%MM##MMM#MMMZ%Z%ZZ&ZEAZ%TVTTTVV%MA%VV&TV&VVTTTTTVTTTT=TTTTTTTTTTTT==???TVEMMM#MMAVT=///////.::: . ..: ..:::///:://
.:   ..:.:>TVZMM###EEAMMM#A%TTTTTTTTTTTTTVTV%V%T%VVTTTT====?==TVTTTTTTTTTTTTTT=VT==TT%AM####EAZ?>/////////:::..  .:...::://::://
.: . .:::/?T%E#####E&AEMEMMZTTVTTVTTTTTTTVVTTVTTTTTTT=????=?>=TTTTTTTTTTTT=TTTTZ###########M&&V?>/////://:::::. ..: ..:::.:::://
.:. ..::/=%AAM######A&A#MMMEVTVTVTTTTTTVTTTTVTTTT===?=?===?====TVVTT==??====?=TZ#########MMMZ%?>/////:::..::: ....:.. :::./::://
.:...::/TV&V&M#######MMMMMME%TVVVVTTTTVTTTTTVVV%%VVVV%%%%%%VZ&ZMM&TT==?>===T?=VE##########ME%=//////::::: ::: ::... ..:::///:::/
.::/:/>=T=>TZM##M#M#######EMZVVT%VTTTTTV&&ZZAVTTT?//=>/?//?/??TZV%T==???===TTT%#############ET>/////::::..::: : .::.. :::.:/:://
:::////////TTAMMEMM######MMMM%VVVTTTTTTT&##AVT==>>>?===T==V=&TTT=T===>?====TTTEM#########EMM#V?/////:::::.::: : :.:..:::://::://
:://////////=TZMM#M###########%VVTTT=T=TTTTVVTTTVVVTTTTTTTTTTTTT==?=?>?T==TTTAM#########MMMZA&=>>///::::..::....::: .::::///:///
//////////>>TVE###############E%VVTTTT==T=TTTTTTTTTTTTTTTTTTT===>>??===?=TTT&M###########MMEAAT>>///:::::/:::...:::...:::/:::///
/////////>=TZM#################AVVTTTTTTT==TTTTTTTT=T??===?T===>>>>?=TTT=TV&Z###########MMMEAAV?>///:::::::::::.:::../:::://:://
////////?T%EM###M###############MVVTTTTTTTTTTTT=TTTT==???=>=>?>>>>?==TTTT%&&E######M###M##MEMA&?>////::/./::::..::: ./:::///////
///>>>>=V&AM##MMM################MZ%TTVTTTTTTT==?==???>///?>/??>??===TVV%Z&VA########MEMMMM#ME&T>>///::://:::::/::: .::::///:://
/>>>>?TV%EM#MME&M##################MZVVVTTT==T==>=?>/>>/>>?>/>=T=TTTTVV&&%%%E###########M#M###M&=>///::/:::::::/:::../:::///////
/>/>?TVA%AMMME%&M###################EZ%VTTTTTT==?=?>??>?????=TTTVVV&&%&%%VV%M##################AV>////:://:::::/:::::/:/:///:///
///=TV%%VMMEM&TZM###################EZA%V%VVVTTTTT=TTTT==TTTTVVVVV&&&&VVTT&AM##################M%?////:///::::/:::::./::////////
>??TVV%T%MEAA%VZA###################EA%%&Z%%VVV%TVTVTTTTVV&&VVV%%&Z&%%VVT%AM###############M###M%?/////////::///::::./:::///////
==TVT%TV%MMAEVV&A###################MA&V&%%VVVVVTVVVTV%VVV%&V%%%&&%%TVVV%AAM##############MM##MEV?////////:::///:::/./:::///////
TVV%V&VAMMMMMVVZE########MMMM########MA%%%VVVV%%VVVVTV%V%V&&&Z&%V%VTTVVVZM#M#############MMM#ME&=>/////////::///:::////::///////
TV%&ZZEAM####MM############MMM#######MMZ&%VVVVVV%VVV%%&VV&&&%%V%VTTTT%ZAE#####M##MMMM####MMMMA&T>>/>///////::///:::::///////////
T%V&&MAMM####################M########MEZ&%VVVTTVVVVT&VVV%%%%VVTTTVV&AEM###M###############MMAVT>>/>/////////////>>?????>///////
T&%&&EAM################################EA&VVVVTTVVTTTTVTVTVVTTTVV%AAMM##################MMMEA%TT?===TTT===TVTTTTTTVTTTTTTTT=?>>
TVVT%&EEM##############################MMEZ&%VVTTVVTTTTVVTTTTTVVV%ZAM#M#M################MMMMM##MMEZZ%%V%%VVVVTTTTVTTTTVVTVTTTVT
TVVV%V&AM#M#M###########################MEAZ&%%TVTVTTTTTVVTTV%VT%EMEEMMMM######################MMMAZZAAZAZ&&V%VVTTVTTTTTVTTTTTVT
T&VT%V%&ZM####M#M#######################MMZZ&%%%%VVVTVVVVVVVTTVV&EEEAMEME####M####################M#MMMMEEAEZ&&ZTTVTTVTTVTVTTTVT
TVVT%VTVVZM#MMMMMM#MM################MMMMMMA%&&ZVTVVVVTVVTTTTTVZAEAAZAAEEMM######################M#####MEAAAMEZZTTVTTTTTVTTTTTVT
TV%T%TTVV%EMMM###MMMMMM#MMMEMEEEMEMMM###MMEEZV&VVTVTTTTTTTTTTTV&V&ZAZEMMMM########################MMEMMMMEMMMMZ%TVVTTTTTTTTVTTVV
TVVT%TTVT%ZM###M#M##MMMAAAAZAAEZEEEMEMM#MEAMZZ%%TVTTTTTTTTTTTVVV&ZZAZMM#######################MM####MMMMEMEMMZ%TTTVT==T=TTTVTTVT
TVVV%VVVV%&AMEEEE#EMM#MMM#MMMMEEAAMEEMMMMMAAEZ&&TVVTTTTTVTTTTVV&%&ZEMMM#############MMMM#######MMMMMMMMEAAAZE%TVTTTTTTT==TTTTTTT
TVTV%TVVV%EAEEAAAZEAZEEEEEEAAEAEZAAEAMMEAEAAAZ%VTTTTTTTTTTTTTVVT%&EE################MMM########MMMEEMMEE%%VTVVTTTTVT==T==TTTTTTT
V%V%%TV%VZMMMAMMEEZZAZAMAA&&Z&AEEMEAEEEAZAZ&&%TTTTTTTTTTVTTT%%%V&AE#MM########MMM#M##MMM########MMMAAA%VVTTTVTTTTTTTT====TTVTTTT
################################################################################################################################
################################################################################################################################

And here is a screenshot of it, if that did not work:

DS-69 .PIX file printed in ASCII.

Well that’s neat. I wonder what I did with this.

Until next time…

Tackling the Logiker 2025 Vintage Computing Christmas Challenge – part 1

7 Replies

See Also: Prologue and part 1.

Rules to the Challenge

❄️ Vintage Computing Christmas Challenge 2025 ❄️ – Logiker

The Pattern

Observations

  1. Since this is a symmetrical pattern, if we can figure out how to draw one quadrant, we can draw the others.
  2. The pattern is 19 characters wide, which contains a center column of asterisks, and a left and right column that are spaces except for the center row of asterisks.
  3. “As if they had planned it,” this means the pattern in each quadrants is 8 characters, matching the number of bits in a byte.

I typed it up to figure out what the bit pattern would be. (Actually, I typed up a bit of it, then pasted that into Copilot and had it tell me the bit pattern.)

.        *
.------*- = 2
.-*-*---* = 81
.--**---- = 48
.-***--*- = 114
.----*--* = 9
.-----*-- = 4
.*-*---*- = 162
.-*-*---* = 81
*******************

That’s a mess, but in the left the “.” would represent the blank space down the left side up to the row of 19 asterisks. After that is the 8-bit pattern with “-” representing a space in the pattern (0 bit) and the “*” representing the asterisk (1 bit).

This let me quickly cobble together a proof-of-concept:

1 READ V
2 A$=STRING$(19,32):MID$(A$,10,1)="*"
3 FOR B=0 TO 7
4 IF V AND 2^B THEN MID$(A$,9-B,1)="*":MID$(A$,B+11,1)="*"
5 NEXT
6 PRINT A$:A$(L)=A$
7 L=L+1:IF L<8 THEN 1
8 PRINT STRING$(18,42)
9 FOR B=7 TO 0 STEP -1:PRINT A$(B):NEXT
10 DATA 2,81,48,114,9,4,162,81
  • Line 10 are the 8 rows of byte data for a quadrant of the snowflake.
  • Line 1 reads the first value from the DATA statement.
  • Line 2 builds a string of 19 spaces, then sets the character at position 10 (in the center) to an asterisk. Every row has this character set.
  • Line 3 begins a loop representing each bit in the byte (0-7).
  • Line 4 checks the read DATA value and ANDs it with the bit value (2 to the power of the the FOR/NEXT loop value). If it is set, the appropriate position in the left side of the string is set to an asterisk, and then the same is done for the right side. To mirror, the left side is center-minus-bit, and the right side is center-plus-bit.
  • Line 5 is the NEXT to continue doing the rest of the bits.
  • Line 6 prints the completed string, then stores that string in an A$() array. L has not been used yet so it starts at 0.
  • Line 7 increments L, and as long as it is still ess than 8 (0-7 for the first eight lines of the pattern) it goes back to line 1 to continue with the next DATA statement.
  • Line 8 once 8 lines have been done, the center row of 19 asterisks is printed.
  • Line 9 is a loop to print out the A$() lines we saved, backwards. As they were built in line 6, they went from 0 to 7. Now we print them backwards 7 to 0.

…and there we have a simple way to make this pattern, slowly:

Logiker 2025 pattern on a CoCo.

On a CoCo 3, adding a WIDTH 40 or WIDTH 80 before it would show the full pattern:

Logiker 2025 pattern on a CoCo 3.

My example program can be made much smaller by packing lines together and removing unnecessary spaces. One minor optimization I already did was doing the bits from 0 to 7 which removed the need to use “STEP -1” if counting backwards. Beyond that, this is the raw proof-of-concept idea of using bytes.

Other options folks have used in past challenges included rune-length type encoding (DATA showing how many spaces, then how many asterisks, to make the pattern) so that probably is worth investigating to see if it helps here.

Then, of course, someone will probably figure out a math pattern to make this snowflake.

What thoughts do you have?

CoCo Disk BASIC disk structure – part 3

Leave a reply

See also: part 1, part 2 and part 3.

A correction, and discovering the order RS-DOS writes things…

A correction from part 2… This example program had “BIN” and “ASC” mixed up. 0 should represent BINary files, and 255 for ASCii files. I fixed it in line 920. (I will try to edit/fix the original post when I get a moment.)

10 ' FILEINFO.BAS
20 '
30 ' 0.0 2023-01-25 ALLENH
40 ' 0.1 2023-01-26 ADD DR
50 ' 0.2 2023-01-27 MORE COMMENTS
55 ' 0.3 2025-11-18 BIN/ASC FIX
60 '
70 ' E$(0-1) - SECTOR HALVES
80 ' FT$ - FILE TYPE STRINGS
90 '
100 CLEAR 1500:DIM E$(1),FT$(3)
110 FT$(0)="BPRG":FT$(1)="BDAT":FT$(2)="M/L ":FT$(3)="TEXT "
120 '
130 ' DIR HOLDS UP TO 72 ENTRIES
140 '
150 ' NM$ - NAME
160 ' EX$ - EXTENSION
170 ' FT - FILE TYPE (0-3)
180 ' AF - ASCII FLAG (0/255)
190 ' FG - FIRST GRANULE #
200 ' BU - BYTES USED IN LAST SECTOR
210 ' SZ - FILE SIZE
220 '
230 DIM NM$(71),EX$(71),FT(71),AF(71),FG(71),BU(71),SZ(71)
240 '
250 INPUT "DRIVE";DR
260 '
270 ' FILE ALLOCATION TABLE
280 ' 68 GRANULE ENTRIES
290 '
300 DIM FA(67)
310 DSKI$ DR,17,2,G$,Z$:Z$=""
320 FOR G=0 TO 67
330 FA(G)=ASC(MID$(G$,G+1,1))
340 NEXT
350 '
360 ' READ DIRECTORY
370 '
380 DE=0
390 FOR S=3 TO 11
400 DSKI$ DR,17,S,E$(0),E$(1)
410 '
420 ' PART OF SECTOR
430 '
440 FOR P=0 TO 1
450 '
460 ' ENTRY WITHIN SECTOR PART
470 '
480 FOR E=0 TO 3
490 '
500 ' DIR ENTRY IS 32 BYTES
510 '
520 E$=MID$(E$(P),E*32+1,32)
530 '
540 ' NAME IS FIRST 8 BYTES
550 '
560 NM$(DE)=LEFT$(E$,8)
570 '
580 ' EXTENSION IS BYTES 9-11
590 '
600 EX$(DE)=MID$(E$,9,3)
610 '
620 ' FILE TYPE IS BYTE 12
630 '
640 FT(DE)=ASC(MID$(E$,12,1))
650 '
660 ' ASCII FLAG IS BYTE 13
670 '
680 AF(DE)=ASC(MID$(E$,13,1))
690 '
700 ' FIRST GRANUAL IS BYTE 14
710 '
720 FG(DE)=ASC(MID$(E$,14,1))
730 '
740 ' BYTES USED IN LAST SECTOR
750 ' ARE IN BYTES 15-16
760 '
770 BU(DE)=ASC(MID$(E$,15,1))*256+ASC(MID$(E$,16,1))
780 '
790 ' IF FIRST BYTE IS 255, END
800 ' OF USED DIR ENTRIES
810 '
820 IF LEFT$(NM$(DE),1)=CHR$(255) THEN 1390
830 '
840 ' IF FIRST BYTE IS 0, FILE
850 ' WAS DELETED
860 '
870 IF LEFT$(NM$(DE),1)=CHR$(0) THEN 1370
880 '
890 ' SHOW DIRECTORY ENTRY
900 '
910 PRINT NM$(DE);TAB(9);EX$(DE);"  ";FT$(FT(DE));" ";
920 IF AF(DE)=0 THEN PRINT"BIN"; ELSE PRINT "ASC";
930 '
940 ' CALCULATE FILE SIZE
950 ' SZ - TEMP SIZE
960 ' GN - TEMP GRANULE NUM
970 ' SG - SECTORS IN LAST GRAN
980 '
990 SZ=0:GN=FG(DE):SG=0
1000 '
1010 ' GET GRANULE VALUE
1020 ' GV - GRAN VALUE
1030 '
1040 GV=FA(GN)
1050 '
1060 ' IF TOP TWO BITS SET (C0
1070 ' OR GREATER), IT IS THE
1080 ' LAST GRANULE OF THE FILE
1090 ' SG - SECTORS IN GRANULE
1100 '
1110 IF GV>=&HC0 THEN SG=(GV AND &H1F):GOTO 1280
1120 '
1130 ' ELSE, MORE GRANS
1140 ' ADD GRANULE SIZE
1150 '
1160 SZ=SZ+2304
1170 '
1180 ' MOVE ON TO NEXT GRANULE
1190 '
1200 GN=GV
1210 GOTO 1040
1220 '
1230 ' DONE WITH GRANS
1240 ' CALCULATE SIZE
1250 '
1260 ' FOR EMPTY FILES
1270 '
1280 IF SG>0 THEN SG=SG-1
1290 '
1300 ' FILE SIZE IS SZ PLUS
1310 ' 256 BYTES PER SECTOR
1320 ' IN LAST GRAN PLUS
1330 ' NUM BYTES IN LAST SECT
1340 '
1350 SZ(DE)=SZ+(SG*256)+BU(DE)
1360 PRINT " ";SZ(DE)
1370 DE=DE+1
1380 NEXT:NEXT:NEXT
1390 END
1400 ' SUBETHASOFTWARE.COM

To test this routine, I created a program that let me type a file size (in bytes) and then it would make a .TXT file with that size as the filename (i.e, for 3000 bytes, it makes “3000.TXT”) and then I could run it through this program and see if everything matched.

It opens a file with the size as the filename, then writes out “*” characters to fill the file. This will be painfully slow for large files. If you want to make it much faster, share your work in a comment.


10 ' MAKEFILE.BAS
20 '
30 ' 0.0 2025-11-18 ALLENH
40 '
50 INPUT "FILE SIZE";SZ
60 F$=MID$(STR$(SZ),2)+".TXT"
70 OPEN "O",#1,F$
80 FOR A=1 TO SZ:PRINT #1,"*";:NEXT
90 CLOSE #1
100 DIR
110 GOTO 50
120 ' SUBETHASOFTWARE.COM

I was able to use this program in the Xroar emulator to create files of known sizes so I could verify the FILEINFO.BAS program was doing the proper thing.

It seems to be, so let’s move on…

A funny thing happened on the way to the disk…

I have been digging in to disk formats (OS-9 and RS-DOS) lately, and learning more things I wish I knew “back in the day.” For instance, I was curious how RS-DOS allocates granules (see part 1) when adding files to the disk. I wrote a test program that would write out 2304-byte blocks of data (the size of a granule) full of the number of the block. i.e., for the first write, I’d write 2304 0’s, then 2304 1’s and so on. My simple program looks like this:

10 'GRANULES.BAS
20 OPEN "O",#1,"GRANULES.TXT"
30 FOR G=0 TO 67
40 PRINT G;
50 T$=STRING$(128,G)
60 FOR T=1 TO 18
65 PRINT ".";
70 PRINT #1,T$;
80 NEXT
90 PRINT
100 NEXT
110 CLOSE #1

I ran this on a freshly formatted disk and let it fill the whole thing up. The very last write errors with a ?DF ERROR (disk full) so it never makes it to the close. I guess you can’t write that last byte without an error?

Now I should be able to look a the bytes on the disk and see where the 0’s went, the 15’s went, and so on, and see the order RS-DOS allocated those granules.

I made a simple test program for this:

0 'GRANDUMP.BAS
10 CLEAR 512
20 FOR G=0 TO 67
30 T=INT((G)/2):IF T>16 THEN T=T+1
40 IF INT(G/2)*2=G THEN S1=10:S2=18 ELSE S1=1:S2=9
50 'PRINT "GRANULE";G;TAB(13);"T";T;TAB(20);"S";S1;"-";S2
54 DSKI$0,T,S1,A$,B$
55 PRINT "GRANULE";G;ASC(A$)
60 NEXT G

Ignore the commented out stuff. Initially I was just getting it to convert a granule to Track/Sectors with code to skip Track 17 (FAT/Directory). And, to be honest, I had an AI write this and I just modified it ;-)

I then modified it to PRINT#-2 to the printer, and ran it in Xroar with the printer redirected to a text file. That gave me the following output:

GRANULE 0  67
GRANULE 1  66
GRANULE 2  65
GRANULE 3  64
GRANULE 4  63
GRANULE 5  62
GRANULE 6  61
GRANULE 7  60
GRANULE 8  59
GRANULE 9  58
GRANULE 10  57
GRANULE 11  56
GRANULE 12  55
GRANULE 13  54
GRANULE 14  53
GRANULE 15  52
GRANULE 16  51
GRANULE 17  50
GRANULE 18  49
GRANULE 19  48
GRANULE 20  47
GRANULE 21  46
GRANULE 22  45
GRANULE 23  44
GRANULE 24  43
GRANULE 25  42
GRANULE 26  41
GRANULE 27  40
GRANULE 28  39
GRANULE 29  38
GRANULE 30  37
GRANULE 31  36
GRANULE 32  1 
GRANULE 33  0 
GRANULE 34  3 
GRANULE 35  2 
GRANULE 36  5 
GRANULE 37  4 
GRANULE 38  7 
GRANULE 39  6 
GRANULE 40  9 
GRANULE 41  8 
GRANULE 42  11
GRANULE 43  10
GRANULE 44  13
GRANULE 45  12
GRANULE 46  15
GRANULE 47  14
GRANULE 48  17
GRANULE 49  16
GRANULE 50  19
GRANULE 51  18
GRANULE 52  21
GRANULE 53  20
GRANULE 54  23
GRANULE 55  22
GRANULE 56  25
GRANULE 57  24
GRANULE 58  27
GRANULE 59  26
GRANULE 60  29
GRANULE 61  28
GRANULE 62  31
GRANULE 63  30
GRANULE 64  33
GRANULE 65  32
GRANULE 66  35
GRANULE 67  34

Now I can see the order that RS-DOS allocates data on an empty disk.

The number in the third column represents the value of the bytes written to that 2304 granule. When I see “GRANULE 67” contains “34” as data, I know it was the 35th (numbers 0-34) granule written out.

Granules 0-33 are on tracks 0-16, then track 17 is skipped, then the remaining granules 34-67 are on tracks 18-34.

You can see that RS-DOS initially writes the data close to track 17, reducing the time it takes to seek from the directory to the file data. This makes sense, though as a teen, I guess I had some early signs of O.C.D. because I thought the directory should be at the start of the disk, and not in the middle ;-)

I brought this data into a spreadsheet, then sorted it by the “data” value (column 3). This let me see the order that granules are allocated (written to). I will add some comments:

GRANULE	33	0 <- first went to gran 33
GRANULE	32	1 <- second went to gran 32

...then it starts writing after Track 17...

GRANULE	35	2 <- third went to gran 35
GRANULE	34	3 <- fourth went to gran 34
GRANULE	37	4
GRANULE	36	5
GRANULE	39	6
GRANULE	38	7
GRANULE	41	8
GRANULE	40	9
GRANULE	43	10
GRANULE	42	11
GRANULE	45	12
GRANULE	44	13
GRANULE	47	14
GRANULE	46	15
GRANULE	49	16
GRANULE	48	17
GRANULE	51	18
GRANULE	50	19
GRANULE	53	20
GRANULE	52	21
GRANULE	55	22
GRANULE	54	23
GRANULE	57	24
GRANULE	56	25
GRANULE	59	26
GRANULE	58	27
GRANULE	61	28
GRANULE	60	29
GRANULE	63	30
GRANULE	62	31
GRANULE	65	32
GRANULE	64	33
GRANULE	67	34
GRANULE	66	35

...now that it has written to the final Track 35 (gran 66-67)...

GRANULE	31	36 <- before Track 17 and the original writes.
GRANULE	30	37
GRANULE	29	38
GRANULE	28	39
GRANULE	27	40
GRANULE	26	41
GRANULE	25	42
GRANULE	24	43
GRANULE	23	44
GRANULE	22	45
GRANULE	21	46
GRANULE	20	47
GRANULE	19	48
GRANULE	18	49
GRANULE	17	50
GRANULE	16	51
GRANULE	15	52
GRANULE	14	53
GRANULE	13	54
GRANULE	12	55
GRANULE	11	56
GRANULE	10	57
GRANULE	9	58
GRANULE	8	59
GRANULE	7	60
GRANULE	6	61
GRANULE	5	62
GRANULE	4	63
GRANULE	3	64
GRANULE	2	65
GRANULE	1	66
GRANULE	0	67 <- last write at the very first gran

And down the rabbit hole I go. Again. I have tasked an A.I. with creating some simple scripts to manipulate RS-DOS disk images (just for fun; the toolshed “decb” command already exists and works great and does more). While I understood the basic structure for an RS-DOS disk, I did not understand “how” RS-DOS actually allocated those granules. Now I have some insight. Perhaps I can make my tools replicate writing in the same way that RS-DOS itself does.

Look for a part 4. I have some more experiments to share.

To be continued…

Open Micro Works Digisector DS-69 digitizer .PIX files in GIMP

Leave a reply

Step 1: Rename the .PIX file so it has the extension .data. This is needed for GIMP to recognize it as a “raw” data file.

Step 2: Open this image in GIMP by expanding “Select File Type” and choosing Raw image data. That should allow the .data file to show up in the browser to open it.

Step 3: The file will open and you must adjust settings to tell GIMP more about the image. Under Pixel format, select Grayscale 4-bit. For the Width and Height, set them to 256 (if it is a 32K file) or 128 (if it is 8K). Now you should be able to Open the image.

Step 4: With the image open, you will need to Invert it to get the colors correct (Colors -> Invert) and rotate the image clockwise (Image -> Transform -> Rotate 90 clockwise).

Step 5: That should give you a 256×256 or 128×128 16-greyscale image you can now save out in whatever format you wish. GIMP can save based on the extension you give it when exporting. (File -> Export As… then change the extension to .PNG or .GIF or whatever.)

Tada!

Neat.

Or, I had A.I. write this quick conversion script… It can convert one file at a time, or run it in a directory with .PIX files and it will do them all. It currently only supports the 128×128 16-grey and 256×256 16-grey photos. I recall there was a 64-grey mode, so if I find one of those images, I will update the script to do them, too.

#!/usr/bin/env python3
import sys
import glob
from PIL import Image

def convert_pix(pix_file):
    with open(pix_file, 'rb') as f:
        data = f.read()

    if len(data) == 32768:
        width, height = 256, 256
    elif len(data) == 8192:
        width, height = 128, 128
    else:
        print(f"Invalid file size for {pix_file} (expected 8192 or 32768 bytes)")
        return

    pixels = []
    for byte in data:
        pixels.append(byte >> 4)
        pixels.append(byte & 0x0F)

    # Create image
    img = Image.new('P', (width, height))
    img.putdata(pixels)

    # Rotate right 90 degrees (CW)
    img = img.rotate(-90)

    # Invert colors
    inverted_pixels = [15 - p for p in img.getdata()]
    img.putdata(inverted_pixels)

    # Set greyscale palette
    palette = []
    for i in range(16):
        v = i * 255 // 15
        palette.extend([v, v, v])
    img.putpalette(palette)

    # Save as PNG
    output_file = pix_file.replace('.PIX', '.png').replace('.pix', '.png')
    img.save(output_file)
    print(f"Converted {pix_file} ({width}x{height}) to {output_file}")

def main():
    if len(sys.argv) == 1:
        pix_files = glob.glob('*.PIX') + glob.glob('*.pix')
        if not pix_files:
            print("No .PIX files found in current directory")
            sys.exit(1)
    else:
        pix_files = sys.argv[1:]

    for pix_file in pix_files:
        convert_pix(pix_file)

if __name__ == "__main__":
    main()

You can find it on my GitHub along with documentation on what all it needs to run:

https://github.com/allenhuffman/DS69-PIX-to-PNG

Good luck!

EXEC dispatch table for 6809 assembly

7 Replies

I am writing this so one of the 6809 experts who reads this can chime in and tell me a better way…

Often I post things so they can get in the search engines in case anyone else looks for that topic later. This is one of those.

Using DEF USR is a great way to put up to ten “easy to execute” routines in an assembly language program. Each of those routines can also do different things based on the numeric (or string) parameter passed in to the USR() call.

If you aren’t trying to be that fancy, but do want multiple functions for whatever reason, what methods are there? Please leave a comment with the best ways to call multiple functions using EXEC from Color BASIC.

Dispatch table

One method that comes to mind is using a dispatch table at the start of the machine language program. If the code is built to compile at &H3F00, then doing an EXEC &H3F00 will run that program. If there are more functions, you have to figure out where they are located and provide those address to the user. This is fine, until you make a change to the code and then those locations shift.

Instead, the start of the program could begin with a series of “branch always” instructions. For example:

            org     $7f00

start1      bra     install
start2      bra     uninstall

The branch always instruction is one byte, and it is followed by a second byte which is how many bytes away the function is. This makes each entry take two bytes. Thus, install is at &H7F00 and uninstall is at &H7F02. A whole series of functions could be done this way, and the user just has to remember which is which — &H7F00, &H7F02, &H7F04, etc. Having every two bytes be an entry makes it easy to remember.

; lwasm dispatch.asm -fbasic -odispatch.bas --map
; a09 -fbasic -odispatch.bas dispatch.asm

ORGADDR     equ     $3f00       ; Where program loads in memory

            org     ORGADDR

;------------------------------------------------------------------------------
; Absolute addresses of ROM calls
;------------------------------------------------------------------------------
CHROUT      equ	    $A002

;------------------------------------------------------------------------------
; This code can be called by EXEC/EXEC xxxx.
;------------------------------------------------------------------------------
; Dispatch table at the start of the program.
start1      bra     install
start2      bra     uninstall

install     leax    <msginst,pcr    ; X points to message
            bra     print           ; print will do the RTS
            ;rts

uninstall   leax    <msguninst,pcr  ; X points to message
            ;bra     print          ; print will do the RTS
            ;rts

;------------------------------------------------------------------------------
; PRINT subroutine. Prints the 0-terminated string pointed to by X plus CR
;------------------------------------------------------------------------------
print       lda     ,x+
            beq     printdone
            jsr     [CHROUT]
            bra     print
printdone   lda     #13
            jmp     [CHROUT]        ; JMP CHROUT will do an rts.
            ;rts

;------------------------------------------------------------------------------
; Data storage for the string messages
;------------------------------------------------------------------------------
msginst     fcc     "INSTALLED"
            fcb     0

msguninst   fcc     "UNINSTALLED"
            fcb     0

            end

One potential issue is that branch can only jump so far. If large functions are being called, you might find they cannot be reached from this dispatch table. One option would be to switch to “long branch”, but then you add more bytes and your dispatch table might be every three bytes – &H7F00, &H7F03, &H7F06, &H7F09, &H7F0C, etc.

That is a fine solution though every 2 may “look” nicer than every 3.

As a workaround, the dispatch table could remain short branches, but they go to a longer one just below it:

            org     $7f00

start1      bra     install
start2      bra     uninstall

; If a short branch cannot reach, it can call a second long branch:
uninstall   lbra    realuninstall

Above, perhaps “install” is within reach of the “bra”, but “uninstall” is too far away. Simply make the “bra uninstall” branch to a spot with a long branch. A few more bytes, a few more clock cycles, but now the dispatch table can remain “every 2 bytes”.

But there has to be a better way…

Leave your suggestions in the comments.

Until next time…

Bonus

Here is a BASIC loader for that example. RUN it, then EXEC &H7F00 or &H7F02 and be amazed. (Loader generated using Sean Conner’s a09 assembler.)

10 DATA32,2,32,5,48,140,21,32,3,48,140,26,166,128,39,6,173,159,160,2,32,246,134,13,110,159,160,2,73,78,83,84,65,76,76,69,68,0,85,78,73,78,83,84,65,76,76,69,68,0
20 CLEAR200,16127:FORA=16128TO16177:READB:POKEA,B:NEXT: