Generally the
only port I trust is console. and I can easily transfer files
to any system that uses
a serial console because of that.
I'm not quite understanding that statement. How can I use console if I
need to interact with the keyboard and see output? Wouldn't that prevent
interaction with the emulated machine? How would I tell the emulator that
console is the file input? There's just not quite enough in the docs for
me to form a coherent picture of how things fit together. The sample
config files look like they connect the emulator serial ports to real
serial hardware on the PC, but I see no explanation for how files get
assocated with the emulated UART - only that it's the default to have
files connect to N* AUX (and, as mentioned, I'm only guessing that the AUX
port I/O associates with CP/M PUN: and RDR:).
What Allison is saying is that the console is the only interface that you can
rely on (otherwise the system doesn't work) - anything else may or may not be
implemented by the particular BIOS that you are using. I'll add that you can
only rely on the console to transfer printable ASCII characters and a few
common control characters.
In the "good ole days" you would read a paper tape on an ASR33 (ASCII teletype
with integrated tape reader) by doing: PIP MY.FIL=CON:
and then start the reader - it would "type" the content of the tape into the
file and when it was done, you typed control-Z to send the EOF character,
PIP would write the file and return to the command prompt.
With more modern equipment, you can replicate this behaviour with a TTY
program on a PC that supports ASCII upload - you execute whatever command
on the target system you need to accept the data from the console, then
tell the TTY program to send the ASCII file (and press ^Z at the end if
needed) - same idea.
I'm not sure if you are taking about my simulator or not, but if you are,
then the default config is that the console serial port communicates with
the PC keyboard/video display, and the secondary serial port communicates
with mounted files. The simulator is however VERY flexible in it's I/O
configuration, and you can set up pretty much any type of virtual UART you
would like at any address you like and it can communicate with kbd/video,
mounted files or real serial ports. You can also map simple I/O accesses
into the PC address map to access non-uart devices if you like.
I provide sample "command option" files with the I/O configuration options
needed to direct the secondary virtual 8251 serial port to COM1, and also
to direct the primary 8251 serial port (console) to a PC com port.
The update that I posted today has an addtional feature that for the virtual
uart that you have configured to talk to the PC keyboard and video (normally
the console), you can mount a "reader file" which acts just like a paper tape
being read into an ASR33 - it gets "typed" into the console. This will let
you PIP files into the system with only the console device working. It has an
advantage over serial console/TTY emulator in that the reader-file is
automatically synced to the I/O requests made to the virtual uart - so no
risk of overrun if the system get busy accessing the disk etc.
Btw - the simulator can only control what Z80 virtual I/O addresses and bit
patterns map to data/status reads/writes with physical hardware on the PC -
it does not control how the CP/M devices are mapped to that virtual I/O...
That is controlled by the BIOS of the CP/M implementation you are using.
In this case, the simulator provides access to mounted files via the secondary
UART, however the CP/M BIOS apparently does not provide a driver to read from
that device.
Dave
--
dave09 (at) Dave Dunfield
dunfield (dot) Firmware development services & tools:
www.dunfield.com
com Classic Computers:
http://www.classiccmp.org/dunfield/
