PDA

View Full Version : Serial Port Programming



dmemphis
January 3rd, 2015, 01:50 PM
Spend some time in search engines looking for information on how to
write software for the serial ports of computers running CP/M.
I may want to write some demos that do things with the serial ports.
Serial ports aresupported by MBasic I find out.
I take it perhaps the serial ports are not standardized... whats it take to do it
another version of basic? a library? Pascal or C?
Looking for some recommendations, thanks.

RickNel
January 4th, 2015, 03:28 AM
The CP/M official documentation is freely available from many sources and tells you everything you want to know, though you also need to know what UART you are programming. If you have a working CP/M system, then MBasic can program the ports using the built-in CP/M hooks, and the methods are also set out in MBasic documentation.

If you want to run things natively in CP/M, then you will find it much better to work with 8080 Assembly language and one of the many assemblers/loader/debuggers. Assembly is the language of the CP/M customisation sources and compiles to the fastest machine language for 8080 (or Z80).

Rick

Chuck(G)
January 4th, 2015, 09:23 AM
Serial ports are not officially supported as such, but they can be made to work through the IOBYTE mechanism. In fact, there's no particular requirement to support anything but console I/O in CP/M.

Most CP/M serial comm programs program serial ports directly, not involving the CP/M API at all.

JDallas
January 4th, 2015, 06:58 PM
...I take it...serial ports are not standardized....

You don't have to write a special BIOS for each application program.

CP/M offers a standardized means of transferring data between all application programs and the host's serial port. It doesn't require any specific serial chips, interface code, or circuit design. CP/M imposes a few requirements concerning which values are passed in which register and how to invoke a particular portal function.

CP/M's BIOS section contains all the unique code tailored for the host design. For a particular serial port chip, the BIOS will have a section that will initialize that chip, and other sections that will move communications data to and from the chip through CP/M to all application programs.

So generally speaking, MBasic will use the same BIOS code through CP/M to use the serial port that Pascal or C or other application programs will use.

dmemphis
January 6th, 2015, 01:12 PM
Thanks for the pointers.
Help me get a little further...


Serial ports are not officially supported as such, but they can be made to work through the IOBYTE mechanism. In fact, there's no particular requirement to support anything but console I/O in CP/M.

Most CP/M serial comm programs program serial ports directly, not involving the CP/M API at all.

Hmmm. I can believe it. but then they weren't portable so you had to do something to make the program
work on different machines.. Like I saw Kermit gets assembled from pieces for a particular machine.
(That was a bad part of CP/M that certainly made moveing to the IBM platform attractive...)

CP/M offers a standardized means of transferring data between all application programs and the host's serial port. It doesn't require the choice of serial chips, its interface code, or its circuit design to be standardized. CP/M imposes a few requirements concerning which values are passed in which register and how to invoke a particular portal function.

CP/M's BIOS section contains all the unique code tailored for the host design. For a particular serial port chip, the BIOS will have a section that will initialize that chip, and other sections that will move communications data to and from the chip through CP/M to all application programs.

So generally speaking, MBasic will use the same BIOS code through CP/M to use the serial port that Pascal or C or other application programs will use. You don't have to write a special BIOS for each application program.

Can you point me to any examples?
I thought maybe AUX could be assigned via CPM to the serial port (or visa versa) and BIOS calls to
AUX char calls could be done. Of course this is probably a performance problem...