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

[Zetr0]

You guys are awesome  - its like a call to arms!! =D



how big is the standard ROM of the CPC464 and the C6128 ?

is there any information on ROM paging with the CPC or is it the same as the Spectrum ?

[arnoldemu]

Is it easy to get those many games loading from such IDE device ?


What about multiloading/bigger games ?

Many games that cngsoft cracked can be loaded from ide, if standard firmware functions are implemented by the ide filesystem.
Other games could be if the crack was modified.

[arnoldemu]

You guys are awesome  - its like a call to arms!! =D



how big is the standard ROM of the CPC464 and the C6128 ?

is there any information on ROM paging with the CPC or is it the same as the Spectrum ?

Personally I would go with writing another rom, which would patch the firmware functions:
cas in open, cas in direct, cas in close and cas catalog.

These would perform functions, or redirect to the next (by keeping a copy of the functions before patching).

This would allow most software to load and run direct from basic.

The amstrad dos was not really intended to be extended.
so I doubt the same approach as for the +3 can be done.
It could be patched and updated, but then you'd need to replace the existing rom to make it work.

This doc describes the cpc's roms that are compatible with the OS:
http://www.cpctech.org.uk/docs/manual/s158se09.pdf

So, 16k, in the upper &c000-&ffff range. You can get the rom when it's sign in function is called to capture existing firmware functions, patch them and allow redirect.
Then have a | command to select/deselect your "drive" so your functions take priority, otherwise you patch in the existing functions.
Your rom has control provided it's lower than slot 7, it can then redirect to amsdos if required (or cassette if amsdos doesn't exist).

cas in open etc here:
http://www.cpctech.org.uk/docs/firmware.pdf

So you need to match the same input parameters, the same output data, but use your functions.

use far call (see lower kernel) to install your patches so it can call into your rom.
you can reserve some area with your rom too.

The amsdos rom is too hard coded towards disc access. no cpm style bios or bdos functions are available


EDIT: I am "knocking up" some code which will allow you to patch the firmware and call your rom functions instead

[MacDeath]

Locobasic was great, sadly never really up^dated... even for the PLUS.


Amstrad feared so much the eventual incompatibilities within the whole CPC range I guess.
(and almost failed with the PLUS range, but mostly due to some bad habits from the Games production)


but this doesn't mean nothing could nor should be done now.


Also that quite true a "cheap" proper and modern IDE solution is clearly what the CPC/PLUS range needs.

[rpalmer]

This whole subject of re-directing the AMSDOS OS functions has been done by me with HDOS.

The HDOS ROM also has the capability to re-direct the DISC Access functions deep within the ROM to go via the HDOS ROM instead. What this means is that is the CPM system were to read a sector of a disc from say drive A then it would be re-directed to HDOS to read from an IDE device such as as a Hard disc.

rpalmer

[SyX]

Sorry, i have been away

This project looks great Zetr0 

With respect to the firmware, there is rpalmer and his wonderful work in HDOS and our "work in progress" sd card firmware, you can find the code here. All the firmware compatibility layer is there and we need to add the filesystem code, more a few extra RSXs, but not a lot of time in the last months, well as i said WIP, jejeje.

[rpalmer]

I should add that i have also created a patched AMSDOS ROM to allow for the disc re-direction to HDOS.

[arnoldemu]

Sorry, i have been away

This project looks great Zetr0 

With respect to the firmware, there is rpalmer and his wonderful work in HDOS and our "work in progress" sd card firmware, you can find the code here. All the firmware compatibility layer is there and we need to add the filesystem code, more a few extra RSXs, but not a lot of time in the last months, well as i said WIP, jejeje.

Great

I will not continue with my work.

I will only release some source showing how to patch a firmware function to then call into a rom, but nothing more.

Well I am happy to use either existing solution.. For me it is more important it works with AMSDOS functions and works with the hardware I want to use. Which both do.

I would also prefer that if using SD-CARD it uses fat filesystem to make it easy to read/write on pc.
That is all.

So when will the  sd card hardware be ready?

[arnoldemu]

@Syx: I read the code, is there a reason why this rom doesn't modify HL to give it it's own space in memory?
You only need to modify HL and return the new value. Firmware will give you the space.

Will this rom work without AMSDOS? I think this is important if the rom/hardware should be used on 464 without DDI-1.

@rpalmer: Does HDOS work on 464 without AMSDOS?

[SyX]

@Syx: I read the code, is there a reason why this rom doesn't modify HL to give it it's own space in memory? You only need to modify HL and return the new value. Firmware will give you the space.

Yes, there is a reason, compatibility, we are using the same buffers as AMSDOS and a few extra bytes after $BE7F, because that we don't reserve any extra bytes during the initialization

Making a breeze copy files between floppies and the SD, and except games accesing directly to the FDC everything works (although there is a low level interface for accesing directly to the SD sectors).

Will this rom work without AMSDOS? I think this is important if the rom/hardware should be used on 464 without DDI-1.

Yes, the rom can work without AMSDOS/PARADOS, it's not a requirement. The actual code only use AMSDOS when the drive in use is not the SD (for using |A, LOAD"A:filename", ...), redirecting the firmware calls to it. That means we only would need to add an extra check during the initialization for finding the AMSDOS rom and it doesn't exist, we'll need to reserve ram.

The actual code is less 2KBs, that leave a lot of space for adding FAT or another filesystems (PulkoMandy's tool for handling his filesystem is basic, but works great and making a fuse driver is something that i always have in my todo list... we only need time, jejeje).

[MacDeath]

I stumbled accross some IDE MSX stuff in another retro Forum (Gamopat, in French)


here I post the pictures...



Interface IDE BEER202 avec carte compact flash



Slot expander 4X + FMPAC + BEER202 + FlashROM SCC + extension 64ko


do someone knows about this ?
Is this not a cartridge port to IDE converter


some pages and topic on this perhaps...


http://gomsx.net/hansotten/index.php?page=beer-ide


Beer 202 IDE interface partitioning tool | MSX Resource Center


Beer 202 IDE interface | MSX Resource Center




Is MSX extension port far different than CPC ?


I mean both machines are supposed to be Z80 based, but MSX had a lot of extra features and the standard had sweet hardware peripherals all compatibles in MSX.


A good point would be to have IDE interface as standard part for all newcoming RAM+ROMbox extensions.


Also it looks like MSX scene has a nice bunch of extra Hardware available, be it homebrew.




Also : Wouldn't this topic be at a better place in the Hardware section ?

Post edit : thx Gryzor, still as efficient as ever.

[Gryzor]

After stopping all the drooling, yes, I'm moving this to HW. Didn't notice it was here.

[TFM]

What do we have?

DOS for the CF: The one from Syx for the French interface and HDOS

My question and desire: Is it doable to use a common format for the devices?

[gerald]

Jumping on that 

Hmmm... With Yareks 8255IDE the FAT system can be used at 180 KB/s. What I want to say is that, 8 bit or 16 bit are not making the difference. It's all about I/O addresses and routines.

How do you acheive a 180KB/s ?
Doing my own test with my own interface, I am limited to one byte every 8us, which gives 125KB/s peak. Real BW is the limited by the loop unrool factor and FS overhead.
core loop code is the following (repeated for loop unroll):

Code Select Expand


  in   a,(C)
  ld   (de),a
  inc  de


Do you have any faster code suggestion?

Thanks

[rpalmer]

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).

If the CPC were capable of 150 Kb/s, then it is possible to access CD writer hardware (it may still be possible with latest devices which have buffer underrun handling capabilities).

The only means by which the CPC could get high data transfer speeds is if the Z80 DMA were somehow able to work without interference from the VGA (but this is where the stumbling block is).

rpalmer

[gerald]

Ok, so no undocumented or magic instruction I would have missed 
The 125kB/s are measured on CPC, and include the VGA interference.

Regarding DMA, while I had only looked on datasheet, the Z80DMA should be able to handle the READY(WAITn) signal from GA, as the Z80 does.

[TFM]

How do you acheive a 180KB/s ?

Well, that's done the following way....

First I have to mention that there are four I/O ports to read a data byte, they all provide the same data byte, that's the smart part of the hardware. Not let's see the software...

ld hl,target-of-data
ld bc,read-io-address
ld d,b

---- the following part will be repeated 64 times (but you also can go down to 8 times if you need more RAM ----

INI
INI
INI
INI
LD B,D

------------

So to read four data bytes you need 21 ys. So in one second you can transfer 186 KB



EDIT: We are not talking about theories here. Actually I developped and tested file-loading functions that way, and in reality it works with slightly more than 180 KB/s, not 186 KB though.

I have seen the source for the symbiface and it can achieve at most 140 Kb/s (or there about).

rpalmer

With my code I archive 160 KB/s when using a SF-II (in theory I need 6 ys for one byte).

[gerald]

Thanks TFM/S for the details

Was thinking about INI, but symbiface doc on wiki does not mention the address mirroring.
My HW does not allo such mirror, mainly to save IO space.

If wiki is right, you IO address will range be FF08, FE08, FD08, FC08 ?

[TFM]

Thanks TFM/S for the details

TFM is enough   You are welcome

Was thinking about INI, but symbiface doc on wiki does not mention the address mirroring.
My HW does not allo such mirror, mainly to save IO space.

The SF2 does NOT have that. I referred to Yareks IDE8255. Only his card has that feature.

If wiki is right, you IO address will range be FF08, FE08, FD08, FC08 ?

See here: IDE8255 - CPCWiki

[Zetr0]

Sorry for the late update - sadly I am dealing with a house flood at the moment, thus my time is limited, however I have since put-together a C128 as a test bed in the office - I have two devices to do some tests (an SD based interface and an IDE based interface)

So when I get some time there will be some fun (and pictures!!!)


while reviewing lots of sources, I cannot seem to find a schematic or even a PCB layout for the the IDE8255 - anyone got one handy? - Yarak's site comes back with missing links sadly =(

[Gryzor]

I seriously hope your house doesn't suffer much damage.


I also seriously wish you'd left those c128's in the water.

[Zetr0]

Ooops   

I meant CPC6128 - sorry about that.... I don't currently have a C128, in fact the only commie 8bit I have is a VIC 20 thats on loan.... but I plan on getting a C128D for much mischief and mayhem soon =)

[Gryzor]

Heheh just kidding. I've always wanted a C128, I remember being a bit mesmerized by its useless versatility at the neighborhood micro store...

[Zetr0]

indeedy....  the C128 has a Z80 in it..... although sadly its only effectively running at 2Mhz
(mainly because of half-assed rom routines and badly written CPM/3 software)

It would be nice to get the opportunity to open that one up a bit =)

[SyX]

I hope that you have exhausted your quote of bad luck Zetr0