Epson CP/M floppy drives. Was: C64/C128 CP/M Cartridge Interest?

[allison]

On 12/26/2010 01:51 PM, Tony Duell wrote:
>>> So the Floppy for the PX8 is specialized for a CP/M host it's not running
>>> CP/M itself as there is not enough ram alone to qualify.
>> To clarify the Epson floppy drive issue, there were three products:
>>
>> TF-20 - Z80 based, 64k RAM, 2k ROM, boot from disk
>> TF-15 - Z80 based, 2k RAM,  8k ROM, runs from ROM
>> PF-10 - 6303 based, 2k RAM, 8k ROM, runs from ROM
>>
>> The TF-20 supported the commands used by the HX-20 and the PX-4/8
>> The TF-15 and PF-10 only supported the PX-4/8 commands.
>
> Now that I didn't realise... I assumed that all drives worked with all
> machines. But the only one I have working is the TF20, which works with
> everything :-)
>
>> The TF-20 used the boot tracks of the disk to load some OS and a program
>> which made it a serial 'file server' for the host. The OS could very
>> well be a slimmed down version of CP/M.
> I think it was close....
>
> The following string exists in the OS on the TF20 system disk (the one
> that also contains HX20 disk BASIC, etc).
>
> "Bdos Err On  : $Bad Sector$Select$File R/O$"
>
> Sure looks like a CP/M message to me ...
>
Yes those messages are embedded in the BDOS, I can easily see doing named
file services over raw blocks.  With enough ram it's possible to do a 
LRU cache
so the current file in use is buffered saving disk activity.

I've done this is some of my systems and even have a pair of 3.5" drives
with 8085 plus FDC to implement that.  The idea being all the system had 
to do
was make the equivalent of of a BDOS call and a sub system (not even CPM)
can grab the parameters and pass them to the disk system.  Works well
for memory starved systems where the added 5.5K of CCP and BDOS are
enough to be over the top.  The down side is even at 38.4K it's about 100
times slower than a native disk.

If you want to copy files from drive to drive then a decent sized buffer
helps speed things.  FYI a copy of CP/M bdos and a bios for drives
has a ram/rom cost of not less than 3.5K (bdos) and likely about 1.5K
(bios) and the file transfer application (CCP is 2K) so thats 8K in itself.
A reasonable buffer is 16K so your to 24K plus rams (that era) were
1/2/4/16/64K Where 32K was generally oddball half good parts.
So with a z80 the cost to do 16 or 64K is able the same in logic and the
difference is cost of eight 16K parts becommin passe` vs  eight 64K
parts getting cheaper.   To me sounds like rom and ram were available
enough to allow software design to take a cheaper (less time) route.


The PF10 however hard to run on batteries so while cpu and memories were
cheap and big enough power was costly enough to make for a different
set of trade offs.

>> The HX-20 commands are file based and were issued mainly from Basic. The
>> Basic
>> extension is also on the boot disk.
>> The PX-4/8 commands are sector based and issued from CP/M.

If the machine is BASIC based having the file system on the drive is
then useful as then you are doing the same or similar to CLOAD
without the usual cassette tape bit banging.  The result is even minimal
Tinybasic can do a named file with little code cost.

> Although IIRC the disk BASIC for the HS20 had DSKI$ and DSKO$ commands
> (or something similar) to read/write absolute sectors.
>
> There's also a free program for linux machines to emulate such a drive.
> Amazingly it works on my acient linux box, and from what I can remember,
> it works with the HX20 and PX4/8 machines.
>

It does but it does not so file level services it's strictly at the 
Sector level.

>> All devices used the same protocol, epspd and baud rate. The same
>> protocol was used internally in the HX-20/PX-8 between the various
>> processors. The HX-20/PX-8 external video device also used it.
> IIRC, at the hardware level it's RS232 voltages, 38400 baud. Probably 8
> bits, no parity, 1 stop.
>
>> The TF-15 and PF-10 are both ROM based. The TF-15 used the same housing
>> as the TF-20. As this resembled the QX-10 computer, the origin of the
>> TF-15/20 product was probably to provide two extra floppies for this
>> computer.
> Of coruse the floppy drives in the TF20 (and maybe the TF15, I've never
> seen one) are the same voice-coil drives as in a QX10.
>
> There's a 34 pin header on the nback of the TF20, which would appear to
> be for adding a couple of exter external drives. AFAIN, the software
> doesn't support it, though.
>

Different from the PF10.  Epson did some interesting things overall.

> More interestingly, there's a parallel interface inside the TF20 (8255 +
> header), I can't remember if it's populated, or if the PCB is simply laid
> out for it. I have no idea what this was supposed to be used with.
>
Motor control or maybe a parallel bus for the PX8 or NEC8201

> The serial inbterface in the TF20 is a daughterboard. Whether other
> interfaces were planned to fit in place of it I don't know.
>
> I also have another Epson prodcut in a very similar case. it's called
> something liek a 'BM5'. The external interface is a DB25 socket, but it's
> not RS232, it's some custom patallel interface. Inside is a PSU,
> controller board and 5.25" floppy drive. But it's not a standard drive at
> all. The interface between the cotnroller and drive is a 34 way and a20
> way ribbon cable, the controller board has a _hard disk_ controller IC on
> it (one of the NEC ones). I believe the drive interface to be close to
> ST412, and the drive to take special floppies (possibly with servo
> tracks) and to have a rahter high capacity. I bought this thing 15 or so
> years ago (back when Greenweld sold interesting stuff) and have never
> been able to fidn out anythign about it. Oh well... It was probably a
> peripherals for the QX10 or something, but I have never seen an interface
> card for it.
>

Never seen that.

Allison


> -tony
>