cc65 and RS232 User Port Serial
Moderator: Moderators
-
- Vic 20 Afficionado
- Posts: 355
- Joined: Thu Oct 13, 2016 11:35 am
- Location: Toronto
- Occupation: Programmer
Re: cc65 and RS232 User Port Serial
I only just spotted this now. I am going to have to give this a try over the weekend!
-
- Vic 20 Afficionado
- Posts: 355
- Joined: Thu Oct 13, 2016 11:35 am
- Location: Toronto
- Occupation: Programmer
Re: cc65 and RS232 User Port Serial
I gave the RS-232 wedge a quick try. Not sure I am loading it right though.
If I understand correctly I should load and activate it with:
However after the initial load I get ?OUT OF MEMORY error for everything I try to do. So I need to do NEW (which shouldn't touch anything in $A000).
I am able to do this:
This seems to work but the behaviour is the same as before, with some apparent dropped characters leading to corrupted text and sometimes a hang of the XML parser (waiting forever for a tag that was corrupted).
Am I loading the wedge correctly? I am guessing so since the SYS40960 didn't just hang.
If I understand correctly I should load and activate it with:
Code: Select all
LOAD "RS-232*",8,1
SYS40960
I am able to do this:
Code: Select all
LOAD "RS-232*",8,1
NEW
LOAD "RSS20.PRG",8
SYS40960
RUN
Am I loading the wedge correctly? I am guessing so since the SYS40960 didn't just hang.
-
- Vic 20 Afficionado
- Posts: 355
- Joined: Thu Oct 13, 2016 11:35 am
- Location: Toronto
- Occupation: Programmer
Re: cc65 and RS232 User Port Serial
Tried loading in the other order and it seems to work based on a five minute test!
I will experiment with this some more and let you guys know if the problem is solved. Initial test looks encouraging though!!
Code: Select all
LOAD "RSS20.PRG",8
LOAD "RS-232*",8,1
SYS40960
RUN
-
- Vic 20 Afficionado
- Posts: 355
- Joined: Thu Oct 13, 2016 11:35 am
- Location: Toronto
- Occupation: Programmer
Re: cc65 and RS232 User Port Serial
With the RS232 wedge loaded I get fewer dropped characters and the communication seems reasonably reliable at 1200 baud. It is still not as robust as on the C64 though.
Re: cc65 and RS232 User Port Serial
Well that not too bad for a first attempt. I only applied the changes that Lee Davison identified as bugs in his disassembly, perhaps there's some other errors that need fixing.
It's missed receive characters you're seeing right?
It's missed receive characters you're seeing right?
- Mike
- Herr VC
- Posts: 4845
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: cc65 and RS232 User Port Serial
Hi, Bobbi,
If you directly call the load routine in the KERNAL, preferably from a running program, 45/46 are not affected. You'd either use SETNAM, SETLFS and LOAD - or, from BASIC the sequence of calls shown here: LOAD memory block ('absolute' load).
indeed the BASIC command LOAD sets the pointer to the start of variables (a.k.a. "end of program") always corresponding to the byte after the last one loaded - even if it is no BASIC program, but machine code loaded with ",8,1". You're right in using NEW to correct the pointer in 45/46 to a usable state once again.Bobbi wrote:However after the initial load I get ?OUT OF MEMORY error for everything I try to do. So I need to do NEW (which shouldn't touch anything in $A000).
If you directly call the load routine in the KERNAL, preferably from a running program, 45/46 are not affected. You'd either use SETNAM, SETLFS and LOAD - or, from BASIC the sequence of calls shown here: LOAD memory block ('absolute' load).
-
- Vic 20 Afficionado
- Posts: 355
- Joined: Thu Oct 13, 2016 11:35 am
- Location: Toronto
- Occupation: Programmer
Re: cc65 and RS232 User Port Serial
I *think* it is missing received characters that I see. Here is what I know for sure:
Code works pretty well on C64 (I won't say it is bug free, but it is close to production standard.)
I can have a few debugging aids - I twiddle with the border colour when I am receiving characters, so it is easy to see when characters stop arriving from the modem, and also to detect changes in rate (bursts after I finish scrolling the screen for example, as the parser catches up with the buffered input.) I have a spinner at the bottom right of the screen that I advance every time I parse an XML tag. Finally, there is the formatted output itself.
On the VIC-20 things work well for a while (several news articles, several kilobytes of input) but at some point the XML parsing stops advancing the spinner. That basically means that the state machine has gotten stuck looking for some tag that doesn't show up because the input is corrupt somehow. Eventually the input is exhausted and the border stops flashing but my code is stuck in the RSS parsing state machine still (I admit the code is not that smart - it only works with well-formed RSS input.)
For ages I assumed it was a bug in my parser. I bought a C64 partly to investigate and play with the WiModem on a better understood platform. However everything seems to work on C64, so I am back at the assumption that I getting corrupt RS232 on the VIC-20.
I also something see corruption within the text of an article - this often happens just before the RSS parser gives up the ghost. The corruption looks mostly like missing characters, but it is possible there are some corrupted (changed) characters as well - don't have the smoking gun on that yet.
I think things are better with the wedge loaded, although not perfect still. It is hard to compare two not quite working things and determine if (a) is better than (b) though, so maybe it is a placebo effect
Code works pretty well on C64 (I won't say it is bug free, but it is close to production standard.)
I can have a few debugging aids - I twiddle with the border colour when I am receiving characters, so it is easy to see when characters stop arriving from the modem, and also to detect changes in rate (bursts after I finish scrolling the screen for example, as the parser catches up with the buffered input.) I have a spinner at the bottom right of the screen that I advance every time I parse an XML tag. Finally, there is the formatted output itself.
On the VIC-20 things work well for a while (several news articles, several kilobytes of input) but at some point the XML parsing stops advancing the spinner. That basically means that the state machine has gotten stuck looking for some tag that doesn't show up because the input is corrupt somehow. Eventually the input is exhausted and the border stops flashing but my code is stuck in the RSS parsing state machine still (I admit the code is not that smart - it only works with well-formed RSS input.)
For ages I assumed it was a bug in my parser. I bought a C64 partly to investigate and play with the WiModem on a better understood platform. However everything seems to work on C64, so I am back at the assumption that I getting corrupt RS232 on the VIC-20.
I also something see corruption within the text of an article - this often happens just before the RSS parser gives up the ghost. The corruption looks mostly like missing characters, but it is possible there are some corrupted (changed) characters as well - don't have the smoking gun on that yet.
I think things are better with the wedge loaded, although not perfect still. It is hard to compare two not quite working things and determine if (a) is better than (b) though, so maybe it is a placebo effect
Re: cc65 and RS232 User Port Serial
OK, I'll have a look over the Rx code of the KERNAL and try and compare it to the C64. I think that the interrupt routines work slightly differently between the VIC and the C64, this might be why.
-
- Vic 20 Afficionado
- Posts: 355
- Joined: Thu Oct 13, 2016 11:35 am
- Location: Toronto
- Occupation: Programmer
Re: cc65 and RS232 User Port Serial
Awesome - thank you so much for this!! If we can get RS232 working reliably there are quite a few little applications that I would like to create for the WiModem + VIC-20.
Re: cc65 and RS232 User Port Serial
So, "Compute!'s VIC-20 and Commodore 64 Tool Kit: Kernal" says
Only one of the timer 1, timer 2 or CB1 interrupts is serviced by any one execution of the VIC-20 NMI interrupt handler. ... The interrupt enable register is temporarily cleared when servicing either of the timer 1, timer 2 or CB1 interrupts, resulting in the NMI output line from the VIA going high. So, the next NMI low would cause another interrupt. This interrupt could occur after clearing the timer 1 interrupt flag, but before executing the RS-232 send routine. It could also occur after clearing the timer 2 interrupt flag, but before executing the RS-232 receive routine. Thus nested NMI interrupts for timer 1 and timer 2 could occur and disrupt the RS-232 send/receive timing sequences. Apparently in recognition of this problem, the NMI interrupt handler was redesigned on the Commodore 64.
-
- Vic 20 Afficionado
- Posts: 355
- Joined: Thu Oct 13, 2016 11:35 am
- Location: Toronto
- Occupation: Programmer
Re: cc65 and RS232 User Port Serial
That looks like a promising lead - if the interrupt handler is borked then occasional character loss or corruption is to be expected. The pattern I am seeing (when plain English text is corrupted) are runs of missing characters (maybe 10 to 20 missing characters in a row) and often immediately before or after the lossage there is one corrupt character (e.g. a 'z' turned into a 'P' in one case).
If I remember correctly the RS-232 is handled by an NMI. What is the IRQ responsible for, just keyboard? Can we disable it in order to debug the issue?
If I remember correctly the RS-232 is handled by an NMI. What is the IRQ responsible for, just keyboard? Can we disable it in order to debug the issue?
-
- Vic 20 Afficionado
- Posts: 355
- Joined: Thu Oct 13, 2016 11:35 am
- Location: Toronto
- Occupation: Programmer
Re: cc65 and RS232 User Port Serial
I tried tossing:
In my C code to disable the IRQ handler. Something clearly re-enables interrupts because the keyboard works at a later point in my code. Anyhow it didn't seem to make any noticeable difference to stability.
Code: Select all
__asm__("sei")
Re: cc65 and RS232 User Port Serial
I don't think it's an interaction between NMIs and IRQs, rather the way that the VIA flags are cleared in the NMI routine allows the hardware to generate another NMI before completion.
It might be possible to re-work the NMI routine to behave more like the C64. I'm reasonably familiar with the workings of the VIA registers, my only worry is that the CIAs of the C64 don't work the same.
It might be possible to re-work the NMI routine to behave more like the C64. I'm reasonably familiar with the workings of the VIA registers, my only worry is that the CIAs of the C64 don't work the same.
-
- Vic 20 Afficionado
- Posts: 355
- Joined: Thu Oct 13, 2016 11:35 am
- Location: Toronto
- Occupation: Programmer
Re: cc65 and RS232 User Port Serial
Meanwhile I have finally debugged my modem handling code so I can reliably hang up and reconnect. I can now run and infinite spool of news on the C64. Looking forward to having it work on the VIC-20 too
Re: cc65 and RS232 User Port Serial
A quick read of the "C64 Prog Ref" reveals that the interrupt handling of the 6526 is quite different. Instead of the VIA's IER and IFR there's a single ICR. It doesn't look like individual interrupts can be cleared in the way that the can with a VIA.
I'll try and find some time this weekend to understand the differences in how the hardware behaves and how the C64 interrupt routine works. This could be quite a sizeable task...
I'll try and find some time this weekend to understand the differences in how the hardware behaves and how the C64 interrupt routine works. This could be quite a sizeable task...