Contents:
- The physical connection (the cable)
- Sending data between PC and the Commodore computer using terminal programs
- Sending data between PC and the Commodore computer using BASIC software
- Sending a binary file from the Commodore computer to the PC
- The hardware and logic side of the RS-232 interface
- A small client / server application in assembly code
1. The physical connection (the cable)
Another project for a cold, wet winter day in Germany: How can I connect an old Commodore 64 or 128 computer from the 1980s to a modern Windows PC and exchange data? Meaning: Connecting the most exciting computers in the world (the Commodore C64 and C128 🙂) with the “boring” Windows computers we find on our desks these days. Since I’ve read some misinformation on this topic online, and the source codes provided didn’t always work, here are my instructions.
In my opinion, there are two main use cases for connecting a Commodore 64/128 computer to a modern PC:
- The Commodore computer becomes a terminal to a UNIX/Linux computer. This case is described very well here and I won’t repeat it.
- The Commodore computer should exchange data with a Windows PC, e.g., when the results of a software program on the C64/C128 need to be transferred to the PC for further processing.
The connection between the C64/C128 and the PC utilizes the Commodore user port’s capability for serial transmission. The obsolete standard for this would have been a serial cable („null modem cable“) between the Windows PC („data terminal equipment“, DTE) and the C64/C128 (also „data terminal equipment“, DTE) via the RS-232 interface with a DB9 connector on each side. However, neither a modern PC nor the C64/C128 have one of these. Serial USB type A interfaces are common on PCs these days.
There is another hurdle: The C64/C128 has RS-232-like lines on the user port, but at TTL level, i.e. with 0/5 volts instead of -12/12 volts.
These problems can be solved cheaply using a “DTech FTDI USB to TTL Serial Adapter 5V UART Cable” as shown in the picture:
This adapter connects the serial USB type A port on the PC to a 2.54 mm pitch 0.1 header, which would normally be plugged into a 6-pin jumper. The USB interface level is converted to UART/TTL levels via the built-in FT232RL chip, making it a perfect fit for the C64/C128. Yes, the little USB port enclosure contains a chip.
After plugging the USB cable into the PC, the Device Manager of the Windows operating system sees it as a new serial (COM) port, in my case COM3:
The settings (300 baud, 8N1, hardware flow control) can be adjusted to suit the Commodore computer or its terminal program via the Properties / Port Settings:
Theoretically, you can set speeds higher than 300 baud, but this is more than sufficient for the initial test. 2400 baud is the limit anyway.
Note: Hardware flow control using the signal lines RTS (Request To Send) and CTS (Clear To Send) or Data Terminal Ready (DTR) and Data Set Ready (DSR) requires a specific cable. A 3-wire null modem cable (RxD, TxD, GND) will not work.
Now connect the black female connector (“pin header”) with a user port connector, as shown in the following image:
This could have done more professionally, but it’s sufficient for my tests. I plugged a 2.54 mm pin header for a few cents into the black socket on the left to make soldering the cables easier. The screws on the user port connector are simply there to allow for easier removal of the connector from the C64/C128´s motherboard (the printed circuit board, PCB) without putting any strain on the cables.
The pin assignment and wiring follow this diagram:
If you follow the wiring carefully, you will see that between the user port and the black socket strip the receive (RxD, Receive Data) and transmit lines (TxD, Transmit Data) are crossed. This is necessary to create a null modem cable. CTS and RTS are also crossed to enable a hardware handshake. The signal ground (GND) of the pitch header is connected to the special signal ground (N) of the user port, not to the protective ground (A).
2. Sending data between PC and Commodore computer using terminal programs
If you start a terminal program now on the PC and one on the C64/C128, you can exchange data between the two computers. I use PuTTY for this on the Windows PC and Elite Term 1.0 on the C64/C128. In PuTTY, it’s important to apply the correct settings for the serial interface and start the session as a serial connection.
If you would set flow control to „RTS/CTS“ at this point, PuTTY could not send any data, as the flow control protocol of PuTTY interferes with the one from the Windows operating system. Typed in characters in PuTTY would only appear on the screen of the Commodore computer after you switched back to „None“!
I also set the window size to 40×24 characters. Local echo is set to „Force on“. „Implicit LF in every CR“ is important so that PuTTY moves the cursor one line down after each return key:
In Elite Term, set the baud rate to “300” in the “Modem” menu:
Now start the “Hayes compatible” ASCII terminal from the same menu. In PuTTY, the session (the terminal window) is started with „Open“:
Everything you enter in the PuTTY terminal window
appears as if by magic on the screen of the C64/C128:
It also works the other way around: Everything you type into Elite Term appears in the PuTTY window.
Every terminal program on the C64/C128 behaves slightly differently, and you have to experiment until you find a suitable one. The terminal program CarTer for example, lacks local echo, so characters typed on the C64/C128 were visible on the PC but not on the Commodore computer itself. In CCGMS, a half-duplex connection provided local echo, but the characters were not displayed correctly between the C64 and C128 (ASCII vs. PETSCII).
While Elite Term cannot handle ANSI control characters, the terminal program CarTer is able to understand some of them. The character string
ESC [ Ashifts the cursor up one line (enter without spaces). The string
ESC [ 2 Jclears the screen on both sides. However, you have to pay attention to the key assignment in CarTer. The ESC character is not accessible as shown on the keyboard, but rather via the „<-“ key above the CONTROL key.
3. Sending data between PC and the Commodore computer using BASIC software
So far, I demonstrated how to physically connect a Commodore 64 or 128 computer via serial connection to a modern PC with a USB port. Sending text back and forth manually is nice, but ultimately just a gimmick. Now it’s time for a more interesting challenge.
To do this, we physically connect both computers again. On the PC, we start PuTTY, and on the C64/C128, we start a small BASIC V2 program:
89 REM CONTROL REGISTER MAP (6)
90 REM 0=1 STOP BIT
91 REM 00=8 WORD BITS
92 REM 0=UNUSED
93 REM 0110=300 BAUD
94 REM COMMAND REGISTER MAP (16)
95 REM 000=NO PARITY
96 REM 1=HALF DUPLEX
97 REM 000=UNUSED
98 REM 0=3-LINE HANDSHAKE
99 POKE 787,PEEK (56):REM STORE MEMSIZ
100 OPEN 2,2, 0,CHR $(6)+CHR$(16):REM OPEN THE RS232 CHANNEL
101 REM COMPARE NEW MEMSIZ WITH OLD VALUE
102 IF PEEK(787)=PEEK(56) THEN PRINT "RS-232 CHANNEL NOT OPEN":END
105 REM
110 GET# 2,A$:REM TURN ON THE RECEIVER CHANNEL (TOSS A ZERO)
190 REM
200 REM MAIN LOOP
210 GET B $:REM GET FROM COMPUTER KEYBOARD
220 IF B$<>"" THEN PRINT# 2,B$;:REM IF A KEY PRESSED, SEND TO TERMINAL
230 GET# 2,C$:REM GET A KEY FROM THE TERMINAL
240 PRINT B $;C$;:REM PRINT ALL INPUTS TO COMPUTER SCREEN
250 SR=ST: IF SR=0 OR SR=8 THEN 200: REM CHECK STATUS, IF GOOD THEN CONTINUE
290 REM
300 REM ERROR REPORTING
310 PRINT "ERROR: ";
320 IF SR AND 1 THEN PRINT "PARITY"
330 IF SR AND 2 THEN PRINT "FRAME"
340 IF SR AND 4 THEN PRINT "RECEIVER BUFFER FULL"
350 IF SR AND 128 THEN PRINT "BREAK"
360 IF (PEEK(673) AND 1) THEN 360:REM WAIT UNTIL ALL CHARS TRANSMITTED
370 CLOSE 2: ENDAt this point, I strongly recommend turning to page 349 of the C64 Programmer’s Reference Guide.
The OPEN command on line 100 opens and configures the RS-232 interface. Parameterization is done via the control register and the command register, two 8-bit values that appear in the fourth position of the OPEN command in the form of CHR$() expressions.
The decimal value “6” (binary %0000 0110) in line 100 results from
0 = 1 stop bit; 00 = 8 data bits; 0 = unused; 0110 = 300 baud
The decimal value “16” (binary %0001 000) in line 100 results from
000 = No Parity; 1 = Half Duplex; 000 = Unused; 0 = 3-line handshake
3-line handshake refers to the RS-232 hardware handshake method using the RTS, CTS, and DTR lines. Interesting enough, this construct is working although DTR (user port E) is not connected. I guess this is because the 2-line handshake using only RTS/CTS for hardware flow control is a standard for some UARTs like the used FT232R. The Commodore computer will simply ignore DTE and just listen to RTS, which we crossed with CTS anyway.
X-line handshake uses the CTS and DSR lines for flow control. DSR (user port L) is also not connected using above cable assembly. So if you select 1 = X-Line Handshake instead of 0 = 3-Line Handshake, data transfer between the PC and the Commodore computer will no longer work. This is not the fault of the FT232R chip in the USB adapter, as it features both DTR and DSR line. It´s just that DTech did not route these two lines out to the pin header. But this is no disavantage, as long as RTS/CTS are available.
The following is a simple process flow chart, explaining how normally a computer (the DTE) sends data over the RS-232 line to a modem (the DCE). As we connected a DTE with a DTE, these lines have to be crossed.
Should the DCE´s receive buffer be full, it would drop (set to low) the RTS line.
When you start above BASIC program, each entered character on the PC is sent to the C64/C128 and output to the screen (via variable C$). Conversely, each entered character on the C64/C128 (via variable B$) is sent to the PC and output on both sides.
This continues until the BASIC program is aborted by the user or the RS-232 interface returns an error. The error code is located in the variable ST („STatus“), see line 250.
In line 360, before the RS-232 interface is closed, memory address 673 (0x2A1) is read. Simply put, this memory address contains the state of the second CIA chip in the Commodore computer, which is responsible for the RS-232 interface. If bit 1 of this address is set, the CIA chip, i.e., the RS-232 interface, is still receiving data from the PC.
4. Sending a binary file from the Commodore computer to the PC
Here is a real use case now: I have a small binary file (“sequential file”, SEQ) called “pv250113.seq” on the file system of the Commodore computer, in which measured values of my photovoltaic system from January 13, 2025 are stored:
2025-01-13 08:00:00 0
2025-01-13 08:10:00 18
2025-01-13 08:30:00 68
2025-01-13 08:40:00 280
2025-01-13 09:00:00 820
2025-01-13 09:10:00 1033
2025-01-13 09:30:00 1285
2025-01-13 09:40:00 1601
2025-01-13 10:00:00 1482
2025-01-13 10:10:00 1513The first column is the date, followed by the timestamp, followed by the yield in kW. At 10:10 a.m., the PV system had generated 1513 kW.
This file should now be transferred to the PC for further processing. A short BASIC program will do this task:
10 REM USE SERIAL LINK TO
20 REM COPY FILE FROM C128 TO PC
30 REM *****************************
90 REM OPEN RS-232 INTERFACE
100 OPEN 2,2, 0,CHR $(6)+CHR$(16):REM OPEN THE RS-232 CHANNEL
110 GET# 2,A $:REM TURN ON THE RECEIVER CHANNEL (TOSS A ZERO)
1000 REM READ PV SEQ FILE AND PRINT
1010 REM TO RS-232 CHANNEL
1100 REM ***
1200 Z$=CHR$(0):REM FOR UNREADABLE CHRS
1300 REM OPEN SEQ FILE READ ONLY
1400 OPEN 5,9,0,"PV 250113,S ,R"
1450 PRINT "DATE ";TAB (11);"TIME";TAB(20);"KW"
1480 REM ANSI CONTROL SEQ. INTRODUCERS
1482 REM ESC IS DEC 27
1490 PRINT# 2,CHR $(27);"[2J"
1500 PRINT#2,"DATE ";CHR $(9);"TIME";CHR$(9);"KW"
1600 REM MAIN LOOP
1610 FOR L=0 TO 1
1700 GET# 5,IN $
2200 L=ABS(ST ):REM L IS > 0 ON ERROR
2205 PRINT IN$;
2210 PRINT# 2,IN $;
2300 NEXT L
2400 CLOSE 5: PRINT# 2,CHR $(13)
3000 CLOSE 2: ENDLine 1490 is interesting. Here, the receiving terminal (the PC) is sent an ANSI Control Sequence Indicator (CSI) with a control command. This is initiated by ESC (Escape, decimal 27), followed by the character string „[2J.“ „ESC [“ is referred to as the CSI. If PuTTY interprets this control command correctly, the screen is cleared.
When you start the program on the Commodore computer, the sequential file containing the measured values is opened and the data is sent byte by byte (bit by bit on the physical line) to the PC. There, the measured values appear in the PuTTY terminal window:
You can now further process the measured values using cut-and-paste. Alternatively, especially with longer files, you might let PuTTY log the „printable characters“ into a file. This allows the data to be transferred „elegantly“ from the Commodore computer to the PC:
Note that the tab character (TAB, CHR$(9)) from the BASIC program, line 1500, is displayed correctly on the screen, but not in the log file!
5. The hardware and logic side of the RS-232 interface
Now let´s cover the internals of the RS-232 interface on the Commodore 64, as documentation with practical implementation examples on the Internet is becoming increasingly scarce. For the Commodore 128, the information can be transferred 1:1; perhaps a different CIA chip (see below) is installed.
For a better understanding, I highly recommend having the digital version of the book Mapping The Commodore 64 at your side as you continue reading. It’s a great way to quickly look up addresses like $DD02 and their functions.
Two 6526 (Complex Interface Adapter (CIA)) chips are installed on the motherboard for input/output operations. For our experiments with the RS-232 interface, the second CIA chip is of interest, providing a serial RS-232 interface with TTL logic via the Commodore user port:
Some of the 6526’s pins are connected directly to the user port, as shown in the image above. RS-232 communication is realized via two data ports, A and B, on the 6526, whose bits (except for the RI bit – Ring Indicator) can be either written or read. In the image above, this is symbolized by the direction of the arrow. These data ports are located in memory (RAM) at addresses $DD00 and $DD01.
The data flow direction is determined by two registers in the 6526: Data Direction Registers A and B, located at addresses $DD02 and $DD03, respectively. To specify that the transmit line TxD at Data Port A is only written and not read, the second bit in Data Direction Register A must be set to „1.“ To specify that the receive line RxD at Data Port B is only read and not written, the zeroth bit in Data Direction Register B must be set to „0“.
In my case, memory address $DD02 contains the binary value 0011 1111, so the second bit is correctly set to „1.“ At address $DD03, I found the value 000 0110. Here, the zeroth bit is correctly set to „0“. Setting the correct bits is done automatically for us i.e. by the BASIC OPEN command, if the device number has the value 2 (the RS-232 interface).
We additionally connected the RxD receive line (user port C) to the FLAG line (user port B). The reason for this is easy to explain: To indicate to the CPU that data has been received, the FLAG line is pulled to zero, which triggers a non-maskable interrupt (NMI). This status can be checked using address $DD0D („Interrupt Control Register“) and its bit 4. A logical one (1) means that the NMI has been triggered. Another option is via address $2A1 („RS-232 Interrupts Enabled“). As soon as you press the return key in the PC’s terminal program, thereby receiving data, bit 1 at address $2A1 changes to a logical one.
Interestingly, the RxD and TxD lines operate with inverted signals. A bit being sent („1“) has a signal level close to 0V, no bits being sent has a signal level of 5V (4,9V says my digital multimeter). The following photo on the left shows the 5V RxD line on the top of the oscilloscope´s screen and the 0V line below. Everytime a bit is being sent over from the PC, the signal drops low:
Each centimeter on the x-axis represents 50 ms. On the right the signal has been traced for better visibility.
Now it’s time to process the data received on the RxD line, for example in BASIC. The BASIC command
OPEN <logical file number>,2,0,<parameter>not only sets the control and command registers by passing the <parameter>, but also initializes the two data direction registers and reserves two 256-byte memory areas at the end of the user data area in memory:
By reserving both memory areas, the maximum available memory for BASIC is reduced by 2*256 bytes. This can be seen by the pointer at address $38, which points to the highest address usable by BASIC minus one:
- Before the OPEN command: $38 = 160 => 160 * 256 – 1 = 40960 = $9FFF
- After the OPEN command: $38 = 158 => 158 * 256 – 1 = 40447 = $9DFF
The memory area for data to be sent is in the address range $9DFF to $9EFE, and the memory area for data to be received is in the address range $9EFF to $9FFF. These two buffers are implemented as „ring buffers“, meaning that each memory area is organized like a ring structure, with the end address connected to the start address.
Each buffer contains two pointers, pointing to the start and end of the current data. The pointer for the start of the sent data is located at address $29C, and the pointer to the end of the sent data is located at address $29B. The pointer for the start of the received data is located at address $29E, and the pointer to the end of the received data is located at address $29D.
For example, I sent the string „XXX“ from my PC to the Commodore computer via the terminal software. Using a memory monitor like SMON, I found the string in the address range $9F35 to $9F37:
The character string is now located in the receive ring buffer, but not at the beginning. The pointer to the start of the character string at address $29E contains the value 54 ($36). $9EFF + $36 = $9F35, which is exactly the address with the first received „X.“ The pointer at address $29D to the end of the received data increments from 54 with each received „X“ and has a value of 56 after three received „X“. Incidentally, the last „X“ is followed by the character $0D (13), which symbolizes the „return“ at the end of the PC input. So finally, $29D will contain the value 57.
The characters received by the RS-232 interface are now assigned to a variable using the BASIC command
GET#<logical file number>, <variable>both pointers $29E and $29D are set to the value 58 ($3A). From now on, the data is considered read from the operating system’s perspective. With $9EFF + $3A = $9F39, the pointers are set to the next available memory location in the ring buffer. $29E = $29D means that no new data has yet been received from the RS-232 interface.
If the PC sends further data on the RS-232 interface, these are continued directly after our “return” ($0D), i.e. from address $9F3A.
In BASIC, it’s important to note that a CLR command is executed after the OPEN command. This means that variables defined before the OPEN command are lost:
10 A=10
20 PRINT “A: “;A
30 OPEN 2,2,0,CHR$(6)+CHR$(16)
40 PRINT “A: “;A
50 CLOSE 2
60 ENDBefore the OPEN statement the variable A is printed as “10”, after the OPEN statement as “0”!
It’s clear that a distinction must be made between data received or sent from the RS-232 interface, and thus from the 6526, and data that is considered received or sent from the operating system’s perspective via PRINT# and GET#. It’s also important to note that the RS-232 interface operates bitwise, but that data sent or received is stored in the two buffers in the form of bytes for easy processing by the user.
6. A small client / server application in assembly code
I’ve decided to write a small sample application in MOS 6502 assembly language. The PC will act as a client to the C64/C128 via the installed serial cable, sending characters to the server (the Commodore computer). The program serves more as a demo than as fully tested software. I’ve well documented the individual code sections, so hopefully, you can quickly conduct your own experiments. The assembly code was created in Turbo Macro Pro (TMP), but can certainly be transferred to other assemblers.
The program is executed by the CPU in the form of machine language starting at address $1000 (4096). Therefore, it can be started from the BASIC prompt with the command “SYS 4096”:
*= $1000
; open rs-232 serial channel and read
; in bytes until x pressedAt the beginning, all entry addresses for system calls are defined. For this purpose, the recommended, fixed addresses of the ROM jump table are used almost consistently:
; define kernel system calls
chkin = $ffc6; set input channel
chkout = $ffc9; set output channel
close = $ffc3; close logical file
clrchn = $ ffcc ; set default i/o dev
chrin = $ ffcf ; get chr from input dev
chrout = $ffd2; print accu to output
getin = $ffe4; get chr from input dev
linprt = $ bdcd ; print number
open = $ffc0; open logical device
readst = $ffb7; read i/o status
setnam = $ ffbd ; set filename params
setlfs = $ ffba ; set log file no…
strout = $ab1e; print stringNext, there’s a switch that determines whether you want to output certain debug information. If the switch is set to „1“ rather than „0,“ a short text block, which will be explained later, will be output each time you press the „D“ key.
debug = 1The character set is then set to “lower / uppercase”, the screen color and border are set, the screen is cleared, and a welcome message is displayed on the screen.
; lower/uppercase chr set
lda $d018
ora #%00000010
sta $d018; setup screen
lda #6 ; blue
sta $d 021 ; background color
sta $d 020 ; border color
lda # 147 ; clear screen
jsr chrout
lda #<welcome
ldy #>welcome
jsr stroutNow the RS-232 interface is parameterized and then opened.
; 6551 control register
; set 8n1, 300 baud
lda #%00000110
sta $0293
; 6551 command register
; set no parity, half-duplex, 3 line
lda #%00010000
sta $0294
; set logical file number
lda #$ 02 ; log file no.
ldx #$ 02 ; dev no.
ldy #$ 00 ; sec address
jsr setlfs
; set filename parameters
lda #$ 00 ; no filename
jsr setnam
; open RS-232 channel
jsr openHow do we know that the RS-232 channel really has been opend? In our BASIC program, we checked for changes in MEMSIZ before and after the OPEN command. This doesn’t work in assembly language. Checking RIBUF doesn’t work either, because the buffer is always created, even if there’s no serial interface or, for example, the serial cable isn’t connected. In BASIC, I haven’t even been able to generate the BASIC error message „DEVICE NOT PRESENT.“. In assembly code, we check bit 6 (CTS) of data port B ($DD01). If CTS is low, the Commodore computer is neither ready to send nor receive data, so something is wrong with the RS-232 channel.
; test data port b if channel is open
lda $dd01
and #64 ; test 6th bit
cmp #64 ; which is CTS
beq errorThis can be easlily tested: $DD01 will contain the value 191 (%1011 1111) if everything with the RS-232 channel is OK. If we unplug the serial cable, the value changes to 255 (%1111 1111). As one can see, the 6th bit representing the CTS line changed from „1“ to „0“.
Now comes the main loop. In this loop, a byte is read from the RS-232 interface (or rather, from the buffer). Then, as an example for error handling, bit 2 (%0100 = 4) of the status register is tested for a receiver buffer overrun. If this occurs, the program branches to an error routine. A character is then read from the keyboard buffer into the accumulator. If the user presses the „X“ key, the program terminates. If the user presses the „D“ key, a debug message is displayed on the C64/C128 screen.
loop
; get byte from rs-232 channel
ldx #$ 02 ; rs-232
jsr chkin
jsr getin
jsr chrout
jsr clrchn
; test status reg for buffer overrun
lda $0297
and #4
bne error
; get a character from keyboard
jsr getin
cmp # 68 ; d key pressed?
beq sdebug
cmp # 88 ; x key pressed?
bne loop
close
; close RS-232 channel
lda #$02
jsr close
rts ; return to basicThe very rudimentary error handling follows:
error
lda #< errormsg
ldy #> errormsg
jsr strout
jmp close ; end programFollowed by the code for the debug message:
sdebug
lda #13
jsr chrout
lda #<d1
ldy #>d1
jsr strout
lda $ 0297 ; 6551 status reg
ora #48
jsr chrout
lda #13
jsr chrout
lda #<d2
ldy #>d2
jsr strout
ldx $029 c ; start rec buffer
lda #$00
jsr linprt
lda #13
jsr chrout
lda #<d3
ldy #>d3
jsr strout
ldx $029 b ; end receive buffer
lda #$00
jsr linprt
lda #13
jsr chrout
lda #<d4
ldy #>d4
jsr strout
ldx $ 38 ; end of user ram
lda #$00
jsr linprt
lda #13
jsr chrout
jmp loop
d1 .text "6551 status register "
.null "at address $297: "
d2 .text "rs-232 start "
.null "receive buffer $29c: "
d3 .text "rs-232 end "
.null "receive buffer $29b: "
d4 .text "pointer to end of "
.null " basic ram: "Finally, the missing strings for the screen output:
errormsg .null "An error occured!"
welcome. text "terminal ready"
.byte 13
.text "waiting for input from "
.null " serial line : "
.endIf you start the program on the Commodore computer and have a connected terminal program running on the PC, then the characters typed on the PC
will appear on the Commodore screen. However, the welcome message “terminal ready, waiting for input from serial line:“ is shown first:
After each „return“ from the PC, I pressed the „d“ key, which resulted in the debug message. After the third input, I exited the program with „x“ and received the „ready.“ prompt from BASIC again.
The debug message isn’t pretty, but it does tell you a little about the status of our serial connection to the PC. The first line with the value 8 is the value of address $297 (RSSTAT). The set bit 3 results in the value %1000 (8) and means „Receive Buffer Empty“. It sounds strange at first, but it makes sense when you know that the sent characters (like “hello from your pc“) have already been read from the buffer using the GETIN function. The fact that the buffer pointer is constantly being moved can be seen at addresses $29c and $29b. After the „hello from your pc”, both the start and end pointers are set to the value 190. After fetching the character “1” (followed by a null termination), both pointers are shifted two places further to 192 (“1” plus $00). The same happens after fetching the character “2”. Now both pointers are set to the value 194.
The pointer at address $38 (MEMSIZ) to the end of the RAM is at 121. This means that the last available address in RAM is 121 * 256 – 1 = 30975 ($78FF). To understand this, you need to know the following: If you start a C64 or C128 in C64 mode and receive the BASIC prompt, address $38 still has the value 160: 160 * 256 – 1 = 40959 ($9FFF). If you now load the TMP v1.2 assembler into memory (RAM), you will find the reduced value 121 at address $38: 121 * 256 – 1 = 30975 ($78FF). TMP has therefore reserved memory space in RAM starting at address $78FF to accommodate the user’s assembly code. The entry address for TMP itself is located at address $8000.
It would now be relatively easy to further develop the code and build a true client / server application: the PC sends a command like “clear” via a terminal program and serial cable to the Commodore computer. The Commodore reads „clear“ from the receive buffer, interprets it as a command to itself as the server, and executes the following simple code to clear it´s screen:
lda # 147 ; clear screen
jsr chroutThis project was a lot of fun to do and in the end, I spent very little money for the required hardware. I do not consider the project complete, as I am still writing software in MOS 6502 assembly code for it.