Transfer files to/from N* CPM image?
ajp166 at verizon.net
Tue Apr 20 16:01:32 CDT 2010
Steven Hirsch wrote:
> On Tue, 20 Apr 2010, allison wrote:
>> Steven Hirsch wrote:
>>> On Mon, 19 Apr 2010, Dave Dunfield wrote:
>>>> 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
>>>> You can also use my simulator to transfer files into and out of
>>>> 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
>>>> 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?
>> Is anything actually hooked up to the reader?? This is both a
>> software question and hardware.
> 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.
NS*dos is a different animal. That says teh port works but the CP/M
are using may have all or no support for AUX and generally RDR: is a
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.
>> 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:).
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
from inside the modem program you can send ascii strings hex files or
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
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
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
and also doing embedded systems a lot of this working near the iron is
More information about the cctech