Userport RS232 emulation via USB2Serial cable

If you're lucky this wasn't disabled by Retro Ltd in the vice emulator code that they've used/modified. Then you can check what options a 2.4 version of vice in a regular Linux or Windows environment enables for it in vicerc. Then you can copy those entries to /root/.vice/vicerc.

But if you're unlucky they ripped out the entire code for RS232 emulation. 

Either UART mod, or FEL mode, whichever you like best.
The source code was requested by swingflip and can be found here.

Abandon all hope.   There are no extra useful modules included in the Linux rootfs. But I managed to compile some usb2serial modules: serial.zip (516.47 KB). You need the included insmod as well to insert them with
# insmod -f ussbnet.ko
# insmod -f xxxx.kobecause the kernel version string doesn't exactly match. The pl2302 one works, the others I'm not sure.

FEL mod allows you to modify the system while the actual kernel / rootfs is not running. So it is more difficult to test things.   So i'd say UART mod is better.

There are people who mad a '3-pin' (or is it 4) C64Maxi to USB connector, and ti works fine apparently.

Raspberry Pi might be be the easiest solution from the software side, but is it as much fun?  

Btw, you can also avoid soldering by using my (still not patented) 'rubber band' methods 1 or 2.

Or run the FEL method once, copy the usbnet.ko and PL2303 usb2serial drivers over to to nand rootfs together with an /etc/init.d script to load them. Then add a line to /etc/inittab below the line

# Put a getty on the serial port
ttyS0::respawn:/sbin/getty -L  ttyS0 0 vt100 # GENERIC_SERIAL

like this:

ttyUSB0::respawn:/sbin/getty -L 115200 ttyUSB0 vt100
And if you then piggyback two PL2303 usb2serial converters, insert one of them in the Maxi, the other in your PC you should get a login prompt.

Yes, I compiled that one too, but wasn't able to test it. So it will be interesting to see if it works.

It isn't real fun if it works on the first try, right?

I haven't looked through the source, but my guess is that the Retro Ltd guys didn't rip out stuff from Vice, that would bee too risky. More likely they remover/changed some of the lookup strings for .vicerc. I notice it doesn'tcomplain about the 'RsUserEnable' setting. So if you're any good at debugging you could try to see where .vicerc is read and see if you can put the 'RsDevice1' back to being recognised. But that's grasping at straws, really.

Also, would /dev/ttyUSB0 not already be in use by the login prompt?

I used /dev/ttyUSB0 just to try as I had only one USB2serial dongle available at home. Anyway, the problem is that the rs232 is not included at build time

Exposing the keyboard seems like the only viable method to me.. or recompile everything which I suppose is something impossible to do

Yea, I was already thinking of some alternatives. For example, I would like to use the SID chip to send data to my PC by modulating the audio frequency. For the other way round, simulating a joypad should be feasible, but I'm worried about the limited transfer rate...

I'm curious about simulating a Mass Storage... I fear that the underlying Linux system (or maybe VICE) would cache THEC64-drive8.d64 data, so if I automagically change it the new data will not be visible Am I wrong?

Do you mean GDB?

Hello again.
I was thinking about using process_vm_readv and process_vm_writev (http://man7.org/linux/man-pages/man2/process_vm_readv.2.html) to directly "peek/poke" the C64 memory from outside (and hence somehow simulate the rs232). Therefore, I need to cross-compile stuff from my Linux box to TheC64 board. Can you give me some advice on how to start? Is there any toolkit already available for that board or I need to compile everything from scratch (I mean the libc and all the other stuff...)?

Hi there, I didn't compiled any software yet but I've made some progress to solve my problem. Here is what I did:


1) I downloaded a statically-linked version of GDB for arm7 and copied to the pendrive. It worked like a charm

2) I found the64 PID with ps ax (turned out to be 171)

3) cat /proc/171/maps to get a description of virtual memory regions of the process

4) in the C64 I've poked some memory at $C100 with a know byte pattern (my name

5) gdb attach 171

6) I started searching around in all the read-write memory regions for the byte pattern that I've written before at location $C100. For example:

(gdb) find /b 0x00058000, 0x00060000-1, 0x46, 0x49, 0x4c, 0x49 ....

7) Few dozens tries later... I've finally found my pattern around 0xB36903EC (in the linux board memory of course)

8) I tried to modify that memory location:

(gdb) set *((unsigned char*)0xb36904ec)=0xFF


9) Voilà! If I poke $C100 now returns 0xFF


So, it is feasible to peek/poke the C64 memory from outside while VICE is stopped in GDB (of course it makes sense, but seeing it working is another thing...). The next challenge is to do that with VICE running, but it should work assuming that  process_vm_readv and process_vm_writev syscalls are both available.


wish me good luck!

Hi, I'm back.

So.. after a while I've found some time to code a simple memory monitor for theC64. It works by invoking the process_vm_readv/process_vm_writev syscalls on the virtual memory regions of the process mapped to the emulated C64 memory. The absolute offset inside the page appears to be constant even if I reset the machine or start in carousel mode. 

If anybody of you wants to test it, just copy the two files tc64monitor and runtc64mon.sh on the USB flash drive, turn on theC64 and open a shell with the usual UART interface. 

Then:


cd /mnt
./runtc64mon.sh



***  tc64monitor ***  v 0.1

*****************************

fusys 2020



     PID: 171

BASE ADDR: 0xb23e7000

  OFFSET: 0x125f876

 C64ADDR: 0x48a

  C64MEM: 0xb36463ec

Type ? for help.

>
At this point is possible to peek/poke the (emulated) C64 memory as follows:

to poke some bytes at <addr>:  
:<addr> <byte1><byte2>....<byten>

to peek n bytes at <addr>:

M<addr> +n

For example, if you type:


:$05F0 08050C0C0F
the word "HELLO" should appear at the center of the screen (assuming that basic is running, otherwise the screen memory region may be different). Note that the process is not stopped as I did previously with GDB. I've successfully used this technique to exchange data between my laptop and the emulated C64 as originally planned by using RS232 interface.

Does anybody want to test it? I'm curious to know if it works also on the C64 mini...

I've also noticed it, that's probably because the c64 memory is not mapped as a contiguous region in VICE. Actually, looking at the source code it seems like some areas are managed by the vic20 subsystem and some others by c64. I haven't investigated it further because I just needed to peek-poke some data with no requirement on the specific memory address.

Anyway, if you think it's interesting for the community I can improve it. Source code will be available as soon as I clean up the messy parts

This is great fusys!