| Posted By
SukkoPera
on 2024-10-28
04:44:54
|  "Parallel" Uploader for the 21st century
Today I had the odd necessity of knowing how the Plus/4 & C64 Uploader works, so I reverse engineered it. Here's my findings:
(BTW, now the link on the page brings to MD's homepage where I am unable to find the download, so maybe it should be added to the page itself, after recovering it  )
Let's start from the cable diagram:
Plus/4 PC
--------------------
P0 (B) Error (15) - Actually not used by this program
P1 (K) SLCT (13) - Not used
P2 (4) PE (12) - Not used
P3 (5) ACK (10) - Not used
P4 (6) D0 (2)
P5 (7) D1 (3)
P6 (J) D2 (4)
P7 (F) D3 (5)
DCD (H) D4 (6)
DSR (L) D5 (7) - Not used
RTS (D) Busy (11)
GND (1) GND (19)
As you can see from the comments I added, only a handful of pins are actually used, so if you want to build the parallel cable, you can save some soldering.
The protocol works like this:
- Transfer is unidirectional: PC --> +4. The +4 only controls an "acknowledge" signal.
- Data is received in nibbles over P4-P7
- "OGRE" (PETSCII upper case) is sent at the beginning of the transfer
- Then load address (2 bytes) and transfer length (2 bytes, subtract 2 from PRG size for load address) are sent
- Then data is sent (again: skip the load address)
- Finally a number indicating how many characters follow (can be 0)
- Any following characters will be put in the keyboard buffer in REVERSE order (Don't forget !)
The protocol on the wire is as follows:
- +4 starts with RTS high
- PC starts with DCD high
- PC sends high nibble and sets DCD low
- +4 samples data and acknowledges by setting RTS low
- PC sets DCD back high
- +4 sets RTS back high
- Repeat for low nibble
Keep in mind that there's an inverter between the ACIA and the userport, so DCD and RTS might not be as you expect...
This was relatively quick to figure out, but of course at that point I wanted to know if my findings were correct, so I spent the rest of the day recycling some old HW and SW in order to test it. Of course my PC no longer has a parallel port, so the bottom line is that I now have an Arduino sketch that runs on a slightly modified Plus4Midi board (remember?) that can be hooked up to a PC via USB and a Python script that does the upload. All of this is compatible with the original receiver program on the +4 side.
I had started all of this for fun but now that I have it working I must admit it TREMENDOUSLY speeds up my development process! I no longer have to remove the SD card from the SD2IEC, put it on the PC, update my binary, remove it, put it back in the SD2IEC, reload, etc. I can just type "/U*" (thanks JiffyDOS!) and then send the PRG from the PC in a pinch. So I got a nice reward for my initially pointless effort! Next step is to put it on a cartridge!
Anyway, the whole thing is not polished enough for a release, but if enough people were interested in this, I'd happily take the final step and make it available. Let me know, in case!  Note that the Plus4Midi board is not required, any cheap Arduino board, a userport connector and a few wires are sufficient.
PS: Since there is no point anymore in doing the transfer in nibbles, the receiver program can easily be updated to receive bytes, making the whole thing even faster!
|
|
Posted By
krzycho751
on 2024-10-27
12:38:41
| Re: "Parallel" Uploader for the 21st century
I think a direct link between a PC and real Commodore hardware is quite useful – especially from the perspective of someone developing software for hardware that doesn’t yet have emulation.
Your projects are a great example of this.
If someone wants to write software for SoundX (I recently soldered it) or maybe DigiMoooz with two AY chips (I can’t wait for it!) and has their Plus/4 close enough to the PC… well, I’d definitely use it!
|
|
Posted By
SukkoPera
on 2024-10-30
19:08:44
| Re: "Parallel" Uploader for the 21st century
Yep, all of my development is for drivers and test programs for my HW, which of course is not yet implemented in emulators (the only one that was, the SNES pad adapter, was buggy, lol!), so this really speeds it up a lot. Actually I am upset I didn't think about this before!
In the meantime I have updated the code to do 8-bit transfers, speed is now ~8 kB/s. I think it could still be improved a bit (I'm not sure where the bottleneck is, though), but since the largest transfer is less than 64 kB, I guess it's already acceptable.
This also shrunk the loader code a bit and I managed to make it fit into the tape buffer, which should increase compatiblity even a bit more. So far everything I've thrown at it has worked.
UPDATE
A funny thing is that the uploader can also be used to quickly test... itself! :) As obvious as it is, I find it funny.
Anyway, the tool now supports a few different transfer modes, selectable from the client:
- Default mode supports CRC checking in order to guarantee data integrity and achieves 6.9 kB/s (8.4 kB/s with CRC disabled).
- Fast mode does a lot of dirty tricks in order to be as fast as possible, including turning the screen off. It does NOT support CRC but achieves 11.7 kB/s and in practice it is 100% reliable, as the speedup is only gained through code optimizations.
- There is also a slow mode which is not necessarily more reliable, so I think it will disappear.
This thing is now definitely overengineered, but it was useful for me to devise as many optimization techniques as possible, including swapping base address and index register, inlining code, disabling the screen and self-modifying code. It was very inspiring for me :).
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
