My video about the RS-232 ROM (User-Port) Bug. Help for optimizations requested Hello friwnds,
i did my research in transmitting a binary file to the Plus/4 from a Raspberry Pi over the User-Port using the RS-232 protokoll. Of course i ran into the ROM Bug, but finally after a few weeks of headscratching I did it and learned a lot during this journey. I could not reach the 19200 baud, since i am using Basic, so if somebody has experience to lead me the way how to write a stable the reciever program in assebly, i would apreciate it. I am also going to try the parallel protokoll, but i need some advice prior, because i don't want to fry the userport or the Plus/4. Anyway here is the video:
The Famous RS-232 Bug In this episode i demonstrate binary data transfer with Python from a Raspberry Pi to the Commodore Plus/4 over Userport. We will transfer a picture of a Tie-fighter.
Re: My video about the RS-232 ROM (User-Port) Bug. Help for optimizations requested As I wrote on Facebook, it should be enough to connect the RTS pin from the RasPi to the CTS pin on the +4, then just remove all the delays in the sending program, the transfer should proceed as fast as possible.
There's no way to fry the serial port anyway, it's much easier to fry the pins on the RasPi!
Re: My video about the RS-232 ROM (User-Port) Bug. Help for optimizations requested Reading through the conversations I am a little confused now.
So there was a 6551 HW bug, but it was managed by the Commodore team to put CTSsignal (input of 6551) to a fix ground state. In fact it is well stated on the drawing, though the original documentation from Bil Herd show a timing for that CTS signal too.
On the other hand it is told now the Kernal routine had a failure.
Previously a US scener told, that even the Commodore modems could be used on Plus/4 if one of the signals (if I remember well, the CTS) is covered with a tape, otherwise they will fail to work.
Question: if the 6551 HW bug was rectified by a HW solution on the CTS signal how it may cause a problem with the Commodore modems? Or it is also just an urban legend, that the Commmodore modems does not work (as it is) with Plus/4?
Re: My video about the RS-232 ROM (User-Port) Bug. Help for optimizations requested I think Commodore's fix for /CTS is evident in the original +4 schematics:
You can clearly see that pin K is aligned with the /CTS pin of the ACIA and it's likely that they were connected with a straight line like most other pins. Then they must have noticed the issue and redirected the signal to pin 1 of the parallel port.
Anyway pin K is the same pin where /CTS is expected on the VIC20 and C64 userports, as you can see from the VIC-1011A schematics so I would expect the Commodore modems to be compatible with the +4 without any modifications.
Maintaining compatibility with the old VIC20/C64 peripherals that used the serial port signals is also the easiest explanation for why the parallel port pins are scattered around the userport as they are, since the serial port signals could not be moved.
Re: My video about the RS-232 ROM (User-Port) Bug. Help for optimizations requested @SukkoPera I connected the RTS Pin from the Raspi (you have to configure it) and CTS Pin K (Plus/4, Kernel), it unfortunatly it does not work. Either the configuration did not work or theere must be some further configuratiuon on Plus/4 side. I will look more into into it, after i will try out assembly first.
Re: My video about the RS-232 ROM (User-Port) Bug. Help for optimizations requested You might have to do something on the Python side. For instance, if you are using pySerial, it does not use flow control by default.
Re: My video about the RS-232 ROM (User-Port) Bug. Help for optimizations requested Yesterday I made some tests in order to get flow control working and I found the following: - First of all, to enable HW flow control when the RasPi is sending to the +4, /RTS from the +4 should be connected to /CTS on the RasPi, I had that reversed in my previous instructions, sorry for that. Note that if you do this, you MUST use a level shifter or your RasPi GPIO will easily be damaged. - Anyway, that would not make a difference since, as far as I understand, the KERNAL code seems to respect HW flow control for outgoing bytes but it doesn't bother with it for incoming bytes: /RTS is never deasserted and the KERNAL only seems to support software flow control for incoming bytes. - So I tried to enable that: on the +4 it's enough to write the desired XON/XOFF character values to $FC/$FD, respectively (values are normally $11 and $13). In the Python sender, xonxoff = True must be added to the pyserial instance constructor. Of course, at this point the TX line from the +4 shall be connected to the RX line on the RasPi (and again, level shifter is mandatory). - By sniffing the TX line from the +4 I was able to see that it was correctly sending the XOFF character but my transmitter would still not stop. I was using a USB HID (CDC) to TTL serial adapter on my laptop and, after a loooong search, I figured out that Linux does not support flow control on most USB to serial converters . This is subtle because the whole mechanism is there and seems to work fine, except that the pause() method in the driver is not implemented and so it will always keep sending without any warnings. Note that this would also break HW flow control. - So the only solution left was to implement SW flow control in the sender program. That is not particularly difficult so I tried it and it seems to work fine for the first couple of XON/XOFFs: the program starts sending, after some bytes (56, IIRC) the +4 will send XOFF and the program will pause. The +4 will then slowly process the incoming queue and issue XON when it's almost done. So the sender resumes sending until the buffer is full again and the +4 sends another XOFF, but at that point the +4 seems to hang and never sends another XON, so transmission never completes. I will have to understand what's going on...
Re: My video about the RS-232 ROM (User-Port) Bug. Help for optimizations requested Thank you for your efforts: So what i have to try out is this:
- a second line from tx to rx (Pi) (level shifter) - Plus4 reviever: Set XON/XOFF character values to $FC/$FD, respectively (values are normally $11 and $13). - Python sender, xonxoff = True
I have tried it out once, but did not seem to work. I will try again. Maybe the chars were not right. Which chars did you use?
Re: My video about the RS-232 ROM (User-Port) Bug. Help for optimizations requested What characters to pick is a good question, since I'm assuming that any such characters will be interpreted as XON/XOFF also in the other direction, so we should pick characters that do not appear in the image being sent over. I had located such characters yesterday but I can't remember them now, I will check tonight.
If you change the defaults, you will also have to tell pyserial about that, I'm not sure how to do it.
Also I'm not sure if the XON/XOFF handling still works after you load the 0-bytes patch.
My video about the RS-232 ROM (User-Port) Bug. Help for optimizations requested
. This is subtle because the whole mechanism is there and seems to work fine, except that the pause() method in the driver is not implemented and so it will always keep sending without any warnings. Note that this would also break HW flow control.
