RS232 on a Commodore 64 using DurexForth #330
Replies: 21 comments 64 replies
-
|
Edit: just saw the brackets. Nevermind. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Burnsauce, Thanks for at least having a look. It wouldn't be the first time my code has an obvious bracket missing. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe needs a CLRCHN following CHROUT?
…On Tue, 9 Mar 2021 at 08:02, Steve Smit ***@***.***> wrote:
Hi all, I have managed to use the RS232 adapter (VIC-1011A) to talk to a
PC and Arduino (using RS232 shield), using both BASIC and Assembler:
10 PRINT CHR$(147);
20 OPEN 5,2,1,CHR$(8)
30 GET#5,A$
40 IF A$<>"" THEN PRINT A$;
50 GET B$
60 IF B$<>"" THEN PRINT#5,B$;
70 GOTO 30
RSINI: LDA #$02
LDX #<PAR
LDY #>PAR
JSR SETNAM
LDA #$02
TAX
LDY #$00
JSR SETLFS
JSR OPEN
; TRANSMISSION
LDX #$02
JSR CHKOUT
LDA X_Var ; Where the byte to send is in X_Var
JSR CHROUT
PAR: .BYTE %00001000,%00000000
Here is my code in DurexForth, but no bytes are being sent:
( RS232 on C64 testing )
: setcom ( -- ) [
$fb stx, \ store a copy of xreg
8 lda,# \ low byte of params
$fd sta, \ store at $fd
0 lda,# \ hi byte of params
$fe sta, \ store at $fe
0 lda,# \ length of filename
$fd ldx,# \ lo byte of params add
$fe ldy,# \ hi byte of params add
$ffbd jsr, \ call kernal setnam
2 lda,# \ 2 = file# & RS232 device#
tax,
0 ldy,# \ no secondary #
$ffba jsr, \ setlfs
$ffc0 jsr, \ open
$fb ldx, ] ; \ restore xreg
: sendbyte ( $fc -- ) [
$fb stx, \ store current val in xreg
2 ldx,# \ rs232 device #
$ffc9 jsr, \ chkout
$fc lda, \ byte to send
$ffd2 jsr, \ chrout
3 ldx,# \ screen device #
$ffc9 jsr, \ chkout
$fb ldx, ] ; \ restore xreg
: main ( -- ) setcom
147 emit 62 emit 13 emit
10 0 do key dup
$fc c! sendbyte emit loop ;
Any suggestions where I could be going wrong? Thanks.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#330>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAY34O6HZE54USHANLXM3ADTCXBZVANCNFSM4Y25L7CQ>
.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks, jkotlinski, that's worth checking out. I'll let you know if that works. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Jkotlinski, while adding CLRCHN might be good housekeeping in a Commodore 64, to get RS232 working with DurexForth doesn't need this added. As you've seen from Whammo, DurexForth modifies the NMI vector and therefore all RS232 handling is being bypassed. Hopefully this can be corrected in later releases of DurexForth, but for now Whammo has provided a work-around that seems to be working for me for now. |
Beta Was this translation helpful? Give feedback.
-
|
I helped someone with this years ago and never heard back from them, so I assumed it worked.
The NMI vector is changed as DurexForth is initialized, so perhaps if it is reset to the default before the OPEN, we might have better luck.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks, Whammo, I also wondered whether DurexForth modified the memory map, but hadn't considered it may also affect the MMI vector. I'll let you know if I can figure this out with some C@ . of suitable memory locations. It makes sense this might be why I'm not seeing any bytes being transmitted with RS232. |
Beta Was this translation helpful? Give feedback.
-
|
Interpreter.asm shows that the NMI vector runs through QUIT. QUIT resets the NMI vector to the restore handler that calls QUIT. |
Beta Was this translation helpful? Give feedback.
-
|
That sounds a bit wierd, and I'm struggling to think of how I can solve this issue. Perhaps I could load a 3rd party RS232 handler (some exist since the original code Commodore put into the C64 couldn't reliably go to 9600 baud for instance), and try to figure out a way to have this called as needed for transmission and reciept over RS232. |
Beta Was this translation helpful? Give feedback.
-
|
Wait. Does NMI cause problems for RS-232?
It never occured to me that it was useful for anything but handling run
stop/restore.
…On Wed, 10 Mar 2021 at 00:47, Whammo ***@***.***> wrote:
Interpreter.asm shows that the NMI vector runs through QUIT. QUIT resets
the NMI vector to the restore handler that calls QUIT.
Pretty heady stuff.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#330 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAY34O7QLP3RPDJ2ONXLXPDTC2QRHANCNFSM4Y25L7CQ>
.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks Whammo, this looks helpful (I think). |
Beta Was this translation helpful? Give feedback.
-
|
At this point I am fairly certain that RS-232 open doesn't change the NMI vector. DurexForth certainly does. $FE47 $318 ! This will cause the restore key to have 'undefined' behavior, but RS-232 may work. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks again Whammo, that certainly seems logical, so I'll give this a try tonight (not with my C64 setup atm). I will also report back my results. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Whammo, I tried the $FF47 $318 ! and it worked! I haven't had a chance to digest your further suggestion, but for now I'm really pleased I can talk via DurexForth to an external RS232 device. |
Beta Was this translation helpful? Give feedback.
-
|
That's great to hear! I appreciate the work you've done to test it out. |
Beta Was this translation helpful? Give feedback.
-
|
It definitely sounds like DurexForth NMI handler should check if Run/Stop
is pressed before calling QUIT.
…On Wed, 10 Mar 2021 at 02:11, Steve Smit ***@***.***> wrote:
Thanks again Whammo, that certainly seems logical, so I'll give this a try
tonight (not with my C64 setup atm). I will also report back my results.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#330 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAY34OY2H4THFOV2LMHGIB3TC3BNNANCNFSM4Y25L7CQ>
.
|
Beta Was this translation helpful? Give feedback.
-
|
I've been looking at the code and I think that if we EDIT- Sorry no, because stop key check doesn't go through the BRK vector it just falls through. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Whammo, |
Beta Was this translation helpful? Give feedback.
-
|
I think that if it works okay the way it is, that's great. |
Beta Was this translation helpful? Give feedback.
-
|
This might be fun. Set this to NMI vector. Set QUIT to the BRK vector. code nmi
pha, \ save a
txa, \ copy x
pha, \ save x
tya, \ copy y
pha, \ save y
$7f lda,# \ disable all interrupts
$dd0d sta, \ save via 2 icr
$dd0d ldy, \ save via 2 icr
+branch bpl, \ skip if nmi enabled
$fe72 jmp, \ go directly to rs-232 routines
:+
$f6bc jsr, \ increment real time clock
$ffe1 jsr, \ scan stop key
+branch bne,
$fe72 jmp, \ if not [stop] restore registers and exit interrupt
:+
pla,
pla,
tax, \ still need to restore X
$316 (jmp), \ brk vector
;code
: install ' quit $316 ! ' nmi $318 ! ;NOTE; Actually, QUIT does reset the return stack. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Whammo, |
Beta Was this translation helpful? Give feedback.
-
|
I guess QUIT is important in that you can write code that blocks, you know, waits for something to happen. Then you can break in if it doesn't happen without resetting the machine. I'm sure it's more than that too. |
Beta Was this translation helpful? Give feedback.
-
|
No, I think that's pretty much it :) If there is an endless loop, or there is some crash or other weirdness due to mistake in the Forth code, Run Stop+Restore should reset the Forth to get the interpreter back in a working state. |
Beta Was this translation helpful? Give feedback.
-
|
It is nice to have the QUIT on runstop+restore, because then its possible
to exit endless loops.
But for sure this feature should not prevent RS-232 usage.
That should be reported as an issue and fixed.
…On Wed, 10 Mar 2021 at 12:07, Whammo ***@***.***> wrote:
I guess QUIT is important in that you can write code that blocks, you
know, waits for something to happen. Then you can break in if it doesn't
happen without resetting the machine. I'm sure it's more than that too.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#330 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAY34O7B76ROM2DV3CNFWRLTC5AEJANCNFSM4Y25L7CQ>
.
|
Beta Was this translation helpful? Give feedback.
-
|
Hi Jkotlinski, |
Beta Was this translation helpful? Give feedback.
-
|
Hallo! Whammo already created an issue + potential fix :-) |
Beta Was this translation helpful? Give feedback.
-
|
Here is a patch for RS-232 it ignores restore, and carts, quits on run/stop restore and even handles BRK nicely. nmi.fs $ce1 value rsh
$cdc value rsl
' quit value out
code nmi
pha, \ save a
txa, \ copy x
pha, \ save x
tya, \ copy y
pha, \ save y
$7f lda,# \ disable all interrupt
$dd0d sta, \ save via 2 icr
$dd0d ldy, \ save via 2 icr
+branch bpl, \ skip if nmi enabled
$fe72 jmp, \ go directly to rs-232
:+
$f6bc jsr, \ increment real time c
$ffe1 jsr, \ scan stop key
+branch bne,
$fe72 jmp, \ if not [stop] restore
:+
pla,
pla,
tax,
out jmp,
;code
code brk
pla,
pla,
tax,
out jmp,
;code
' brk $316 ! ' nmi $318 !
$316 c@ rsl c! $317 c@ rsh c!
quit |
Beta Was this translation helpful? Give feedback.
-
|
Hi Whammo, |
Beta Was this translation helpful? Give feedback.
-
|
Hi Whammo, Just to make sure there was no issues with my setup, I then did a hardware reset (in WinVICE) and loaded the basic program I used previously and confirmed all characters typed were being sent via RS232 successfully.
|
Beta Was this translation helpful? Give feedback.
-
|
Is the NMI vector being changed back from $FE47?
|
Beta Was this translation helpful? Give feedback.
-
|
Hi Whammo, |
Beta Was this translation helpful? Give feedback.
-
|
I'm trying to determine whether or not durexforth is changing the NMI vector back to point at QUIT at some point, because it will do that under certain conditions. So what I am saying after it fails to send, do $318 @ and see if it's still $FE47 |
Beta Was this translation helpful? Give feedback.
-
|
Fundamentally, the issue with RS-232 on DurexForth is the handling of NMI. restore_handler
cli
jmp QUIT
quit_reset
sei
lda #<restore_handler
sta $318
lda #>restore_handler
sta $319
cliThese are the first few lines of interpreter.asm. quit_reset is executed upon startup, through QUIT and through restore_handler. $ce1 value rsh \ from my patch above
$cdc value rslThese are the addresses in the current distro <restore_handler and >restore_handler following their respective lda in quit_reset. $FE rsh c! $47 rsl c! it might eliminate this as an issue. |
Beta Was this translation helpful? Give feedback.
-
|
No, I assumed the $FE47 $318 ! idea was all I had to do. The 'patch' you posted, do I run this inside my code or once only to try and fix the issue? |
Beta Was this translation helpful? Give feedback.
-
|
Ah. Yes, just include it once before anything else. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I hadn't tried this yet. I will do and report my outcome. Looks like it should work (I think). |
Beta Was this translation helpful? Give feedback.
-
|
Hi Whammo, I'm also going to do some testing shortly using a real C64 just in case there is something wierd going in in WinVICE (I'm running v3.5, which is the latest, but you never know with emulators). But since I'm able to use BASIC and that works fine, I'm fairly convinced it's just DurexForth that's the issue. Thanks again for any help you can offer. |
Beta Was this translation helpful? Give feedback.
-
|
I'm glad to help. It's unfortunate, but as it is, DurexForth doesn't support rs232. I've dabbled with attempting to get it going with VICE, and had similar success. You may have better luck on an actual 64. |
Beta Was this translation helpful? Give feedback.
-
|
You also might want to try it with BASIC ROM flipped in. |
Beta Was this translation helpful? Give feedback.
-
|
Early testing shows that the vector keeps getting reset after changing it, so that may be the issue. |
Beta Was this translation helpful? Give feedback.
-
|
This will set and prevent the vector from changing: $FE47 $318 ! $FE $ce1 c! $47 $cdc c! |
Beta Was this translation helpful? Give feedback.
-
|
Hi Whammo, Thanks, I will try this tonight and let you know how I go (both in WinVICE and on real hardware). Steve |
Beta Was this translation helpful? Give feedback.
-
|
Hi Whammo, |
Beta Was this translation helpful? Give feedback.
-
|
Hi Whammo. |
Beta Was this translation helpful? Give feedback.
-
|
If you've got it working in pure assembly outside of durexforth, there's no reason you cannot LOADB your binary, |
Beta Was this translation helpful? Give feedback.
-
|
Hi Whammo, OK, thanks I'll try this and let you know how I go. Regards, |
Beta Was this translation helpful? Give feedback.
-
|
Hi Steve,
If you have a possibility to share your project, maybe I could take a look
at it too, if I find the time :-)
…On Fri, 16 Apr 2021 at 04:37, Steve Smit ***@***.***> wrote:
Hi Whammo.
I have only managed to get a short time this week to do more testing, and
unfortunately I'm still not getting it to work. I tested on a real C64 as I
wanted to confirm that WinVICE isn't the issue. I went back and made sure
my BASIC and Assembler code programs work and they do, so it's getting
DurexForth to work with RS232 that I'm still stuck with.
I will try to do some more testing this weekend as I want to make 100%
sure that my Forth code isn't perhaps the issue (that could be
embarrassing!). Currently I'm not using the stack to store the byte I want
to send, which looks sloppy in Forth given that ideally the value to be
sent should be popped on the stack first. Having said that, I can't see
(yet) if there is something in my code that is preventing the actual bytes
I want sent ending up as $ff or $fe.
Regards,
Steve
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#330 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAY34OZV7ONNHMMQHCEMWJTTI6PF7ANCNFSM4Y25L7CQ>
.
|
Beta Was this translation helpful? Give feedback.
-
|
Hi Jkotlinski, How do I get you a copy of my .D64 DurexForth file? Regards, |
Beta Was this translation helpful? Give feedback.
-
|
It will accept a .zip file. just rename it to xxx.zip and point out its a ,d64 and to rename it so. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Jkotlinski, I've turned the .D64 file into a ZIP file. Let me know if you got this OK? Regards, |
Beta Was this translation helpful? Give feedback.
-
|
Hi Whammo, I actually ZIPped the file up (using an online free ZIP utility). If needed, I will also try just renaming the extension. Thanks, |
Beta Was this translation helpful? Give feedback.
-
|
I've included a patch to keep the BASIC ROM in context. Rename file to rgf.d64 |
Beta Was this translation helpful? Give feedback.
-
|
I've changed some code, my testing indicates it may be working now. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Whammo, I'm just downloading and trying it now too. Regards, |
Beta Was this translation helpful? Give feedback.
-
|
$9e00 is the output buffer. It shows two runs of MAIN.
|
Beta Was this translation helpful? Give feedback.
-
|
Hi Whammo, I just completed a test via WinVICE out to an Arduino and it's working!!! Awesome. I'm about to also do a test on a real C64, but given this test's success, I can already predict it will work. This is great stuff and well done, thank you. Regards, |
Beta Was this translation helpful? Give feedback.
-
|
Test also confirmed on real C64 now too! |
Beta Was this translation helpful? Give feedback.
-
|
I am not certain that the BASIC ROM is required to be in, but I am curious, |
Beta Was this translation helpful? Give feedback.
-
|
It's all good, I was going to sort this out at at some point, anyway. I'm glad to be a part of it. |
Beta Was this translation helpful? Give feedback.
-
|
My next challenge (to myself) is to be able to process bytes coming into DurexForth. This just requires me to read the RS232 input buffer. I'm going to assume bytes can fill the buffer in the background as it's handled by the NMI routine. This will be fun for my planned robotic projects in Forth (DurexForth on the C64 and a version of Forth on the Arduino [and other devices should I use others in the future]). Thanks again Whammo! Regards, |
Beta Was this translation helpful? Give feedback.
-
|
We've done a good thing. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Whammo, The retro scene from what I'm seeing is growing, and Forth is perfect for doing robotic projects, so hopefully supporting RS232 will be more and more appreciated. I certainly am, so thanks again. Regards, |
Beta Was this translation helpful? Give feedback.
-
|
It's definitely opening a can of worms. You'll know soon how the Kernal handles nulls received, and other fun stuff. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for not being very responsive in this thread.
I would welcome a pull request with necessary changes to add RS-232 support
in master :-)
…On Tue, 20 Apr 2021 at 14:50, Whammo ***@***.***> wrote:
We've done a good thing.
Maybe a half-dozen people in the world would be really excited if they
knew about it. 👍
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#330 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAY34O6JH2DW756G7FDYOATTJV2BLANCNFSM4Y25L7CQ>
.
|
Beta Was this translation helpful? Give feedback.
-
|
Sorry you missed out on all the fun! |
Beta Was this translation helpful? Give feedback.
-
|
Ah, do you think there should be a release? I guess I should just package
whats on master right now. Its probably relatively OK.
…On Tue, 20 Apr 2021 at 15:05, Whammo ***@***.***> wrote:
Sorry you missed out on all the fun!
I can work something up after the next release... ;)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#330 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAY34O3RK7IVA74TK2DZXOLTJV3ZPANCNFSM4Y25L7CQ>
.
|
Beta Was this translation helpful? Give feedback.
-
|
Are you interested in a pull request for the forth port of the DOS/io/open libraries? |
Beta Was this translation helpful? Give feedback.
-
|
It depends. What is the size difference? I remember doing something similar
before, but found there were no savings in having it in Forth.
…On Wed, 21 Apr 2021 at 02:30, Whammo ***@***.***> wrote:
Are you interested in a pull request for the forth port of the DOS/io/open
libraries?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#330 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAY34O7OG7AYSOMGSTAJ4E3TJYMBBANCNFSM4Y25L7CQ>
.
|
Beta Was this translation helpful? Give feedback.
-
|
You're correct as usual. Forth compiles to considerably more object code. It was still fun doing it. |
Beta Was this translation helpful? Give feedback.
-
|
Or rather it would be that Restore would fall through harmlessly when NMI is enabled, and otherwise QUIT. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Whammo and anyone else interested, After confirming I could send bytes over RS232 using DurexForth, I then proceeded to check that I could also recieve bytes over RS232 also using DurexForth. After much trial and many errors, I finally have low level Forth words for sending a byte and recieving a byte (if one is present).
RS232 on C64 testing ) : setup ( -- ) : sendbyte ( byte -- ) $fc c! [ : rec ( -- b f ) [ \ rs232 byte flag Now to start doing some robotics via RS232 from a C64! Regards, |
Beta Was this translation helpful? Give feedback.
-
Hi all, I have managed to use the RS232 adapter (VIC-1011A) to talk to a PC and Arduino (using RS232 shield), using both BASIC and Assembler:
10 PRINT CHR$(147);
20 OPEN 5,2,1,CHR$(8)
30 GET#5,A$
40 IF A$<>"" THEN PRINT A$;
50 GET B$
60 IF B$<>"" THEN PRINT#5,B$;
70 GOTO 30
RSINI: LDA #$02
LDX #<PAR
LDY #>PAR
JSR SETNAM
LDA #$02
TAX
LDY #$00
JSR SETLFS
JSR OPEN
; TRANSMISSION
LDX #$02
JSR CHKOUT
LDA X_Var ; Where the byte to send is in X_Var
JSR CHROUT
PAR: .BYTE %00001000,%00000000
Here is my code in DurexForth, but no bytes are being sent:
( RS232 on C64 testing )
: setcom ( -- ) [
$fb stx, \ store a copy of xreg
8 lda,# \ low byte of params
$fd sta, \ store at $fd
0 lda,# \ hi byte of params
$fe sta, \ store at $fe
2 lda,# \ length of filename
$fd ldx,# \ lo byte of params add
$fe ldy,# \ hi byte of params add
$ffbd jsr, \ call kernal setnam
2 lda,# \ 2 = file# & RS232 device#
tax,
0 ldy,# \ no secondary #
$ffba jsr, \ setlfs
$ffc0 jsr, \ open
$fb ldx, ] ; \ restore xreg
: sendbyte ( $fc -- ) [
$fb stx, \ store current val in xreg
2 ldx,# \ rs232 device #
$ffc9 jsr, \ chkout
$fc lda, \ byte to send
$ffd2 jsr, \ chrout
3 ldx,# \ screen device #
$ffc9 jsr, \ chkout
$fb ldx, ] ; \ restore xreg
: main ( -- ) setcom
147 emit 62 emit 13 emit
10 0 do key dup
$fc c! sendbyte emit loop ;
Any suggestions where I could be going wrong? Thanks.
Beta Was this translation helpful? Give feedback.
All reactions