Cad CF Card or CF Card Board?

[Michael Kamprath]

Hi. Suddenly my CF Card board is acting up (RC2014 pro setup). Basically, reading and writing files to a CF card drive does not work correctly. For example, consider this attempt to copy a file from B: to C: on RomWBW v1.9.1-pre5:

C>B:COPY B:LOAD.COM C:

COPY  Version 1.72 (for ZSDOS)   17 Jul 93

Copying B0:LOAD    .COM to C0:

 -> LOAD    .COM..Ok  Verify.. ..Bad

 1 Errors

C>DIR

C: LO2D  2  CO2

 And when I xmodem a file to the system, the file name I use get letters missing in the file name (e.g., ".COM" becomes ".CO").

I've tried replacing the CF Card, but the same behavior persists. 

Does anybody have any idea what might be the problem?

Michael

[Stuart Smith]

If your CF card board isn't close to the CPU board, try moving it closer on teh backplane. Some people have had issues that were cured when placed next to the CPU board.

[Michael Kamprath]

Thanks for the tip. Unfortunately, that hasn't changed anything. 

[Michael Kamprath]

So this is where I stand on things:

• I noticed that one of the pins (pin1 GND) of the CF holder wasn't actually soldered, so I fixed that, ensuring I didn't introduce any bridges.
• I replaced the 74hct138 address decoder. 
• I've refreshed the current and previous RC2014 compatible version of RomWBW
• I've replaced the CF card
• I've replaced the Z80 CPU, the RAM chip and the flash ROM chip
• I've tried multiple card arrangements in my pro backplane

Nothing fixes the situation. I will note that the RomWBW system works fine with the CF card as long as I stick to drives A: (the ram disk) and B: (the ROM disk). I have the dual clock and SIO/2 cards. This all used to work, and only changed after a period of non-use (~2 weeks).

I really don't know what to investigate next. Ideas welcome.

Michael

[Michael Kamprath]

OK, I have a sort of resolution here. I had forgotten I had built the Dr. Scott Baker CF card board, and so I tried that out, jumping for address 10h. That worked just fine, even with the CF cards that didn't work with the official RC2014 CF card board. So I have a real mystery: how does did my RC2014 CF card board suddenly go bad? All the soldering looks good. Other than that GND pin that was loose for the CF socket, all those pins look good. I'm not sure what to make of this. 

Michael

[Spencer Owen]

Hi Michael,

The short and honest answer is I have no idea why it would stop working.  I know you've had the board for a few months now, so I assume it *was* fine when you got it?

I do wonder about the long term resilience of the CF socket to PCB connections, although I've no idea how to simulate "real world" use to test it.  But it is possible that it's become loosened somehow?

If you remove the '138, and follow the schematic for the CF Module, you should be able to test out each pin with a beeper test to its destination.  Check them from the CF side of the socket, although note that the bottom row of pins can be tricky to get a firm connections to.  Most pins go directly to one of the header pins, although some go to the resistors or '138.  (Note that with the '138 in place you'll wonder why there are all kinds of pins shorted out when they shouldn't be. Yeah, I fell for that that once. Or twice!). 

Hope that helps, and I'd be very interested to hear back how you get on.

Cheers

Spencer

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/aef7cd55-8252-4379-a9c8-ab5ff1de1e27%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Kamprath]

Just to follow up here: I went and did continuity testing on every path on the CF card (without the 138 in), and every path checked out fine. I replaced the 138 with a new one in case mine went bad, and I still get the same behavior described earlier in this thread. The CF card works fine the the smbaker CF holder I have, but does not work properly in the original CF holder from Spencer. At this point, my best theory is corrosion of some sort, since the CF holder used to work and then for no apparent reason stopped working. I lack the tools (or patience) to diagnose this further, so I will just build a new card.

Michael

[Michael Kamprath]

The saga continues on this issue. So I purchased a new CF Card unit from Spencer on Tinder. I got it today, built it, and popped it into my RC2014. The exact same behavior occurred. What???

After some more interactions and testing, I realized this behavior of incomplete filenames and general CF card weirdness only occurs with RomWBW CP/M. The version of CPM that Spencer provides on the CF Card works just fine.

Now I am stumped. Does anybody have any ideas what might be happening here?

Michael 

[Spencer Owen]

On Sun, 26 Aug 2018, 08:37 Michael Kamprath, <mic...@kamprath.net> wrote:

So I purchased a new CF Card unit from Spencer on Tinder. 

Damn, my Tinder profile is meant to be secret. I'd recommend people visit Spencer on TINDIE and swipe right though ;-)

With regard to CF not working from RomWBW, are you formatting it from RomWBW first? The two different CP/M versions use different formats so cards are not directly readable from each other.

Spencer on Tindie 

[Richard Deane]

I can also suggest using a hex edit prog on PC to fill entire image with E5 then burn to cf card. Saves init dir on each drive. No use though if you need to boot from cf as it wipes the system tracks, but with romwbw probably not a problem as boot from rom and then syscopy.

I use romwbw as main flavour and it works fine with my two spencer cf cards.
Richard

[Michael Kamprath]

On Sunday, August 26, 2018 at 3:11:46 AM UTC-7, Spencer Owen wrote:

On Sun, 26 Aug 2018, 08:37 Michael Kamprath, <> wrote:

So I purchased a new CF Card unit from Spencer on Tinder. 

Damn, my Tinder profile is meant to be secret. I'd recommend people visit Spencer on TINDIE and swipe right though ;-)

LOL ... sorry, must have been one for those auto corrects I missed. 

 

With regard to CF not working from RomWBW, are you formatting it from RomWBW first? The two different CP/M versions use different formats so cards are not directly readable from each other.

Yes, it is formatted for RomWBW. As I said previously, the same CF Card works fine with SMBaker's CF Card board Looking at the circuit diagrams, the main differences I see are:

• SMBaker has the 74hct138's /E1 and /E2 (or /G2A and /G2B depending on manufacturer's label) driven by IORQ and optionally A4 (which I selected), but your board has them driven by IORQ and A6 (always). 
• SMBaker maps address A5, A6, A7 in to the '138's A, B, C input, but your board maps A3, A4, A5. 
• SMBaker OR's (with a 74hct32) the WR and RD signal with IORQ before feeding them into /IOWR and /IORD (respectively).    

Note that I have my SMBaker board configure to select when A4, A5, A6, A7 are low (that is, I jumped the A4 line and selected the 0x0 address space to get . Your board selects when A4 is high and A3, A5, and A6 are low. I think therein lies the difference (how the A4 line is interpreted and using A3 vs A7), but admittedly I don't readily understand why. Is because of this selection difference the data is laid out differently on the CF Card, hence the reason my card works on one board and not the other?

Am I the only one which can get our CF card to work with RomWBW?

Michael

[Mark T]

From your description you have Spencers card set at base address 0x10, and shadowed at 0x90. Scotts card set at base address 0x00. So they are not both going to work with the same software. I think if you remove the JP3 jumper from Scotts card ( base address 0x00 and repeated at 0x10) and use a build of RomWBW that addresses the card at 0x10 then your cf card should work with both systems.

I think CPM on the CF card from spencer would be written to expect base address of 0x10.

Mark

[Michael Kamprath]

Thanks. I guess this is a part of things I am not familiar. What is meant that the base address is shadowed else where? Also, I guess a more basic question is how do these ports work in general? Is the a good reference on this part of the computer’s hardware design?

Michael

[Mark T]

Maybe take a look at Steve Ciarcia's book for starting with the basics.

https://archive.org/details/BuildYourOwnZ80ComputerSteveCiarcia

The Compact flash card uses three address lines A0,A1 and A2 to select a control or data register in the compact flash card so it occupies 8 input/output addresses. By base address I mean the low address for the first of those register. The addresses for the card in the basic RC2014 would be 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17.

By shadowed I mean that the address for the same compact flash registers can also be addressed at 0x90, 0x91, 0x92 .... 0x97, as the A7 line is not included in the address decoding, but the software is only using 0x10 etc.

Mark

[Crni Mrki]

Greetings!

Same behaviour by me:

B>copy *.* e:

COPY  Version 1.72 (for ZSDOS)   17 Jul 93

Copying B0:????????.??? to E0:

 -> ASM     .COM..Ok  Verify.. ..Bad

 -> ASSIGN  .COM..Ok  Verify.. ..Bad

SC126 and 10e CF module from Karl Albert Brokstad configured for address 10

[karlab]

The most likely reason is that the CF card is bad.

I will send you a new CF card.

Karl

[Crni Mrki]

Thank you Karl, maybe is that reason, I dont know and I have not another CF card to try.

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/a80c9086-682a-4e89-b589-4612a3d3d2b7%40googlegroups.com.

[Crni Mrki]

Update 09.02.2020.

Although I measured the voltage and it was in the range (above 5v) I am tried it with another power supply and now everything worked :-).

The problem is solved!

Thanks everybody.

Bruno