DOS for CPC6128

[Munchausen]

1) The specification I m reading for CF cards is as clear as mud when it comes to 8-bit IDE mode. It's mostly focused more modern modes and I expect that I am not interpreting it properly. I don't know of I can read a $sector directly or if I need to read the $sector into the buffer and then read it from there. OR even if the buffer exists in 8 bit mode.

Looking into this before I found some posts on other sites about the importance of command ordering and 8-bit IDE mode with CF cards, maybe it's useful for you now: 8-bit compact flash interface « waveguide.se

The relevant comments are:

what I saw in your source code is that you first select the mode and drive (write $E0 to UNIT register) and then set the feature (1 to the FEATURE register) and then the command ($EF set feature to the command register). As it seams many CF-Cards will not work when you change the order (1 to FEATURE, $E0 to UNIT and $EF to COMMAND register). So your source code solved quit a lot of issues

and

It took me some trial and error before I got it right also. I suspect that changing mode via REG6 in mid-flight is a bit shaky. I read somewhere that the SET FEATURE command should be issued directly after every FEATURE written. The documentation I've found so far is also pretty vague about the 8-bit mode. Perhaps it's not even supported on all cards. It would not surprise me. I have used only SanDisk (4GB and 8GB) and Kingston (2GB) and they have all worked fine so far.

[RobertM]

Looking into this before I found some posts on other sites about the importance of command ordering and 8-bit IDE mode with CF cards, maybe it's useful for you now: 8-bit compact flash interface « waveguide.se

That's for that [Munchausen]. I had already read that (and many more pages) it it does clarify an important point.

I wanted to post a comment there because in the text of the page he has written something like *send &FE to the command register* when in fact he means *send &EF to the command register* ... it is however correct in his code.

[RobertM]

Ok I have made enough FAILs now to start over!!! My code is exceptionally longer than other code and it doesn't work.

Here is what I learnt.

Terminology -

IDE - Embedded Drive Electronics - this means nothing as they are all IDE so it just adds confusion.
True IDE - this is often presented in quotes as it seems to be a defacto understanding for which there is no formal or specific specification to.
XTA - IBM XT (and clones) used this. It stands for XT Attachment, was 8 bit and was almost a direct bridge to the IBM XT's 8 bit bus.
ATA - IBM AT Attachment. This was almost a direct bridge to the IMB AT's 16 bit bus.

Trap number 1). The 8 bit mode of CF cards is NOT XTA. It is in fact an 8 bit mode of ATA that is in NO way compatible with XTA.

There is a document tree here lol.

1) The top of the tree is the PCMCIA specification because CF cards are compatible with PCMCIA. This document is not really that important.

2) The CF specification itself is needed to understand how to get the CF card into 8 bit mode (ground on pin on power up). It is not usefull after that as it covers too much - doesn't clarift a lot about 8 bit mode and will lead you down a garden path.

3) The ATA specification (ATA-1) has the needed information without the clutter ... and that is what I will read next.

So now I have to "redo from start" with the software but first I have to fix a printer so I can print some docs.

so far -
ground one pin on power up or tie it to ground. You also need to be able to power cycle the CF for live swapping. this sets IDE mode.
set (feature register) to &01 (feature 8 bit mode)
set (command register) to &EF (execute the "Set Feature" command)
set (head/lba/drive register) to &E0 this sets LBA mode and Drive 0

to read sector
Set (sector count register) to 1 (to read only one sector)
Set (all LBA regesters) to point to wanted sector
Set (command register) to 20 (send read sector command)
Read (data register) 512 times.

none of this is working for me so far


set reg 6 to E0 => LBA mode, Drive 0

[RobertM]

No progress to report.

I am getting gibberish back from the reader and I have noticed that the longer it is switched on the more chance I get gibberish.

I did some voltage measurements and I saw 4.51Volts on the extension board. The CF specification requires 4.7Volts for Voh so yeah that's a problem.

I went and bough a new Switch Mode Plug Pack or Wall Wart or what ever it is were you are and now I have 4.71Volts on the external add on board that I made.

I still get memory corruption on the CPC and I am wondering if there is some other mode that the CPU uses that is triggering the interface to overtake the bus when it shouldn't.

I know the Z80 has some weird interrupt methods but I thought the CPC just uses Mode 0.

I saw another circuit and it had M0 as an input and I don't know why that would be.

Anyway, not giving up but really struggling to understand whats wrong. I don't have a scope and that doesn't help.

[arnoldemu]

I still get memory corruption on the CPC and I am wondering if there is some other mode that the CPU uses that is triggering the interface to overtake the bus when it shouldn't.

I know the Z80 has some weird interrupt methods but I thought the CPC just uses Mode 0.

I saw another circuit and it had M0 as an input and I don't know why that would be.

Anyway, not giving up but really struggling to understand whats wrong. I don't have a scope and that doesn't help.

CPC uses the Z80 in Mode 1.

M0? Not M1? M1 is one of the signals from the Z80.

www.zilog.com/docs/z80/um0080.pdf

for i/o, check /iorq, /wr, address lines and data lines.

your device should only give data when /iorq, /rd (indicating z80 is trying to read from the port).

If you're doing it at other times you are potentially writing to memory and corrupting it.

[arnoldemu]

please post part of your code, especially the part that writes the commands

[RobertM]

CPC uses the Z80 in Mode 1.

M0? Not M1? M1 is one of the signals from the Z80.

http://www.zilog.com/docs/z80/um0080.pdf

for i/o, check /iorq, /wr, address lines and data lines.

your device should only give data when /iorq, /rd (indicating z80 is trying to read from the port).

If you're doing it at other times you are potentially writing to memory and corrupting it.

Sorry, by mode I meant MODE0 MODE1 MODE2 that the Z80 uses for interrupts. By M0 I really meant the OP FETCH cycle of the Z80.

[RobertM]

please post part of your code, especially the part that writes the commands

Well it's written in BASIC and over 100 lines. Ironically it purpose is to allow me to transfer data / programs between the CPC and my PC and if I could do that than I could comply with your request to post my code.

I can do type some of it of you want. It doesn't check the "BUSY" registers because I have assumed that the CF card would be much faster that BASIC code.

[RobertM]

Progress!!!

After buying a new power supply, the code now crashes every single time. No more random lol.

I tried some earlier code and it seems to work - it just reads the ID info and uses the internal buffer.

It seems that when ever I try to read sector zero, I get RAM corruption. Sector one reads but it garbled.

I am going to start over again but this time I will go over all the hardware and probably re-program the CPLD and then try with ASM.

[RobertM]

I found *a* problem.

The Z80 A1 nad A2 signals are reversed by the time they get to the CF card.

They don't go via the CPLD so I can't fix it in VHDL.

I will change the code to match the port number and try that.

Also I read the Z80 timings and M1 and IORQ go low during an interrupt. That may be causing the memory corruption. This is not needed for the MODE 1 interupts that the CPC uses (it's intended for MODE 0) but it reads as if the CPU will do it anyway.

[cpc4eva]

don't know if its already been posted but i just came across this in AA issue 6 March 1986 - article on the Amstrad Computer Show stated that a German company called Vortex were / had been working on a MS DOS board for the CPC 6128.

Anyone know if this did get released ?

[RobertM]

Well I changed the port addressing in my BASIC code to match the fact that two address signals were swapped and after one or two other code edits I had "Hello World" on the CPC6128 screen.

The significance being that I used A hex editor (HxD) on my Windows desktop computer to enter the "Hello World" directly into the beginning of sector 1.

I still get RAM corruption on the CPC. I will change the VHDL and try that. If that doesn't fix it them I will do a mod so that I have access to M1 (OP CODE fetch) inside the CPLD.

[seanb]

"Just about everyone in the Amstrad world was here, with the notable exception of Alan Sugar. But he wasn't really missed"

 

[RobertM]

Another new day.

A changed the VHDL so that no IO can occur when M1 is low. In hindsight that shouldn't matter because there is no RD or WR on the INT OP / Vector Fetch cycle of Interrupt modes 0 and 2.

I removed the CF card and tested and I get no memory corruption when the CF card is removed.

There are no direct connections to the CF card except the 5Volts and ground. Everything else goes through a buffer (and level translator) 74HC245. The only thing that can get back is the data bus which goes through a tristate buffer as well. I checked the VHDL for that and it seems fine.

So now I am left with two things that I can think of -

1) A problem in the VHDL that allows the CF to OUTPUT to the Buffer chip when the chip is also outputing to the CF card - and causing higher current drain, dropping the 5Volt rail and effecting the CPC that way.

2) Perhaps I still haven't solved the power issue. I am getting about 4.8Volts on the CF interface board after buying a new 3Amp switchmode - was the highest they had.

Oh for a scope right now.

I  am going to spend some time trying random things because I don't have any test equipment.

Here is what I have in VHDL

M1 disables all access
CF_cs0 is related to IORQ and the Address range FEF0 to FEF7
CF_IORD is related to IORQ and RD
CF_IOWR is related to IORQ and WR
The buffer direction is related to CF_IORD
The buffer output enable ir related to CF_IORD or CF_IOWR

as below

databus buffer direction is -
0, Z80 <= CF card
1, Z80 => CF card

sigaddress_range <= ZA(15) AND ZA(14) AND ZA(13) AND ZA(12) AND -- 0x  F
                ZA(11) AND ZA(10) AND ZA(9)  AND NOT ZA( AND  --     E
                     ZA(7)  AND ZA(6)  AND ZA(5)  AND ZA(4) AND      --     F
                     NOT ZA(3);                                      --     0 to 7


sigcf_cs0 <= NOT (sigaddress_range AND (NOT Z_IORQ) AND Z_M1);

sigcf_iord <= NOT (sigaddress_range AND (NOT Z_IORQ) AND (NOT Z_RD) AND Z_M1);

sigcf_iowr <= NOT (sigaddress_range AND (NOT Z_IORQ) AND (NOT Z_WR) AND Z_M1);

sigcfdatadir <= sigcf_iord;

sigcfdata_oe <= NOT ((NOT sigcf_iord) OR (NOT sigcf_iowr));   --NOT ((NOT sigcf_cs0) AND ((NOT Z_RD) OR (NOT Z_WR)));

sigcf_reset <= '1';

the code actually reads the sector or part of the sector (correctly) before crashing. When it crashes I get errors like sn error in line ... and a look at the line shows data corruption - ie incorrect basic keywords inserted into line.

[RobertM]

Ok I did the random things -

Put a wire directly from the 5v (after the switch) to the expansion port.

I found 0.1 Ohms in the crimp connector for the power switch plug and soldered them and re-terminated the other end of the wires on the switch.

Now I get 4.81 Volts on the CF interface board.

Other than that - no change - still getting RAM corruption. Allways seems to be the same line of BASIC code that gets corrupted.

I should go read what the line does - that might be a clue.

I am running out of ideas other than that.

[TFM]

don't know if its already been posted but i just came across this in AA issue 6 March 1986 - article on the Amstrad Computer Show stated that a German company called Vortex were / had been working on a MS DOS board for the CPC 6128.

Anyone know if this did get released ?

Yes, it got released. But it was expensive. I saw it running, but don't know anybody currently who would own it. It was an interesting machine though.

[RobertM]

I haven't given up here. I am just re-thinking my strategy.

[cpc4eva]

Yes, it got released. But it was expensive. I saw it running, but don't know anybody currently who would own it. It was an interesting machine though.

maybe someone out there has one, it would be a rare item indeed.

[RobertM]

OK This was on the back burner for a long time.

I ordered a Disk On Module (DOM) and tried it and it worked first time.

I then made an adapter and tried a 2.5 inch PATA Hard Disk Drive and it works fine to. I had to use a second power supply though.

So the problem wasn't between the 3v3 CPLD and the level translator - the problem was between the level translator and the CF card. The drop in voltage on the 5 Volt line meant that the Voh from the level translator was lower (with noise) than the CMOS Vih of the CFCard (4v7 from memory).

Anyway now I need to worry about software.

I previously looked inside the CPC 6128 and it didn't look like I could fit a ZIF in there for the rom(s?).

Is there an existing TSR or RSX that extends the existing Amstrad Disk functions to an IDE device?

Is it better for me to mod a ROM or just add and external ROM?

My setup is the eight port addresses (I think 4 are used in 8 bit mode) that other older CPC-IDE hardware has. ie - It's a standard 8 bit IDE port like on 8 bit mode of the original IBM AT.

That might sound confusing ! and it is confusing ! There is an 8 bit AT mode that it NOT an 8 bit XT mode and that is what has been used by others and that is what is supported by CF cards! CF cards do NOT! support the 8 bit XT mode.

What I want is to add the RSX "|c" that extends the featured like RUN" load" cat |dir to the hard drive.