Questions and comments about durexForth's source.

[ekipan]

I'm reading durexForth and learning C64 as I go. (I moved the actual question to a comment, so that replies to it will thread there, and any further questions to their own comments as well.)

[ekipan]

In quit_reset you configure the screen, and then set the processor port to enable IO at $DXXX. Wouldn't it be prudent to enable IO first, if this is intended to reset after any arbitrary program? If there's something I'm missing it could be worth a comment in the source! Here's the commit that added it, and another that removed basic rom from it, both very old.

[jkotlinski]

Ohh, that's a good point! If $d000-$dfff for some reason was mapped to RAM, screen initialization would fail. That's what you had in mind, right?

[ekipan]

Yeah. Currently quit_reset does presume IO is mapped, but then it sets the mapping anyway afterwards.

You can imagine an errant program that blows the stack and overwrites $1 with garbage, unmapping IO. If it somehow makes it back to quit_reset, those screen settings won't be restored until the user calls quit a second time. It's not much, but unless it would cause any other problems I'm not seeing, then it seems like a simple improvement.

[jkotlinski]

That makes total sense! Nice catch!

[Whammo]

I concur. Nailed it!

👍

[Whammo]

If however $1 was changed with purpose and the current IRQ routine requires that the Kernal not be there, it would be prudent to initialize the IRQ vector.

[ekipan]

Also in quit_reset are these instructions (my own comments added):

    lda #$17
    sta $dd00    ; $3 vic bank 0, ($14 clock a bit onto user port?)
    sta $d018    ; $6 character rom, $10 screen 0

Do I understand the $dd00 store correctly and is the clocked bit actually used or just a harmless side effect of saving one lda instruction? Actually I guess this kinda stuff is more C64 in general than durexForth specifically, perhaps a different place would be more appropriate for this kind of question.

[jkotlinski]

$17 was used, simply because it is the $dd00 default value. I did not put any thought into bits 2-7. Do you think it could cause problems?

[Whammo]

Bits 0 and 1 select the current 16K bank for video memory from the
four possible choices using the following bit patterns:

00 (bit value of 0) Bank 3 (49152-65535, $C000-$FFFF)
01 (bit value of 1) Bank 2 (32768-49151, $8000-$BFFF)
10 (bit value of 2) Bank 1 (16384-32767, $4000-$7FFF)
11 (bit value of 3) Bank 0 (0-16383, $0-$3FFF)

The others are:
56576 $DD00 CI2PRA
Data Port Register A

Bits 0-1: Select the 16K VIC-II chip memory bank (11=bank 0, 00=bank 3)
Bit 2: RS-232 data output (Sout)/Pin M of User Port
Bit 3: Serial bus ATN signal output
Bit 4: Serial bus clock pulse output
Bit 5: Serial bus data output
Bit 6: Serial bus clock pulse input
Bit 7: Serial bus data input

Shouldn't cause a problem. These are the default states of the output lines. /ATN is active low and you can't tell who's holding the clock and data low, but if you are, you can tell when everybody is. 😉

[ekipan]

In v.fs you scratch a file with the command "s0:filename\r".
In block.fs you use the command "s0:filename".

Is the '0' important? It doesn't seem to be mentioned in the 1541 manual.

[Whammo]

The "0" is the drive number in dual drive devices and/or partition path. It's inclusion is often optional, but sometimes required.

[jkotlinski]

Sadly I don't remember why, but I imagine some other device than the 1541 expects it.

[jkotlinski]

Commodore 4040

[Whammo]

https://www.atarimagazines.com/compute/issue65/save_with_replace.php

[ekipan]

I noticed in interpreter.asm the READ_NUMBER routine allows some nonstandard parses:

#$%101 .
5 ok

I think this might fix it, plus make it very slightly smaller and faster:

Click for diff.

diff --git a/asm/interpreter.asm b/asm/interpreter.asm
--- asm/interpreter.asm
+++ asm/interpreter.asm
@@ -584,17 +573,8 @@
     jsr R_TO
     jsr PLUS
     jmp SWAP
 
-apply_base
-    sta BASE
-    dec .chars_to_process
-    inc W3
-    bne +
-    inc W3+1
-+   lda (W3),y
-    rts
-
 ; Z = success, NZ = fail
 ; success: ( caddr u -- number )
 ; fail: ( caddr u -- caddr u )
 READ_NUMBER
@@ -619,25 +599,32 @@
     lda (W3), y
     cmp #"'"
     beq .parse_char
 
-    cmp #"#"
+    cmp #"$"
     bne .check_decimal
-    lda #10
-    jsr apply_base
+    lda #16
+    bne .base_a
 
 .check_decimal
-    cmp #"$"
+    cmp #"#"
     bne .check_binary
-    lda #16
-    jsr apply_base
+    lda #10
+    bne .base_a
 
 .check_binary
     cmp #"%"
     bne .check_negate
     lda #2
-    jsr apply_base
 
+.base_a
+    sta BASE
+    dec .chars_to_process
+    inc W3
+    bne +
+    inc W3+1
++   lda (W3),y
+
 .check_negate
     cmp #"-"
     bne .loop_entry
     inc .negate

Maybe the two bne .base_a instructions are going too far and should be jmp instead. What do you think?

I opted to check for $ first so any hex literals are the fastest (also the label .check_decimal was previously misnamed). I also found that entering a missing word %x for instance leaves the interpreter in base 2. I suspect the standard doesn't specify this condition so perhaps it's fine. It wouldn't be trivial to fix.

[jkotlinski]

bne looks like a good optimization to me :-) It does not sound good that entering a missing word would change base. That is not something I would expect.

[ekipan]

Lines 3 and 9 of accept.fs contain the phrase: $cc >r ( ... ) r> $cc c!, which stores the value $cc at $cc, effectively always turning off the cursor when accept is done. Was that intended to be $cc c@ >r ( ... ) r> $cc c!, restoring the previous cursor state?

In any case I took the liberty of rewriting accept, keeping the same behavior but shrinking the code from 210 to 147 bytes. It's a bit slower I guess but that's fine since it's a user input word. Here it is, let me know if you'd prefer I send a pull request:

(code moved to PR)

[ekipan]

PR: #557

[jkotlinski]

”Was that intended to be $cc c@ >r ( ... ) r> $cc !, restoring the previous cursor state?” Probably :-) well spotted! I would welcome a pull request, then it is easy to see the diff. sön 14 maj 2023 kl. 23:02 skrev ekipan ***@***.***>:

…

Lines 3 and 9 of accept.fs <https://github.com/jkotlinski/durexforth/blob/e33627cf924816f408cf58bbd4a09afd61050f06/forth/accept.fs#L3-L9> contain the phrase: $cc >r ( ... ) r> $cc !, which stores the value $cc at $cc, effectively always turning off the cursor when accept is done. Was that intended to be $cc c@ >r ( ... ) r> $cc !, restoring the previous cursor state? In any case I took the liberty of rewriting accept, keeping the same behavior but shrinking the code from 210 to 147 bytes. It's a bit slower I guess but that's fine since it's a user input word. Here it is, let me know if you'd prefer I send a pull request: 0 value addr : accept ( addr avail -- len ) swap to addr 0 ( avail len )0 $cc c! \ cursor onbegin key case $d of \ cr 1 $cc c! nip space exit endof$14 of \ del dup if 1- $14 emit then endof( avail len char ) \ add to buffer? >r 2dup > r@ bl $7f within and if r@ over addr + c! 1+ r@ emit then r>endcase again ; hide addr — Reply to this email directly, view it on GitHub <#538 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAY34O3WXCLQQDVZTPEBIVTXGFB7XANCNFSM6AAAAAAW6M2DCY> . You are receiving this because you commented.Message ID: ***@***.***>