6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Wed Sep 25, 2024 1:25 pm

All times are UTC




Post new topic Reply to topic  [ 19 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Sat Aug 28, 2021 5:29 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1382
I guess I wasn't clear on my suggestion. I was thinking that having the memory config specified in the NVRAM would be used to define what address ranges you actually test upon cold start, not bypassing the memory test.

Getting corrupted NVRAM can happen when testing code... I've seen this as well. I'd also note that if you managed to corrupt the NVRAM on the RTC, then it's pretty much a given that you corrupted the entire RTC set of registers before you clobbered the NVRAM. Once you have properly working code, this issue should go away. Having the checksum in the NVRAM can indicate that the RTC is not properly setup, so you can invoke some additional ROM code to allow setup.

Swapping out the RTC - well, you can say about any of the socketed components. In some cases, it could be comparable to swapping out the EEPROM, as both hold specific data. You would certainly program the new EEPROM before installing it... and likewise, you would setup the RTC registers when installing a new one, otherwise, no-worky.

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 28, 2021 5:38 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10938
Location: England
I realise: if you know the useful RAM is going to be found in contiguous low banks, then it's much easier - to march through the banks, checking if each one is RAM, and if it's a mirror of an earlier bank. Even easier if you know that banks will be supplied in multiples of 2 or 8, and can make assumptions about what kind of mirroring might occur.

In other words, a less general situation will admit a simpler solution!


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 29, 2021 5:04 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1948
Location: Sacramento, CA, USA
Here's a very untested little routine that cruises up and down all of the 64K banks and populates a 256 byte table with zeros for banks where it encounters at least one byte of valid RAM and non-zeros for banks that are mirrors of a lower-numbered bank or simply not RAM. I'm just throwing it out here for comments ... if you don't think it's something you can use, my feelings won't be hurt:
Code:
; sizemem:  Create a table which marks banks
; containing at least one byte of RAM.
; Read and save one location from each bank in
; ascending order in a 256 byte table.
; Write a signature byte to those same locations
; in descending order, then check for the proper
; signature in ascending order.  If that byte
; appears to be RAM, mark it as so in the same
; table and restore the original value.
; This should allow identification of non-RAM
; banks and higher-numbered banks of mirrored RAM,
; but it's probably not quite 100% fool-proof.
; Needs 3 bytes of direct page for ptr, 3 bytes
; + return address of stack, and 256 bytes of
; the current data bank for bufferd.
sizemem:
    php
    sep #$30       ; 8-bit everything
    lda #$5a
    sta ptr
    sta ptr+1
    stz ptr+2      ; start at address $005a5a
    ldy #0
savebnk:
    lda [ptr]
    sta bufferd,y  ; save original byte values
    inc ptr+2      ; in ascending order
    iny
    bne savebnk
seedbnk:
    dec ptr+2
    lda ptr+2
    eor #$ff
    cmp [ptr]
    bne seed2
    eor #$a5       ; make sure we change it
seed2:
    sta [ptr]      ; seed $xx5a5a for every xx
    dey            ; in descending order
    bne seedbnk
chkbnk:
    lda ptr+2
    eor #$ff
    cmp bufferd,y
    beq chk2
    eor #$a5
chk2:
    eor [ptr]      ; check for expected seed
    bne notram     ; absent or mirrored RAM
    lda buffrd,y
    sta [ptr]      ; restore original byte value
    lda #0         ; zero means "good" bank
notram:
    sta bufferd,y  ; non-zero means "no-good"
    inc ptr+2
    iny
    bne chkbnk
    plp
    rts

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Last edited by barrym95838 on Sun Sep 12, 2021 6:45 am, edited 2 times in total.

Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 30, 2021 2:58 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8395
Location: Midwestern USA
floobydust wrote:
I guess I wasn't clear on my suggestion. I was thinking that having the memory config specified in the NVRAM would be used to define what address ranges you actually test upon cold start, not bypassing the memory test.

Using NVRAM to define the address range to test is what I'm trying to avoid. If I can reliably determine how many banks are installed then the memory test becomes self-configuring.

BigEd wrote:
I realise: if you know the useful RAM is going to be found in contiguous low banks, then it's much easier...In other words, a less general situation will admit a simpler solution!

Bingo!

I did mention earlier that only certain combinations of RAM and resulting total RAM sizes would be used. Also, the "contiguous low banks" thing is a planned feature of the machine's architecture.

Anyhow, in cogitating on this while looking at address bit patterns and available single-piece RAM sizes, I developed the following rules for populating memory :

  1. Installed total memory will 64KB × N, where N is the number of installed banks. Since it is possible to build a 65C816 system with no extended RAM—only basic RAM, N will always start at 1. As an aside, in most practical systems, bank $00 space would not be 100 percent RAM, but that doesn't affect the memory population "formula."

  2. Extended banks will be contiguous and bank $01 will be the first extended bank. In other words, there will be no "memory holes."

  3. In a system with extended RAM, each addition to installed RAM will double the number of total banks. Ergo the installed RAM progression would be 128KB, 256KB, 512KB, etc., which is readily accommodated with available SRAM.

  4. Finally, the top of bank $00 will always be ROM (starting with V1.2, ROM extends from $00D000 to $00FFFF). Hence RAM from $010000 onward will be contiguous

Once I had formulated the above, it quickly became apparent that the bank discovery algorithm would be relatively uncomplicated. So I wrote test code to run on POC V1.3. V1.3 only has 128KB of RAM, so the test run isn't conclusive. However, it appears the algorithm's principle is correct, as the test run reported that there is one extended RAM bank. I also dusted off V1.1, which has no extended RAM, and ran the test, which reported that are no extended banks.

Code:
;exbchk: NON-DESTRUCTIVELY DETERMINE NUMBER OF EXTENDED RAM BANKS
;
;   ———————————————————————————————————————————————————————————————————————
;   This function determines how many extended RAM banks are present.  The
;   result of testing will be a 16-bit integer in the range $0000 (no ex-
;   tended RAM detected) to $00FF.  The test result is stored in location
;   EXBANKS.  This is not a detailed memory test—only 2 locations are
;   tested.
;
;   The test location's address LSW points to an address in ROM.  The MSW
;   is the bank being checked.  A 16-bit test pattern is written to that
;   address, a short delay is executed & the test location is compared to
;   the test pattern.  If the comparison fails, either the test location is
;   ROM or a defective pair of memory cells.  In either case, testing is
;   terminated & the bank being probed, as well as all succeeding banks, is
;   assumed to not be present.
;
;   If the comparison succeeds then the test pattern is byte-swapped &
;   again written, the delay executed & the test location compared to the
;   pattern.  This redundant check accounts for a case where the test loc-
;   ation coincidentally has the same content as the test pattern.
;
;   Testing is non-destructive.  If the location appears to be RAM, an att-
;   empt will be made to restore the original content & verify it.  If the
;   verification fails testing will be halted & carry will be set upon ret-
;   turn.  If the verification succeeds, the bank being tested is assumed
;   to exist & the MSW of the test location address will be incremented to
;   point to the next bank, & the test will be repeated.  EXBANKS will con-
;   tain the number of extended banks that were detected & carry will be
;   clear upon return.
;
;   Carry will be clear upon return even if no extended RAM is present.  In
;   such a case EXBANKS will contain $0000.
;
;   Note that this test procedure will malfunction if the total number of
;   installed banks is an odd number or is not an exact multiple of 2.
;
;   All registers are used & will be set to 16-bits upon return.  Elapsed
;   time for testing will be, worst case, 18-20 milliseconds per bank.  A
;   test of a system with 16MB of RAM could take approximately 6 seconds to
;   finish on a 16 MHz system.
;   ———————————————————————————————————————————————————————————————————————
;
exbchk   longr                 ;16-bit everything
;
;—————————————————————————————————————————————————
;LOCAL DEFINITIONS
;
.delay   =32768                ;test delay counter
.testpat =%1010010110100101    ;test pattern
;—————————————————————————————————————————————————
;
         lda !#v_udefnm        ;test cells LSW
         sta addra             ;set test address LSW
         stz addra+s_word      ;starting bank = $00
         stz exbanks           ;reset extended bank count
;
.0000010 inc addra+s_word      ;next bank
         lda addra+s_word      ;get bank & byte-swap it
         xba                   ;bank $FF checked?
         bne .0000050          ;yes, done
;
         lda [addra]           ;fetch from test cells &...
         tax                   ;preserve
         lda !#.testpat        ;test pattern
         sta [addra]           ;write it
         ldy !#.delay          ;delay period
;
.0000020 dey                   ;short delay to allow...
         bne .0000020          ;RAM to "settle"
;
         cmp [addra]           ;check test cells
         bne .0000050          ;no more banks...
;
;   ——————————————————————————————————————————————————————————————————
;   If the above comparison fails then one of the below possibilities
;   exists:
;
;   1) The bank number being tested is even ($02, $04, $0A, etc.) & is
;      a mirror of bank $00.  Hence the comparison will be against ROM
;      instead of RAM & will, of course, fail.
;
;   2) The bank being tested is not a mirror of bank $00, which means
;      one or both of the test cells is/are defective.
;
;   As it isn't possible at this point in the test cycle to determine
;   which of the above cases applies, it must be assumed the bank that
;   is being probed doesn't exist.  That being the case, the test will
;   be terminated.
;   ——————————————————————————————————————————————————————————————————
;
         xba                   ;reverse test pattern &...
         sta [addra]           ;write it
         ldy !#.delay
;
.0000030 dey                   ;short delay
         bne .0000030
;
         cmp [addra]           ;test pattern good?
         bne .0000060          ;no, abort...
;
;   ———————————————————————————————————————————————
;   If the above comparison fails then it is likely
;   that RAM is defective at the test location.
;   ———————————————————————————————————————————————
;
         txa                   ;yes, restore...
         sta [addra]           ;old content
         ldy !#.delay
;
.0000040 dey                   ;yet another delay
         bne .0000040
;
         cmp [addra]           ;verify original content
         bne .0000060          ;oops!
;
         inc exbanks           ;bump extended bank count &...
         bra .0000010          ;probe next bank
;
.0000050 clc                   ;completed wo/error
         rts
;
.0000060 lda !#e_memory        ;return memory fault code &...
         sec                   ;die with an error
         rts

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: barnacle and 22 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: