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

[BruceMcF 295]

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".

[TheUnknownDad 5]

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.

[BruceMcF 295]

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.

 

[Cyber 141]

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.

[BruceMcF 295]

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.

[kelli217 45]

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.

[rje 235]

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 February 15 by rje

[Lorin Millsap 194]

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

[TomXP411 358]

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/

 

[rje 235]

Yes, I figured I can't just connect these two critters pin-to-pin.  Even on the Pi it's not recommended (read: dangerous).  Thanks for the level shifter link, Tom!

[rje 235]

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 March 3 by rje