17 Apr
2010
17 Apr
'10
3:14 p.m.
I found what purports to be a diskdef for cpmtools, but am not having any
success at all. The file _appears_ to copy into the image and I can read
it back out uncorrupted with cpmtools, but when I write it to a disk with
Dave Dunfield's NST and boot it, the file is filled with E5s.
I did note the diskdef is for 70 tracks (double-sided) and tried changing
the track value to 35. No luck.
I'm trying to move the Morrow HD format/test utility to a diskette that
can be accessed from my N* CPM 2.2 boot diskette, but so far it's "Can't
Get There from Here..".
I'd try a comm program, but guess what I don't have on an N* diskette?
:-).
Steve
--
18 Apr
18 Apr
10:24 a.m.
Have you considered using the serial line to a PC as terminal (I prefer
Procomm or VTcom)
and transfering an ascii file of a simple file transfer utility using
PIP as in PIP foo.txt=con:?
If you can pip text across you can pip a source for simple transfer
utility and do it via serial
line rather than trying to create disks.
Allison
Steven Hirsch wrote:
I found what purports to be a diskdef for cpmtools,
but am not having
any success at all. The file _appears_ to copy into the image and I
can read it back out uncorrupted with cpmtools, but when I write it to
a disk with Dave Dunfield's NST and boot it, the file is filled with E5s.
I did note the diskdef is for 70 tracks (double-sided) and tried
changing the track value to 35. No luck.
I'm trying to move the Morrow HD format/test utility to a diskette
that can be accessed from my N* CPM 2.2 boot diskette, but so far it's
"Can't Get There from Here..".
I'd try a comm program, but guess what I don't have on an N* diskette?
:-).
Steve
19 Apr
19 Apr
5:46 a.m.
I found what purports to be a diskdef for cpmtools,
but am not having any
success at all. The file _appears_ to copy into the image and I can read
it back out uncorrupted with cpmtools, but when I write it to a disk with
Dave Dunfield's NST and boot it, the file is filled with E5s.
I did note the diskdef is for 70 tracks (double-sided) and tried changing
the track value to 35. No luck.
I'm trying to move the Morrow HD format/test utility to a diskette that
can be accessed from my N* CPM 2.2 boot diskette, but so far it's "Can't
Get There from Here..".
I'd try a comm program, but guess what I don't have on an N* diskette?
:-).
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).
Another way to transfer files into the simulator is to halt the simulation,
then use the simulator 'L'oad command to load an image into memory, then
restart the simulation and save it with CP/M.
Regards,
Dave
--
dave09 (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Classic Computers: http://www.classiccmp.org/dunfield/
6:58 p.m.
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 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
--
20 Apr
20 Apr
6:20 a.m.
Steven Hirsch wrote:
On Mon, 19 Apr 2010, Dave Dunfield wrote:
Is anything actually hooked up to the reader?? This is both a software
question and hardware.
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.
Allison
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
8:50 a.m.
On Tue, 20 Apr 2010, allison wrote:
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:).
Yes, I'm very confused :-)
Steve
--
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
11:15 p.m.
I would not be surprised if there was an implementation of MEX or IMP? For
N* with CP/M, don't know about N*Dos. ISTR that 99% of the code is the same
for all systems, just the overlay for the communications ports differed.
There's also Kermit :) a great fallback to have around.
And ISTR there was a configurable XMODEM.COM out there for CP/M
7:58 p.m.
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:). 
10:01 a.m.
If you can load a file into memory, and regain access to the CP/M command
processor, then the SAVE command could be quite useful.
10:14 a.m.
Fred Cisin wrote:
If you can load a file into memory, and regain access
to the CP/M command
processor, then the SAVE command could be quite useful.
His problem is that RDR is a closed loop driver. It sits and spins in a
tight loop until it gets a char, until then the system never sees the
CTRL-C or CTRL-Z.
The solution is to use the serial console to a PC/other running a terminal
program so that you always have control-C test (also CTL-Z needed to
exit pip and write the file.).
Allison
10:25 a.m.
On 20 Apr 2010 at 13:14, allison wrote:
The solution is to use the serial console to a
PC/other running a
terminal program so that you always have control-C test (also CTL-Z
needed to exit pip and write the file.).
I'm assuming that he's at least got DDT. Write some code and be done
with it--8-bit CP/M systems are generally very simple and only rarely
employ anything as involved as interrupt processing.
--Chuck
1:33 p.m.
Chuck Guzis wrote:
On 20 Apr 2010 at 13:14, allison wrote:
Long term the solution was a Xmodem up/down loader for me
so I could use procomm or similar programs on a PC/PDP-11/VAXVMS
as terminal.
The AUX: device thing requires knowing what the BIOS for that system
looks like. I've encountered systems where there was a null driver.
Allison
The solution is to use the serial console to a
PC/other running a
terminal program so that you always have control-C test (also CTL-Z
needed to exit pip and write the file.).
I'm assuming that he's at least got DDT. Write some code and be done
with it--8-bit CP/M systems are generally very simple and only rarely
employ anything as involved as interrupt processing.
--Chuck
1:43 p.m.
On 20 Apr 2010 at 16:33, allison wrote:
The AUX: device thing requires knowing what the BIOS
for that system
looks like. I've encountered systems where there was a null driver.
Sure, it wasn't a requirement to implement it and neither was IOBYTE.
But I assume that technical documentation exists for the UART/USART
that the N* has. By and large, those things are easy to program,
even if one's only tool is DDT. You could certainly do the job with
less.
I'm reminded of the DOS batch files that would create programs with
nothing more than ECHO statements.
--Chuck
21 Apr
21 Apr
4:49 a.m.
Chuck Guzis wrote:
On 20 Apr 2010 at 16:33, allison wrote:
By null I meant if you read RDR: or wrote to PUN: the data would go
to the bit bucket and not to any device.
Allison
The AUX: device thing requires knowing what the
BIOS for that system
looks like. I've encountered systems where there was a null driver.
Sure, it wasn't a requirement to implement it and neither was IOBYTE.
But I assume that technical documentation exists for the UART/USART
that the N* has. By and large, those things are easy to program,
even if one's only tool is DDT. You could certainly do the job with
less.
I'm reminded of the DOS batch files that would
create programs with
nothing more than ECHO statements.
--Chuck
10:05 a.m.
On 21 Apr 2010 at 7:49, allison wrote:
By null I meant if you read RDR: or wrote to PUN: the
data would go
to the bit bucket and not to any device.
Exactly so. If you have, for example, an Amstrad Joyce, there's
nowhere to send or receive the data, as there is no (standard) extra
port. There's a printer, but that's a horse of a different color and
not serial at all.
But I've also seem (and been guilty of one or two) CP/M
implementations that completely ignore implementing IOBYTE, so that
any attempt at redirection using STAT fails. If all you have is a
memory-mapped console display and integrated keyboard and printer,
IOBYTE makes little sense for most applications. I suppose one could
implicitly redirect RDR to the keyboard, again, it makes little
sense.
PIP has a couple of device names that most CP/M implementations are
meaningless (INP: and OUT:) and many others (e.g. UC1:, CRT:) that
are known only to PIP.
--Chuck
3:35 p.m.
Chuck Guzis wrote:
On 21 Apr 2010 at 7:49, allison wrote:
On some it's not there and others not present and that applies
to PRN:, PUN:, RDR:.
On systems I build and play with the BDOS is often a fresh assembly
rather than an old image and the first fix is to make punch and reader
call table handle them as NUL (move data to A and return no error).
That prevents hangs needing reset or a timeout loop in the driver
that takes forever.
By null I meant if you read RDR: or wrote to PUN:
the data would go
to the bit bucket and not to any device.
Exactly so. If you have, for example, an Amstrad Joyce, there's
nowhere to send or receive the data, as there is no (standard) extra
port. There's a printer, but that's a horse of a different color and
not serial at all.
But I've also seem (and been guilty of one or two)
CP/M
implementations that completely ignore implementing IOBYTE, so that
any attempt at redirection using STAT fails. If all you have is a
memory-mapped console display and integrated keyboard and printer,
IOBYTE makes little sense for most applications. I suppose one could
implicitly redirect RDR to the keyboard, again, it makes little
sense.
I've also done that. That means all devices are console
or null.
However I find implement the console portion of IObyte
is handy as that can easily make the console redirectable
at both input and output level. That works well on NS as
there are two SIO and printer(or some parallel thingie.
PIP has a couple of device names that most CP/M
implementations are
meaningless (INP: and OUT:) and many others (e.g. UC1:, CRT:) that
are known only to PIP.
IN and OUT are devices internal to a patch area of pip
and makes it easy to create "pipmodem". The others
the BIOS can work with if IObyte is implmented.
Why do IObyte? Because it makes CP/M IO programatically easy
and sidesteps all of the problems of IO hangs.
Simple file printer:
Get command line
Open file(s) to print
set IObyte console to point to printer device for OUTPUT
transfer file
on EOF reset IObyte to previous setting.
exit.
simple terminal program:
DO
test constat and fetch conin byte if present
flip IO byte
output char to conout
test constat and fetch conin byte if present
flip IO byte and output char to conout
while conin not "CTRL-C"
exit.
The drivers for logical conin, conout and constat can be pointed to the
logical
devices enumerated in the IObyte field bits and an point to one of 4
devices or device combinations, same for Punch, Reader, and LIST
bit fields. This can be controlled from user via STAT. It's easy enough
to create an ASSIGN tool to modify IO byte as well as we are talking
about a single byte at 0003H and maybe in the BIOS if user want it to
remain across boots.
Likely overkill answer but it's often annoying to see CP/M
implementations that
leave out very useful bells and whistles.
Allison
--Chuck
4:03 p.m.
"Chuck Guzis" <cclist at sydex.com> writes:
If you have, for example, an Amstrad Joyce,
there's nowhere to send or
receive the data, as there is no (standard) extra port.
I know third-party serial ports, standard disk drives and so on were
widely available later in the PCW's life, but how was development done
when it first came out? Did Amstrad provide developer-friendly PCWs with
extra hardware to make porting existing CP/M applications easier, or did
development houses have to come up with their own approaches?
--
Adam Sampson <ats at offog.org> <http://offog.org/>
4:44 p.m.
On 22 Apr 2010 at 0:03, Adam Sampson wrote:
I know third-party serial ports, standard disk drives
and so on were
widely available later in the PCW's life, but how was development done
when it first came out? Did Amstrad provide developer-friendly PCWs
with extra hardware to make porting existing CP/M applications easier,
or did development houses have to come up with their own approaches?
I have no idea, but I transfer files by writing the diskettes on a
PC.
--Chuck
6:08 p.m.
On Thu, Apr 22, 2010 at 12:03 AM, Adam Sampson <ats at offog.org> wrote:
"Chuck Guzis" <cclist at sydex.com>
writes:
An add-on extra serial port was one of the 1st peripherals, I believe,
and a simple terminal app was supplied with the system, by the name of
MAIL232.COM (IIRC - I got my PCW as my 21st birthday present, and I'm
now 42, so it was half my life ago...)
--
Liam Proven ? Profile: http://www.linkedin.com/in/liamproven
Email: lproven at cix.co.uk ? GMail/GoogleTalk/Orkut: lproven at gmail.com
Tel: +44 20-8685-0498 ? Cell: +44 7939-087884 ? Fax: + 44 870-9151419
AOL/AIM/iChat/Yahoo/Skype: liamproven ? LiveJournal/Twitter: lproven
MSN: lproven at hotmail.com ? ICQ: 73187508
If you have, for example, an Amstrad Joyce,
there's nowhere to send or
receive the data, as there is no (standard) extra port.
I know third-party serial ports, standard disk drives and so on were
widely available later in the PCW's life, but how was development done
when it first came out? Did Amstrad provide developer-friendly PCWs with
extra hardware to make porting existing CP/M applications easier, or did
development houses have to come up with their own approaches? 
22 Apr
22 Apr
1:50 p.m.
"Chuck Guzis" <cclist at sydex.com> writes:
I don;t know how early iyt came out (relative to the release of the
PCW), but there was an amstrad serial interface module which plugged into
the system bus.
The disk drive was standard -- a standard 3" unit (and the Amstrad PCW --
and Amstrad Z80 machines in general -- were not the only machines to use
that size disk). The disk cotnroler was, IIRC, a standard 765=, the disk
format was a normal-ish MFM one. I suyspect it would be very easy to link
an Amstrad 3" drive (or any other 3" drive -- some of the Hitachi ones
had a 34 pin edge connector with the stnadard pinout) to another machine
and write Amstrad disks on it.
Some to think of it, didn't the CPC6128 pre-date the PCW? It had an
external drive connector which IIRC was a standard 34 pin one. Was there
ever an external 3" srive unit for that machine? If so it would be very
easy to link to another machine.
-tony
If you have, for example, an Amstrad Joyce,
there's nowhere to send or
receive the data, as there is no (standard) extra port.
I know third-party serial ports, standard disk drives and so on were
widely available later in the PCW's life, but how was development done
23 Apr
23 Apr
11:17 a.m.
New subject: Amstrad (Was: Transfer files to/from N* CPM image?
On Thu, 22 Apr 2010, Tony Duell wrote:
The disk drive was standard -- a standard 3" unit
(and the Amstrad PCW --
and Amstrad Z80 machines in general -- were not the only machines to use
that size disk). The disk cotnroler was, IIRC, a standard 765=, the disk
format was a normal-ish MFM one. I suyspect it would be very easy to link
an Amstrad 3" drive (or any other 3" drive -- some of the Hitachi ones
had a 34 pin edge connector with the stnadard pinout) to another machine
and write Amstrad disks on it.
Some to think of it, didn't the CPC6128 pre-date the PCW? It had an
external drive connector which IIRC was a standard 34 pin one. Was there
ever an external 3" srive unit for that machine? If so it would be very
easy to link to another machine.
Amdek sold an external drive unit with two 3" drives. Their advertising
targeted the RS Color Computer. Trivial to connect to most machines with
a "standard" floppy interface.
Amdek also sold an external unit for Apple ][!
Unless it had its own proprietary interface card, then I would have to
assume that that unit had different "logic board". Anybody know?
Was "Amdek" affiliated with Amstrad in any way? Or were the names purely
coincidental?
At one of the Silicon Valley computer swaps (John Craig's "Computer Swap
America"), there were occasional drives for sale. They had "standard"
interfaces, even "standard" data and power connectors, so connecting them
was truly trivial. There were 2-sided drives and single sided "flippy"
drives.
--
Grumpy Ol' Fred cisin at xenosoft.com
2:06 p.m.
New subject: Amstrad (Was: Transfer files to/from N* CPM image?
On Thu, 22 Apr 2010, Tony Duell wrote:
Indeed...
When the 3" drive was going out of fashion over here -- when it was clear
that the 3.5" drive owuld be the standard one -- some companies were
selling off 3" drives very cheaply. I rememebr buying a couple to use as
second drives on my CoCos. IIRC they were Hitachi units with 34 pin edge
connectors and plugged straight in [1].
I also have somwhere a 3" drive that was sold for use on the BBC micro.
Again it was a standard 34 pin interface and would trivially connect to
other machines
[1] Althought I added a little bit of circuitry -- a couple of TTL chips
IIRC -- to allow it to be accessed as either a double-sided drive or 2
separate single-sided drrives. Color TRS-DOS didn't understnad about
dobule-sided drives, so it was easier to treat it as 2 separate drives
under that OS. Of course OS9 had no problems with a double-sided drive.
-tony
The disk drive was standard -- a standard 3"
unit (and the Amstrad PCW --
and Amstrad Z80 machines in general -- were not the only machines to use
that size disk). The disk cotnroler was, IIRC, a standard 765=, the disk
format was a normal-ish MFM one. I suyspect it would be very easy to link
an Amstrad 3" drive (or any other 3" drive -- some of the Hitachi ones
had a 34 pin edge connector with the stnadard pinout) to another machine
and write Amstrad disks on it.
Some to think of it, didn't the CPC6128 pre-date the PCW? It had an
external drive connector which IIRC was a standard 34 pin one. Was there
ever an external 3" srive unit for that machine? If so it would be very
easy to link to another machine.
Amdek sold an external drive unit with two 3" drives. Their advertising
targeted the RS Color Computer. Trivial to connect to most machines with
a "standard" floppy interface. 
27 Apr
27 Apr
3:38 a.m.
New subject: Amstrad (Was: Transfer files to/from N* CPM image?
On Fri, Apr 23, 2010 at 11:17:10AM -0700, Fred Cisin wrote:
On Thu, 22 Apr 2010, Tony Duell wrote:
> The disk drive was standard -- a standard 3" unit (and the Amstrad PCW --
> and Amstrad Z80 machines in general -- were not the only machines to use
> that size disk).
They were, apparently, quite popular in some proprietary navigation
thingy, because they were far more robust than 3.5/5.25 inch disks.
After new disks disappeared from computery shops, you could still get
them for a few years in chandlers' along the east coast of England.
> The disk cotnroler was, IIRC, a
standard 765=, the disk
> format was a normal-ish MFM one. I suyspect it would be very easy to link
> an Amstrad 3" drive (or any other 3" drive -- some of the Hitachi ones
> had a 34 pin edge connector with the stnadard pinout) to another machine
> and write Amstrad disks on it.
Yes. I used to connect a 3" drive to a PC when I needed to transfer
files to/from my CPC 6128. IIRC I told the PC BIOS that it was a 5.25"
drive with a stupidly low capacity and it Just Worked. 22DISK would
happily read and write files.
> Some to think of it, didn't the CPC6128
pre-date the PCW? It had an
> external drive connector which IIRC was a standard 34 pin one. Was there
> ever an external 3" srive unit for that machine? If so it would be very
> easy to link to another machine.
Yes, there was. You could also use 3.5 and 5.25 inch external floppies.
Amdek sold an external drive unit with two 3"
drives. Their advertising
targeted the RS Color Computer. Trivial to connect to most machines with
a "standard" floppy interface.
Was "Amdek" affiliated with Amstrad in any way?
Not AFAIK.
--
David Cantrell | semi-evolved ape-thing
Irregular English:
you have anecdotes; they have data; I have proof
23 Apr
23 Apr
2:39 p.m.
On 22 Apr 2010 at 21:50, Tony Duell wrote:
The disk drive was standard -- a standard 3" unit
(and the Amstrad PCW
-- and Amstrad Z80 machines in general -- were not the only machines
to use that size disk). The disk cotnroler was, IIRC, a standard 765=,
the disk format was a normal-ish MFM one. I suyspect it would be very
easy to link an Amstrad 3" drive (or any other 3" drive -- some of the
Hitachi ones had a 34 pin edge connector with the stnadard pinout) to
another machine and write Amstrad disks on it.
My own Joyce has the 3" drive replaced by two Teac 235F (720K)
drives. If you change a couple of bytes in the boot sector of an PCW
8256 boot disk, it'll boot just fine on an 8512 as a 720K drive.
One gotcha to look out for is the power connector on the Joyce 3"
drives--it *looks* like a standard 3.5" floppy connector, but the +5
and +12 lines are exchanged. Magic smoke time if you miss that one.
With 2 720K drives and the full complement of DRAM (512K?), the 8512
is actually a pretty decent system for general CP/M work.
--Chuck
24 Apr
24 Apr
11:31 a.m.
My own Joyce has the 3" drive replaced by two
Teac 235F (720K)
That's not something I would do, if only because it means the machine can no
longer use any of its native disks. Hook up a 3.5" drive as a second
unit, sure. But not as the boot drive.
With 2 720K drives and the full complement of DRAM
(512K?), the 8512
is actually a pretty decent system for general CP/M work.
I'd rather have an Epson QX10 (my personal favourite CP/M machine).
But I think the Amstrad PCW was a very sensible product. Bundling in a
printer and word processing software meant it could be used out of the
box for what a lot of people wanted a computer for.
-tony
12:07 p.m.
On 24 Apr 2010 at 19:31, Tony Duell wrote:
That's not something I would do, if only because
it means the machine
can no longer use any of its native disks. Hook up a 3.5" drive as a
second unit, sure. But not as the boot drive.
I didn't want to fool with the near -unobtainium-ness of the media
here in the US. The original 3" drive was relocated to an external
drive box that hooks to a PC. If I get the CF media, I can simply
copy it over to 3.5". The 3" drives aren't the most reliable in
the world; they often fall prey to disintegrating drive belts.
--Chuck
4:20 p.m.
On 04/24/2010 19:31, Tony Duell wrote:
But I think the Amstrad PCW was a very sensible product. Bundling in a
printer and word processing software meant it could be used out of the
box for what a lot of people wanted a computer for.
-tony
I have 3 Amstrad PCW 512+ brand new in boxes if anyone is interested.
To heavy to post but would swap..
I live in Sussex UK
These have the 3.5 inch floppy drive 512K ram and a daisywheeel printer
with sheetfeed.
Complete with cp/m and locoscript disks. The only problem is that the
drive belt in the floppy drive will have perished by now.
Roger
25 Apr
25 Apr
6:36 a.m.
On Sun, Apr 25, 2010 at 12:20 AM, Roger Pugh <rogpugh at mac.com> wrote:
On 04/24/2010 19:31, Tony Duell wrote:
I don't know of a PCW 512+ but Wikipedia tells me there was a 9512+
with a 3?" drive instead of a 3" - is this the model you mean?
I find myself strangely tempted, if so... Would Sir be interested in a
classic Macintosh of some hue, at all? I have a few I wish to get rid
of.
--
Liam Proven ? Profile: http://www.linkedin.com/in/liamproven
Email: lproven at cix.co.uk ? GMail/GoogleTalk/Orkut: lproven at gmail.com
Tel: +44 20-8685-0498 ? Cell: +44 7939-087884 ? Fax: + 44 870-9151419
AOL/AIM/iChat/Yahoo/Skype: liamproven ? LiveJournal/Twitter: lproven
MSN: lproven at hotmail.com ? ICQ: 73187508
But I think the Amstrad PCW was a very sensible product. Bundling in a
printer and word processing software meant it could be used out of the
box for what a lot of people wanted a computer for.
-tony
I have 3 Amstrad PCW 512+ brand new in boxes if anyone is interested. ?To
heavy to post but would swap..
I live in Sussex UK
These have the 3.5 inch floppy drive 512K ram and a daisywheeel printer with
sheetfeed.
Complete with cp/m and locoscript disks. ?The only problem is that the drive
belt in the floppy drive will have perished by now.
8:11 a.m.
On 04/25/2010 14:36, Liam Proven wrote:
I don't know of a PCW 512+ but Wikipedia tells me there was a 9512+
with a 3?" drive instead of a 3" - is this the model you mean?
I find myself strangely tempted, if so... Would Sir be interested in a
classic Macintosh of some hue, at all? I have a few I wish to get rid
of.
Yep, i missed the 9 on the keyboard. its a 9512+
http://www.old-computers.com/museum/computer.asp?st=1&c=190
from the Old computer bible :-)
If i took in another Classic Mac, Mrs P would string me up by the
unmentionables.
however i'm willing to accept an IOU of something intresting if you want
one tho, they are only sitting in a storage unit.
contact further off list i think
Roger
8:21 a.m.
If i took in another Classic Mac, Mrs P would string
me up by the
unmentionables.
I knew there was a reason I was unmarried.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Of course, what I really want is total world domination. -- Linus Torvalds -
8:53 a.m.
On Apr 25, 2010, at 11:21 AM, Cameron Kaiser wrote:
My live-in girlfriend likes the ASR-33 in the living room. It
*is* possible to find significant others who actually like who we are
and what we do.
-Dave
--
Dave McGuire
Port Charlotte, FL
If i took in
another Classic Mac, Mrs P would string me up by the
unmentionables.
I knew there was a reason I was unmarried.
9:07 a.m.
On 04/25/2010 16:53, Dave McGuire wrote:
My live-in girlfriend likes the ASR-33 in the living room. It *is*
possible to find significant others who actually like who we are and
what we do.
I used to have a nice 100Mhz HP oscilloscope as a coffee table and a Mac
Classic looked lovely in the Kitchen..
9:10 a.m.
If i took in another Classic Mac, Mrs P would string
me up by the
unmentionables.
I knew there was a reason I was unmarried. 
12:23 p.m.
New subject: Computer Furniture (was Transfer files to/from N* CPM image?)
On Sun, 25 Apr 2010, Dave McGuire wrote:
My live-in girlfriend likes the ASR-33 in the living
room. It *is* possible
to find significant others who actually like who we are and what we do.
My wife tolerates an IBM 129 keypunch downstairs in the music studio,
but says that's the limit.
Mike Loewen mloewen at cpumagic.scol.pa.us
Old Technology http://sturgeon.css.psu.edu/~mloewen/Oldtech/
12:42 p.m.
New subject: Computer Furniture (was Transfer files to/from N* CPM image?)
Mike Loewen wrote:
My wife tolerates an IBM 129 keypunch downstairs in
the music studio,
but says that's the limit.
I was expecting , a player piano punch down there instead. :)
Mike Loewen mloewen at cpumagic.scol.pa.us
Old Technology http://sturgeon.css.psu.edu/~mloewen/Oldtech/
6 May
6 May
11:18 a.m.
On Sun, Apr 25, 2010 at 4:11 PM, Roger Pugh <rogpugh at mac.com> wrote:
On 04/25/2010 14:36, Liam Proven wrote:
And indeed thanks to the estimable Mr Pugh, I now have one of these
absolutely mind 'Strads in my possession, which makes me jolly happy.
:?) Thanks, Roger!
--
Liam Proven ? Profile: http://www.linkedin.com/in/liamproven
Email: lproven at cix.co.uk ? GMail/GoogleTalk/Orkut: lproven at gmail.com
Tel: +44 20-8685-0498 ? Cell: +44 7939-087884 ? Fax: + 44 870-9151419
AOL/AIM/iChat/Yahoo/Skype: liamproven ? LiveJournal/Twitter: lproven
MSN: lproven at hotmail.com ? ICQ: 73187508
I don't know of a PCW 512+ but Wikipedia tells me there was a 9512+
with a 3?" drive instead of a 3" - is this the model you mean?
I find myself strangely tempted, if so... Would Sir be interested in a
classic Macintosh of some hue, at all? I have a few I wish to get rid
of.
Yep, i missed the 9 on the keyboard. its a 9512+
? ?http://www.old-computers.com/museum/computer.asp?st=1&c=190
from the Old computer bible :-)
If i took in another Classic Mac, Mrs P would string me up by the
unmentionables.
however i'm willing to accept an IOU of something intresting if you want one
tho, they are only sitting in a storage unit.
contact further off list i think
Roger
20 Apr
20 Apr
10:23 a.m.
On 20 Apr 2010 at 10:01, Fred Cisin wrote:
If you can load a file into memory, and regain access
to the CP/M
command processor, then the SAVE command could be quite useful.
There are possibilities even on systems without what appears to be
any means of data linking. I once transfered a bunch of files by
taping a phototransistor over a controllable LED on the keyboard of
what appeared to be an otherwise impenetrable system. Bit-bang by
blinking.
It's mostly software, anyway.
--Chuck
11:59 a.m.
On Tue, 20 Apr 2010, Fred Cisin wrote:
If you can load a file into memory, and regain access
to the CP/M command
processor, then the SAVE command could be quite useful.
That's what I ended up doing. But, I'd still like to understand how to
directly read files from the AUX UART.
--
12:35 p.m.
Fred Cisin schrieb:
If you can load a file into memory, and regain access
to the CP/M command
processor, then the SAVE command could be quite useful.
...unless the program uses overlays, like WordStar, and unless the
loaded program overwrites
the CCP area. PIP is surely a better option for copy attempts.
Holger
10:12 a.m.
>> 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.
Is anything actually hooked up to the reader?? This
is both a software
question and hardware.
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.
Yeah! - that appears to be the case. I use this technique lots under NorthStar
DOS (where I have utilities that can read/write to any of the I/O devices),
and I *assumed* that the Horizon implementations of CP/M would have at least
one input device pointed at the secondary serial port - however this appears
to NOT be the case :-(
I've made two additions to my HORIZON support package which should help you
out:
1) I've added a small 'CPM' utility which takes a file on your PC and
converts
it into an Intel HEX format download file origined at address 0100 (the CP/M
TPA) and padded to a multiple of 256 bytes with 0x1A (EOF) characters.
- you can then boot CP/M, halt the simulation, 'L'oad this file, resume
simulation and 'SAVE' the TPA to a CP/M file, effectively importing the file
to the CP/M disk. This method is very fast and easy, but is limited to files
the size of your CP/M TPA or less.
2) I've added a "Reader" option to the simulator Mount command, which mounts
a
file to be read as if it were typed at the keyboard (normally the console).
When the file hits EOF it is unmounted and normal keyboard operation resumes.
You can use this like you would the paper tape reader of an ASR33 - just
PIP CON: into the file you want, then mount the file on the Reader (which
automatically starts it) - after it is finished, you must press ^Z to send
the EOF character from the keyboard, which will cause PIP to close the file.
The updated package has been uploaded to the site.
Hope this works for you.
regards,
Dave
--
dave09 (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Classic Computers: http://www.classiccmp.org/dunfield/
1:39 p.m.
Dave Dunfield wrote:
Depends on what implementation you have. I have three different
commercial ones with differing behavior and one I built with
interrupt driven (buffered) IO. It's more what the BIOS writer did
than what CP/M can do. Most BIOS are near minimal implementation.
>> 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.
>
Is anything actually hooked up to the reader??
This is both a software
question and hardware.
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.
Yeah! - that appears to be the case. I use this technique lots under NorthStar
DOS (where I have utilities that can read/write to any of the I/O devices),
and I *assumed* that the Horizon implementations of CP/M would have at least
one input device pointed at the secondary serial port - however this appears
to NOT be the case :-(
I've made two additions to my HORIZON support
package which should help you
out:
1) I've added a small 'CPM' utility which takes a file on your PC and
converts
it into an Intel HEX format download file origined at address 0100 (the CP/M
TPA) and padded to a multiple of 256 bytes with 0x1A (EOF) characters.
- you can then boot CP/M, halt the simulation, 'L'oad this file, resume
simulation and 'SAVE' the TPA to a CP/M file, effectively importing the file
to the CP/M disk. This method is very fast and easy, but is limited to files
the size of your CP/M TPA or less.
A handy tool. CP/M is simple and the easiest way is through the
console port and using PIP or DDT (hand entered simple program)
to do console input capture.
Then a simple modem program that does Xmodem transfers will
be the next level for transfers.
Allison
2) I've added a "Reader" option to the
simulator Mount command, which mounts a
file to be read as if it were typed at the keyboard (normally the console).
When the file hits EOF it is unmounted and normal keyboard operation resumes.
You can use this like you would the paper tape reader of an ASR33 - just
PIP CON: into the file you want, then mount the file on the Reader (which
automatically starts it) - after it is finished, you must press ^Z to send
the EOF character from the keyboard, which will cause PIP to close the file.
The updated package has been uploaded to the site.
Hope this works for you.
regards,
Dave
--
dave09 (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Classic Computers: http://www.classiccmp.org/dunfield/
7:35 p.m.
Yeah! - that
appears to be the case. I use this technique lots under NorthStar
DOS (where I have utilities that can read/write to any of the I/O devices),
and I *assumed* that the Horizon implementations of CP/M would have at least
one input device pointed at the secondary serial port - however this appears
to NOT be the case :-(
Depends on what implementation you have. I have three different
commercial ones with differing behavior and one I built with
interrupt driven (buffered) IO. It's more what the BIOS writer did
than what CP/M can do. Most BIOS are near minimal implementation. A handy tool. CP/M is simple and the easiest way is
through the
console port and using PIP or DDT (hand entered simple program)
to do console input capture.
Then a simple modem program that does Xmodem transfers will
be the next level for transfers.
Thats great when you are working with a physical system, however I often
find it easier to work under the simulator (single PC)... especially when
the hardware has been stored away as most of my collection is - the newly
added "mount reader file" feature I mentioned in my last post will let you
do the PIP thing by stuffing a file in via the console interface.
I wonder if any of the multi-tasking OS's capable of running DOS software
support virtual com port connections between sessions ... this would let
you run the simulator and a terminal emulator capable of xmodem etc.
transfers on the same PC.
Dave
--
dave09 (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Classic Computers: http://www.classiccmp.org/dunfield/
21 Apr
21 Apr
4:34 a.m.
On Tue, 20 Apr 2010, Dave Dunfield wrote:
Wow, thanks, Dave. I will give that a try.
--
> 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.
Is anything actually hooked up to the reader??
This is both a software
question and hardware.
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.
Yeah! - that appears to be the case. I use this technique lots under NorthStar
DOS (where I have utilities that can read/write to any of the I/O devices),
and I *assumed* that the Horizon implementations of CP/M would have at least
one input device pointed at the secondary serial port - however this appears
to NOT be the case :-(
I've made two additions to my HORIZON support package which should help you
out:
1) I've added a small 'CPM' utility which takes a file on your PC and
converts
it into an Intel HEX format download file origined at address 0100 (the CP/M
TPA) and padded to a multiple of 256 bytes with 0x1A (EOF) characters.
- you can then boot CP/M, halt the simulation, 'L'oad this file, resume
simulation and 'SAVE' the TPA to a CP/M file, effectively importing the file
to the CP/M disk. This method is very fast and easy, but is limited to files
the size of your CP/M TPA or less.
2) I've added a "Reader" option to the simulator Mount command, which
mounts a
file to be read as if it were typed at the keyboard (normally the console).
When the file hits EOF it is unmounted and normal keyboard operation resumes.
You can use this like you would the paper tape reader of an ASR33 - just
PIP CON: into the file you want, then mount the file on the Reader (which
automatically starts it) - after it is finished, you must press ^Z to send
the EOF character from the keyboard, which will cause PIP to close the file.
The updated package has been uploaded to the site.
Hope this works for you.
12:54 p.m.
I've made
two additions to my HORIZON support package which should help you
out:
1) I've added a small 'CPM' utility which takes a file on your PC and
converts
it into an Intel HEX format download file origined at address 0100 (the CP/M
TPA) and padded to a multiple of 256 bytes with 0x1A (EOF) characters.
- you can then boot CP/M, halt the simulation, 'L'oad this file, resume
simulation and 'SAVE' the TPA to a CP/M file, effectively importing the file
to the CP/M disk. This method is very fast and easy, but is limited to files
the size of your CP/M TPA or less.
2) I've added a "Reader" option to the simulator Mount command, which
mounts a
file to be read as if it were typed at the keyboard (normally the console).
When the file hits EOF it is unmounted and normal keyboard operation resumes.
You can use this like you would the paper tape reader of an ASR33 - just
PIP CON: into the file you want, then mount the file on the Reader (which
automatically starts it) - after it is finished, you must press ^Z to send
the EOF character from the keyboard, which will cause PIP to close the file.
The updated package has been uploaded to the site.
Hope this works for you.
Wow, thanks, Dave. I will give that a try.
5121
days inactive
5140
days old
44 comments
16 participants
participants (16)
-
ajp166＠verizon.net -
ard＠p850ug1.demon.co.uk -
ats＠offog.org -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
cisin＠xenosoft.com -
dave09＠dunfield.com -
david＠cantrell.org.uk -
geoffr＠zipcon.net -
holger.veit＠iais.fraunhofer.de -
lproven＠gmail.com -
mcguire＠neurotica.com -
mloewen＠cpumagic.scol.pa.us -
rogpugh＠mac.com -
snhirsch＠gmail.com -
spectre＠floodgap.com