Denial

Bobbi wrote:Yes! I can finally parse RSS at 1200 baud. The key was to stop using the CBM kernal I/O - if I use the conio routines from cc65, it works way way better than using putchar() and friends. Go figure!?

I will make a new release of the RSS reader with support for speeds up to 1200 baud in due course. However first I need to clean up the output routines and implement some form of scrolling - it's all very crude at the moment, but it is working!!

Great!

I was about to write you might try to open RS232 just for small stints of, say, 64 bytes and write those to the file. Of course that relies upon the KERNAL I/O correctly handling RTS/DTR.

In an unrelated matter, the filename "@:rss.xml,p" uses save-with-replace, which is bugged on real CBM DOS drives - it can accidentally free the *wrong* sectors leading to data corruption later on. This is not related to the fact, that the old file remains on disk until the new file is closed (which in itself leads to trouble if the new file doesn't fit on disk along with the old file). You should be using a scratch command on the old file instead.

Furthermore, you're writing a PRG file - by convention this should be a SEQ file, but that's a minor issue.

Yeah I know about the buggy '@' and I probably wouldn't use it in released code. However I do use it with debug code I am only going to run on SD2IEC.

I am wondering why using kernal I/O via putchar() leads to such disastrous results! It is not that it is too slow - my RX buffer never fills up beyond 20 bytes or so. One thing that seems to be an issue is that whenever I print a quote mark (") using putchar() it puts the console into quoted mode, just like I had entered it interactively in BASIC. From that point certain control characters such as RVS ON / RVS OFF now print out rather than take effect. I don't quite have the smoking gun but I think it was this behaviour that was somehow causing some of my issues ...

Not sure if the kernal is to blame here or if cc65 library code is misusing it.

Bobbi wrote:Yeah I know about the buggy '@' and I probably wouldn't use it in released code.

If you replace "probably" with "surely", I'm fine with that. (PM sent)

[...]One thing that seems to be an issue is that whenever I print a quote mark (") using putchar() it puts the console into quoted mode, just like I had entered it interactively in BASIC. [...] Not sure if the kernal is to blame here or if cc65 library code is misusing it.

That's standard KERNAL behaviour on screen output. It also is not related to whether the output is done in direct mode or program mode (try out PRINTCHR$(34)CHR$(17)CHR$(34) inside a program and you'll see what I mean).

I can only presume conio on cc65 circumvents this by either using own screen output routines (unlikely), or by throwing a wrench into the gears of the KERNAL (i.e. intentionally switching off quote mode after each char).

I think conio implements its own and ignores the kernal. It is cross platform functionality in the library (not CBM only.)

It only takes a few minutes to make a simple console I/O library that doesn't do daft things

However conio does not offer scrolling so it's marginal how useful it is compared to just doing it from scratch.

Bobbi wrote:[...]conio[...] It is cross platform functionality in the library (not CBM only.) [...] However conio does not offer scrolling [...]

O.K., I stand corrected on this one. The omission of scrolling then indeed is bad.

I must confess though I haven't used cc65 that often, just for small example programs. I see people getting particularly nice results in C on the VIC-20 (see misfit's recent releases), but I always found cc65 quite limiting for the kind of programs I'd like to write. And I have no exact idea what side effects the C run time causes in the ZP and OS area ($0200..$03FF).

It only takes a few minutes to make a simple console I/O library that doesn't do daft things

That just depends on using the right tool for the job.

It has been a while since I posted regarding my adventures with VIC-20 user port RS232 here.

I ended up buying a rather nice breadbox C64 to test RS232 stuff on. During the weekend I ported the RSS Reader code to the C64 and I have been playing with it using the WiModem at 1200 baud. The interesting thing is that while the code is pretty reliable on the C64 it often ends up dropping characters on the VIC-20. I believe this is due to the fact that cc65 uses the kernal RS232 routines, which have a bug on the VIC-20 so that X-wire handshaking does not work.

Does anyone know of any working RS232 routines (in C or 6502 asm) for the VIC-20 that I can use? I don't want to have to reinvent the wheel. It would be great to have the RSS Reader working as well on the VIC as it does on the 64.

(I posted the new version of the RSS Reader to the CBC News App / RSS Reader thread in this board.)

Would it be possible to adapt the c64 rom code?

If I am right about the cause of this, it would probably be easier to fix the bug in the VIC-20 kernal ROM (which is a known bug - looking at the incorrect VIA if I recall correctly.) The code would have to be migrated to RAM of course. Not sure how much work it would be to do. The C64 uses a CIA rather than a VIA so I guess the code is rather different in the kernal (haven't looked at C64 kernel disassembly though so no idea how different.)

the ROM code should be very similar actually, and probably wouldnt help much.

i'd probably look at some standalone (non kernal) code for the c64 (eg the famous "transactor" article) and then adapt it for VIA (dont forget to recalculate the timer constants). shouldnt be terribly hard afterall

From memory there are three separate bugs in the RS-232 code. It would be possible to write a wedge to fix them but it probably won't be small, at least one change to the NMI codepath is needed.

I'll take a look at it tonight, I've not much use for it myself as I've built a cart with a 16550 UART.

Let me know if you have any luck with it. I'd love to see this working properly on the VIC-20 and there must be other programs that need working RS232 flow control

Bobbi wrote:Let me know if you have any luck with it. I'd love to see this working properly on the VIC-20 and there must be other programs that need working RS232 flow control

The one thing I can't fix with a wedge is the bug in READST, it always returns 0 for device 2. It is not vectored so whatever code calls it needs to be patched. If it reads RSSTAT directly then noting needs changing.

So my initial attempt (untested) is just under 600 bytes. Where abouts in memory would you like it to be located?

I am using cc65. My code is not too big - about 6kb. It could probably go in the $a000 space somewhere.

Here is the memory layout from the map file:

OK, so here's my crude attempt at a wedge. It loads in at $A000, you will need to call the following addresses:

$A000 - enable the wedge
$A004 - disable the wedge
$A008 - replacement for READST

I've only tested it with 3-line handshaking, I don't think my level shifting dongle handles anything but Rx and Tx.