20 Apr
2010
20 Apr
'10
2:01 p.m.
Steven Hirsch wrote:
Use a PC modem(terminal emulator) program as the console.
Inside the modem(terminal emulator) progam you talk to the CP/M system
and can issue command and then
On Tue, 20 Apr 2010, allison wrote:
NS*dos is a different animal. That says teh port works but the CP/M
implementation you
are using may have all or no support for AUX and generally RDR: is a
pretty useless
IO as it's a wait till char ready loop and there is usually no way to
escape that from the console
as the OS (actually bios) is in a state where the console is not being
looked at, ever!
See if you can find UP and DOWN which are trivial programs to transfer
files and it was
nominally supplied with the Apple Softcard (Z80 for apple ][) but by
changing a few bytes
in the IO works with anything.
Steven Hirsch wrote:
There's nothing in the help or docs that really explains where the AUX
port input and output appear under CP/M, so I just assumed (probably
incorrectly) that the input became RDR:. I know under N*DOS I can
print to 1 (from memory) and have it spool to the file, so things on
the emulator side work fine - at least in that direction.
On Mon, 19 Apr 2010, Dave Dunfield wrote:
Is anything actually hooked up to the reader?? This is both a
software question and hardware. You can transfer files via serial port, using
PIP, XMODEM etc.
At the most basic level, you can transfer a index hex file load and
save
it.
You can also use my simulator to transfer files into and out of
images,
and then use NST to transfer those images to the real system. This may
be easier than hooking up serial lines etc.
You can "mount" files for input/output over the virtual serial
port. This
means you can mount a file then receive from it into CP/M just like
you
would have done with an external PC and TTY emulator (but without the
syncronization problems).
Maybe I'm just being dense, but I cannot seem to get this working.
I hit F3 to stop, then F7 whereupon I mount the input file. Then I
'g' back to CP/M and try:
A>PIP B:TEST.HEX=RDR:
At this point it just hangs and will not respond to Ctrl-C. If I
reboot the emulator I find an empty TEXT.$$$ file on the target disk.
In the debugger, it is simply looping on the UART status register
but apparently never seeing anything.
I'm not using a config file, which I believe makes the default 'file'.
What am I doing wrong?
Steve
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:).
from inside the modem program you can send ascii
strings hex files or
what ever.
The idea being you can type CP/M commands or the program can down load
ascii or hex files(cut and paste!)
and the CP/M system will have no clue if you typed it or the modem
program did.
With that there are two caveats, the modem program must do character
pacing as the CP/M system
may get behind and loose stuff. This is especially true if it started
writing to disk, NS* CP/M cannot
write a disk and poll the terminal IO.
You use this optimally _once_ to get a more sophisticated CP/M terminal
program going like mdm7,
Kermit or similar running on the CP/M side. Then if you do the
programming you can talk to another
system via the second serial port with the program staying in control.
And yes everything you nominally expect a PC and do will not happen on a
CP/M system
as often the programming or other resources are not there to do things
like read a port
and write to disk as the same time. Often this means knowing how the
software and hardware
interact and what can be done and what has to be programed around.
The generalized CP/M user manuals are good to start but often the
specific BIOS implementation
is where you need docs or study that usually means getting down to ASM.
The good news
is when you get to a certain point and understand how the BIOS and CP/M
interact and what
is available and how it works in your installation it becomes much easier.
Yes, I'm very confused :-)
Understood. PCs made life severely easy.
As someone that still builds and programs from the ground up on Z80 and
using CP/M
and also doing embedded systems a lot of this working near the iron is
second nature.
Allison
Steve