Compact Flash adaptors

[Steve Cousins]

Hi all

Here's a product recommendation.

The Compact Flash adaptor I use is the "Sintech - Flash Compact (CF) Female To 3.5" 40 Pins IDE Adapter" (Amazon's description), pictured below with my prototype LiNC80 SBC.

It seems to work well.

I really like this device as it mounts directly on the SBC, although that does mean the height could be an issue for some.

I got mine from Amazon (UK) for £8.66

https://www.amazon.co.uk/gp/product/B000REZSJC/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1

However, there are cheaper adaptors on eBay that look to be the same device.

eBay from China for £0.99:

https://www.ebay.co.uk/itm/1PCS-Compact-Flash-CF-to-3-5-Female-40-Pin-IDE-Bootable-Adapter-Converter-Card-U/192049670928?epid=834614544&hash=item2cb70d6b10:g:9MEAAOSwA3dYS8~~

eBay from UK for £2.99:

https://www.ebay.co.uk/itm/Compact-Flash-CF-to-3-5-Female-40-Pin-IDE-Bootable-Adapter-Converter-UK-SELLER/272887095961?hash=item3f8956a299:g:oVsAAOSwXhZZ4cs2

eBay from UK for £2.31:

https://www.ebay.co.uk/itm/Compact-Flash-CF-to-3-5-Female-40-Pin-IDE-Bootable-Adapter-Converter-ZG/112916645491?hash=item1a4a5b4673:g:eL8AAOSwK6RZEiBt

I have not tried any of these cheaper products, but they definitely look like the same thing.

Steve

ps. is it adaptors or adapters ????

[Steve Cousins]

I decided to get a second Compact Flash IDE adaptor.

I purchased, on eBay, a much cheaper version of the above adaptor.

https://www.ebay.co.uk/itm/272887095961

This version works fine and looks very similar to the one I got from Amazon.

The only significant difference I can see is that the cheaper version is made with a much thinner circuit board material, so it is not as strong. But it seems fine.

I suspect this is actually one of the really cheap models that can be obtained direct from China for about a third the price I paid.

If you get one make sure you check the voltage jumper is set for 5 volts. The one I got was supplied set for 3.3 volts despite the label saying 5 volts is the default. That or I've got it all backwards!

So far a good purchase.

Steve

[Chris Scullion]

I picked up this one on Amazon: https://www.amazon.com/gp/product/B001HZ5HMS/ref=oh_aui_detailpage_o00_s01?ie=UTF8&psc=1

It works fine, though beware that it gets plugged in opposite to the way pictured in the first post of this thread.

[Cube Central]

Chris, that is the same adapter identified as "M1" in the chart in my new post about IDE CF card adapters.

If you would, please try out the test program, also attached in that post, here

I would be VERY interested to see the results, if you're able to run it for several hours that would be best, but usually I found failures fairly soon.

Thanks, cheers!

    -Randal   (at CubeCentral)

[Cube Central]

Steve, that adapter I think is identical to the one I listed as "Q1" in the new post about IDE/CF card adapters.

I would be very interested in the results, if you would run the BASIC test program I've attached in that post.

Please try it out, and do let me know of your results after several hours.  I did see failures fairly quickly on mine.

Thanks and Cheers!

    -Randal   (at CubeCentral)

[Chris Scullion]

I'm not sure what the expected output should be.  Here's what I got after a couple minutes:

run

Random number seed (-32768 to 32767)? -15378

AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz

Configured for 15 drive letters A: to O:

W>K:MI1.MMM   V<K:MI1.MMM   C>O:MI1.MMM   V<O:MI1.MMM    .246094  20238 

W>I:MK2.MMM   V<I:MK2.MMM   C>M:MK2.MMM   V<M:MK2.MMM    .738281  20238 

W>E:DI3.MMM   V<E:DI3.MMM   C>O:DI3.MMM   V<O:DI3.MMM    1.47656  20238 

W>C:HS4.MMM   V<C:HS4.MMM   C>K:HS4.MMM   V<K:HS4.MMM    2.46094  20238 

W>I:YK5.MMM   V<I:YK5.MMM   C>G:YK5.MMM   V<G:YK5.MMM    3.69141  20238 

W>J:JF6.MMM   V<J:JF6.MMM   C>D:JF6.MMM   V<D:JF6.MMM    5.16797  20238 

W>A:YX7.MMM   V<A:YX7.MMM   C>H:YX7.MMM   V<H:YX7.MMM    6.89063  20238 

W>A:YX8.MMM   V<A:YX8.MMM   C>E:YX8.MMM   V<E:YX8.MMM    8.85938  20238 

W>M:ED9.MMM   V<M:ED9.MMM   C>F:ED9.MMM   V<F:ED9.MMM    11.0742  20238 

W>K:OF10.MMM  V<K:OF10.MMM  C>D:OF10.MMM  V<D:OF10.MMM   13.5352  20236 

W>K:UH11.MMM  V<K:UH11.MMM  C>I:UH11.MMM  V<I:UH11.MMM   16.2422  20236 

W>G:AE12.MMM  V<G:AE12.MMM  C>K:AE12.MMM  V<K:AE12.MMM   19.1953  20236 

W>K:IS13.MMM  V<K:IS13.MMM  C>H:IS13.MMM  V<H:IS13.MMM   22.3945  20236 

W>K:OV14.MMM  V<K:OV14.MMM  C>B:OV14.MMM  V<B:OV14.MMM   25.8398  20236 

W>L:PY15.MMM  V<L:PY15.MMM  C>J:PY15.MMM  V<J:PY15.MMM   29.5313  20236 

W>D:EZ16.MMM  V<D:EZ16.MMM  C>L:EZ16.MMM  V<L:EZ16.MMM   33.4688  20236 

W>O:LY17.MMM  V<O:LY17.MMM  C>D:LY17.MMM  V<D:LY17.MMM   37.6523  20236 

W>J:VN18.MMM  V<J:VN18.MMM  C>B:VN18.MMM  V<B:VN18.MMM   42.082  20236 

W>J:JE19.MMM  V<J:JE19.MMM  C>G:JE19.MMM  V<G:JE19.MMM   46.7578  20236 

W>N:KB20.MMM  V<N:KB20.MMM  C>D:KB20.MMM  V<D:KB20.MMM   51.6797  20236 

W>B:UH21.MMM  V<B:UH21.MMM  C>I:UH21.MMM  V<I:UH21.MMM.

Syntax error in 1260

Ok

1260 

[CubeCentral]

Chris, this shows an issue as suddenly there is a “Syntax Error” on a line that has been run at least several hundred times.  This shouldn’t happen.

The starting output is as expected, it is writing (W) then verifying (V) on one partition, then copying (C) and then verifying that copy.

It ran through nearly 22 loops and wrote about 51K.

Please try again and see if you get different results.  I assure you the “Syntax Error” is NOT my code, but some sort of corruption in memory that is happening.

 

    -Randal   (at CubeCentral)

--
You received this message because you are subscribed to the Google Groups "LiNC80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linc80+un...@googlegroups.com.
To post to this group, send email to lin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/linc80/6fe26acd-baf7-44f0-be35-bb716f4a395b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Scullion]

I have tried it several times and get similar results each time, though at different points in the run, and syntax errors at different lines.

Sorry if I'm being obtuse, but I don't understand what you're trying to do.  Are you saying that there are CF adapters that work, while others do not?  Or are you saying that the LiNC80 has a problem that affects all CF adapters?  This sure looks like a software problem to me... what has lead you to suspect a hardware problem?

[Cube Central]

Chris, thanks for asking some good questions, and I will try to make clear my understanding of what is going on.

In my other post, I detail testing five different IDE to CF adapters.  I use this BASIC test program to perform those tests on both the RC2014 and the ZiNC80 SBC1.  There are clearly adapters that work on the RC2014 that do not work with (my) LiNC80 SBC1.  The failures show themselves in different ways:

1) The entire system will hang and not be responsive and I must press the reset button.

2)  Random "Syntax Errors" or other nonsensical errors on program lines that have been executed hundreds of thousands of times before, stopping the program.

3)  As with my "Modulus Madness" post, the program gives results that make no sense, such as reporting that 1+1=3, but the program continues running.

4)  Occasionally data written to the CF card, will be read back incorrectly, or copied wrong, or verified to be bad.

What conclusions can I begin to draw from each of these above failures in turn, as I believe them to be interconnected in some way?

1)  I am unable to diagnose why it hung, but I suspect that some critical portion of the programs "stack" or memory has become corrupted.

2)  As it may look like a software problem, or a bug in the BASIC program, it isn't, it cannot be.  If a line is executed correctly the first time, it should continue to be executed correctly every other time it is encountered. The "Syntax Error" is a symptom of a larger problem.

3)  This may be a symptom of a similar memory corruption, but occurs perhaps when a "bitwise" operation is performed in memory.  

4)  If we assume that the CF card and adapter are performing as they should, identical read-back of written data should occur.  Perhaps the data is being corrupted on its way to or from the CF card.  It's difficult to say.

Since I am no expert, and I have never designed a PCB or a computer, please understand that I am approaching this from an analytical view, and I do not have any concrete evidence of what is, in fact happening.  But I can guess.

My guess is that somehow memory locations are being corrupted.  I don't understand the exact mechanism as it isn't repeatable in any recognizable pattern.  If the answer 1+1=3 always occurs then that is a clue, but it isn't that clear - it isn't an "off by 1 byte" error or some other pattern I can find.  If it were just the IDE Bus or attached devices it would only occur when IDE reads or writes happen, but since - as you saw - the program is stopping on a line that once was perfectly fine to execute, it must be more than just the IDE Bus.  (again, see the results of the "Modulus Madness" post)  

Why there seems to be a difference between IDE/CF Card adapters might give us a clue.  Perhaps the ones operating while directly connected to the board are giving off more noise and exacerbating any existing memory corruption issue.  As my post detailing the testing shows, I am able to use all of these adapters in the RC2014, and only the adapters that aren't directly connected to the LiNC80 SBC1.  Could simple noise the the culprit?  What makes Ed Brindley's IDE Adapter different than the IDE connection on the LiNC80 SBC1?  What is the RC2014 doing that is different than the SBC1?

What if it is a systemic issue, something about the design or function of the LiNC80 SBC1?  As I said, this is where I have no experience, so I couldn't begin to say what faults might lay with the design or function.  I have no desire to cast a shadow on an excellently documented and wonderfully put together kit.  I would be the last to wish it to be some fundamental flaw.

What we need is more data, I think.  If everyone that has a LiNC80 SBC1 would run the IDE Test Program, as you have done,  and the Modulus program we can perhaps put to rest the question of "Is this just my system?" or "did I mess something up assembling it?"  If they all fail in the ways I've listed above, we have a more complete picture of what is going on.  If only mine and yours fail, then we must endeavor to find what is the same with our two systems, but different than all the rest.

I hope that this has shed some light on my thought process and has answered your questions.  Unfortunately I do not, as of yet, have any concrete answers, only questions.  Please do let me know if you or anyone else has more questions, or would like more or different tests to be run.

I would love to see an assembly language level program of the Modulus test, so that we could rule out BASIC.  Alas, I have not retained the assembly language skills from all those decades ago, but I am trying to get it back - perhaps someone could step up to that challenge?

    -Randal   (at CubeCentral)

[Chris Scullion]

Very thorough... thanks.

My money is on a memory leak in the BIOS or BDOS, probably due to some hardware difference that wasn't accounted for.  Your MOD problem  doesn't use the CF adapter at all, so I don't see how that could be a cause... unless you have tested your MOD program with different adapters and see success with cable-attached ones?  I have a second, cable-attached CF card arriving tomorrow, so I'll try both programs with both adapters and report results.

Also, I'm curious if you see the same MOD problem when you run it in ROM BASIC mode (no CP/M)?

[Cube Central]

Chris, I am replying here in case you didn't see my answer in another thread:

There isn't a "MOD" operator in the version BASIC on the ROM.  Without it, I would have to find or discover another function that is testable in the same way.  So much for trying it without an IDE/CF adapter.  

And as far as running the MOD program with different CF Adapters as I did for my "IDE CF Adapter Testing" post, I'm sure that I have at different stages but haven't gone to the lengths of documenting it as thoroughly.  I suspect that the noise issue which is causing the "Media Mayhem" program to fail, will also cause the "Modulus Madness" program to fail.  It would be an interesting test, and the next time I have all five adapters free and some time, I will try it out.  Thanks for the idea, I sure appreciate it.  Please update with your testing when you can.  Cheers!

    -Randal   (at CubeCentral)

[Chris Scullion]

Well, here's a pro tip for you:

If you plug the CF IDE adapter in one row off (holes 1 and 2 plugged in to pins 3 and 4), it fries the CF card and the adapter.  I am out of commission until replacement parts arrive (Friday).

What I managed to run before that disaster was a modified version of MOD Madness on the ROM BASIC without the CF adapter installed.  I had to replace the INKEY$ to get it to run (I just output the value of X every time through that line). I got no error on the MOD line itself (I added an END after the error print so I wouldn't miss it if it happened even once), so I'm not sure about your comment about MOD not being supported.  Anyway that version of the program ran for 10 minutes or so before I killed it.  I also stopped work on the LiNC80 for the night so that I didn't cause any more damage.  I might check on that MOD in ROM BASIC if I get up the nerve later tonight.

I also ran Mod Madness on the RC2014 in CPM and it ran for hours without issue.  I know you are suspecting a hardware problem, but I still think there's a possibility of a software problem.  I'm thinking of writing a memory test program in assembly language to see if my suspicion is correct.

[Jon Langseth]

On Wednesday, May 30, 2018 at 12:33:59 AM UTC+2, Chris Scullion wrote:

Well, here's a pro tip for you:

If you plug the CF IDE adapter in one row off (holes 1 and 2 plugged in to pins 3 and 4), it fries the CF card and the adapter.  I am out of commission until replacement parts arrive (Friday).

Ouch! I'm so sorry to hear this. Unfortunately reverse polarity often does that to electronics, and there's no good way I can prevent that except removing P20VCC support and adding a shrouded connector. I wish those shrouded 40-pin connectors weren't so stupidly expensive compared to the "naked" ones :(

[Cube Central]

Oh no Chris!  I am so sorry to hear that!  Maybe a keyed "boxed" connector would go on my wish list for future versions?

I am certain that the MOD statement is doing anything in ROM BASIC.  I think that it is treating it like some variable and not a function.  Here's a quick test, while in BASIC, type:

PRINT 7 MOD 5

and you will get output:

 7  0 

Ok

if you type

PRINT (7 MOD 5)

you will get

?SN Error

Ok

Rather than the answer of "2" which is what the BASIC from CP/M does - it actually performs the calculation.  This is not performing any calculation and therefore the test program isn't valid.

Additionally, there is no INKEY$ function in ROM BASIC, so that line is not going to ever evaluate to true.

Just to clarify, so I understand.  When I boot my LiNC80 SBC1 I can go into ROM BASIC like so:

*BASIC

Memory top? 

Z80 BASIC Ver 4.7b

Copyright (C) 1978 by Microsoft

47811 Bytes free

Ok

I found a PDF for the manual this version of ROM BASIC is based upon, and there is no mention of a MOD operator (or INKEY$)

I am sorry about your system and hope that it can be repaired easily.  Please do let me know if there are additional questions, or if your findings don't agree with what I have.  I just want to be clear so that I don't get confused.  Thanks again for your help!!

    -Randal   (at CubeCentral)

[Jon Langseth]

On Wednesday, May 30, 2018 at 1:31:21 AM UTC+2, Cube Central wrote:

Just to clarify, so I understand.  When I boot my LiNC80 SBC1 I can go into ROM BASIC like so:

*BASIC

Memory top? 

Z80 BASIC Ver 4.7b

Copyright (C) 1978 by Microsoft

47811 Bytes free

Ok

I found a PDF for the manual this version of ROM BASIC is based upon, and there is no mention of a MOD operator (or INKEY$)

There is two copies of Nascom ROM BASIC from Microsoft in ROM, one SCMon-launched via the BASIC keyword, and one that can be started via GSL.
Both are based on the 80-BUS code adapted by Grant Searle, as per the source code at https://github.com/linc80/z80sbcFiles/blob/master/source/basic.asm

Randal is correct about the MOD and INKEY$ statements not being implemented in this version of BASIC.

The link to Philip's copy of the manual is also correct. I should probably host a copy of that as well :)
Oh, and ... I'll cross-copy a bit, as this should probably be in the other thread....

[Steve Cousins]

Hi Randal/Chris/Jon ..and anyone else watching.

I've been running some tests on my system. I'm not sure which of the topics to post this in, but I guess you'll all see it.

Below (way below!) is the log of my tests with MM8.BAS, MODCHK4.BAS and my own compact flash test program.

My system seems generally stable. It is a pre-release model which has had lots of use over more than two months, particularly in developing SCMonitor and associated software. I don't use it much for CP/M. I have a direct connection compact flash adapter.

During development and testing I experienced a few issues with compact flash access, although it should be noted I have been trying to create problems in order to develop robust software. I have obtained a couple of faulty/unreliable cards to test my software with. How many genuine problems I've seen is hard to tell in this environment. I think with decent CF cards my system is reliable.

The few formal tests I've done on compact flash access have yet to give me any sensible statistical results. To reach any conclusion I would need to run days more tests with different cards and on different systems.

In summary.

My system fails both MM8 and MODCHK4 in a few seconds to a few minutes. This surprised me given the track record of my system.

The bigger of the surprises is the MODCHK4 program, which is just number crunching. I've seen nothing to make me think my system has problems with that kind of test.

However, I have not done much with CP/M and this was my first use of MBASIC.

Given that an MBASIC number crunching program fails, which has no compact flash reading/writing, I think, for now, the compact flash failures should be considered as symptoms of CPM/MBASIC issues.

Testing should concentrate on the failures with the least dependencies.

I thus agree with the idea of doing tests with ROM BASIC to see if it is CPM/MBASIC only that fails.

Once the cause of the MBASIC number crunching failures is determined and fixed, we can re-visit the compact flash test.

There seem to be two possibilities:

Chris said "My money is on a memory leak in the BIOS or BDOS, probably due to some hardware difference that wasn't accounted for."

This could explain why my system only seems unstable with MBASIC programs. But the random element is still a mystery.

The other is electrical noise, which is already being discussed.

I do have an electrically very noisy fridge which could account for occasional failure here but not all the failures detailed below.

I think it may take a while to resolve this!

"After seven and a half million years, the super computer Deep Thought finally reveals the ultimate answer...."

Hopefully not that long.

My test results:

Tera Term

Using LiNC80 SBC1 with SCMonitor v1.0.0 

Testing with MM8.BAS...

This is how I built the test environment:

Send file: 

SCWorkshop017_SCMonitor100\SCWorkshopProjects\CPM v2.2 Format\Format_CF128_code8000.hex

G8000

Send file: 

SCWorkshop017_SCMonitor100\SCWorkshopProjects\CPM v2.2 PutSys Plus\PutSys_LiNC80_SIO_CF128_code8000.hex

G8000

Send file: 

SCWorkshop017_SCMonitor100\SCWorkshopProjects\\CPM v2.2 Download.com\SCMon_LiNC80_Download_code8000.hex

G8000

cpm

save 2 download.com

Set terminal delays to 1 ms/char and 1 ms/line

Sent Grant style package of MBASIC.COM  v5.21

Set terminal delays to 1 ms/char and 50 ms/line

Send file: MM8.BAS

Running MM8.BAS...

Random number seed (-32768 to 32767)? 1000

AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz

Configured for 15 drive letters A: to O:

W>E:RC1.MMM   V<E:RC1.MMM   C>J:RC1.MMM   V<J:RC1.MMM    .246094  20238

W>C:GH2.MMM   V<C:GH2.MMM   C>E:GH2.MMM   V<E:GH2.MMM    .738281  20238

W>K:LQ3.MMM   V<K:LQ3.MMM   C>M:LQ3.MMM   V<M:LQ3.MMM    1.47656  20238

W>A:PD4.MMM   V<A:PD4.MMM   C>O:PD4.MMM   V<O:PD4.MMM    2.46094  20238

W>F:FZ5.MMM   V<F:FZ5.MMM   C>A:FZ5.MMM   V<A:FZ5.MMM    3.69141  20238

W>G:GW6.MMM   V<G:GW6.MMM   C>D:GW6.MMM   V<D:GW6.MMM    5.16797  20238

W>B:MC7.MMM

Program hung

Reboot and ran again

run

Random number seed (-32768 to 32767)? 5

AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz

Configured for 15 drive letters A: to O:

W>C:GC1.MMM   V<C:GC1.MMM   C>M:GC1.MMM   V<M:GC1.MMM    .246094  20238

W>L:LY2.MMM   V<L:LY2.MMM   C>G:LY2.MMM   V<G:LY2.MMM    .738281  20238

W>H:QW3.MMM   V<H:QW3.MMM   C>B:QW3.MMM   V<B:QW3.MMM    1.47656  20238

W>B:XU4.MMM   V<B:XU4.MMM   C>N:XU4.MMM   V<N:XU4.MMM    2.46094  20238

W>N:TM5.MMM   V<N:TM5.MMM   C>G:TM5.MMM   V<G:TM5.MMM    3.69141  20238

W>G:KH6.MMM   V<G:KH6.MMM   C>N:KH6.MMM   V<N:KH6.MMM    5.16797  20238

W>N:QN7.MMM   V<N:QN7.MMM   C>H:QN7.MMM   V<H:QN7.MMM    6.89063  20238

W>L:ZM8.MMM   V<L:ZM8.MMM   C>F:ZM8.MMM   V<F:ZM8.MMM    8.85938  20238

W>F:UM9.MMM   V<F:UM9.MMM   C>N:UM9.MMM   V<N:UM9.MMM    11.0742  20238

W>D:WO10.MMM  V<D:WO10.MMM  C>C:WO10.MMM  V<C:WO10.MMM   13.5352  20236

W>E:KB11.MMM  V<E:KB11.MMM  C>G:KB11.MMM  V<G:KB11.MMM   16.2422  20236

W>D:JF12.MMM  V<D:JF12.MMM  C>I:JF12.MMM  V<I:JF12.MMM   19.1953  20236

W>M:PD13.MMM  V<M:PD13.MMM  C>I:PD13.MMM  V<I:PD13.MMM   22.3945  20236

W>H:DE14.MMM  V<H:DE14.MMM  C>D:DE14.MMM  V<D:DE14.MMM   25.8398  20236

W>H:QH15.MMM  V<H:QH15.MMM  C>K:QH15.MMM  V<K:QH15.MMM   29.5313  20236

W>L:TD16.MMM  V<L:TD16.MMM  C>F:TD16.MMM  V<F:TD16.MMM   33.4688  20236

W>G:IG17.MMM  V<G:IG17.MMM  C>C:IG17.MMM  V<C:IG17.MMM   37.6523  20236

W>B:ZN18.MMM

Program hung

Testing with MODCHK4.BAS...

Loaded MODCHK4.BAS by sending from terminal

run

Random number seed (-32768 to 32767)? 234

ERROR!  A= 24720  B= 18961  C= 5759  D= 24720  X= 86

ERROR!  A= 13064  B= 30699  C= 13064  D= 6.28825E+13  X= 94

CHECK:  A= 581  B= 29681  C= 581  D= 581  X= 270

CHECK:  A= 16549  B= 21655  C= 16549  D= 16549  X= 1073

CHECK:  A= 15367  B= 25749  C= 15367  D= 15367  X= 1133

^C

Break in 110

Ok

run

Random number seed (-32768 to 32767)? 234

Division by zero in 100

Ok

Re-ran program

and within a few seconds it crashed:

run

Random number seed (-32768 to 32767)? 55

AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz

Configured for 15 drive letters A: to O:

W>G:ZS1.MMM   V<G:ZS1.MMM   C>H:ZS1.MMM

                                        LiNC80 CP/M BIOS 1.2 by G. Searle 2007-18

CP/M 2.2 Copyright 1979 (c) by Digital Research

Testing with my compact flash test program...

Reset (leaving everything exactly as it was above)

Ran my own compact flash test (started ~11:00)

This is the program included with SCWorld distribution 0.1.7

After about 1.5 hours the porgram reported a verify error.

A verify error being that a read back does not give the expected data.

My program allows the read part to be repeated and again the error was seen.

I repeated this multiple times.

This indicates the error is a write failure as a random read error would not be repeatable.

Note, my program checks for and reports any error detected by the card of which there were none.

I continued the program starting at the next sector.

Ran without problems for another hour or so.

Restarted the test to see if it failed at the same location but it didn't.

It appears there was a single non-repeatable write error.

The program has now be running a total of 7 hours with just that one error.

My test program is written in assembler as an SCMonitor App, so it does not use BASIC or CPM.

Conclusion...

Is one error in 7 hours of continuous reading and writing an indication of a problem???

My fridge is electrically very noisy whien the pump stops. It causes my speakers to crackle 

and sometimes my monitor blanks for about a second. Could this be what caused the write 

failure??? If so is that just life???

I don't have enough statistical info to answer the above questions.

Even if my test program is showing a fault in the system as a whole it is nothing like the 

regularity as the two BASIC test programs. Also my system does not show any other instability,

just the odd problem with compact flash access.

[Jon Langseth]

Thank you for your thorough examination.

I find it hard to take a software fault like a memory leak to be at fault. So far we have three reports of issues running the modchk4/5 or mm8 basic files, along with two reports of no issues. We also have a report of issues that are no longer present after replacing the power source. I was thinking that a possible reason we are able to more reliably run code from ROM than to run code loaded from CF may perhaps be because any connected CF card has not been initialized yet, and thus does not actively take part in the system. But I struggle with that explanation, because as the CF card is basically run in a register based approach, it should not make much difference if it is initialized or not.

Currently I have MODCHK4.BAS running, and it has been running without errors for close to 6 hours now. At this point, I'd almost wish I could report that I too had experienced errors with running Randal's BASIC code. That would give me a direct vector to dig into electronically.

[CubeCentral]

Steve, thank you for your testing and report!

 

I want to briefly repeat something in another thread to answer the statement where you said:

“I thus agree with the idea of doing tests with ROM BASIC to see if it is CPM/MBASIC only that fails.”

 

I agree with you that it would be best to try running the tests in a simplified system to remove variables, but unless we can put a different version of the ROM BASIC on the chip, I am unable to run the MODCHK program in the supplied ROM BASIC as it lacks the MOD operator.  The thinking behind that test is the MOD operator is failing (or showing the symptom) and that the alternative way of arriving at a modulus computation is working correctly.  Without the MOD operator, that computation can only take place the alternative way with no other way to compute a check.

 

I have the tools to be able to write a new EEPROM, but not the knowledge or skills to adapt the CPM version of MBASIC to a ROM-runnable one.  If we find a different version of ROM BASIC (and it contains the MOD operator) perhaps it could be put on a ROM?  I don’t know.

 

Thanks again, and I will try to do some testing this afternoon after applying some noise suppression chokes to the power supply and power input.

 

    -Randal   (at CubeCentral)

 

 

From: lin...@googlegroups.com [mailto:lin...@googlegroups.com] On Behalf Of Steve Cousins
Sent: Wednesday, May 30, 2018 12:26
To: LiNC80 <lin...@googlegroups.com>
Subject: [linc80] Re: Compact Flash adaptors

 

Hi Randal/Chris/Jon ..and anyone else watching.

--

You received this message because you are subscribed to the Google Groups "LiNC80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linc80+un...@googlegroups.com.
To post to this group, send email to lin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/linc80/d22acabc-56a0-41a0-817b-ed56c1f8f4f4%40googlegroups.com.

[Robert Grabau]

Steve,
I appear to have the same card as what you bought on fleabay, I got mine
from Amazon.  However, I have run into an interesting issue.  I can read
all day or at least for a while), but I can't write to the CF card. It
appears to write, but when I do a dir, no new file.  I have a generic
128mb CF card that I also got from Amazon.  I did initialize the CF card
on my winders system.

Can you write to your CF card?

AstroBob

> --
> You received this message because you are subscribed to the Google
> Groups "LiNC80" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to linc80+un...@googlegroups.com

> <mailto:linc80+un...@googlegroups.com>.

> To post to this group, send email to lin...@googlegroups.com

> <mailto:lin...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/linc80/aec635f6-4736-488d-8877-cc730c9906a7%40googlegroups.com
> <https://groups.google.com/d/msgid/linc80/aec635f6-4736-488d-8877-cc730c9906a7%40googlegroups.com?utm_medium=email&utm_source=footer>.

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

--
Bob Grabau

http://www.astrohbg.org
http://www.cherrysprings.org

Our Star Party: June 14-17, 2018 Cherry Springs State Park, PA

[Steve Cousins]

Hi Robert

Yes, I can write okay.

I have two similar adapters and multiple CF cards. 

I personally do not initialise the cards on my PC, but on the LiNC80 SBC1.

If you look at my post above you will see a detailed log of some testing I was doing. Within that is a step by step record of how I formatted the card, installed CP/M on it and added files.

Included with the SCWorkshop+SCMonitor download are all the utilities I use. These included a compact flash test program which can be quickly downloaded to SCMonitor and run without any further setting up. You could try this to help you check the card/adapter/LiNC80 are working.

Steve

> an email to linc80+unsubscribe@googlegroups.com
> <mailto:linc80+unsubscribe@googlegroups.com>.

> To post to this group, send email to lin...@googlegroups.com

> <mailto:linc80@googlegroups.com>.

[Jon Langseth]

I have (as you may expect) tested a few CF cards, and I have experienced
exactly what you mention with one 128MB card and one 512MB card.
Reads work fine, and writes seem to work, but don't actually do anything.
Using software that verifies saves (like Wordstar) will notice this and
produce error messages.

Those are the only two cards that give me this issue out of my stack of
14 CF cards: eight 64MB cards, one 128MB, three 256MB, two 512MB,
one 1GB and one 2GB. I also have a 512MB card that's simply flaky, and
a pair of cards that simply won't work with either my LiNC80 or my RC2014.

Basically, this all boils down to how well the cards are made to work with
the register-based XT-IDE 8-bit mode that we use, and it's a bit random what
cards work reliably, so it's difficult for me to give a clear recommendation
other than what I already have done :(

[Robert Grabau]

Steve,
Well, after a bit of testing and a different CF card that I recently
got, it is the CF Card at fault.  The generic CF cards won't allow
writes (as best as I can tell).  The other CF card, from Spencer Owen's
RC2014 does work just fine.  I have ordered another pair of CF cards and
they will be here tomorrow along with different adapters to try.

So, Buyer beware, not all CF cards will work.
These DON'T!
https://www.amazon.com/gp/product/B07BFC2WG2

AstroBob

> > an email to linc80+un...@googlegroups.com
> <mailto:linc80%2Bunsu...@googlegroups.com>
> > <mailto:linc80+un...@googlegroups.com
> <mailto:linc80%2Bunsu...@googlegroups.com>>.

> > To post to this group, send email to lin...@googlegroups.com

> <mailto:lin...@googlegroups.com>
> > <mailto:lin...@googlegroups.com <mailto:lin...@googlegroups.com>>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/linc80/aec635f6-4736-488d-8877-cc730c9906a7%40googlegroups.com
> <https://groups.google.com/d/msgid/linc80/aec635f6-4736-488d-8877-cc730c9906a7%40googlegroups.com>
>
> >

> <https://groups.google.com/d/msgid/linc80/aec635f6-4736-488d-8877-cc730c9906a7%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/linc80/aec635f6-4736-488d-8877-cc730c9906a7%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> --
> Bob Grabau
>
> http://www.astrohbg.org
> http://www.cherrysprings.org
>
> Our Star Party: June 14-17, 2018 Cherry Springs State Park, PA
>

> --
> You received this message because you are subscribed to the Google
> Groups "LiNC80" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to linc80+un...@googlegroups.com
> <mailto:linc80+un...@googlegroups.com>.

> To post to this group, send email to lin...@googlegroups.com

> <mailto:lin...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/linc80/422cc19e-efe2-440b-b76b-fce3cba953f3%40googlegroups.com
> <https://groups.google.com/d/msgid/linc80/422cc19e-efe2-440b-b76b-fce3cba953f3%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jon Langseth]

In this thread we have had good discussions about issues with stability, where even running a fairly low-impact Modulus test written in BASIC caused incorrect calculations and even system crash and/or hangs. Randal has since done a very thorough test after we started to suspect power supply or noise to be the source of the issues. Thanks to this test, the hypothesis has been confirmed, and the stability issues have been resolved. Please read the post at https://groups.google.com/d/msg/linc80/IaiiOF3u-1M/3rFPZ_OpAwAJ to see the results of Randal's test.

We have also had a confirmation that many of the Direct Plug-in type CF adapters add noise or other interference to the system, leading to instabilities like the ones described by Steve and also discussed in the Modulus Madness thread. The currently recommended IDE CF adapter is still the one made by StarTech, preferably connected using a short IDE cable.

Still, I would love to see reports of other IDE CF adapters that work without stability issues...

Worth noting is also Robert's report that the generic CF card he bought from Amazon are giving him issues, and do not work, as per the quoted message below: