Jump to content

Device #2 for Serial I/O?


rje
 Share

Does Device #2 seem right for Serial I/O?  

2 members have voted

  1. 1. Does Device #2 seem like the right place for a Serial I/O device?

    • Yes
    • No
      0
    • No!! (For a VERY GOOD REASON) (specify)
      0
  2. 2. Alternately, which device number would you prefer?

    • Something above 11 (specify)
    • A range, such as 12-15 (specify)
    • A very high number, like 200 (specify)
    • A very high number range, like 200-204 (specify)
    • Custom / neither device number nor Kernal I/O patch (specify)
    • I prefer a completely different approach BECAUSE (specify)

This poll is closed to new votes

  • Please sign in or register to vote in this poll.
  • Poll closed on 06/18/21 at 05:20 AM

Recommended Posts

I was idly thinking about writing a game that could interact with other players via a server.

So, serial I/O via a card attached to the User Port or *wherever*.  Maybe a modem, or ethernet, or heliograph, or carrier pigeon.  Just thinking about it, and how it might be nice to abstract that protocol into the existing KERNAL I/O.  A driver to patch the lines, and custom handler code (probably a lot of code on the card itself).  That sort of thing...

...but to make programming easier, it seems right to allocate a device number for that I/O channel.

On the C64, the RS-232 interface was Device #2.

Seems the right place to start here, as well.

Edited by rje
Link to comment
Share on other sites

I see no reason why we could not use #2. If we have to use something different, I was thinking that we might as well choose something that is recognizable from other platforms such as the PC, like $3F8. Only after I submitted my answer, I realized that we probably only have a single byte for the ID. 😳

Edited by JimmyDansbo
Link to comment
Share on other sites

  • Super Administrators

of course, it will be #2. 

Back in the Commodore days, it was #2, and even if users added a Swiftlink (which used a 6551 ACIA), the new 6551 serial port was still accessed via port 2. The Swiftlink cartridge provided a ROM update that replaced the User port serial code with code on the cartridge. 

So add-on serial ports could either patch the KERNAL or provide their own routine in Golden RAM or in a bank at $A000

For example: 

$400 : Port number (for multi-port cards)
$401 : bytes waiting in read buffer on UART
$402 : bytes waiting in write buffer on UART
$403 : flow control state
$404 : data to send
$405 : 1 if byte was read in last call, 0 if no data received
$406 : last byte read

And the read/write routines at $410, $440, and so on:
$410 : Update status registers
$413 : Send a byte 
$415 : Read a byte

So BASIC code would look like:
Send a byte: POKE $404 : SYS $413
Read a byte: SYS $415 : IF PEEK(405) > 0 THEN A$=CHR$(406)
Check the modem status: SYS 410 : S = PEEK($403)


 

Edited by TomXP411
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use