View Full Version : Identify harddisk and controller

Roland Huisman
March 30th, 2013, 05:31 AM
Can anyone identify this RMS 518 hard disk and Xebec MFM controller?

A little searching gives me the XEBEC S1410 controller. Is that true?
And I've never heard about the RMS 518 hard disk. Are there any technical specs known?

I need this set which is missing from my Holborn 6100 computer.
Does anyone know where the Xebec controller is used in other computers?


Thanks in advance!
Regards, Roland

Roland Huisman
April 7th, 2013, 12:52 PM
I have still no RMS 518 technical data.

But with a little help from Fred Jan I've got some other RMS disk data.

Disk format (H CYL S)
RMS 503 => 2 153 17 2.6MB
RMS 506 => 4 153 17 5.2MB
RMS 512 => 8 153 17 10.4MB
RMS 514 => 4 338 17 11.5MB

All these drives are 17 sector drives.

The Xebec controller is jumpered to 256 Byte / 32 sector according the Xebec documentation.
I wonder, is the drive "misused" with a slightly different data amount per track?
(It that possible anyway?) Or is it really a 32 sector drive?

Counting protection wires and diodes tells me it's probably an 8 head drive.

But still I have no clue about further technical data.
I really wonder is anyone knows this disk...

Regards, Roland

April 7th, 2013, 01:08 PM
8 215 17 15MB is what I found.

Roland Huisman
April 7th, 2013, 01:33 PM
Hello Stone,

Thanks for your reply! Where did you find this data?
On the web I could not find this information.

8 215 17 15MB sounds reasonable to me. RMS made small
steps in sizes. And the 17 sectors matches with the other drives.


But then I don't understand the jumpering on the Xebec controller.

256/32 gives exactly 8192 bytes per cylinder (a nice exact 8KByte)
512/17 gives 8704 bytes per cylinder. (a bit more then 8KByte)

Maybe it was easier programming or cheaper hardware putting
an exactly data format of 8KByte into memory...

So the setting gives a lower data rate and exactly 8KB.
But can you do this without any problems with any 17 sector drive?

Regards, Roland

April 7th, 2013, 01:52 PM
An MFM drive is essentially a tabula rasa--it doesn't know from zip sectors per track--that's entirely up to the controller. Of course, regardless of what you do, you will have to low-level format the drive before using it to store data.

April 7th, 2013, 02:19 PM
Hello Stone,

Thanks for your reply! Where did you find this data?Hi Roland,

I found it in The PC Engineer's Reference Book Volume 3.

April 7th, 2013, 02:46 PM
Et tu, Brute

April 7th, 2013, 03:24 PM
Still beat you to it by 20 minutes (http://www.vintage-computer.com/vcforum/showthread.php?36581-RMS-518-harddisk-technical-data&p=271697#post271697), Stone. My path was a bit different, however. My notes on RMS say that it was merged with DPI and the result called Disctron, so Diskbase showed the drive parameters under "Disctron". I think Otari then proceeded to gobble up Disctron.

Heady days, those.

April 7th, 2013, 04:10 PM
Still beat you to it by 20 minutes (http://www.vintage-computer.com/vcforum/showthread.php?36581-RMS-518-harddisk-technical-data&p=271697#post271697), Stone.I don't see how you calculated that:


My post was 40 minutes before yours. :-)

April 7th, 2013, 05:13 PM
Sorry, backwards math--and the problem that Roland posted the same request on two different threads. :oops:

The funny thing is that none of the manual that I have say "RMS: See Disctron". Some of the fallout from the drive company mergers and acquisitions can lead to some puzzling units. I have a Miniscribe unit (clearly says "Miniscribe" on the HDA casting), but has a Micropolis label on it. I also have a Priam drive with an ATASI label. Stuff can get confusing.

One of these days, I mean to create a table of who bought whom (or the wreckage of whose bankruptcy). It's getting more difficult as the years go by to remember what happened to an outfit.

April 7th, 2013, 07:08 PM
It's getting more difficult as the years go by to remember what happened to an outfit.:-) Who you tellin'? It's getting more difficult as the years go by to remember..... anything. :-)

Roland Huisman
April 8th, 2013, 02:32 AM
Hello Chuck and Stone,

Thanks a lot for the data. I don't have reference books,
and I have never heard from Disctron too... :-)

So it seems Holborn wasted a bit of the capacity...
8704 - 8192 = 512 Bytes/track wasted
512 Bytes * 215 * 8 = 880640 Bytes

So more than 800K wasted from 15MB, that's more than 5%

Lets say the harddrive was $1500, then about $75 was wasted.

Regards, Roland

Frank S
April 8th, 2013, 03:07 AM
Hello Roland,
the waste is a point of sight.
The Holborn operating system is CP/M. For each CP/M file the lowest filesize is the size of the sector.
When an sector can contain 128Byte and you want to write only "Hello World" in the file, the file is 128Byte "big".
But the containing data is only about 16Byte. You waste in this case 112Byte.
When the sectorsize is 512Byte, you waste 496Bytes.


April 8th, 2013, 03:45 AM
Hello Chuck and Stone,

Thanks a lot for the data. I don't have reference books...Hi Roland,

I have PDFs of the PC Engineer's Reference Book(s) if you would like that.

Roland Huisman
April 8th, 2013, 07:46 AM

1-0 for Holborn :D You are probably right.
And in those days files were very small.
I hope to contact old Holborn employees to ask
some questions about the Holborn... Maybe they do remember...


Yes I would like to receive those PDF files.
I will PM you my email address.

Regards, Roland

April 8th, 2013, 08:20 AM
The PDF for volume 3 is already online: here (http://itelsoft.com.au/north_star_manuals/pc_engineers_vol3dl_hard_drives_video_memory_info. pdf) if it's more convenient.

To amplify on Frank's point a bit, CP/M allocates by "chunks" (Allocation Units) of sectors, the smallest chunk being 1024 bytes on the smallest drives. As there is a fixed number of "chunks", it is necessary to make a chunk larger as drive sizes grow. The maximum size of a chunk is 16K and is commonly found with hard disks. So a 3-byte file will occupy 16KB. You can see a similar issue with MS-DOS FAT allocation schemes. There are other, more efficient allocation schemes, but they all have their price for this.

Roland Huisman
April 11th, 2013, 12:40 PM
Hello Chuck,

Thanks for the document!

I've lost the story a bit. I understand that a file, containing
just one byte, takes the size of one sector. That's clear and
knew this issue also from the MS-Dos systems.

But..... You say: CP/M works in blocks of minimal 1024 bytes.
If that is true then is, in my opinion, no need to make hard disk
sectors smaller then 1024 bytes (please correct me if I'm wrong).

The jumper setting on de Xebec controller are 17 and 32 sectors:
256/32 gives exactly 8192 bytes per cylinder (a nice exact 8KByte)
512/17 gives 8704 bytes per cylinder. (a bit more then 8KByte)

Both settings are smaller than the 1024 bytes. The controller
is set to the 32 sectors. So there is a bit space wasted
in my opinion. Or do I oversee something?

Regards, Roland

April 11th, 2013, 04:33 PM
That's essentially correct, Roland. The minimum allocation unit ('cluster", if you will) is 1024 bytes; the most common floppy cluster size is 2048 bytes. The minimum transfer size is 128 bytes--that is, you can read or write 128, 256,384, 512... bytes, but not 1, 129, 258, etc.

The point others have tried to make is that the amount of lost data by using 32 x 256 sectors instead of 17 x 512 sectors is really in the noise area, particularly if you have a lot of files not an exact multiple of your allocation unit size. On the other hand, 32 x 256 may actually give you a bit more speed, owing to the 17 sector model needing to cross a track boundary to read or write a complete allocation unit. In practice, however, it won't really be evident, so either allocation is fine. Since the CBIOS must block/deblock a physical sector into 128-byte logical sectors, the 256 byte physical sector could possibly get you 256 bytes more free memory, but in fact, that too is in the noise.

The bottom line is to use whatever you prefer--any performance differences won't really be noticeable.

Roland Huisman
April 14th, 2013, 12:49 AM
Chuck, Thanks for the explanation!

PS, what is the maximum size for a CP/M 2.2 hard disk (partition)?

At this moment I have these drives for the project:
- 1982 36MB Quantum (512/8/17)
- 1985 20MB Fujitsu (320/8/17)

I prefer to use the Quantum because this one
is build in the same year as the computer...

But I don't know how or where the hard drive
settings are made. There is no documentation
found about this computer at this moment.
I'm a little afraid that the size is fixed in Eprom.

I've chosen both drives because they have 8 heads and 17 sect
like the RMS. So both should work... But is the size is fixed
it will only see 15MB...

Regards, Roland

April 14th, 2013, 07:51 AM
On CP/M 2.2, if my ever-more-unreliable memory serves, the maximum partition size is about 8 MB, but the System Alteration Guide could be more specific.

May 11th, 2013, 07:45 PM
Yes, you're right...

What he left out is that he should have around 517 cylinders on the 36 megger...

... tho he'd only be able to use 32 of it. :whatthat: