Modulus Madness

333 views
Skip to first unread message

Cube Central

unread,
May 25, 2018, 1:19:16 AM5/25/18
to LiNC80
Howdy All!

This is a follow-up post to my previous post regarding some instability.  I wanted to provide some evidence that modulus arithmetic is not being computed properly on my LiNC80 SBC1.
Attached, and below, please find the BASIC program I created just to test the claim that I had made.  I wanted to comment some on the code and process so that you might understand and try it on your SBC1.  Please download the attached version without all the comments to try and run on your system.  That way there won't be any formatting issues.

I've tried this same code on my RC2014 using the same BASIC and am not able to replicate the results.

10 REM *** PROGRAM: MODCHK4.BAS
20 REM *** CUBECENTRAL LABS 2018
30 REM ***SETUP***
40 Randomize
50 MAX=32766  :  REM Set the maximum value for the integers to test
60 REM ***BEGIN LOOP***
70 B=Int(Rnd*MAX)+1  :  REM Create a pair of integers
80 A=Int(Rnd*MAX)+1
90 X=X+1  :  REM simply a counter
100 C=A Mod B  :  REM the problem statement.  C should be the "remainder" of when A is divided by B
110 Q=Int(A/B)  :  REM begins the alternate computation of the modulus, taking just the integer part of the division
120 P=Q*B  :  REM The result of the previous division is then multiplied by the divisor
130 M=A-P  :  REM the resulting subtraction of the dividend from the previous multiplication is the "remainder" or modulus
140 D=M  :  REM simply setting M to D to keep with naming convention
150 If Len(INKEY$) Then Print "CHECK:  A=";A;" B=";B;" C=";C;" D=";D;" X=";X  :  REM print a status when a key is pressed
160 If C<>D Then GOSUB 200  :  REM In theory, C should ALWAYS equal D.  Always.
170 B=0 : C=0 : D=0 : Q=0 : P=0 : M=0  :  REM Set the variables used back to zero, just in case
180 Goto 60  :  REM Loop the program forever
190 End
200 REM ***ERROR***    The program should never get here, unless the modulus was computed wrong.
210 REM
220 Print "ERROR!  A=";A;" B=";B;" C=";C;" D=";D;" X=";X  :  REM Show the values of the variables
230 REM STOP
240 Return

The results of one program run follow:

RUN
Random number seed (-32768 to 32767)? 999
CHECK:  A= 22311  B= 17568  C= 4743  D= 4743  X= 41 
ERROR!  A= 494  B= 18487  C= 481  D= 494  X= 268 
CHECK:  A= 5224  B= 19084  C= 5224  D= 5224  X= 269 
ERROR!  A= 4163  B= 674  C= 118  D= 119  X= 1229 
CHECK:  A= 31230  B= 5615  C= 3155  D= 3155  X= 3825 
ERROR!  A= 19369  B= 15941  C= 3427  D= 3428  X= 5471 
ERROR!  A= 21461  B= 20444  C= 1016  D= 1017  X= 5651 
ERROR!  A= 10608  B= 29654  C= 10593  D= 10608  X= 5773 
ERROR!  A= 5192  B= 21111  C= 5187  D= 5192  X= 6200 
ERROR!  A= 23739  B= 22703  C= 19329  D= 1036  X= 8650 
ERROR!  A= 19015  B= 18972  C= 18065  D= 43  X= 10087 
ERROR!  A= 11233  B= 9991  C= 1241  D= 1242  X= 11373 
ERROR!  A= 4042  B= 7856  C= 19772  D= 4042  X= 11922 
ERROR!  A= 14807  B= 31599  C= 14804  D= 14807  X= 12003 
ERROR!  A= 24598  B= 24654  C= 20031  D= 24598  X= 12024 
ERROR!  A= 21467  B= 2020  C= 19361  D= 1267  X= 14040 
ERROR!  A= 13335  B= 23944  C= 13332  D= 13335  X= 14631 
ERROR!  A= 19689  B= 16626  C= 2966  D= 3063  X= 16193 
ERROR!  A= 19786  B= 25803  C= 19777  D= 19786  X= 16198 
ERROR!  A= 2617  B= 9696  C= 19624  D= 2617  X= 17327 
ERROR!  A= 10417  B= 16412  C= 10416  D= 10417  X= 17554 
ERROR!  A= 4071  B= 29556  C= 19774  D= 4071  X= 17755 
ERROR!  A= 24279  B= 10098  C= 4004  D= 4083  X= 17872 
ERROR!  A= 4275  B= 21539  C= 19845  D= 4275  X= 19651 
ERROR!  A= 16218  B= 14825  C= 19382  D= 1393  X= 20200 
ERROR!  A= 18362  B= 3740  C= 19735  D= 3402  X= 20393 
ERROR!  A= 19852  B= 16321  C= 19742  D= 3531  X= 21301 
ERROR!  A= 8426  B= 19086  C= 8417  D= 8426  X= 22065 
ERROR!  A= 14287  B= 18722  C= 14286  D= 14287  X= 22100 
ERROR!  A= 19568  B= 14571  C= 19871  D= 4997  X= 22956 
ERROR!  A= 31626  B= 22149  C= 9475  D= 9477  X= 23214 
ERROR!  A= 3986  B= 22156  C= 3976  D= 3986  X= 23245 
ERROR!  A= 28982  B= 3095  C= 19338  D= 1127  X= 23934 
ERROR!  A= 13835  B= 744  C= 442  D= 443  X= 25113 
ERROR!  A= 318  B= 23895  C= 316  D= 318  X= 26120 
ERROR!  A= 11435  B= 27584  C= 11432  D= 11435  X= 26223 
ERROR!  A= 29026  B= 10786  C= 20009  D= 7454  X= 28647 
ERROR!  A= 20027  B= 28294  C= 19976  D= 20027  X= 29791 
^C
Break in 90
Ok

You can see that it isn't even that rare of an error!  C should always equal D.  I've tried computing the "C" results in different number bases, comparing them to the "D" results, subtracting 32767 or other numbers, but haven't gotten very far.  Perhaps someone here will be able to look at these results and compute what is going on.  I believe a bitwise operation is happening somewhere that might be the cause, but am not at all sure how the BASIC assembly source looks or how to read it.  As I said, this seems specific to the SBC1 and am unable to replicate it on my RC2014.  I've tried swapping the LOW and HIGH RAM chips in case one of them was flaky, but it didn't make any difference.

Please do let me know if you would like me to try a different test, or formula and I would be happy to do so.  A real puzzler, this!

    -Randal   (at CubeCentral)


PS:  The other claim about STRING$ may have to wait, as I've discovered that it might be related to MOD somehow, but need to run more tests.




MODCHK4.BAS

Cube Central

unread,
May 26, 2018, 11:51:59 AM5/26/18
to LiNC80
I wanted to update this post with the results of some additional testing:

I've modified the above MODCHK4.BAS to loop through integers rather than selecting random ones.  This means that A and B would be incremented by one, B forming the "outside" loop and A forming the "inside loop.  So B would be set to 1, and then A would be incremented 1,2,3... all the way to a maximum value.  Then B would be 2, and A would start again from 1.

I wanted to see if the issue was reproducible with a certain pair of integers.  If by feeding A MOD B the same numbers, would I get the same results.  After letting it run overnight I had a good baseline, so I started it again this morning.  Right away I can tell that the errors are not linked to a specific pair of integers.  Where the first run didn't encounter problems until it had run for a while, where B=21, the second run showed errors almost immediately where B=2.  
I think this demonstrates that it is not a programmatic error, but something deeper having to do with memory, memory access, or the like.

One positive take-away from this is that the system ran the program overnight without hanging or other forms of instability.  It did stop once, with a nonsensical "Syntax error in 130" - a line that had been executed hundreds of thousands of times before.  This is consistent in frequency with, and symptomatic of, a cosmic ray strike.  I’ve explored these sorts of events in the past, and have seen it happen with older computers as well as CMOS sensors used in astronomy.  I happen to live at a fairly high altitude at about 5450 feet (~1661m) so I am subject to more of these sorts of events than those at or near sea level (about 3.5 times more!).  Nothing can be done about it, so I’ve learned to statistically figure these sorts of errors out of my testing and conclusions.  How we now take ECC RAM for granted!  

Cheers!  Happy Hacking...

    -Randal   (at CubeCentral)

Chris Scullion

unread,
May 29, 2018, 10:28:09 AM5/29/18
to LiNC80
I ran this program on my LiNC80 and got different output.  In my case, BASIC ends without ctrl-C after a varying number of iterations.  Do you have a version of the program that would run in ROM BASIC so I can eliminate the CF Card?

results:

A>b:mbasic MODMADD.BAS
BASIC-80 Rev. 5.21
[CP/M Version]
Copyright 1977-1981 (C) by Microsoft
Created: 28-Jul-81
29752 Bytes free
Random number seed (-32768 to 32767)? 2000
ERROR!  A= 11345  B= 32451  C= 20154  D= 11345  X= 103 
ERROR!  A= 32411  B= 25776  C= 19987  D= 6635  X= 121 

A>

Cube Central

unread,
May 29, 2018, 1:16:10 PM5/29/18
to LiNC80
Hi Chris, thank you for running that!

I think you will discover that the output is going to change each time you run it.  This is particularly frustrating as it doesn’t point to an obvious source.  There should never be reported errors in the first place, and the errors do not occur at the same point every time.  If you were to start the program again, with the same random number seed, you will get different output.  Also, the program should not stop unless you press Ctrl-C.  It stopping is another symptom.

I’ve attached a version of the program that loops through increasing values for the MOD operation.  This way, one can send the same values each run to the MOD operator.  Even with this version, I get different errors at different points.

As far as it running in ROM BASIC I have yet to try it more than once.  As there is just simple support for serial communication, it makes it impossible to paste the program into ROM BASIC, and I must enter it line by line.  I will try different delay speeds in TeraTerm to see if I can bypass this issue.

The version above, as well as the attached version, should both run in ROM BASIC, as it is a very simple program.  I look forward to seeing more results.  Cheers!

    -Randal   (at CubeCentral)
MODCHK5.BAS
MODCHK5.zip

Stephan van Radecke

unread,
May 29, 2018, 3:43:05 PM5/29/18
to LiNC80
Hm,
maybe I don't really understand it, but I don't get any error.

B>mbasic MODCHK4.BAS
BASIC-80 Rev. 5.21
[CP/M Version]
Copyright 1977-1981 (C) by Microsoft
Created: 28-Jul-81
29752 Bytes free
Random number seed (-32768 to 32767)? 2000
CHECK:  A= 9494  B= 19994  C= 9494  D= 9494  X= 188 
CHECK:  A= 23064  B= 27387  C= 23064  D= 23064  X= 227 
CHECK:  A= 26799  B= 3868  C= 3591  D= 3591  X= 252 
CHECK:  A= 1807  B= 8607  C= 1807  D= 1807  X= 255 
CHECK:  A= 10484  B= 16672  C= 10484  D= 10484  X= 258 
CHECK:  A= 8866  B= 21549  C= 8866  D= 8866  X= 262 
CHECK:  A= 24073  B= 9471  C= 5131  D= 5131  X= 265 
CHECK:  A= 27374  B= 8117  C= 3023  D= 3023  X= 268 
CHECK:  A= 4619  B= 19963  C= 4619  D= 4619  X= 271 
CHECK:  A= 5153  B= 23956  C= 5153  D= 5153  X= 275 
CHECK:  A= 19306  B= 7869  C= 3568  D= 3568  X= 278 
CHECK:  A= 31705  B= 3745  C= 1745  D= 1745  X= 281 
CHECK:  A= 9269  B= 15609  C= 9269  D= 9269  X= 285 
CHECK:  A= 28756  B= 23921  C= 4835  D= 4835  X= 288 
CHECK:  A= 11854  B= 30727  C= 11854  D= 11854  X= 291 
CHECK:  A= 8900  B= 13550  C= 8900  D= 8900  X= 295 
CHECK:  A= 691  B= 16413  C= 691  D= 691  X= 298 
CHECK:  A= 22586  B= 17170  C= 5416  D= 5416  X= 301 
CHECK:  A= 25128  B= 4438  C= 2938  D= 2938  X= 304 
CHECK:  A= 17779  B= 8318  C= 1143  D= 1143  X= 308 
CHECK:  A= 8353  B= 30494  C= 8353  D= 8353  X= 311 
CHECK:  A= 29716  B= 14640  C= 436  D= 436  X= 314 
CHECK:  A= 29729  B= 29918  C= 29729  D= 29729  X= 318 
CHECK:  A= 4409  B= 4518  C= 4409  D= 4409  X= 321 
CHECK:  A= 15896  B= 1225  C= 1196  D= 1196  X= 324 
CHECK:  A= 28032  B= 19440  C= 8592  D= 8592  X= 328 
CHECK:  A= 18427  B= 11352  C= 7075  D= 7075  X= 331 

and so on

Jon Langseth

unread,
May 29, 2018, 4:01:24 PM5/29/18
to LiNC80
I have had the MODCHK4.BAS version running for two hours now, and I am not getting any errors either.
I don't think it's anything you have not understood, Stephan. I think Randal and Chris are having issues that you and I do not.

I have had intermittent noise-related issues on one of my four builds, and I have a suspicion that is what Randal and Chris are seeing. I also have an idea about something to try, and I'm already talking with Randal about that off-list. But as it's not a verified hypothesis, I am hesitant to talk much about it before we have had an opportunity to test it.

Stephan van Radecke

unread,
May 29, 2018, 4:08:43 PM5/29/18
to LiNC80
Jon,

to be clear, you've hitten a key for 2 hours to run the program?
I changed line 150 to print the result every loop.

Jon Langseth

unread,
May 29, 2018, 4:36:25 PM5/29/18
to LiNC80
Good point, I did not spot that it waits for inkey :D
Will run it again, sorry for my derp :) 

Jon Langseth

unread,
May 29, 2018, 4:51:47 PM5/29/18
to LiNC80
OK, I now ran it for about 10 minutes with constant input (keyboard repeat <3) without issues. As I need to use the PC for other things,
I have put a REM at line 150, and I'm now running it "background" to see if the error triggers. 

CubeCentral

unread,
May 29, 2018, 5:23:57 PM5/29/18
to LiNC80

Just to be clear, line 150, the “INKEY” line, only checks to see if the user has pressed a key, and if so, print a status report.  Otherwise it continues to run by itself, there is no need to press a key.  That was simply put in there so that I could check on the system to see if it was still running and not to print out the results of every passed test.  Printing every line slowed the program and I didn’t care about successful comparisons, only the failures.

--
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/f09a682f-7a43-42df-8525-49924c5ebfbb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

CubeCentral

unread,
May 29, 2018, 5:31:54 PM5/29/18
to LiNC80

I just tied a version of the MODCHK5 program in ROM BASIC (selecting “basic” from the initial load screen) and there isn’t a modulus operator (A MOD B) in this version of BASIC.  Without it, this test is useless.  So much for testing it without a IDE/CF adapter.

 

    -Randal   (at CubeCentral)

 

 

From: lin...@googlegroups.com [mailto:lin...@googlegroups.com] On Behalf Of Cube Central
Sent: Tuesday, May 29, 2018 11:16
To: LiNC80 <lin...@googlegroups.com>
Subject: [linc80] Re: Modulus Madness

 

Hi Chris, thank you for running that!

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

Cube Central

unread,
May 29, 2018, 5:44:50 PM5/29/18
to LiNC80
Stephan, thanks for running that.  Would you please let it run for quite a bit longer?  I see that it had only completed 331 iterations, if you stopped the program soon after that.  It might take an hour (though I've never seen it take that long) for an error to be reported.  I appreciate you giving it a try and look forward to your results.

    -Randal   (at CubeCentral)

Jon Langseth

unread,
May 29, 2018, 6:54:18 PM5/29/18
to LiNC80

OK, I now ran it for about 10 minutes with constant input (keyboard repeat <3) without issues. As I need to use the PC for other things,
I have put a REM at line 150, and I'm now running it "background" to see if the error triggers. 

My session of running it with a REM on line 150 (even if that was not needed, see Randal's post) has been running silently for 2 hours. It ran continuously for 1hr 45 minutes before I gave it a Break to check that it was still alive, and I resumed it with a little CONT. No issues still. I have to end my session now, and it'll be a while until I can do a longer run, but I suspect that won't change anything if my suspicions are right ;)

Jon Langseth

unread,
May 30, 2018, 5:32:46 AM5/30/18
to LiNC80


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

Stephan van Radecke

unread,
May 30, 2018, 5:34:43 AM5/30/18
to LiNC80
mine is running now for 2 and a half hours, no problems / errors so far.

B>mbasic MODCHK4.BAS
BASIC-80 Rev. 5.21
[CP/M Version]
Copyright 1977-1981 (C) by Microsoft
Created: 28-Jul-81
29752 Bytes free
Random number seed (-32768 to 32767)? 999
CHECK:  A= 6150  B= 32359  C= 6150  D= 6150  X= 431972

Stephan van Radecke

unread,
May 30, 2018, 7:48:28 AM5/30/18
to LiNC80
another result:
I played around with 3 possible power supplies and now I got errors.

1) 5V from USB port
2) Apple charger (the big one)
3) Phihong PSAA20R-050 (5V/3A)

these 3 stopped with 'Type mismatch in 170' or 'Type mismatch in 120',
the first 2 within 400 loops
the third within 3500 loops

My 'ever' running power supply is a 'MW NC050P100PGS' (5V/1A), no error till now.

Jon Langseth

unread,
May 30, 2018, 10:11:16 AM5/30/18
to LiNC80
That does seem to correlate with my suspicion that this is noise or power-supply induced, but that makes me just as confused about why Steve's build is experiencing errors when it hasn't done so before :(

By the way, I would not recommend using a PC USB port as a 5V source. The original USB spec only allowed for 100mA draw, and anything beyond that may cause either voltage fluctuations, noise on the VCC, or worst case a damaged USB port (unless you add the full USB2/USB3 power negotiation bit...).

Chris, Randal, Steve, maybe you can try checking your power supplies, and perhaps add a ferrite choke for noise supression?

CubeCentral

unread,
May 30, 2018, 10:43:23 AM5/30/18
to LiNC80

Jon –

 

I would be happy to give a different power supply a try.  I have always used the same power supply for all the testing I’ve done.  As the power input to the computer is the screw terminals, where would you suggest placing the ferrite choke?

 

I am using a lab bench power supply at 10V going into something similar to this:  https://www.sparkfun.com/products/114   … Which puts out a very nice, steady 5V, with little to no ripple that I could see on the scope.  I wanted to use a regulated supply like this rather than straight from the bench power supply as this has reverse polarity and overcurrent protection.  This is the same supply that I used to drive IDE/CF adapter cards requiring external power.  I also used this same supply on the RC2014 before installing the on-board regulator.

 

The next step in my testing was going to be switching power supplies, and seeing if the problem persists, so this post is timely.

 

Please specify the test parameters and what you would like to see and I will make it happen here later today.  Cheers!

 

    -Randal   (at CubeCentral)

 

 

From: lin...@googlegroups.com [mailto:lin...@googlegroups.com] On Behalf Of Jon Langseth
Sent: Wednesday, May 30, 2018 08:11
To: LiNC80 <lin...@googlegroups.com>
Subject: [linc80] Re: Modulus Madness

 

That does seem to correlate with my suspicion that this is noise or power-supply induced, but that makes me just as confused about why Steve's build is experiencing errors when it hasn't done so before :(

--

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.

Jon Langseth

unread,
May 30, 2018, 11:04:01 AM5/30/18
to LiNC80

Where to place the choke? On the cable feeding power in to the board, reasonably (1-3inches) close to the board. I used an oversized ferrite core as an example choke here.  If you have a choke of the clip-on type, even better than my example. 


Cube Central

unread,
May 30, 2018, 11:24:51 AM5/30/18
to LiNC80
OK Jon, how's this? It's pretty tight on there, but I can change it if it's not quite what you had in mind.


I can't begin tests right now, maybe this afternoon or tomorrow if this setup looks OK.  I have more of these chokes and can add them on the Bench Power Supply, the Power Adapter, etc. if they aren't already on there!
Great minds must think alike, as I had planned to try this and a different power supply.  I will be sure to report my findings!  Cheers!

    -Randal   (at CubeCentral)

Jon Langseth

unread,
May 30, 2018, 11:32:09 AM5/30/18
to LiNC80
Looks good! Best of luck with the tests.

Stephan van Radecke

unread,
Jun 1, 2018, 11:18:26 AM6/1/18
to LiNC80
BASIC-80 Rev. 5.21
[CP/M Version]
Copyright 1977-1981 (C) by Microsoft
Created: 28-Jul-81
29752 Bytes free
Random number seed (-32768 to 32767)? 999
CHECK:  A= 9072  B= 22950  C= 9072  D= 9072  X= 398 
CHECK:  A= 11024  B= 22386  C= 11024  D= 11024  X= 1635 
ERROR!  A= 14143  B= 12082  C= 2060  D= 2061  X= 3760 
Type mismatch in 170
Ok

2) MW 5V/1A:
running forever, till I stopped it:

B>mbasic modchk4.bas
BASIC-80 Rev. 5.21
[CP/M Version]
Copyright 1977-1981 (C) by Microsoft
Created: 28-Jul-81
29752 Bytes free
Random number seed (-32768 to 32767)? 999
CHECK:  A= 6759  B= 19339  C= 6759  D= 6759  X= 5294 
CHECK:  A= 21156  B= 31197  C= 21156  D= 21156  X= 17429 
CHECK:  A= 29165  B= 25717  C= 3448  D= 3448  X= 46853 
CHECK:  A= 1068  B= 13534  C= 1068  D= 1068  X= 89139 
CHECK:  A= 20743  B= 17465  C= 3278  D= 3278  X= 106909 
CHECK:  A= 5655  B= 1785  C= 300  D= 300  X= 146577 
CHECK:  A= 16351  B= 5143  C= 922  D= 922  X= 342202 
CHECK:  A= 13389  B= 31840  C= 13389  D= 13389  X= 369874 
CHECK:  A= 1583  B= 15600  C= 1583  D= 1583  X= 444511 
CHECK:  A= 7178  B= 22971  C= 7178  D= 7178  X= 3.8691E+06 
^C
Break in 110
Ok

Jon Langseth

unread,
Jun 1, 2018, 3:16:50 PM6/1/18
to LiNC80
Just to be sure I interpret these results correctly, this indicates no change for you?

Stephan van Radecke

unread,
Jun 2, 2018, 5:02:13 AM6/2/18
to LiNC80
bad news, my 'ever running' power supply stopped with 'Syntax error in 100' after 20 hours and attached ferrite.

CubeCentral

unread,
Jun 2, 2018, 10:31:39 AM6/2/18
to LiNC80

Stephan,

 

20 hours is pretty good!  A single memory glitch like that might happen due to a cosmic ray strike.  Since this memory isn’t error correcting ECC RAM it is susceptible to interference. If you live at higher altitude, the problem is worse than for those near sea level.

 

Stay tuned for a post detailing my testing results, which I hope to post later today.  Cheers!

 

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

Jon Langseth

unread,
Jun 2, 2018, 3:35:07 PM6/2/18
to LiNC80
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.a

Derry UK

unread,
Jun 3, 2018, 11:26:22 AM6/3/18
to LiNC80
I wish I was able to run the basic program and test my system but sadly I do not know how too. Just download and run this basic program leaves me blank at the moment.

Anyway some thoughts. I do not think it is anything to do with power supplies unless they are introducing a couple of volts in a spike or some such. The fact that changing a supply might allow the program to run would indicate to me that something else is marginal which will be triggered at some time. Millions of Z80 system have been built and they all run with any old supply (with the usual caveats.)

The other puzzle is that a CF card would work at the end of a cable but not if plugged in directly (without a cable). In my limited experience things tend to improve if you remove cable, not worsen.

The failures are seemingly random in time.

Going back to the cable removal would the program run without a CF card I wonder, perhaps an SD card (with IDE interface) or hard disk?

For info using a Raspberry Pi power supply I get +- 40mV of AC noise measured at the Z50BUS with the system waiting for me to enter a "?" character at start up.
 
Derry.

CubeCentral

unread,
Jun 3, 2018, 12:02:55 PM6/3/18
to LiNC80

Hi Derry,

If you’re trying to run the MODCHK program, it won’t look like it is doing anything unless you press a key.  Would you try that and let me know?

 

I’m afraid I disagree with you about it not being power supplies.  All the testing I’ve done seems to indicate that the power supply is – if not the root cause – a major factor in the failures.  All things left the same, the only variable which changed was the power supply which lead to much better outcomes.

 

And I agree that the cable issue is a puzzle.  Right now, I am doing some tests involving the direct-connect IDE CF adapters.  As soon as more time has passed I will update my post with the results later today.

 

I do agree that the failures are seemingly random, as they are not reproduceable by the usual means. 

 

The problem with running the test without a CF card is that one would have to use the supplied ROM BASIC to run the test program.  Unfortunately, the version of BASIC on the ROM doesn’t support the MOD operator used in the tests.  I’ve considered using a “spinning rust” hard drive, but would need some way to place the CP/M image on it.  I purchased an IDE/USB adapter for this purpose but haven’t yet had the opportunity to try it out.  When I do, I will for sure post an update.

 

Thanks for your input and please do let me know if I can help with running the MODCHK test program.  Cheers!

 

    -Randal   (at CubeCentral)

 

From: lin...@googlegroups.com [mailto:lin...@googlegroups.com] On Behalf Of Derry UK
Sent: Sunday, June 3, 2018 09:26
To: LiNC80 <lin...@googlegroups.com>
Subject: Re: [linc80] Re: Modulus Madness

 

I wish I was able to run the basic program and test my system but sadly I do not know how too. Just download and run this basic program leaves me blank at the moment.

--

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.

Jon Langseth

unread,
Jun 3, 2018, 2:05:12 PM6/3/18
to LiNC80
I have no reservations with agreeing that something needs to be marginal for the issues to appear so ... predictably. However, I disagree with the notion of needing a several volts spike. If my layout has accidentally led to either the clock line or data lines be placed so we pick up harmonics off the power line, that would mean that not much of a signal is needed, as long as it hits the right frequencies. I can freely admit that I had help from an autorouter laying out parts of the board, so it is indeed possible the root cause is in the trace layout.

However, this does not mean the LiNC80 SBC1 can't be a reliable board. Randal has confirmed that a system experiencing issues can be brought to be rock solid by choosing the correct power supply. Personally, my primary release kit has currently been running the Modulus Madness (modchk4) without throwing an error or hanging since may 30th. That would currently be three full days, coming up on the fourth...

And I agree that the cable issue is a puzzle.  Right now, I am doing some tests involving the direct-connect IDE CF adapters.  As soon as more time has passed I will update my post with the results later today.


As I don't have a direct attach adapter, I can't confirm this, but I have a sneaking suspicion there's an LDO voltage regulator on there that does not get disconnected when jumpering from 3.3V to 5V, but instead gets a different control resistor to set it to 5V. This voltage regulator may be doing the same as the LM317 on Randal's breadboard supply did, and thus cause the issues.
 

The problem with running the test without a CF card is that one would have to use the supplied ROM BASIC to run the test program.  Unfortunately, the version of BASIC on the ROM doesn’t support the MOD operator used in the tests.  I’ve considered using a “spinning rust” hard drive, but would need some way to place the CP/M image on it.  I purchased an IDE/USB adapter for this purpose but haven’t yet had the opportunity to try it out.  When I do, I will for sure post an update.


I think you will find that you'll have problems using spinning rust, unless you have a REALLY old drive. This is because the on-board IDE uses 8-bit XT-IDE mode, which has not been supported by regular IDE drives for a long time. Compact Flash cards include this mode, simply because it is part of the Compact Flash standard (and that is also why many manufacturers fail to test the mode properly, and why some cards are not working). This is why I try to be clear about this not being full IDE. Spinning rust works with the third party RC2014 IDE interfaces (like the from Ed Brindley), simply because they are full IDE interfaces with a controller chip, handling the 8bit-to-16bit-and-back magic. So, to use spinning rust with the LiNC80 SBC1, a full IDE controller would need to be (possibly designed, and) attached, and software written to use it.
 

Derry UK

unread,
Jun 4, 2018, 10:31:35 AM6/4/18
to LiNC80
Talking of trace layout Dave Jones on EEVBLOG recently released an interesting video where he removed all bypass caps to see what effect it would have on his TTL computer EEVBOG bypass caps et al Removing all caps didn't affect his computer at all but he showed some interesting effects at various parts of the PCB.

The other thing that occurred to me re running with/without a cable to the CF board is that a cable will introduce a time delay. I can't really see why this should be significant though.

Good point re 8bit and 16bit drives Jon, I had forgotten about that (it's my age.)

Derry.

Derry UK

unread,
Jun 4, 2018, 2:16:25 PM6/4/18
to LiNC80
Apologies all. I have reread this thread and realise I made a terrible assumption. I thought that the results were being written to the CF card and it was during this write process where the error was discovered.

Sadly "It's my age" has been confirmed.

Thinking about "some boards do it some don't" and "it depends on my power supply" may I ask if Randal has tried different ICs on his board?

I've been building a PCB for my RC2014 and if it works tomorrow I'll give this modulus madness a go on my LiNC80.

Apologies again all.

Derry.


Cube Central

unread,
Jun 4, 2018, 3:28:05 PM6/4/18
to LiNC80

Derry,

 

Not to worry, it happens to the best of us!

 

I’ve not tried different ICs on my board, but would be willing to do so if I knew exactly what other ICs to put in there.  Unfortunately, that’s where my experience and knowledge falls a bit short, and would be terrified of guessing.  If a Bill of Materials were put together with alternate ICs, I would gladly order them from Mouser or Digi-Key.

 

Attached, please find MODCHK5.BAS.  This one differs from MODCHK4.BAS in that instead of trying random combinations of numbers, it instead loops through integers from 1 to some maximum (set by variable to 32766).  This is the one that I’ve been using most recently.

 

On a related note, I’ve been using the MODCHK program – as you’ve all seen - to weed out what appear to be noise issues, coming from either the Power Supply or the IDE/CF Card Adapter.  If this program runs for a good long while without errors, I then move to the more data-intensive “Media Mayhem” program, MM8.BAS (also attached) to determine if the IDE/CF bus and adapter are working well.  I’ve found that if the MODCHK program generates errors, then the MM program is sure to fail.  The MODCHK program was created due to bizarre errors encountered by earlier MM programs, which used the MOD operator (and the STRING$ function) to generate data to move back and forth from the CF card.  I had made an earlier claim about the STRING$ function also not working properly, but I’ve yet to create a program just to test for it (as I did the MODCHK program) – I may do that later this week.

 

I look forward to seeing what PCB you’ve created and do please let me know if you have any further questions, concerns, or suggestions.  Cheers!

 

    -Randal   (at CubeCentral)

MODCHK5.zip
MM8.zip

Derry UK

unread,
Jun 5, 2018, 6:14:16 AM6/5/18
to LiNC80
Randal I was just thinking in terms of trying another IC of the same type - just to eliminate the possibility of a flaky IC on your board.

Re. PCB I'm only building Ed Brindley's  IDE adapter for my RC2014.

I have been toying with giving up Z80 hardware altogether and switching to Yaze in Win10. My main interest is writing Z80 assembler programs but these days I get frustrated with mickey mouse editors and the like and if I have downloaded a program from the internet transferring it to my Z80 system.

Well see.

Derry.

CubeCentral

unread,
Jun 5, 2018, 9:52:52 AM6/5/18
to LiNC80

I saw this posted on the RC2014 group, and thought that it might be of use to you since you said you write Z80 assembler:

https://smallcomputercentral.com/projects/small-computer-workshop/

I’ve played with it some and it looks very full featured, but might be finicky as it is homebrew software.  I hope it can help?

 

    -Randal   (at CubeCentral)

 

From: lin...@googlegroups.com [mailto:lin...@googlegroups.com] On Behalf Of Derry UK
Sent: Tuesday, June 5, 2018 04:14
To: LiNC80 <lin...@googlegroups.com>
Subject: Re: [linc80] Re: Modulus Madness

 

Randal I was just thinking in terms of trying another IC of the same type - just to eliminate the possibility of a flaky IC on your board.

--

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.

Derry UK

unread,
Jun 5, 2018, 10:22:56 AM6/5/18
to LiNC80
Thank you for that link.

Assuming I am doing everything correctly I too get errors. Below was a run with MODCHK5.

run

Random number seed (-32768 to 32767)? 999
CHECK:  A= 202  B= 1  C= 0  D= 0  X= 202  Y= 32766
CHECK:  A= 620  B= 1  C= 0  D= 0  X= 620  Y= 32766
CHECK:  A= 905  B= 1  C= 0  D= 0  X= 905  Y= 32766
CHECK:  A= 1289  B= 1  C= 0  D= 0  X= 1289  Y= 32766
CHECK:  A= 1574  B= 1  C= 0  D= 0  X= 1574  Y= 32766
ERROR A= 4856  B= 1  C= 0  D= 8  X= 4856  Y= 32766

Derry.

CubeCentral

unread,
Jun 5, 2018, 10:46:16 AM6/5/18
to LiNC80

Derry,

 

Yup, and early on as well.  The program had just started and was 4856th iteration of the first loop (B=1).  Interestingly, the MOD operator returned the correct value (C=0) but the alternative calculation returned the wrong answer!  (D=8).

 

If you have some time I sure would appreciate you running this a bit longer on your system … either a few hours or five or so errors?  I just want to see if the errors are similar to what I get.  Thanks!

Derry UK

unread,
Jun 5, 2018, 10:55:44 AM6/5/18
to LiNC80
At the moment I am beginning to think my basic is at fault. I am now getting errors reported where there are none! However I was poking about with my scope probe at the time...........

B>mbasic modchk5

BASIC-80 Rev. 5.21
[CP/M Version]
Copyright 1977-1981 (C) by Microsoft
Created: 28-Jul-81
29752 Bytes free
Random number seed (-32768 to 32767)? 999
CHECK:  A= 174  B= 1  C= 0  D= 0  X= 174  Y= 32766
CHECK:  A= 276  B= 1  C= 0  D= 0  X= 276  Y= 32766
ERROR A= 488  B= 1  C= 0  D= 0  X= 488  Y= 32766
ERROR A= 846  B= 1  C= 0  D= 0  X= 846  Y= 32766
CHECK:  A= 4835  B= 1  C= 0  D= 0  X= 4835  Y= 32766
ERROR A= 5753  B= 1  C= 0  D= 0  X= 5753  Y= 32766
ERROR A= 5822  B= 1  C= 0  D= 0  X= 5822  Y= 32766
CHECK:  A= 7248  B= 1  C= 0  D= 0  X= 7248  Y= 32766
ERROR A= 8319  B= 1  C= 0  D= 0  X= 8319  Y= 32766
ERROR A= 14403  B= 1  C= 0  D= 0  X= 14403  Y= 32766
CHECK:  A= 23624  B= 1  C= 0  D= 0  X= 23624  Y= 32766
ERROR A= 29910  B= 1  C= 0  D= 0  X= 29910  Y= 32766


Derry.

CubeCentral

unread,
Jun 5, 2018, 11:21:19 AM6/5/18
to LiNC80

Derry,

I’m sure your BASIC is fine, getting random nonsensical errors is a part of the issue.  It is probably a memory location getting randomly changed by the same process that causes the MOD operation to report incorrect values.

Looking at your output now, maybe I see what you are thinking, where C and D are both equal to zero.

I’ve found that this could be BASIC reporting a very small floating point value (I do not wish to get into a discussion of floating point arithmetic here, it’s beyond the scope of the Group, but here are a couple of links)

In either case, the error is valid because if C and D are actually zero, then the comparison of C=D should be true.   In the program, an error is reported if C doesn’t equal D. 

I would review the program (using LIST in BASIC) and visually compare it to a known good copy to be sure that the program is intact and didn’t get altered when transferred to the SBC1. 

(Not sure if you know enough BASIC to do this, but you would start in CPM, load BASIC by typing MBASIC, once there you can “LOAD x:MODCHK5.BAS” where x: is the drive letter.  Once loaded you can issue a “LIST” command to view the program.

 

Please let me know if you have any further questions or concerns, as I am happy to help!!  Cheers!

 

    -Randal   (at CubeCentral)

 

From: lin...@googlegroups.com [mailto:lin...@googlegroups.com] On Behalf Of Derry UK
Sent: Tuesday, June 5, 2018 08:56
To: LiNC80 <lin...@googlegroups.com>
Subject: Re: [linc80] Re: Modulus Madness

 

At the moment I am beginning to think my basic is at fault. I am now getting errors reported where there are none! However I was poking about with my scope probe at the time...........

--

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.

Derry UK

unread,
Jun 5, 2018, 3:40:20 PM6/5/18
to LiNC80
I don't know if this is significant but there may be runt pulses at play. I set my scope trigger to 0.8 - 2.2v runt pulse single shot and captured them on the data lines. The Z84C0008PEG spec gives  the range of 0.4 - 0.8 for low and 2.2 - 2.4 for high depending on input or output. The peak of the runt my scope triggered on was 1.2v. I took my measurements on the Z80 cpu itself.

This may of course be perfectly normal and if anyone reading this knows the answer please comment ....

Derry.


runt.jpg
runtspec.jpg

Jon Langseth

unread,
Jun 5, 2018, 5:19:42 PM6/5/18
to LiNC80
I may be weird, but seeing your 'scope-trace made me really excited.

I don't have a scope that's allowed me to see what you are showing me, so this is really great for me!
Is this signal behavior happening across the lines, or is it just one/a few? And, what line are you 'scoping in the attached trace? 

CubeCentral

unread,
Jun 5, 2018, 6:11:32 PM6/5/18
to LiNC80

The real trick would be to see if one of these pulses syncs up with an error in MODCHK.

 

Unfortunately, I don’t have a scope with dual triggers that would allow me to view a pulse over some limit, but under another.  Will have to play around a bit and see if I can find another way of viewing these interim “runt” pulses.

 

Would it really cause an issue if the voltage is 0.9V below the lower threshold?  I’ve been reading some and came across this page which talks about logic signal voltage levels and I’m just not sure a pulse at 1.2V would be outside the noise margin for the gates.

 

Keep up your investigations, Derry, I am also interested in your findings!  Cheers!

 

    -Randal   (at CubeCentral)

 

PS:  Jon, you’re not weird.

 

 

 

From: lin...@googlegroups.com [mailto:lin...@googlegroups.com] On Behalf Of Jon Langseth
Sent: Tuesday, June 5, 2018 15:20
To: LiNC80 <lin...@googlegroups.com>
Subject: Re: [linc80] Re: Modulus Madness

 

I may be weird, but seeing your 'scope-trace made me really excited.

--

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.

Cube Central

unread,
Jun 5, 2018, 7:06:45 PM6/5/18
to LiNC80
Not sure if we should create a new Topic, but I searched a bit using the tools available to me, and found what look similar to what Derry was talking about.  Note that these snapshots were taken on the D1 line off the Z50Bus on a system that is not experiencing any errors while running the MODCHK test program.
The first photo includes the scope "cursor" function which allows me to measure portions of a waveform. I noted that the maximum value is around 600mV.
The second photo is the same shot but without the cursors.



It might be more helpful if I looked at a system that was experiencing errors to see if these spurious pulses are larger in amplitude.  I will try to follow that up later this evening.

    -Randal   (at CubeCentral)

Derry UK

unread,
Jun 5, 2018, 7:15:07 PM6/5/18
to LiNC80
The runt pulses were occurring on the data lines, address lines were clean ie didn't trigger the runt detector. Another oddity was when I put my scope probe on the CPU NM! pin it invoked a CP/M warm start, not sure why that is.

Derry.


Cube Central

unread,
Jun 5, 2018, 7:40:27 PM6/5/18
to LiNC80
I put the W1 power supply back on the SBC1 and looked at the scope. No distinguishing changes. (This was a power supply that generated errors right away yesterday)
The blue trace is from D0 and the yellow is from D1. It feels to me as if the "bumps" or "runts" that are observed at the very small voltages could simply be from neighboring data lines. The following snapshots may illustrate that:
With the U1 power supply:


With the W1 power supply:

With my equipment here (and no "Runt" setting on my oscilloscope), I am unsure if I am seeing what Derry is seeing and cannot draw any meaningful conclusions.  Sorry :\

    -Randal   (at CubeCentral)

Derry UK

unread,
Jun 6, 2018, 6:26:51 AM6/6/18
to LiNC80
Relax all.

Another look at my computer this morning and we now don't have runt pulses. Yesterday I used an RS IC clip to attach my scope probe to, mainly because I am paranoid about slipping with the probe and shorting out a couple of pins and poof....... there goes another CPU.

Anyway today I risked it and put my probe directly on the CPU  pins, funny I thought there are no runts! Anyway as the snapshot shows the "runt" peak is now circa 780mV which of course is below my runt detector value.

Also not using an IC clip the CPU now doesn't reset when I touch the NMI pin with my probe.

We live and learn.

If I may ask Randal, where do you suspect the error is occurring? The CPU, the ram or the path in between? At the moment I suspect the path between simply because of your demonstrated increase in errors by changing the power supply of CF location. I just want to get others thinking so I don't shoot off on a tangent again.

I live and learn.

Derry.


smaller.jpg

Derry UK

unread,
Jun 6, 2018, 9:06:55 AM6/6/18
to LiNC80
After the above debacle I thought I would read my scope probe manual and now realise I should have switched it to x 10 for better bandwidth and therefore more detail. See below. Can anybody tell me why my alleged "runt" pulses have their tops sloping at 45 deg.?

Derry.
x10.jpg

Derry UK

unread,
Jun 6, 2018, 9:42:41 AM6/6/18
to LiNC80
I had a look to see if I could find which pins were creating the runt noise, I couldn't. I couldn't readily get address pulses to match with runts but I could with data and RD (pin 21). In dual1 below red id D1 and blue is D7. In dual2 red is D1 and blue is RD.

Derry.
Dual1.jpg
dual2.jpg

CubeCentral

unread,
Jun 6, 2018, 9:58:18 AM6/6/18
to LiNC80

Derry,

 

Thanks for the follow up.  I’ve learned the hard way to double check my oscilloscope results, especially if I see something out of the ordinary.  So many small variables, like an IC clip, or using a bit longer length of wire, can add up!

 

You pose an excellent question about where the error might be occurring.  I don’t know for sure, but I can infer a bit from the test program results.  I first was thinking maybe it was RAM, but I modified the MODCHK program to immediately do the calculation again after encountering an error, and the results are always the correct value.  If it were RAM, and somehow a variable was stored or retrieved incorrectly, then doing an operation on that memory location (i.e. variable) would repeatedly give the same error, or at least another incorrect value.  Also, sometimes the program will stop with a nonsensical “Syntax Error” on a line that has been executed millions of times before, but if I view that line in the program, all is as it should be.  If it were RAM then that program line would be mangled. 

 

As you said, the path between does seem to be the most likely suspect.  I think we could rule out the CPU as it is ROM, and an older, well proven architecture.  It there was an issue with the CPU I think we would see it in the form of more repeatable errors or more serious ones (including perhaps system hangs).  Having data somehow become corrupt somewhere between the RAM and CPU or RAM and other RAM could account for the types of issues we are seeing.  Changing the power supplies, thus changing the “noise profile”, would certainly influence the communication paths.  This is all my best guess, as I have no direct proof one way or the other. 

 

Hope that helps and if anyone disagrees, please do let me know – I’m always eager to learn something new!  Cheers!

 

    -Randal   (at CubeCentral)

 

 

From: lin...@googlegroups.com [mailto:lin...@googlegroups.com] On Behalf Of Derry UK
Sent: Wednesday, June 6, 2018 04:27
To: LiNC80 <lin...@googlegroups.com>
Subject: Re: [linc80] Re: Modulus Madness

 

Relax all.

--

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.

Derry UK

unread,
Jun 6, 2018, 3:57:45 PM6/6/18
to LiNC80
Your second para has just saved me a job Randal, I was going to try a recalculation after error myself.

I agree about the CPU as we all have different CPUs in fact today I tried the CPU from my RC2014 and got the same results. I wanted to check the pseudo runt pulses were the same, they were.

I am still not convinced by the power supply theory but I have just bought a new lab power supply so I will give that a go tomorrow. My reasoning is that their noise level is so low, well mine is at 80mV ish when I already have runts at 800mV ish.

Of course we are left with the fact that some here do not get errors if we all did then we could point at the PCB (no slight intended) and the errors are seemingly random. The other thing that occurred to me is if we all bought our kits from Tindie perhaps some of us got faulty "other" ICs from a batch. Something along the lines of the "other" IC randomly drags a data line to ground/+5v to generate an error.

I suppose to prove this we would need to buy components made by alternative manufacturers and plug them into the PCB, what do you think?

Not relevant really but I tried your modchk5 on my Win10 pc in Yatze and let it run until x was over a million, no errors of course..

Derry.

CubeCentral

unread,
Jun 6, 2018, 4:23:30 PM6/6/18
to LiNC80

Derry,

 

I hadn’t thought about swapping parts with the RC2014, it just didn’t occur to me.  Well done!

 

I’m currently testing yet another different power supply, an old faithful one that I’ve had for decades.  I’m also testing a shielded cable to power the SBC1 but it’s too early to report any findings and will update my other post.

 

I would be more than happy to buy a whole set of ICs from Mouser or Digi-Key if I could get a BOM specifying exactly what to get – as I said, I haven’t the experience to know which ones for sure to get, and am not keen to guess!  ;)

 

Out of curiosity, I wanted to ask what is this “Win10 pc in Yatze” you speak of?  Is it an emulator?  If you’ve a link that would be very handy as googling for it gets me results for the dice game.   Cheers!

 

    -Randal   (at CubeCentral)

 

From: lin...@googlegroups.com [mailto:lin...@googlegroups.com] On Behalf Of Derry UK
Sent: Wednesday, June 6, 2018 13:58
To: LiNC80 <lin...@googlegroups.com>
Subject: Re: [linc80] Re: Modulus Madness

 

Your second para has just saved me a job Randal, I was going to try a recalculation after error myself.

--

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.

Derry UK

unread,
Jun 7, 2018, 5:47:37 AM6/7/18
to LiNC80

Derry UK

unread,
Jun 7, 2018, 9:25:37 AM6/7/18
to LiNC80
I tried my bench supply but sadly got an error message after 30 minutes.

I am flummoxed.

Derry.


Jon Langseth

unread,
Jun 7, 2018, 11:11:51 AM6/7/18
to LiNC80
All glue-logic chips have come from the same set of tubes, bought at the same time, and all bearing the same production identification. The glue logic that I am using on my fault/glitch-free system is from the same set of tubes. So, I really do not think there's a difference in the IC's shipped. If the PCB layout is marginal, then there will indeed be different behavior for different users, as the actual assembly will differ slightly, and the noise-environment will be different for all users.

Derry UK

unread,
Jun 7, 2018, 2:24:40 PM6/7/18
to LiNC80
Yes I remembered your working board after I had posted that message.

Re noise if it was an issue then why wait 30 minutes before failing? As I tested my lab supply today I thought I would have a look with a spectrum analyser at the board noise. There were a few peaks as you'd expect but nothing stuck out, not even the crystal clock frequency. The span of my analysis was 8 MHz and looks typically white.

Now lets say a particular frequency (x) is causing the problem then that could be the reason why you have to wait for some time for the error to occur. But if the noise is white in nature then there would be lots of noise a fraction of a hertz from x. Now it would be almost impossible for x to cause a failure and x+0.01 not to I would have thought.

I do accept that Randal has a supply that seemingly does not give error, likewise you have a board that works and one that doesn't I am just trying to think it through.

I presume you use the same supply with your working and non-working boards? If so then the error is with the board, all that is required is another revision and it should solve the problem (he says lightly :-)

Derry.

Jon Langseth

unread,
Jun 7, 2018, 5:15:04 PM6/7/18
to LiNC80
I presume you use the same supply with your working and non-working boards? If so then the error is with the board, all that is required is another revision and it should solve the problem (he says lightly :-)


Actually, the opposite. The board that is consistently giving me problems is the one that I have hacked a linear voltage regulator onto, so it's the only one I can't use the same supply on...
I hooked up my RevA board, that has a completely different layout and routing, and I can reliably reproduce errors with the modchk basic files... So, it seems we have a (somewhat at least) reliable workaround, but not identified the actual root cause yet.

Derry UK

unread,
Jun 9, 2018, 6:41:34 AM6/9/18
to LiNC80
This morning I measured the clock rise time, the manual quotes 30nS max. Measuring the cpu and other ICs where the clk pin is shown my system gave 4nS. However when I measure it at the Z50bus connector it was 45nS with a max of 58nS.

Now if you look at the attached JPG the minimum rise time is 5nS (the grey band at the bottom) so I wonder what is causing the spread in readings at this location on the board.

Any thoughts Jon?

Derry.


Derry UK

unread,
Jun 9, 2018, 6:45:06 AM6/9/18
to LiNC80
whoops
bus rise time.jpg

CubeCentral

unread,
Jun 9, 2018, 9:37:12 AM6/9/18
to LiNC80

Derry,

 

I’m curious about the oscilloscope used to measure this?  I am wondering if we should account for the rise time of the probes as well as the bandwidth of the scope.  I remember the following formula from way back, and is applied to the leading edge of a pulse in a dynamic system, related to resistor-capacitor filter time constants and settling time:

 

Rise time (in seconds) = 0.35/bandwidth (in Hz), or Bandwidth (Hz) = 0.35/rise time(s)

 

So, for an oscilloscope that has 20 MHz bandwidth:

Rt (s) = 0.35 / 20000000 = 1.75 × 10^-8 (s) = 17.5 ns

 

… that has 100MHz bandwidth:

Rt (s) = 0.35 / 100000000 Hz = 3.5 × 10^-9 (s) = 3.5ns

 

… that has 200MHz bandwidth:

Rt (s) = 0.35 / 200000000 Hz = 1.75 × 10^-9 (s) = 1.75ns

 

Rise time is defined as the time required for a signal to move from 10% to 90% of a rising waveform, so is your scope making that measurement for you?  (if so, that’s pretty cool!)  I would be suspicious of any result of 4ns even with a 200MHz scope, as that’s nearly half of the rise time of the measuring instrument.

 

And, of course, we should all make sure we have carefully compensated probes to minimize induced ringing.

 

Thanks for sharing your measurement, and I will have a look later today at any differences between a signal at the oscillator and at the Z50Bus connector.  Cheers!

 

    -Randal   (at CubeCentral)

 

From: lin...@googlegroups.com [mailto:lin...@googlegroups.com] On Behalf Of Derry UK
Sent: Saturday, June 9, 2018 04:45
To: LiNC80 <lin...@googlegroups.com>
Subject: Re: [linc80] Re: Modulus Madness

 

whoops

--

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.

Derry UK

unread,
Jun 9, 2018, 11:39:17 AM6/9/18
to LiNC80
Yes it is a function in my picoscope and measures from 20% to 80%. Usual caveats with probes applies but at 4nS no one is going to complain about my probe. If you want to look at the software you can download a demo Pico Just pick software for the relevant scope and if no scope connected will run in demo mode (mine does when I forget to connect my scope!) The signal generator will give you something to look at.


BTW is there a revD PCB track layout in .PDF? I have a overview of component position but not with tracks.

Derry.


Jon Langseth

unread,
Jun 9, 2018, 5:37:48 PM6/9/18
to LiNC80
I'm confused about what manual specifies a rise time of 30nS max. Don't get me wrong,I'm not arguing the number or it's applicability, I just haven't seen it before. Seen from the Z80's point of view, it's "max accepted rise time" would be on the order of hours, as it is level triggered, and the minimum clock for the Z80 is strictly anything above DC :)

The rise time and ringing does look like reflection from the clock reaching the bus. It's a fairly "long way over" to there, so I expected it to reflect, and also that the reflection would be somewhat dissipated "on the way back". With your observation of 4nS rise time on CPU and other locations where the clock is more critical, it seems I got a better result than I had envisioned. 
Well, at least those are _my_ thoughts. I may be off the mark, and don't mind to stand corrected.

Regarding a track layout, as you asked about in a follow-up message. At the moment, no, but: I will release the full schematic and PCB design as KiCAD files at or after the end of the summer (northern hemisphere), but I'm "holding on" to them for a little while. As I will be releasing them, I can send them to you directly, if you agree to not make them public until I have done so. That offer goes to anyone who would like a deeper look. Send me a direct mail off-list, and we'll work that out (Note, I have to make sure they are working outside my environment, I have some very local path-locks in there atm, so it'll take a little bit of time).

Derry UK

unread,
Jun 10, 2018, 6:40:30 AM6/10/18
to LiNC80
I got 30nS from the Zilog Z84C000 Product Specification PS017801-0602 top of page 35. I got mine at RS website Datasheet.

I wanted a PDF of the track layout to investigate what is between the bus and the rest of the board. It strikes me as odd that I can measure a different rise time (10 x greater) at the bus than elsewhere. One might expect it to be slower that at the CPU but not 10X slower. 5nS is a more believable number.

I suspect there may be something odd with my construction.

Derry.


Jon Langseth

unread,
Jun 10, 2018, 12:54:24 PM6/10/18
to LiNC80
Nice! I've been going by the datasheet that Zilog provides (UM0080.pdf), and that does not include any timing info at all. It had not occurred to me that the older datasheet that RS provides contains more info. Thanks!

As I said in my previous post, send me a direct mail, and I'll provide the trace layout as best I can. The reason I want a direct mail about that, is that some people use separate addresses for private correspondence and forums, and I'd like to keep things equal for all, as well as being fully sure I have the correct address :) Any of the following can be used to reach me directly: in...@linc.no / jon.la...@gmail.com / jon.la...@linc.no / sa...@linc.no

coinst...@gmail.com

unread,
Aug 20, 2018, 12:33:10 AM8/20/18
to LiNC80
I just found this google group from a posting on RC2014 forum.  I find the discussion about mm8.bas and modchk5.bas quite interesting.  I don't have a LiNC80 nor do I have a standard RC2014 Z80.  What I have is a Z280RC which features a direct-connect CF interface, but it is 16-bit wide interface instead of 8-bit wide.  You can see the pictures & description of it here:
https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:z280rc

I ran modchk5.bas and everything appears to work after 10-15 minutes.

d>a:mbasic80 modchk5.bas

BASIC-80 Rev. 5.21
[CP/M Version]
Copyright 1977-1981 (C) by Microsoft
Created: 28-Jul-81
32824 Bytes free
Random number seed (-32768 to 32767)? 1000
CHECK:  A= 78  B= 1  C= 0  D= 0  X= 78  Y= 32766
CHECK:  A= 457  B= 1  C= 0  D= 0  X= 457  Y= 32766
CHECK:  A= 8816  B= 1  C= 0  D= 0  X= 8816  Y= 32766
CHECK:  A= 16565  B= 1  C= 0  D= 0  X= 16565  Y= 32766
CHECK:  A= 30415  B= 1  C= 0  D= 0  X= 30415  Y= 32766
CHECK:  A= 12847  B= 2  C= 1  D= 1  X= 45613  Y= 32766
CHECK:  A= 28902  B= 2  C= 0  D= 0  X= 61668  Y= 32766
CHECK:  A= 25739  B= 3  C= 2  D= 2  X= 91271  Y= 32766
CHECK:  A= 13834  B= 4  C= 2  D= 2  X= 112132  Y= 32766
CHECK:  A= 25551  B= 4  C= 3  D= 3  X= 123849  Y= 32766
CHECK:  A= 1892  B= 5  C= 2  D= 2  X= 132956  Y= 32766

After that I ran mm8.bas which I edited line 60 to MD=5 because I only have 5 drives set up in my BIOS (the 5th drive is actually a RAM drive).  I ran for about 40 minutes when I control-C to stop it.

d>a:mbasic80 mm85.bas

BASIC-80 Rev. 5.21
[CP/M Version]
Copyright 1977-1981 (C) by Microsoft
Created: 28-Jul-81
32824 Bytes free
Random number seed (-32768 to 32767)? 1000

AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz

Configured for 5 drive letters A: to E:

W>B:RC1.MMM   V<B:RC1.MMM   C>D:RC1.MMM   V<D:RC1.MMM    .246094  23341
W>A:GH2.MMM   V<A:GH2.MMM   C>B:GH2.MMM   V<B:GH2.MMM    .738281  23341
W>D:LQ3.MMM   V<D:LQ3.MMM   C>E:LQ3.MMM   V<E:LQ3.MMM    1.47656  23341
W>A:PD4.MMM   V<A:PD4.MMM   C>E:PD4.MMM   V<E:PD4.MMM    2.46094  23341
W>B:FZ5.MMM   V<B:FZ5.MMM   C>A:FZ5.MMM   V<A:FZ5.MMM    3.69141  23341
W>C:GW6.MMM   V<C:GW6.MMM   C>B:GW6.MMM   V<B:GW6.MMM    5.16797  23341
W>A:MC7.MMM   V<A:MC7.MMM   C>C:MC7.MMM   V<C:MC7.MMM    6.89063  23341
W>E:QX8.MMM   V<E:QX8.MMM   C>A:QX8.MMM   V<A:QX8.MMM    8.85938  23341
W>C:IL9.MMM   V<C:IL9.MMM   C>D:IL9.MMM   V<D:IL9.MMM    11.0742  23341
W>B:LZ10.MMM  V<B:LZ10.MMM  C>C:LZ10.MMM  V<C:LZ10.MMM   13.5352  23339
W>E:JI11.MMM  V<E:JI11.MMM  C>B:JI11.MMM  V<B:JI11.MMM   16.2422  23339
W>E:ZG12.MMM  V<E:ZG12.MMM  C>D:ZG12.MMM  V<D:ZG12.MMM   19.1953  23339
W>C:TC13.MMM  V<C:TC13.MMM  C>E:TC13.MMM  V<E:TC13.MMM   22.3945  23339
W>A:PY14.MMM  V<A:PY14.MMM  C>C:PY14.MMM  V<C:PY14.MMM   25.8398  23339
W>A:NG15.MMM  V<A:NG15.MMM  C>D:NG15.MMM  V<D:NG15.MMM   29.5313  23339
W>A:NE16.MMM  V<A:NE16.MMM  C>E:NE16.MMM  V<E:NE16.MMM   33.4688  23339
W>B:YV17.MMM  V<B:YV17.MMM  C>E:YV17.MMM  V<E:YV17.MMM   37.6523  23339
W>C:MH18.MMM  V<C:MH18.MMM  C>E:MH18.MMM  V<E:MH18.MMM   42.082  23339
W>C:WH19.MMM  V<C:WH19.MMM  C>E:WH19.MMM  V<E:WH19.MMM   46.7578  23339
W>E:FJ20.MMM  V<E:FJ20.MMM  C>B:FJ20.MMM  V<B:FJ20.MMM   51.6797  23339
W>C:UQ21.MMM  V<C:UQ21.MMM  C>D:UQ21.MMM  V<D:UQ21.MMM   56.8477  23339
W>D:AK22.MMM  V<D:AK22.MMM  C>C:AK22.MMM  V<C:AK22.MMM   62.2617  23339
W>B:NL23.MMM  V<B:NL23.MMM  C>E:NL23.MMM  V<E:NL23.MMM   67.9219  23339
W>E:WS24.MMM  V<E:WS24.MMM  C>B:WS24.MMM  V<B:WS24.MMM   73.8281  23339
W>A:IN25.MMM  V<A:IN25.MMM  C>E:IN25.MMM  V<E:IN25.MMM   79.9805  23339
W>C:BL26.MMM  V<C:BL26.MMM  C>D:BL26.MMM  V<D:BL26.MMM   86.3789  23339
W>A:NM27.MMM  V<A:NM27.MMM  C>B:NM27.MMM  V<B:NM27.MMM   93.0234  23339
W>E:CX28.MMM  V<E:CX28.MMM  C>C:CX28.MMM  V<C:CX28.MMM   99.9141  23339
W>C:HV29.MMM  V<C:HV29.MMM  C>D:HV29.MMM  V<D:HV29.MMM   107.051  23339
W>A:FX30.MMM  V<A:FX30.MMM  C>C:FX30.MMM  V<C:FX30.MMM   114.434  23339
W>E:QG31.MMM  V<E:QG31.MMM  C>C:QG31.MMM  V<C:QG31.MMM   122.063  23339
W>E:CG32.MMM  V<E:CG32.MMM  C>A:CG32.MMM  V<A:CG32.MMM   129.938  23339
W>A:JK33.MMM  V<A:JK33.MMM  C>E:JK33.MMM  V<E:JK33.MMM   138.059  23339
W>D:XZ34.MMM  V<D:XZ34.MMM  C>B:XZ34.MMM  V<B:XZ34.MMM   146.426  23339
W>C:LH35.MMM  V<C:LH35.MMM  C>A:LH35.MMM  V<A:LH35.MMM   155.039  23339
W>C:ZG36.MMM  V<C:ZG36.MMM  C>E:ZG36.MMM  V<E:ZG36.MMM   163.898  23339
W>D:RU37.MMM  V<D:RU37.MMM  C>E:RU37.MMM  V<E:RU37.MMM   173.004  23339
W>A:SD38.MMM  V<A:SD38.MMM  C>E:SD38.MMM  V<E:SD38.MMM   182.355  23339
W>D:WG39.MMM  V<D:WG39.MMM  C>B:WG39.MMM  V<B:WG39.MMM   191.953  23339
W>E:YQ40.MMM  V<E:YQ40.MMM  C>A:YQ40.MMM  V<A:YQ40.MMM   201.797  23339
W>E:AF41.MMM  V<E:AF41.MMM  C>B:AF41.MMM  V<B:AF41.MMM   211.887  23339
W>C:XF42.MMM  V<C:XF42.MMM  C>E:XF42.MMM  V<E:XF42.MMM   222.223  23339
W>E:PD43.MMM  V<E:PD43.MMM  C>B:PD43.MMM  V<B:PD43.MMM   232.805  23339
W>C:CQ44.MMM  V<C:CQ44.MMM  C>E:CQ44.MMM  V<E:CQ44.MMM   243.633  23339
W>B:EC45.MMM  V<B:EC45.MMM  C>A:EC45.MMM  V<A:EC45.MMM   254.707  23339
W>C:TY46.MMM  V<C:TY46.MMM  C>A:TY46.MMM  V<A:TY46.MMM   266.027  23339
W>C:TW47.MMM  V<C:TW47.MMM  C>D:TW47.MMM  V<D:TW47.MMM   277.594  23339
W>E:OP48.MMM  V<E:OP48.MMM  C>D:OP48.MMM  V<D:OP48.MMM   289.406  23339
W>B:XY49.MMM  V<B:XY49.MMM  C>E:XY49.MMM  V<E:XY49.MMM   301.465  23339
W>A:WI50.MMM  V<A:WI50.MMM  C>C:WI50.MMM  V<C:WI50.MMM   313.77  23339
W>D:XB51.MMM  V<D:XB51.MMM  C>A:XB51.MMM  V<A:XB51.MMM   326.32  23339
W>D:VH52.MMM  V<D:VH52.MMM  C>C:VH52.MMM  V<C:VH52.MMM   339.117  23339
W>C:VE53.MMM  V<C:VE53.MMM  C>B:VE53.MMM  V<B:VE53.MMM   352.16  23339
W>E:HB54.MMM  V<E:HB54.MMM  C>D:HB54.MMM  V<D:HB54.MMM   365.449  23339
W>A:HM55.MMM  V<A:HM55.MMM  C>C:HM55.MMM  V<C:HM55.MMM   378.984  23339
W>B:DZ56.MMM  V<B:DZ56.MMM  C>A:DZ56.MMM  V<A:DZ56.MMM   392.766  23339
W>D:GW57.MMM  V<D:GW57.MMM  C>A:GW57.MMM  V<A:GW57.MMM   406.793  23339
W>A:PT58.MMM  V<A:PT58.MMM  C>E:PT58.MMM  V<E:PT58.MMM   421.066  23339
W>A:OD59.MMM  V<A:OD59.MMM  C>E:OD59.MMM  V<E:OD59.MMM   435.586  23339
W>B:OW60.MMM  V<B:OW60.MMM  C>C:OW60.MMM  V<C:OW60.MMM   450.352  23339
W>A:YG61.MMM  V<A:YG61.MMM  C>E:YG61.MMM  V<E:YG61.MMM   465.363  23339
W>B:NW62.MMM  V<B:NW62.MMM  C>C:NW62.MMM  V<C:NW62.MMM   480.621  23339
W>A:HX63.MMM  V<A:HX63.MMM  C>B:HX63.MMM  V<B:HX63.MMM   496.125  23339
W>D:OI64.MMM  V<D:OI64.MMM  C>E:OI64.MMM  V<E:OI64.MMM   511.875  23339
W>A:AN65.MMM  V<A:AN65.MMM  C>B:AN65.MMM  V<B:AN65.MMM   527.871  23339
W>D:BT66.MMM  V<D:BT66.MMM  C>A:BT66.MMM  V<A:BT66.MMM   544.113  23339
W>D:HX67.MMM  V<D:HX67.MMM  C>C:HX67.MMM  V<C:HX67.MMM   560.602  23339
W>A:XA68.MMM  V<A:XA68.MMM  C>D:XA68.MMM  V<D:XA68.MMM   577.336  23339
W>C:WJ69.MMM  V<C:WJ69.MMM  C>B:WJ69.MMM  V<B:WJ69.MMM   594.316  23339
W>E:VX70.MMM  V<E:VX70.MMM  C>A:VX70.MMM  V<A:VX70.MMM   611.543  23339
W>A:IV71.MMM  V<A:IV71.MMM  C>D:IV71.MMM  V<D:IV71.MMM   629.016  23339
W>A:SJ72.MMM  V<A:SJ72.MMM  C>C:SJ72.MMM  V<C:SJ72.MMM   646.734  23339
W>B:US73.MMM  V<B:US73.MMM  C>C:US73.MMM  V<C:US73.MMM   664.699  23339
W>B:WQ74.MMM  V<B:WQ74.MMM  C>C:WQ74.MMM  V<C:WQ74.MMM   682.91  23339
W>D:RX75.MMM  V<D:RX75.MMM  C>A:RX75.MMM  V<A:RX75.MMM   701.367  23339
W>E:HP76.MMM  V<E:HP76.MMM  C>B:HP76.MMM  V<B:HP76.MMM   720.07  23339
W>B:QO77.MMM  V<B:QO77.MMM  C>C:QO77.MMM  V<C:QO77.MMM   739.02  23339
W>A:MS78.MMM  V<A:MS78.MMM  C>D:MS78.MMM  V<D:MS78.MMM   758.215  23339
W>B:IU79.MMM  V<B:IU79.MMM  C>D:IU79.MMM  V<D:IU79.MMM   777.656  23339
W>A:UD80.MMM  V<A:UD80.MMM  C>B:UD80.MMM  V<B:UD80.MMM   797.344  23339
W>D:GW81.MMM  V<D:GW81.MMM  C>C:GW81.MMM  V<C:GW81.MMM   817.277  23339
W>D:OJ82.MMM  V<D:OJ82.MMM  C>E:OJ82.MMM  V<E:OJ82.MMM   837.457  23339
W>D:XG83.MMM  V<D:XG83.MMM  C>C:XG83.MMM  V<C:XG83.MMM   857.883  23339
W>E:QB84.MMM  V<E:QB84.MMM  C>A:QB84.MMM  V<A:QB84.MMM   878.555  23339
W>A:LI85.MMM  V<A:LI85.MMM  C>E:LI85.MMM  V<E:LI85.MMM   899.473  23339
W>D:FX86.MMM  V<D:FX86.MMM  C>B:FX86.MMM  V<B:FX86.MMM   920.637  23339
W>C:HW87.MMM  V<C:HW87.MMM  C>E:HW87.MMM  V<E:HW87.MMM   942.047  23339
W>E:KP88.MMM  V<E:KP88.MMM  C>A:KP88.MMM  V<A:KP88.MMM   963.703  23339
W>B:SX89.MMM  V<B:SX89.MMM  C>E:SX89.MMM  V<E:SX89.MMM   985.606  23339
W>B:JT90.MMM  V<B:JT90.MMM  C>C:JT90.MMM  V<C:JT90.MMM   1007.75  23339
W>C:TK91.MMM  V<C:TK91.MMM  C>D:TK91.MMM  V<D:TK91.MMM   1030.15  23339
W>E:PB92.MMM  V<E:PB92.MMM  C>A:PB92.MMM  V<A:PB92.MMM   1052.79  23339
W>C:LH93.MMM  V<C:LH93.MMM  C>E:LH93.MMM  V<E:LH93.MMM   1075.68  23339
W>A:JF94.MMM  V<A:JF94.MMM  C>B:JF94.MMM  V<B:JF94.MMM   1098.81  23339
W>A:LX95.MMM  V<A:LX95.MMM  C>E:LX95.MMM  V<E:LX95.MMM   1122.19  23339
W>D:WG96.MMM  V<D:WG96.MMM  C>A:WG96.MMM  V<A:WG96.MMM   1145.81  23339
W>A:TV97.MMM  V<A:TV97.MMM  C>B:TV97.MMM  V<B:TV97.MMM   1169.68  23339
W>D:RW98.MMM  V<D:RW98.MMM  C>A:RW98.MMM  V<A:RW98.MMM   1193.8  23339
W>A:OP99.MMM  V<A:OP99.MMM  C>D:OP99.MMM  V<D:OP99.MMM   1218.16  23339
W>D:CY100.MMM V<D:CY100.MMM C>A:CY100.MMM V<A:CY100.MMM  1242.77  23337
W>C:LJ101.MMM V<C:LJ101.MMM C>D:LJ101.MMM V<D:LJ101.MMM  1267.63  23337
W>D:FW102.MMM V<D:FW102.MMM C>B:FW102.MMM V<B:FW102.MMM  1292.73  23337
W>E:AC103.MMM V<E:AC103.MMM C>A:AC103.MMM V<A:AC103.MMM  1318.08  23337
W>A:YD104.MMM V<A:YD104.MMM C>D:YD104.MMM V<D:YD104.MMM  1343.67  23337
W>C:OZ105.MMM V<C:OZ105.MMM C>B:OZ105.MMM V<B:OZ105.MMM  1369.51  23337
W>B:WH106.MMM V<B:WH106.MMM C>A:WH106.MMM V<A:WH106.MMM  1395.6  23337
W>D:ND107.MMM V<D:ND107.MMM C>C:ND107.MMM V<C:ND107.MMM  1421.93  23337
W>A:AX108.MMM V<A:AX108.MMM C>C:AX108.MMM V<C:AX108.MMM  1448.51  23337
W>B:VK109.MMM V<B:VK109.MMM C>E:VK109.MMM V<E:VK109.MMM  1475.33  23337
W>E:OY110.MMM V<E:OY110.MMM C>D:OY110.MMM V<D:OY110.MMM  1502.4  23337
W>C:JG111.MMM V<C:JG111.MMM C>A:JG111.MMM V<A:JG111.MMM  1529.72  23337
W>B:SH112.MMM V<B:SH112.MMM C>C:SH112.MMM V<C:SH112.MMM  1557.28  23337
W>C:LE113.MMM V<C:LE113.MMM C>D:LE113.MMM V<D:LE113.MMM  1585.09  23337
W>D:GN114.MMM V<D:GN114.MMM C>C:GN114.MMM V<C:GN114.MMM  1613.14  23337
W>A:JD115.MMM V<A:JD115.MMM C>B:JD115.MMM V<B:JD115.MMM  1641.45  23337
W>B:JJ116.MMM V<B:JJ116.MMM C>E:JJ116.MMM V<E:JJ116.MMM  1669.99  23337
W>C:ED117.MMM V<C:ED117.MMM C>A:ED117.MMM V<A:ED117.MMM  1698.79  23337
W>A:KW118.MMM V<A:KW118.MMM C>B:KW118.MMM V<B:KW118.MMM  1727.82  23337
W>D:HE119.MMM V<D:HE119.MMM C>E:HE119.MMM V<E:HE119.MMM  1757.11  23337
W>D:XJ120.MMM V<D:XJ120.MMM C>C:XJ120.MMM V<C:XJ120.MMM  1786.64  23337
W>A:SX121.MMM V<A:SX121.MMM C>D:SX121.MMM V<D:SX121.MMM  1816.42  23337
W>A:WL122.MMM V<A:WL122.MMM C>D:WL122.MMM V<D:WL122.MMM  1846.44  23337
W>E:WH123.MMM V<E:WH123.MMM C>A:WH123.MMM V<A:WH123.MMM  1876.71  23337
W>A:LX124.MMM V<A:LX124.MMM C>B:LX124.MMM V<B:LX124.MMM  1907.23  23337
W>D:CW125.MMM V<D:CW125.MMM C>C:CW125.MMM V<C:CW125.MMM  1937.99  23337
W>D:UN126.MMM V<D:UN126.MMM C>A:UN126.MMM V<A:UN126.MMM  1969  23337
W>C:YZ127.MMM V<C:YZ127.MMM C>E:YZ127.MMM V<E:YZ127.MMM  2000.25  23337
W>C:ZL128.MMM V<C:ZL128.MMM C>B:ZL128.MMM V<B:ZL128.MMM  2031.75  23337
W>A:JQ129.MMM V<A:JQ129.MMM C>D:JQ129.MMM V<D:JQ129.MMM  2063.5  23337
W>D:ZJ130.MMM V<D:ZJ130.MMM C>B:ZJ130.MMM V<B:ZJ130.MMM  2095.49  23337
W>E:IY131.MMM V<E:IY131.MMM C>B:IY131.MMM V<B:IY131.MMM  2127.73  23337
W>D:LP132.MMM V<D:LP132.MMM C>A:LP132.MMM V<A:LP132.MMM  2160.21  23337
W>C:RP133.MMM V<C:RP133.MMM C>B:RP133.MMM V<B:RP133.MMM  2192.94  23337
W>E:BS134.MMM V<E:BS134.MMM C>B:BS134.MMM V<B:BS134.MMM  2225.92  23337
W>A:UI135.MMM V<A:UI135.MMM C>C:UI135.MMM V<C:UI135.MMM  2259.14  23337
W>B:WA136.MMM V<B:WA136.MMM C>C:WA136.MMM V<C:WA136.MMM  2292.61  23337
W>A:DQ137.MMM V<A:DQ137.MMM C>C:DQ137.MMM V<C:DQ137.MMM  2326.32  23337
W>D:DS138.MMM V<D:DS138.MMM C>C:DS138.MMM V<C:DS138.MMM  2360.29  23337
W>C:JX139.MMM V<C:JX139.MMM C>A:JX139.MMM V<A:JX139.MMM  2394.49  23337
W>E:MO140.MMM V<E:MO140.MMM C>C:MO140.MMM V<C:MO140.MMM  2428.95  23337
W>B:XS141.MMM V<B:XS141.MMM C>D:XS141.MMM V<D:XS141.MMM  2463.64  23337
W>D:UW142.MMM V<D:UW142.MMM C>A:UW142.MMM V<A:UW142.MMM  2498.59  23337
W>B:TL143.MMM V<B:TL143.MMM C>E:TL143.MMM V<E:TL143.MMM  2533.78  23337
W>A:HX144.MMM V<A:HX144.MMM C>E:HX144.MMM V<E:HX144.MMM  2569.22  23337
W>B:UU145.MMM V<B:UU145.MMM C>D:UU145.MMM V<D:UU145.MMM  2604.9  23337
W>B:WO146.MMM V<B:WO146.MMM C>D:WO146.MMM V<D:WO146.MMM  2640.83  23337
W>C:QS147.MMM V<C:QS147.MMM C>E:QS147.MMM V<E:QS147.MMM  2677.01  23337
W>B:MI148.MMM V<B:MI148.MMM C>C:MI148.MMM V<C:MI148.MMM  2713.43  23337
W>C:OW149.MMM V<C:OW149.MMM C>A:OW149.MMM V<A:OW149.MMM  2750.1  23337
W>D:BV150.MMM V<D:BV150.MMM C>C:BV150.MMM V<C:BV150.MMM  2787.01  23337
W>C:TN151.MMM V<C:TN151.MMM C>D:TN151.MMM V<D:TN151.MMM  2824.17  23337
W>B:KC152.MMM V<B:KC152.MMM C>C:KC152.MMM V<C:KC152.MMM  2861.58  23337
W>A:QA153.MMM V<A:QA153.MMM C>B:QA153.MMM V<B:QA153.MMM  2899.23  23337
W>D:XR154.MMM V<D:XR154.MMM C>E:XR154.MMM V<E:XR154.MMM  2937.13  23337
W>E:CU155.MMM V<E:CU155.MMM C>A:CU155.MMM V<A:CU155.MMM  2975.27  23337
W>B:ZZ156.MMM V<B:ZZ156.MMM C>C:ZZ156.MMM V<C:ZZ156.MMM  3013.66  23337
W>E:DS157.MMM V<E:DS157.MMM C>B:DS157.MMM^C

I have not encountered problems yet, but I want to make sure I have a proper understanding of mm8.bas and modchk5.bas before I run them overnight.

My power supply is an adjustable bench power supply over 24" pigtail.  The voltage on board is 4.99V

  Bill

Jon Langseth

unread,
Aug 20, 2018, 11:44:56 AM8/20/18
to LiNC80
It looks like you've got the running of the mm and modcheck right. As you are running this on the Z280RC, I think you'll see no errors.

First, it seems we have concluded that the errors we have seen are not caused by the version of BASIC used, or the powersupply. We have not come to a proper conclusion, but it seems there is either crosstalk, capacitive coupling or interference causing the errors that the LiNC80 exhibits, and that it is caused by the board layout or bus termination. These issues seem to only manifest on the LiNC80 when it is running repetitive tight-loop tasks, as the modchk is, and it has been shown that the impact of the issue can be reduced by selection of powersupply and cf-card.

As you are using the Z280RC, I would be very surprised if you encounter any of the same problems. It has a very different, even if somewhat compatible design, and it uses a very different CF-card approach.

On Monday, August 20, 2018 at 6:33:10 AM UTC+2:
[snip]

Bill Shen

unread,
Aug 20, 2018, 2:00:12 PM8/20/18
to LiNC80

I think you are right that Z280RC won't see problems with mm8 and modchk5.  I ran the mm8 with 5 disk partitions twice and both times it ran OK for over an hour until it ran out of disk space on the small RAM disk (1.5 meg).  I think I can run it longer if I change mm8.bas to only use 4 disk partitions of 8 meg per drive.

I also have another Z280-based SBC that has 8-bit Z80-compatible bus:
https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:zz80rc
But it has no CF interface, just two small RAM disks.  It ran modchk5 fine for many hours and can run mm8 OK for a few minutes until it ran out of disk space.  I do like the mm8 diagnostics and when I do add a CF interface, I'll run the mm8 diagnostic again.

  Bill
Reply all
Reply to author
Forward
0 new messages