Jump to content

What's the state of play with serial port support?


BruceMcF
 Share

Recommended Posts

23 minutes ago, TheUnknownDad said:

I would try to splitt that apart into two aspects: Installing and using.

I want to make sure that everyone can do both. Many of my questions above in the discussion with Lorin are pointing to the "install" part. I am a strong believer in ease of use. I don't doubt, that getting an autoload program from SD is technically the best solution (as long as it then manages things like installing BASIC extensions & stuff like that).

How will the "setup" programm  get on the SD card? What does the user need to decide and what does he need to know to use the expansion card? My way of looking at things is to hide all technical aspects but not to make them unavailable. Meet people at their specific level and give them the opportunity to evolve further by digging deeper - but only if they want to.

That will be however the autoloaded program does it, isn't? Those are all important problems for an autoload program to solve, but if an autoload program has problems solving them, "write a better autoload program" seems to me to be a lot more effective response than "make massive changes to the hardware architecture".

Link to comment
Share on other sites

8 minutes ago, BruceMcF said:

That will be however the autoloaded program does it, isn't? Those are all important problems for an autoload program to solve, but if an autoload program has problems solving them, "write a better autoload program" seems to me to be a lot more effective response than "make massive changes to the hardware architecture".

That is totally true.

I wasn't initially asking for hardware architecture change. I was asking for details on how that whole expansion system is supposed to work. I already stated that I am desperately looking for information on the whole process of booting and integration von expansion cards in that process.

Hardware changes are only valid in two cases: 1. something is impossible to realize in software only; 2. things are really, really complicated to solve in software and would be easy with very little change to the design.

I hope too, that both reasons are no longer valid.

Link to comment
Share on other sites

On 1/8/2021 at 11:37 PM, TheUnknownDad said:

That is totally true.

I wasn't initially asking for hardware architecture change. I was asking for details on how that whole expansion system is supposed to work. I already stated that I am desperately looking for information on the whole process of booting and integration von expansion cards in that process.

Hardware changes are only valid in two cases: 1. something is impossible to realize in software only; 2. things are really, really complicated to solve in software and would be easy with very little change to the design.

I hope too, that both reasons are no longer valid.

The BASIC interpreter is much less set in stone than the memory map ... if it can be done at the keyword level. DEC Basic was not modular at all when Bill Gates "borrowed" it's design for 8080 Basic, and MS 6502 Basic was a port of 8080 Basic, so structural changes can be a major challenge, but adding a keyword is much more straightforward. So I would hope a main config file loading keyword can be devised that allow loading regular programs without the current problem of the subprogram overwriting the main program.

Then the main program could be a program that reads a filename from a sequential file, loads and runs it. The subprogram runs the config program again, it reads the second filename from the file and runs it. And so on until the end of the file of filenames. Interspersed are section names in some distinctive format which the master config program ignores and grabs the next name .

Then a utility to edit the list of filenames and insert the name of the config program(s) in the section(s) that they belong in, based on an .INFO file, which is run to install the drivers into that list of filenames.

 

Link to comment
Share on other sites

On 1/8/2021 at 3:19 PM, TheUnknownDad said:

isn't installing drivers something we love to not have needed "back then"?

I loved this driverless approach in the past, despite it being primitive and obsolete in modern world. And I'm happy that X16 brings back this experience.

  • Like 2
Link to comment
Share on other sites

1 hour ago, Cyber said:

I loved this driverless approach in the past, despite it being primitive and obsolete in modern world. And I'm happy that X16 brings back this experience.

Quite. Installing drivers into the Kernel API is entirely optional. That is a bit of a shift in mindset to get used to for people who came up after drivers became mandatory to get any hardware to work on a system.

In thinking the process of installing drivers into the Kernel API through, it can be a little hard coming up with a lot of examples of things I would want to handle that way. I can see wanting to have drivers for a serial card, if I happened to have one, and maybe if a parallel port interface to a PC is designed to emulate a drive. I'm not sure how many more I would want to have installed. So maybe one or two.

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

I remember when application programs had to handle support for different hardware on their own. 😮

Word processors came with a disk of printer drivers, games on the PC asked you what kind of video card you had. Nothing was taken for granted, and there was no standard driver interface.

I am not at all opposed to a terminal program asking me whether I have a SuperLink, a MondoSerial TL, a 68B50RS232 Junior, or the native hardware, and then adjusting its capabilities and menu options accordingly.

  • Like 2
Link to comment
Share on other sites

I think as long as I/O isn't too difficult to figure out then I can write my own transfer programs.

For me, the tricky part is with the electronics.  I would need to connect GPIO pins on the X16 to the GPIO pins on a Raspberry Pi Zero.  Assuming I didn't fry either board in doing that, then I think I'd be ok. 

Maybe.

 

Edited by rje
Link to comment
Share on other sites

I think as long as I/O isn't too difficult to figure out then I can write my own transfer programs.
For me, the tricky part is with the electronics.  I would need to connect GPIO pins on the X16 to the GPIO pins on a Raspberry Pi Zero.  Assuming I didn't fry either board in doing that, then I think I'd be ok. 
Maybe.
 

If the Pi has 5v tolerant IO it will work directly. If they are 3.3v only then you will need to use transceivers to shift the voltage.


Sent from my iPhone using Tapatalk
Link to comment
Share on other sites

30 minutes ago, Lorin Millsap said:


If the Pi has 5v tolerant IO it will work directly. If they are 3.3v only then you will need to use transceivers to shift the voltage.


Sent from my iPhone using Tapatalk

The Pi's GPIO pins are NOT 5v tolerant. You will need a level shifter. 

You can use a level shifter hat, like this one:
https://www.tindie.com/products/chris_wag/rpi-level-shifter-hat/

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

  • 3 weeks later...

Lorin says:

Quote

Ok. So just to sum up where the RS232 serial (not to be confused with the IEC serial) is at, it is implemented as part of the user port and is implemented via one of the 65c22 chips. A lot of that is not set in stone as the routines haven’t been written yet. But that is the functional RS232 serial on the main board.

I/O Use cases:

  1. Loading a file from a modern computer into X16 RAM somewhere.
    • The Burrito Principle* suggests that ideally this is a single-step operation.
    • The existing RS-232 connection could be suited for this.
  2. Saving data somewhere on the X16 to a file for later reference.
    • RS-232 and IEC devices are two ways to fill this niche.
  3. Streaming data off of the X16 to an output channel thing.
    • Fun and interesting.
  4. Streaming data into the X16 somehow.
    • Fun and interesting.

Sounds like we're talking about the #3 and #4 there.  Are we targeting a particular solution?

* 80% of the meat is in 20% of the burrito.  My way of co-opting the Pareto Principle.

By "single-step operation", I mean ideally you could load a file, off of a connected modern computer, to the X16 with:

LOAD "MYFILE.PRG",2       :rem or whatever device #

and

LOAD "MYDATA.BIN",2,1,$A000

and of course

DOS"$",2

Edited by rje
Link to comment
Share on other sites

  • 2 months later...

Hi all, my first post there, I thought I'd just jump in.

There's a bunch of usecases for a communications port. One would be to use remote storage. Not sure if that is very compelling with the on-board and pretty much infinitely big SD card. Another use is to get stuff on and off the X16, like a download. But also: direct communication, such as logging in to a BBS, or multiuser gaming.

For all of those except for using a remote file server a serial port would work really well.

A serial port is also simple enough that less experienced programmers can work with it.

That also applies on the modern computer side: either those still have a serial port or usually one can be added without having to install a driver (which is getting harder every year on MacOS...), and interfacing with the serial port can be entirely done by a "userland" program without special privileges. So it would be easy to write software for Windows, Linux, MacOS that will transfer files back and forth with the X16, and/or make network connections on behalf of the X16.

So it's really too bad that a serial port isn't included in the current X16 design. I expect that as the X16 gets out in the world, the lack of a way to interface with the rest of the world will be a big bottleneck, something that you don't really notice with the emulator.

Link to comment
Share on other sites

Hi all, my first post there, I thought I'd just jump in.
There's a bunch of usecases for a communications port. One would be to use remote storage. Not sure if that is very compelling with the on-board and pretty much infinitely big SD card. Another use is to get stuff on and off the X16, like a download. But also: direct communication, such as logging in to a BBS, or multiuser gaming.
For all of those except for using a remote file server a serial port would work really well.
A serial port is also simple enough that less experienced programmers can work with it.
That also applies on the modern computer side: either those still have a serial port or usually one can be added without having to install a driver (which is getting harder every year on MacOS...), and interfacing with the serial port can be entirely done by a "userland" program without special privileges. So it would be easy to write software for Windows, Linux, MacOS that will transfer files back and forth with the X16, and/or make network connections on behalf of the X16.
So it's really too bad that a serial port isn't included in the current X16 design. I expect that as the X16 gets out in the world, the lack of a way to interface with the rest of the world will be a big bottleneck, something that you don't really notice with the emulator.

A user port certainly is a serial port. What we aren’t including is a UART or a modem which would allow faster transfers. The user port could also certainly be used as a parallel transfer instead of serial, so with the right interface you could still get respectable speeds.


Sent from my iPhone using Tapatalk
  • Like 1
Link to comment
Share on other sites

I remember that the C64 could do 2400 BPS bit banging the user port. The X16 is 8 x faster, so that should translate into 19200 (and the fact that the VIC-II isn't there to steal 1/8th of memory cycles when drawing the screen should make that easier). So that's not entirely pathetic, but you'd still need a special connector and some electronics to boost the TTL signal to RS232 levels.

All simple enough, but still an important barrier that will make sure that only a small minority of users will ever use this.

We'll see how this works out in practice.

Link to comment
Share on other sites

Posted (edited)
13 hours ago, ZeroByte said:

Yaknow, a user port device that presents  the X16 file system as a USB stick would be cool. Run a bridging application on the X16 and then just drag and drop files on your PC.

If the RPi pico can be a USB master, it seems like it should be able to be a smart USB peripheral, so once a UserPort parallel protocol is working between the Pico and the CX16, it seems doable by that route.

But a widget that presents a USB flash stick as Device #11, with the right Kernel API support, that'd do me.

Edited by BruceMcF
Link to comment
Share on other sites

Posted (edited)
12 hours ago, iljitsch said:

I remember that the C64 could do 2400 BPS bit banging the user port. The X16 is 8 x faster, so that should translate into 19200 (and the fact that the VIC-II isn't there to steal 1/8th of memory cycles when drawing the screen should make that easier). So that's not entirely pathetic, but you'd still need a special connector and some electronics to boost the TTL signal to RS232 levels.

All simple enough, but still an important barrier that will make sure that only a small minority of users will ever use this.

We'll see how this works out in practice.

I don't see that "tick the serial user port option" on the CX16 order would be an important barrier. Nor a similar "tick the parallel user port option". So I think that is a preventable or fixable problem. (depending, respectively, on whether they do that from the outset or figure out that they should do that as they go). 

IIRC, translating voltage between +5V and +12V is real easy when you have a +12v rail. You only need that MAX chip that charges capacitors up to 12V if you don't have a 12V power supply available.

Edited by BruceMcF
Link to comment
Share on other sites

14 hours ago, Lorin Millsap said:


A user port certainly is a serial port. What we aren’t including is a UART or a modem which would allow faster transfers. The user port could also certainly be used as a parallel transfer instead of serial, so with the right interface you could still get respectable speeds.


Sent from my iPhone using Tapatalk

 

FYI: I've already done some simulations in the emulator, and I can send around 750 bytes a second in BASIC using raw transfer routines in the 6522. (ie: Set the data lines and cycle the clock line using POKE statements.)

In assembly language, if we send one byte per 100 clock cycles, which is totally reasonable, we should be able to send 80KBps. So if we were to integrate parallel I/O routines into the KERNAL, it's possible that using a PC, Pi, or Arduino for file storage would actually be faster than the internal SD card. 

 

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