Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #1367 > unrolled thread

Can anyone see a way to improve this ?

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Can anyone see a way to improve this ? mdj <mdj.mdj@gmail.com> - 2014-10-27 05:04 -0700
    Re: Can anyone see a way to improve this ? "Anton Treuenfels" <teamtempest@yahoo.com> - 2014-10-27 08:38 -0500
    Re: Can anyone see a way to improve this ? Vladimir Ivanov <none@none.tld> - 2014-10-27 15:56 +0200
      Re: Can anyone see a way to improve this ? Michael J. Mahon <mjmahon@aol.com> - 2014-10-27 13:21 -0500
        Re: Can anyone see a way to improve this ? mdj <mdj.mdj@gmail.com> - 2014-10-27 17:48 -0700
          Re: Can anyone see a way to improve this ? Snertking <SNERTKING@GMAIL.COM> - 2014-10-27 21:28 -0400
            Re: Can anyone see a way to improve this ? mdj <mdj.mdj@gmail.com> - 2014-10-27 22:45 -0700
              Re: Can anyone see a way to improve this ? Michael J. Mahon <mjmahon@aol.com> - 2014-10-29 10:33 -0500
                Re: Can anyone see a way to improve this ? mdj <mdj.mdj@gmail.com> - 2014-10-29 22:54 -0700
                  Re: Can anyone see a way to improve this ? qkumba <peter.ferrie@gmail.com> - 2014-10-31 14:46 -0700
        Re: Can anyone see a way to improve this ? Snertking <SNERTKING@GMAIL.COM> - 2014-10-27 21:25 -0400
        Re: Can anyone see a way to improve this ? michael.pohoreski@gmail.com - 2014-12-30 10:12 -0800
    Re: Can anyone see a way to improve this ? awanderin <awanderin@gmail.com> - 2014-10-27 21:35 -0600

#1367 — Can anyone see a way to improve this ?

Hi,

Below is a memory test loop for 1 page - assume the high order bytes get replaced for each page being tested. Zero page is deliberately avoided - this runs in either the language card or the $800-$BFFF area of main memory, testing pages of auxiliary memory without assuming any given byte of aux memory works.

The obvious one is to unroll, which I'll do. Just wondering if I'm missing something else obvious.

Thanks,

Matt


         LDX   #$00
NEXTBYTE LDY   #$08
         LDA   #$01
NEXTBIT  EOR   #$FF       ; Set and check complement first
         STA   $2000,X
         CMP   $2000,X
         BNE   ERROR
         EOR   #$FF
         STA   $2000,X
         CMP   $2000,X
         BEQ   CONT
ERROR    JSR   FLAGERR
CONT     ASL
         DEY
         BNE   NEXTBIT
         INX
         BNE   NEXTBYTE
         RTS
FLAGERR  RTS              ; Record this meaningfully in the future

[toc] | [next] | [standalone]

#1368

"mdj" <mdj.mdj@gmail.com> wrote in message 
news:34030b70-c7cb-4b31-a99a-6b44c3877066@googlegroups.com...

         LDX   #$00
NEXTBYTE LDY   #$08
         LDA   #$01
NEXTBIT  EOR   #$FF       ; Set and check complement first
         STA   $2000,X
         CMP   $2000,X
         BNE   ERROR
         EOR   #$FF
         STA   $2000,X
         CMP   $2000,X
         BEQ   CONT
ERROR    JSR   FLAGERR
CONT     ASL
         DEY
         BNE   NEXTBIT
         INX
         BNE   NEXTBYTE
         RTS
FLAGERR  RTS              ; Record this meaningfully in the future

=======================

Well you might consider that "ASL" is moving a single set bit "across" the 
A-register from least to most significant bit. Every shift sends a zero bit 
into the carry register - except when the set bit is the MSB, in which case 
the shift will set the carry flag. So you could use that as a signal to 
branch to "NEXTBIT" and not use the Y-register as a counter at all.

Similarly the Z-flag will not be set as long as there is a set bit in the 
A-register, but a shift from the MSB to the carry flag will leave the 
A-register all zero bits, so the Z-flag will be set. You could use that if 
you like, and similary eliminate the Y-register as a counter.

Of course neither will work reliably if "FLAGERR" disturbs the A-register. 
But if so you can put the Y-register to good use like this:

   TAY
   JSR FLAGERR
   TYA

...and as long as FLAGERR doesn't disturb the Y-register you should be okay. 
Otherwise perhaps a judiciously placed PHA/PLA combination would protect the 
value in the A-register.

These changes only save 18 cycles per byte, though, or 4608 cycles per page. 
So while shorter and faster, it's not likely going to make a noticeable 
difference. On a 1-MHz machine you'd have to check around 2000 pages to save 
a single second.

- Anton Treuenfels

[toc] | [prev] | [next] | [standalone]

#1369

On Mon, 27 Oct 2014, mdj wrote:

> Hi,
>
> Below is a memory test loop for 1 page - assume the high order bytes get replaced for each page being tested. Zero page is deliberately avoided - this runs in either the language card or the $800-$BFFF area of main memory, testing pages of auxiliary memory without assuming any given byte of aux memory works.
>
> The obvious one is to unroll, which I'll do. Just wondering if I'm missing something else obvious.
>
> Thanks,
>
> Matt
>
>
>         LDX   #$00
> NEXTBYTE LDY   #$08
>         LDA   #$01
> NEXTBIT  EOR   #$FF       ; Set and check complement first
>         STA   $2000,X
>         CMP   $2000,X
>         BNE   ERROR
>         EOR   #$FF
>         STA   $2000,X
>         CMP   $2000,X
>         BEQ   CONT
> ERROR    JSR   FLAGERR
> CONT     ASL
>         DEY
>         BNE   NEXTBIT
>         INX
>         BNE   NEXTBYTE
>         RTS
> FLAGERR  RTS              ; Record this meaningfully in the future
>

You might want to change "BEQ COUNT" to "BNE ..." outside of the loop upon 
error, and save a cycle.

And for heavier memory test, you could sacrifice speed, fill the memory 
with pseudo-random pattern, wait some time, and then check with same seed 
again. Rinse and repeat. This does not substitute specialized tests like 
walking 0/1s.

[toc] | [prev] | [next] | [standalone]

#1370

Vladimir Ivanov <none@none.tld> wrote:
> On Mon, 27 Oct 2014, mdj wrote:
> 
>> Hi,
>> 
>> Below is a memory test loop for 1 page - assume the high order bytes get
>> replaced for each page being tested. Zero page is deliberately avoided -
>> this runs in either the language card or the $800-$BFFF area of main
>> memory, testing pages of auxiliary memory without assuming any given
>> byte of aux memory works.
>> 
>> The obvious one is to unroll, which I'll do. Just wondering if I'm
>> missing something else obvious.
>> 
>> Thanks,
>> 
>> Matt
>> 
>> 
>>         LDX   #$00
>> NEXTBYTE LDY   #$08
>>         LDA   #$01
>> NEXTBIT  EOR   #$FF       ; Set and check complement first
>>         STA   $2000,X
>>         CMP   $2000,X
>>         BNE   ERROR
>>         EOR   #$FF
>>         STA   $2000,X
>>         CMP   $2000,X
>>         BEQ   CONT
>> ERROR    JSR   FLAGERR
>> CONT     ASL
>>         DEY
>>         BNE   NEXTBIT
>>         INX
>>         BNE   NEXTBYTE
>>         RTS
>> FLAGERR  RTS              ; Record this meaningfully in the future
>> 
> 
> You might want to change "BEQ COUNT" to "BNE ..." outside of the loop
> upon error, and save a cycle.
> 
> And for heavier memory test, you could sacrifice speed, fill the memory
> with pseudo-random pattern, wait some time, and then check with same seed
> again. Rinse and repeat. This does not substitute specialized tests like walking 0/1s.

I think I'd test two patterns, $55 and $AA, and only look for which bit
fails if any of them do. 

Single bit errors in RAMs tend not to be crosstalk errors, where all other
bits can cause the bad one to flip--in other words, the bits can be
considered independent. 
-- 
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

[toc] | [prev] | [next] | [standalone]

#1371

On Tuesday, 28 October 2014 04:21:56 UTC+10, mjm...@aol.com  wrote:

> I think I'd test two patterns, $55 and $AA, and only look for which bit
> fails if any of them do. 

Yeah - I've already implemented this one as a faster "QC Passed" test. The 'walking ones' style test above (with the redundant Y-register use and one level of unroll) takes approximately 1 hour to test 16MB of RAM. Unfortunately all extant accelerators violate the spirit of the test :-)

> Single bit errors in RAMs tend not to be crosstalk errors, where all other
> bits can cause the bad one to flip--in other words, the bits can be
> considered independent. 

These particular chips are 0.5mm pin-pitch TSOP packages, so I was more concerned about crosstalk due to a poor solder joint making an air-gap capacitor between two adjacent address/data pins.

Matt

[toc] | [prev] | [next] | [standalone]

#1373

On 10/27/2014 20:48, mdj wrote:
> These particular chips are 0.5mm pin-pitch TSOP packages,


um... so this isn't an actual apple II this is being run on? Or am i 
missing some model that used ram in that style packaging?


do tell what this is for. Curious folks wanna know!

[toc] | [prev] | [next] | [standalone]

#1375

On Tuesday, 28 October 2014 11:28:44 UTC+10, Snertking  wrote:

> um... so this isn't an actual apple II this is being run on? Or am i 
> missing some model that used ram in that style packaging?
> 
> 
> do tell what this is for. Curious folks wanna know!

This is for testing the ScramWorks, a yet-to-be-release 8 or 16MB RamWorks compatible memory card for the IIe.

Matt

[toc] | [prev] | [next] | [standalone]

#1381

mdj <mdj.mdj@gmail.com> wrote:
> On Tuesday, 28 October 2014 11:28:44 UTC+10, Snertking  wrote:
> 
>> um... so this isn't an actual apple II this is being run on? Or am i 
>> missing some model that used ram in that style packaging?
>> 
>> 
>> do tell what this is for. Curious folks wanna know!
> 
> This is for testing the ScramWorks, a yet-to-be-release 8 or 16MB
> RamWorks compatible memory card for the IIe.
> 
> Matt

Woohoo!
-- 
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

[toc] | [prev] | [next] | [standalone]

#1382

On Thursday, 30 October 2014 01:33:55 UTC+10, mjm...@aol.com  wrote:

> Woohoo!

Glad you're enthusiastic about it Michael! Looking forward to seeing what strange and interesting things people do with all the space, once it's available.

Matt

[toc] | [prev] | [next] | [standalone]

#1383

You have a bug that corrupts A in the event on an error in the even bits:
        LDA   #$01 
NEXTBIT  EOR   #$FF       ; Set and check complement first 
         STA   $2000,X 
         CMP   $2000,X 
         BNE   ERROR ;A is negated here
         ...
ERROR    JSR   FLAGERR 
CONT     ASL ;A still negated

If we combine Anton's and Vladmimir's suggestions, and fix the bug, we have this:

         LDX   #$00 
NEXTBYTE LDA   #$01 
NEXTBIT  EOR   #$FF       ; Set and check complement first 
         STA   $2000,X 
         CMP   $2000,X 
         BNE   FLAGERR1
         EOR   #$FF 
         STA   $2000,X 
         CMP   $2000,X 
         BNE   FLAGERR
CONT     ASL 
         BNE   NEXTBIT 
         INX 
         BNE   NEXTBYTE 
         RTS 
FLAGERR1 EOR   #$FF
FLAGERR  TAY  ; or PHA to free Y, but costs 1 more cycle
              ; Record this meaningfully in the future 
         TYA
         JMP   CONT

[toc] | [prev] | [next] | [standalone]

#1372

On 10/27/2014 14:21, Michael J. Mahon wrote:
> the bits can be
> considered independent.


well, yes. correct me if i am wrong, but each bit is on a different 
chip, at least for the II and II+.

[toc] | [prev] | [next] | [standalone]

#1448

On Monday, October 27, 2014 11:21:56 AM UTC-7, mjm...@aol.com wrote:
> I think I'd test two patterns, $55 and $AA, and only look for which bit
> fails if any of them do. 
> 
> Single bit errors in RAMs tend not to be crosstalk errors, where all other
> bits can cause the bad one to flip--in other words, the bits can be
> considered independent. 

I would *highly* recommend having more then just those 2 patterns.

~Two years ago when I upgraded one of my gaming PC's from 8GB to 16GB, I ran memtest86+.  After an hour or so it detected an error.  I naturally assumed it was the _new_ RAM. Turns out it was the _old_ RAM!.  I notified G.Skillz and they actually honored their lifetime memory warranty!!

At the very least I would encourage having a "walking 1's" aka pow2

01
02
04
08
10
20
40
80

Along with the usual byte patterns:
00
FF

See this link for more details on the bit test patterns:

* http://www.memtest86.com/technical.htm#description

[toc] | [prev] | [next] | [standalone]

#1374

mdj <mdj.mdj@gmail.com> writes:

> Hi,
>
> Below is a memory test loop for 1 page - assume the high order bytes
> get replaced for each page being tested. Zero page is deliberately
> avoided - this runs in either the language card or the $800-$BFFF area
> of main memory, testing pages of auxiliary memory without assuming any
> given byte of aux memory works.
>
> The obvious one is to unroll, which I'll do. Just wondering if I'm
> missing something else obvious.
>
> Thanks,
>
> Matt
>
>
>          LDX   #$00
> NEXTBYTE LDY   #$08
>          LDA   #$01
> NEXTBIT  EOR   #$FF       ; Set and check complement first
>          STA   $2000,X
>          CMP   $2000,X
>          BNE   ERROR
>          EOR   #$FF
>          STA   $2000,X
>          CMP   $2000,X
>          BEQ   CONT
> ERROR    JSR   FLAGERR
> CONT     ASL
>          DEY
>          BNE   NEXTBIT
>          INX
>          BNE   NEXTBYTE
>          RTS
> FLAGERR  RTS              ; Record this meaningfully in the future
>
>
>

For a thorough discussion of strong memory-checkers, see this article:

    http://www.ganssle.com/articles/ramtest.htm

I guess it depends on how confident you are in the machine's RAM in the
first place.

--
Jerry    awanderin at gmail dot com

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web