Mass Storage (8/16 bit IDE) for CPC464/6128 Project

[wilco2009]

+1.
I wanna one!

[Fordka]

..and after reading 7 pages of very interesting chat about the possibility of attaching a hard drive to my CPC6128 it (yet again) fizzles out to nothing... I too have tried to sign up to yareks site with no luck - dead page - thought I might learn something about attaching an IDE nterface to the 6128... I thought I would also track down the guy who was so positive he would release the solution to the public for less than $30 but well, Google led me to a dead end there as well, he seems to have disappeared into development hell, Don't get me wrong guys, while I have the technical ability to implement the result, I certainly don't have the understanding to contribute in the topics you guys are talking in - or of the concepts of whats behind it... most of what I have just read is w-a-ay above my head, but then I'm a near 60 year old who expects the world from the younger generation hahahaha! Ah well, while I'm waiting for my new drive belt to arrive, I'll fire up WinAPE and play Bruce Lee one mre time... or maybe BombJack....

[TFM]

Your choices are:


- Try to email Jarek


- Try to get a SF2

[Bryce]

As far as I know, Jarek only did hardware, no new Firmware? As I mentioned before, the hardware is the easy part, it's the firmware (OS) that's lacking.

Bryce.

[TFM]

Well, I got a patched AmsDOS from him.


Source codes for accessing his device are available too.

[Prodatron]

Is there an Amsdos extension for an IDE filesystem (FATxx) access available?

[TFM]

Something like that, but it's too long ago. I don't remember precisely. Have to take a look at it in one months.

[zhulien]

gerald

The CPC cannot achieve a speed of 180 Kb/s as the VGA will no doubt interfere in data transfers.  I have seen the source for the symbiface and it can achieve at most 140 Kb/s (or there about).
rpalmer

I'm actually trying to work out how fast a CPC can transfer data in memory, I am likely totally wrong in my calculations... but...


Let's say 16kb... 16384 bytes. an LDIR takes 21 t-states per iteration except the last is 16, so let's just round it to 16384 x 21 = 344064 t-states.  I read a Z80 at 10Mhz takes 1.2 microseconds to ful-fill 12 t-states (source: http://www.ganssle.com/articles/abuscyc.htm).  So... that would be 34406.4 microseconds.  Since the CPC is about 3.3Mhz, let's say it takes about 3x longer than a 10Mhz Z80, so... 103219.2 microseconds for a full 16kb using LDIR.  So far that is about one tenth of a second.  Some smart coding can code a loop that is 19% faster than that LDIR (source: http://map.grauw.nl/articles/fast_loops.php)... so let's make it 83607.552 microseconds to copy 16kb data.  So how much data can we transfer in a second?  Perhaps 191kb/second assuming no other logic than the 16kb transfer... but we want a tiny bit of loop logic, so quite likely somewhere between 180kb/second to 191kb/second to sustain a transfer to a "memory mapped" hardware device.  Can that memory mapped hardware device sustain that transfer rate?  Let's hope...

[JonB]

If the AMSDOS extension uses IDE-ATA registers, 8-bit mode and LBA they may work with uIDE-16. All that is required is the I/O base address of the driver, then you configure uIDE-16 appropriately using jumpers. Provisionally, I have it at the same address range as CPC-CompactFlash which is FEF0-FEF7.

However, the PCW (soon to be 6128) driver supports CP/M Plus only, and implements a native CP/M disk format, so it will not be compatible (unless the AMSDOS extension does the same).

@TFM : If you have the AMSDOS extension code would you like to share it with me?

[HAL6128]

CP/M is able to use more then one partition or volumes via an offset table. I don't know the technical details, but would it be able to use both a 120 MByte FAT16 at the beginning of the DOM and a 8 MByte native CP/M volume at the end?
What I have read is that the data table or information are not stored on the drive itself. The CP/M has to be adapted / patched?

[rpalmer]

CP/M can handle at most 512Mb of data on a given storage device (I have the CP/M 3.0 bible, it has over 500 pages of information about the OS). It is due to the way CP/M accesses records and not a physical limitation in hardware.

Also CP/M does not know about "partitions", so any offset table is a custom support function to achieve a drive like system (E:, F:, G:, etc). This is due to it original design which was aimed at a hardware level to access storage devices as a whole device and not burdened with partitions on any device.

rpalmer

[zhulien]

Why not make a modern ide interface with at least a 1mb buffer that is memory mapped? Just using the IO ports is like having a modern graphics card with no gpu.  You can even consider an fgpa or a perhaps a microcontroller on the ide interface so it does the work of filling up or saving the buffer...

[arnoldemu]

@zhulien: Your timings are for a "perfect" case and unlikely to be real world.

For example, what happens when you want to load data to the location where your memory mapped registers are located?

You now either have to load to a different location, disable the registers and ldir it into place, or have the ability to remap the location of the memory mapped registers have two load routines and then have to plan your loading more carefully. I/O is a bit slower but avoids that.

For memory i/o your fastest case is possibly a list of LDI.
This is 5us, but then you need more than 1 consecutive location for transfering data.

ld a,(de)
ld (hl),a
inc hl

is closest with one memory mapped register pointed to be de.

this comes to 6us per byte.

Another thing that will alter your timings is the seek timing of the device. For mechanical drives this adds a small cost, for SSD and DOM it's probably negligible. For your PI you may need to factor in the speed of the SD card reading from the PI...


(In the case of disc loaders, people often forget the head load time, the head unload time, the step rate and other factors that alter the results).

[JonB]

[/size][size=0px]CP/M is able to use more then one partition or volumes via an offset table. I don't know the technical details, but would it be able to use both a 120 MByte FAT16 at the beginning of the DOM and a 8 MByte native CP/M volume at the end?What I have read is that the data table or information are not stored on the drive itself. The CP/M has to be adapted / patched?[/size]

[size=0px]


Hmm, yes that's possible., but you would need the CP/M data at the start of the disk.

Yes, patch.

You're correct about the way the driver works, it assumes the drive is a contiguous array of sectors and addresses them by LBA. The CP/M drive letter is used to provide an offset so there is no partition table. Thus, a CP/M "partition" is not the same as a hard drive partition that you would set up on the drive itself using fdisk.[/size]