Test for Extended RAM

[flashjazzcat]

I'm working on a routine to allow my word processor to configure itself automatically for a variety of extended RAM configurations. The routine I've come up with, while it works for a standard 130XE, is having trouble recognizing other set-ups. Does anyone have a routine I can use to build up a table of PORTB bank selection masks which works with a variety of RAM upgrades? I assume SpartaDOS X, for example, includes code which recognizes most memory set-ups.

[flashjazzcat]

Have adapted code from the "SmartRAM" RAMdisk driver, and it works properly with all extended memory emulated in Atari800Win. I'll release a beta shortly, which will need testing on real hardware if anyone fancies trying it. Still to add is code to avoid SpartaDOS banked memory/RAMdisks, and similar routines to avoid MyDOS/DOS 2.5/DOS XE expanded RAM usage. At least SpartaDOS X is easy enough to do using COMTAB.

[+Allan]

Have adapted code from the "SmartRAM" RAMdisk driver, and it works properly with all extended memory emulated in Atari800Win. I'll release a beta shortly, which will need testing on real hardware if anyone fancies trying it. Still to add is code to avoid SpartaDOS banked memory/RAMdisks, and similar routines to avoid MyDOS/DOS 2.5/DOS XE expanded RAM usage. At least SpartaDOS X is easy enough to do using COMTAB.

Cool. I'm looking forward to this. I still have to finish my ram upgrade to my 130XE. Hopefully this will modivate me.

 

Allan

[flashjazzcat]

I was getting lots of people reporting errors with LW beta 2.2's extended RAM detection routine, which was adapted from the "SmartRAM" RAMdisk driver and therefore unable to correctly detect several more modern memory upgrades. I decided to have a look at the XRAM utility with a disassembler and there's a section of code in there like this:

 

			ldx #0
		txa
clearloop:
		sta banktable,x
		inx
		bne clearloop
testlp1:
		stx PORTB
		stx $4000
		txa
		clc
		adc #4
		sta $4001
		inx
		bne testlp1
testlp2:
		stx PORTB
		ldy $4000
		tya
		clc
		adc #4
		cmp $4001
		bne notsame
		lda #$FF
		sta banktable,y
notsame:
		inx
		bne testlp2
		rts

This appeared to build a table "banktable", with $FF in locations corresponding to a portb value which resulted in a bank switch. However, I built a test program around it and the cmp $4001 always came out false so the routine never worked. To be honest I'm unclear about how it's supposed to work. Clearly it works in XRAM, so I'm obviously not following the logic of the algorithm properly. Anyway, I sat and thought about it for an hour and then came up with something I could understand.

 

; Expanded RAM test
;
INCLUDE D:STDIO.INC
;
*= $3000
;
START:
			SEI
			LDA NMIEN; TURN OFF INTERRUPTS
			PHA
			LDA #0
		STA NMIEN
			LDA PORTB
			PHA
;
			LDX #0
TESTLP1:
			STX PORTB
			LDA $4000; SAVE MEMORY
			STA SAVETABLE,X
			LDA $4001
			STA SAVETABLE+256,X
			TXA
			STA $4000
			CLC
			ADC #4
			STA $4001
			INX
			BNE TESTLP1
			LDY #0
TESTLP2:
			STX PORTB
			CPX $4000
			BNE NOTSAME
			TXA
			CLC
			ADC #4
			CMP $4001
			BNE NOTSAME
			TXA
			STA BANKTABLE,Y; ADD TO TABLE
			INY
NOTSAME:
			INX
			BNE TESTLP2
			DEY; IGNORE MAIN BANK ($FF)
			STY BANKS; # EXPANDED BANKS IN Y
;
			LDX #0
RESTORE:
			STX PORTB
			LDA SAVETABLE,X; RESTORE OLD VALUES
			STA $4000
			LDA SAVETABLE+256,X
			STA $4001
			INX
			BNE RESTORE
;
			PLA
			STA PORTB
			PLA
			STA NMIEN; RE-ENABLE INTERRUPTS
			CLI
;
			JSR _PRINTF
			BYTE "%d extended banks",155,0
			WORD BANKS
;
			LDA BANKS
			BEQ ALLDONE
			LDA #0
			STA BANK
DISPLOOP:
			LDA #< BANKTABLE
			CLC
			ADC BANK
			STA MASK
			LDA #> BANKTABLE
			ADC #0
			STA MASK+1
			JSR _PRINTF
			BYTE "%02x ",0
MASK:
			WORD $FFFF
			INC BANK
			LDA BANK
			CMP BANKS
			BCC DISPLOOP
;
ALLDONE:
			RTS
;
BANK:
			BYTE 0
BANKS:
			WORD 0
BANKTABLE:
			DS 256
SAVETABLE:
			DS 512
;
			INCLUDE D:PRINTF.INC
;
			END START

This builds a table (banktable) of portb bitmasks, one for every 16K bank in the system. The non-destructive routine writes two unique test values to $4000/$4001, then loops through again to check for them. The last value in the table is always $FF, which is just ignored. The program also displays the number of extended banks and a list of all the portb values. I've tested this with every memory upgrade emulated by Atari800Win and it's worked every time (or should I say the output corresponds to that of XRAM).

 

The advantage of this method is that it should work with every conceivable memory upgrade for the Atari8. Apologies if this is nothing new to some people, but I've been stuck on this problem for ages and I thought it might be of interest to programmers.

 

I've also included a disk image of the program, along with source code:

BANKS.zip

Edited January 7, 2009 by flashjazzcat

[spookt]

Well for someone like myself who is still learning assembler it's always great to see real code along with an explanation, so thanks !

[a8isa1]

This builds a table (banktable) of portb bitmasks, one for every 16K bank in the system. The non-destructive routine writes two unique test values to $4000/$4001, then loops through again to check for them. The last value in the table is always $FF, which is just ignored. The program also displays the number of extended banks and a list of all the portb values. I've tested this with every memory upgrade emulated by Atari800Win and it's worked every time (or should I say the output corresponds to that of XRAM).

 

The advantage of this method is that it should work with every conceivable memory upgrade for the Atari8. Apologies if this is nothing new to some people, but I've been stuck on this problem for ages and I thought it might be of interest to programmers.

 

I've also included a disk image of the program, along with source code:

Thanks for writing this utility.

 

Unfortunately I had 3 problems

 

1) There is something odd about your ATR. DOS 2.0d could read the directory but not load the program.

 

2) After recreating your ATR, your program would now load but immediiately following the display of the bank information the screen clears and the DOS menu appears.

 

The problem occurs with both Atari DOS 2.0d and MyDOS 4.53

 

3) With SpartaDOS 3.2g your program runs fine BUT it mistakenly detects 15 banks (83, 8B, 8F, A3, A7, AB, AF, C3, C7, CB, CF, E3, E7, EB, EF).

 

My memory upgrade is a Wiztronics 256K (total RAM) which I believe is a Rambo XL type. There are only 12 banks.

 

I'm not 100% sure but I believe banks 83, 8B, and BF are not part of this upgrade.

 

- Steve Sheppard

Edited January 7, 2009 by a8isa1

[Heaven/TQA]

unfortunatly my website is gone but thanks to: http://web.archive.org/web/20071231110133/..._nadj/main.html

 

...

 

 

 

Witazije polish coders! Try using extended memory in this way...(special message to Coders of VENT and JOURNEY)

 

Let me give Tamas Bene of HARD the keyboard...

 

"...It depends on what we call "standard". My expansion is 130XE-compatible (without Antic-switching), so all programs which is written for XE should run as well on my Atari. Actually it is a 192K expansion, so the whole memory is 256K.

The problem is that demo-coders (and others) use $d301 in a non-standard way. I mean they change bits in $d301 which work differently on different expansions, or even they store values in $d301 other than $fc-$ff, instead of masking only those bits which are intended to be changed. (Fortunately the Atari OS was written much more carefully, they even use bit masking for setting values like $ff. Otherwise even the OS might not work with extended machines. :^)

For example, I found the following instructions in the Journey demo at several places:

lda #$b3 sta $d301

This has some meaning on a particular expansion, but I have no idea what it should do. For me, it just switches OS in and BASIC out.

BTW, my 192K expansion works as follows:

bits 0,1 and 7 work as for normal Atari (switching OS/Basic/Selftest). bit 4 switches the expansion on/off, just like for 130XE. here is a table for bits 2,3,5,6:

 

bit6 bit5 bit3 bit2 action

------------------------------

0 0 0 0 maps base memory $0000-$3fff to $4000-$7fff

0 0 0 1 maps base memory $4000-$7fff to $4000-$7fff

0 0 1 0 maps base memory $8000-$bfff to $4000-$7fff

0 0 1 1 maps base memory $c000-$ffff to $4000-$7fff

0 1 0 0 extended bank #01 at $4000-$7fff

0 1 0 1 extended bank #02 at $4000-$7fff

0 1 1 0 extended bank #03 at $4000-$7fff

0 1 1 1 extended bank #04 at $4000-$7fff

1 0 0 0 extended bank #05 at $4000-$7fff

1 0 0 1 extended bank #06 at $4000-$7fff

1 0 1 0 extended bank #07 at $4000-$7fff

1 0 1 1 extended bank #08 at $4000-$7fff

1 1 0 0 extended bank #09 at $4000-$7fff

1 1 0 1 extended bank #10 at $4000-$7fff

1 1 1 0 extended bank #11 at $4000-$7fff

1 1 1 1 extended bank #12 at $4000-$7fff

 

 

This expansion is quite a standard, it was published in the german Atari Magazin a couple of years ago. Also, it needs the simplest hardware among all the extensions I know of, so it's the cheapest one too. I'm sure a lot of people built it for this reason.

 

Most programs using extended memory do some sort of memory check (at least the self-respecting ones But they usually fail on my expansion because they detect expanded banks in the first 4 cases (bit5=bit6=0) even though in these cases the base memory is mapped to the bankswitched $4000-$7fff area. I wonder why they don't do a check for this case. It would be simple - just treat the 4 16K "banks" of the base memory in the same way as expanded banks, and check if writing to any bank causes any changes in any other bank. The check could look like this:

 

1. Set all possible values in bits 2,3,5,6, and store a different number for each of them at $4000. (numbers 1-16)

2. Store numbers 17-20 at addresses $0000, $4000, $8000, and $c000 in the base memory.

3. Set all possible values in bits 2,3,5,6 again, and check if the value stored at $4000 in each bank is still there, or it is overwritten. If overwritten with a different value, then it is not a real, separate bank, so remove from the list of available banks.

It's so simple.

An even simpler way would be to let the user configure the number of memory banks and the actual $d301 values he want to use. For example, the ramdisk in DOSes like TurboDOS and MyDOS work in that way. Other example is the excellent game The Brundles by KE-Soft.

/Tamas"

 

______________________________________

/__ __ __ _\

/ / /_|_ | |__\ Software, Hungary

______________________________________

 

Here is another Description by Dracon...

 

XL/XE RAM expansions

 

There are some types of RAM expansions designed for XL and XE

computers. The most popular in Europe are based on the general

concept used by the Atari Corp. in the 130XE computer: a port,

formerly responsible for controlling joysticks #2 and #3, is now used

as a memory controller port. This port is mapped at $D301 and

traditionally labelled as PORTB.

 

The general purpose of the PORTB is to control all on-board memory

resources, i.e. the system RAM as well as the OS and BASIC ROMs.

 

I. ROM controller

 

Bits #0, #1 and #7 control the system ROM. This function is common

for all XL and XE computers:

 

Bit Meaning (if set)

--- ----------------

#0 OS ROM enable

#1 Atari BASIC ROM disable

..

#7 SELF TEST ROM disable

 

Bit #0 changes affect the XL OS area at $C000-$CFFF and $D800-$FFFF,

if the bit is set, there is the XL OS ROM there, otherwise the shadow

RAM is enabled. NOTE: the PDVREG $D1FF has higher priority than PORTB!

 

Bit #1 affects the area $A000-$BFFF. If this bit is cleared, there's

Atari BASIC ROM there, RAM otherwise.

 

Bit #7 affects the area $5000-$57FF. If it is cleared, the SELF TEST

ROM, located normally at $D000-$D7FF and masked out by hardware I/O

registers, is switched to $5000-$57FF; otherwise, there's normal RAM

there.

 

II. RAM controller

 

1) Atari 130XE

 

Stock 800XL and 65XE computers lack additional RAM, so the remaining

PORTB bits do nothing. 130XE however and expanded XL/XE use them to

control RAM extensions.

 

Generally, considering the 16-bit address bus, it is impossible to

enlarge the physical address space past the existing 64k. In the

130XE, the total amount of system RAM is split into two large parts:

64k base RAM and 64k bank select RAM. That last is accessible as four

16k portions to be exchanged with a 16k block belonging to the base

RAM area.

 

This area is located from $4000 up to $7FFF. Both 6502 and Antic are

granted an *independent* access to this memory. PORTB bits meaning is

as follows:

 

bits #2, #3 - bank select

bits #4, #5 - access control

bit #6 - unused

 

The first pair (bits 2 & 3) selects one of four additional 16k banks

you want to access to. The other pair decides, which processor will

use the bank selected by the first two bits:

 

#4 - CPU access: 0 - additional RAM

1 - base RAM

#5 - Antic access: 0 - additional RAM

1 - base RAM

 

This gives four possible combinations:

 

76543210

--------

xx00xxxx - both processors use the additional bank

xx01xxxx - only Antic uses the additional RAM

xx10xxxx - only CPU uses the additional bank

xx11xxxx - both processors use the base RAM

 

That's all for 130XE.

 

2) 192k RAM expansion

 

The computer's behaviour is exactly the same as in 130XE besides of

that bit #6 is used together with the bits #2 and #3 to select an

additional banks. This gives eight combinations, i.e. eight banks may

be accessed, 16k each.

 

3) 320k Compy Shop expansion

 

Also known as "German 320k". This type of RAM extension is quite

popular in Europe, so that several American programs get confused

considering this to be 192k.

 

Since all free bits have been used for bank selection, the Compy Shop

expansion uses bit #7 for bank selection. This gives 16 possible

combinations, hence the additional RAM area can be enlarged to 256k

(256 + 64 = 320).

 

To get rid of possible conflicts with the SELF TEST ROM (normally

controlled by the bit #7), this bit is used to control SELF TEST only

when bits #4 & #5 are both set to 1. Otherwise it controls the bank

select RAM.

 

4) 256k Newell Industries expansion

 

This expansion is NOT fully 130XE compatible. It is similar to the

192k with except that the bit #5 is used for bank selection, not for

Antic access control. It means, that you have four bits for bank

selection, but both CPU and Antic must use the same memory at a time.

Furthermore, only 12 of 16 possible combinations are used so that you

have 192k additional RAM instead of 256k. This is the most stupid

expansion I have ever seen (my computer has it installed).

 

4) 320k Newell Industries expansion

 

Also known as "American 320k". This expansion is NOT fully compatible

with the 130XE standard, but it was apparently quite popular in the

USA since some software (f.e. ICD's SpartaDOS X 4.x) seems to base on

it. Nevertheless, some software, like "Envision" for example, may

fail on such computers.

 

Only bit #4 is used to control the memory access here, which implies

that there's no separated access for the CPU and Antic. In fact, both

processors must use the same type of RAM at the same time; if bit #4

is set, CPU and Antic use the base RAM, otherwise both use additional

bank.

 

Bits #2, #3, #5 and #6 are used for bank selection.

 

5) 576k expansion.

 

This is similar to the American 320k with except that bit #7 is used

the same way as in Compy Shop 320k expansion. So bits #2, #3, #5, #6

and #7 are used for bank selection if the bit #4 is set to zero

(CPU & Antic additional RAM access). This expansion is not fully

compatible with the 130XE.

 

6) 1 MB (1088k) expansion.

 

The same as 576k with except that the bit #1 (normally controlling

Atari BASIC ROM) is used for bank selection if bit #4 is set to zero.

This gives six bits (64 banks, 16k each) for bank selection, so that

the additional bank area may be enlarged to 1024k. This type of

expansion isn't fully 130XE compatible either.

 

III. RAM detection routine

 

Since it is quite difficult to determine what expansion a particular

computer has and what amount of memory is currently available, the

most simple solution is to use the following routine. It is a

non-destructive test, any data previously stored in the additional

RAM will remain intact.

 

The routine returns the number of found additional RAM in the

accumulator. You must multiply it by 16 then add 64 to get the total

amount of the system RAM in kilobytes as a result.

 

; Bank select RAM detection

; Stolen from the SysInfo

;

; Must NOT be located within the $4000-$7FFF !!!

;

portb = $d301

extra = $4000

;

lda portb

pha

lda #$00

sta counter

ldx #$7f ;Save the ramdisk contents before the test

loop1 txa

asl

ora #$01

sta portb

lda extra

sta buffer,x

dex

bpl loop1

ldx #$7f ;Clear tested RAM.

loop2 txa

asl

ora #$01

sta portb

lda #$00

sta extra

dex

bpl loop2

lda #$ff ;Reset PORTB

sta portb

lda #'K ;Mark base RAM as tested.

sta extra

ldx #$7f ;Count banks.

loop3 txa

asl

ora #$01

sta portb

lda extra

bne skip

inc counter

lda #'K

sta extra

skip dex

bpl loop3

ldx #$7f ;Restore the ramdisk contents

loop4 txa

asl

ora #$01

sta portb

lda buffer,x

sta extra

dex

bpl loop4

pla

sta portb

lda counter

rts

;

counter .dc 0 ;number of banks

buffer .ds 64 ;64-byte buffer

 

 

Konrad M.Kokoszkiewicz mail:draco@mi.com.pl http://www.orient.uw.edu.pl/~conradus/ IRC:[Draco] *** Ea natura multitudinis est, *** aut servit humiliter, aut superbe dominatur. ************************************************* *** U pospolstwa normalne jest, ze albo sluzy ono *** unizenie, albo bezczelnie sie panoszy. (Liv. XXIV, 25)

[+CharlieChaplin]

Well,

but afaik there is a mistake in the info about the Atari Magazin memory enhancement, its not a 256k enhancement giving you 64k base RAM and 192k XRAM - instead its a full 256k enhancement (total memory = 320k RAM!) giving you 64k base RAM and 256k XRAM.

 

The Newell/Buchholz/Rambo/... 256k upgrades were *originally* designed in such a way, that you had to replace 64k base RAM with 256k RAM, thus ending up with 64k base RAM and 192k extended RAM (blocks ACE)

 

Not so with the Compyshop XL and XE (256k, blocks 26AE), the Megaram 1,2,3 (256k, blocks 26AE) and the AM (256k, blocks 8ACE) RAM enhancements, they added 256k XRAM to the existing 64k base RAM (total memory = 320k RAM).

 

And err, again and again I have to write that all RAM enhancements that replace 64k RAM with 256k RAM (Newell, Buhholz, Rambo, etc.) will show up false values in any RAM/XRAM detecting program. As said before these RAM enhancements do have 64k base RAM and 192k extended RAM - but when using any of the RAM detection programs they will show 240k XRAM and a faulty 16k RAM/XRAM (actually the RAM under the OS which is not seen by these programs). Meaning all these RAM detection programs will also show part of the base RAM (48k) as XRAM which isn`t true. Alas, this "bug" is a hardware problem and afaik cannot be avoided or solved with software - its absolutely typical for these kind of RAM upgrades...

 

greetings, Andreas Koch.

 

P.S.: There is a large section in the A8FAQ by Michael Current dealing with memory upgrades (subjects 8.11, 8.12, 8.13) - and I was the one collecting all the information presented there (so forgive me for any errors, I have merely collected the information that others gave me)...

[Mathy]

Hello Andreas

 

Alas, this "bug" is a hardware problem and afaik cannot be avoided or solved with software...

AFAIK all RAMtesters store different values in each bank and compare them. Same value means same bank. If main memory is compared with banked memory in the same way, these upgrades (64kB + 192kB instead of 64kB + 256kB) should return the same values for both main and part of extended memory. So it is possible to detect them.

 

greetings

 

Mathy

[flashjazzcat]

Thanks for writing this utility.

 

Unfortunately I had 3 problems

 

1) There is something odd about your ATR. DOS 2.0d could read the directory but not load the program.

 

2) After recreating your ATR, your program would now load but immediiately following the display of the bank information the screen clears and the DOS menu appears.

 

The problem occurs with both Atari DOS 2.0d and MyDOS 4.53

 

3) With SpartaDOS 3.2g your program runs fine BUT it mistakenly detects 15 banks (83, 8B, 8F, A3, A7, AB, AF, C3, C7, CB, CF, E3, E7, EB, EF).

 

My memory upgrade is a Wiztronics 256K (total RAM) which I believe is a Rambo XL type. There are only 12 banks.

 

I'm not 100% sure but I believe banks 83, 8B, and BF are not part of this upgrade.

 

- Steve Sheppard

 

Sorry about the problems with the ATR: I'll upload another version since I have a feeling I may have accidentally created a MyDOS formatted image. Also, I meant to point out that the program works best with SpartaDOS because of the screen clearing problem. Again, this will be rectified in the next upload.

 

As to point 3), there's clearly a problem there so I'll go away and test it some more. Does XRAM report your memory correctly? Thanks for the feedback - I can't make this work without bug reports!

 

Witazije polish coders! Try using extended memory in this way...(special message to Coders of VENT and JOURNEY)

 

Let me give Tamas Bene of HARD the keyboard...

 

Wow... thanks for the very copious information. It's going to take me some time to digest all of that, but hopefully it'll result in a working program. Universal RAM detection is something of a subtle problem, it would seem...

 

It should also be said that in my routine, the RESTORE loop should run backwards (with the X reg starting at $FF) in order to properly restore the main bank. That just occured to me last night.

 

I thought I had this sewn up... clearly not!

 

An even simpler way would be to let the user configure the number of memory banks and the actual $d301 values he want to use. For example, the ramdisk in DOSes like TurboDOS and MyDOS work in that way. Other example is the excellent game The Brundles by KE-Soft.

 

LOL... this is the way The Last Word worked before I got requests to make it auto-detect RAM upgrades. Maybe I should go back to that! On the other hand...

Hello Andreas

 

Alas, this "bug" is a hardware problem and afaik cannot be avoided or solved with software...

AFAIK all RAMtesters store different values in each bank and compare them. Same value means same bank. If main memory is compared with banked memory in the same way, these upgrades (64kB + 192kB instead of 64kB + 256kB) should return the same values for both main and part of extended memory. So it is possible to detect them.

 

greetings

 

Mathy

...I agree. It must be possible to write a catch-all routine.

Edited January 8, 2009 by flashjazzcat

[flashjazzcat]

Another strange problem: my detection routine works fine in SDX 4.22 (AtariWin800 emulator) with or without the X command, but when appended to the LW executable in the init routine at $3000, SDX crashes after an exit to DOS.

 

More specifically, if my detection routine is loaded with the X command as the first segment at $3000 of a larger executable, it works fine (subject to errors). However, after the application exits to DOS, any subsequent attempt to run an application with the X command results in a jump back into corrupted application code. Clearly this routine is screwing up the X command, but I can't see how. Must be something to do with the way it switches BASIC in and out, but the same routine doesn't cause a problem when the routine is a standalone app... weird.

 

Also, RAMBO 256K upgrade reports 16 banks in SDX and 8 banks in SpartaDOS 3.2G with my routine. Really weird... it's totally OS independent.

Edited January 8, 2009 by flashjazzcat

[Heaven/TQA]

Thanks for writing this utility.

 

Unfortunately I had 3 problems

 

1) There is something odd about your ATR. DOS 2.0d could read the directory but not load the program.

 

2) After recreating your ATR, your program would now load but immediiately following the display of the bank information the screen clears and the DOS menu appears.

 

The problem occurs with both Atari DOS 2.0d and MyDOS 4.53

 

3) With SpartaDOS 3.2g your program runs fine BUT it mistakenly detects 15 banks (83, 8B, 8F, A3, A7, AB, AF, C3, C7, CB, CF, E3, E7, EB, EF).

 

My memory upgrade is a Wiztronics 256K (total RAM) which I believe is a Rambo XL type. There are only 12 banks.

 

I'm not 100% sure but I believe banks 83, 8B, and BF are not part of this upgrade.

 

- Steve Sheppard

 

Sorry about the problems with the ATR: I'll upload another version since I have a feeling I may have accidentally created a MyDOS formatted image. Also, I meant to point out that the program works best with SpartaDOS because of the screen clearing problem. Again, this will be rectified in the next upload.

 

As to point 3), there's clearly a problem there so I'll go away and test it some more. Does XRAM report your memory correctly? Thanks for the feedback - I can't make this work without bug reports!

 

Witazije polish coders! Try using extended memory in this way...(special message to Coders of VENT and JOURNEY)

 

Let me give Tamas Bene of HARD the keyboard...

 

Wow... thanks for the very copious information. It's going to take me some time to digest all of that, but hopefully it'll result in a working program. Universal RAM detection is something of a subtle problem, it would seem...

 

It should also be said that in my routine, the RESTORE loop should run backwards (with the X reg starting at $FF) in order to properly restore the main bank. That just occured to me last night.

 

I thought I had this sewn up... clearly not!

 

An even simpler way would be to let the user configure the number of memory banks and the actual $d301 values he want to use. For example, the ramdisk in DOSes like TurboDOS and MyDOS work in that way. Other example is the excellent game The Brundles by KE-Soft.

 

LOL... this is the way The Last Word worked before I got requests to make it auto-detect RAM upgrades. Maybe I should go back to that! On the other hand...

Hello Andreas

 

Alas, this "bug" is a hardware problem and afaik cannot be avoided or solved with software...

AFAIK all RAMtesters store different values in each bank and compare them. Same value means same bank. If main memory is compared with banked memory in the same way, these upgrades (64kB + 192kB instead of 64kB + 256kB) should return the same values for both main and part of extended memory. So it is possible to detect them.

 

greetings

 

Mathy

...I agree. It must be possible to write a catch-all routine.

 

don't take me too seriously as all info is dated 1997/98!!! (Man...why did I not setup my own start up and went public and got riiiiiiich.... )

Edited January 8, 2009 by Heaven/TQA

[flashjazzcat]

don't take me too seriously as all info is dated 1997/98!!! (Man...why did I not setup my own start up and went public and got riiiiiiich.... )

Lol!

 

Okay, I've been testing my routine some more and I still can't replicate the errors that other people have reported but I'll keep at it. It's certainly close to being finished. The problems with the SDX cart were limited to 4.21 and 4.22. For some reason, direct access to some of the bigger extended RAM upgrades using my routine was fouling up the filing system. I don't think these versions of SDX like bits 7 or 1 of PORTB being altered when the library is disabled with the X command. Later versions of SDX don't have this problem, but I wanted to preserve support for all versions, so I'm using my routine unless SDX is detected, in which case I use this one:

 

;
OFFSET = $014E

START; SPARTADOS X RAM TEST
LDA COMTAB
SEC
SBC #< OFFSET
STA XRPTR+1
LDA COMTAB+1
SBC #> OFFSET
STA XRPTR+2
LDY #$1D
LDA (COMTAB),Y
STA NBANKS
DEY
LDA (COMTAB),Y
STA EXTBITS
LDA #0
STA BANKS
SDXRLP
LDY NBANKS
DEY
STY NBANKS
BMI SDXIT
TYA
AND #$03
ASL A
ASL A
STA TMP1
TYA
LSR A
LSR A
TAX
XRPTR
LDA $FFFF,X
ORA TMP1
EOR PORTB
AND EXTBITS
EOR PORTB
LDY BANKS
STA BANKTABLE,Y
INC BANKS
BNE SDXRLP
;
SDXIT
RTS
;
EXTBITS
BYTE 0
NBANKS
BYTE 0
BANK
BYTE 0
BANKS
WORD 0
BANKTABLE
DS 64

This routine was adapted from a translation of the Polish SDX programming docs kindly provided by drac030, and works well. It relies on the fact that SDX has its own table of PORTB masks in the user-accessible data table. I did notice that SDX 4.21 and 4.22 themselves don't recognize some of the bigger RAM upgrades properly either. LW will, however, go along with whatever SDX reports since I don't want to risk crashing into any banks used by the OS. All other operating systems should work well with the earlier routine, including SpartaDOS 3.x. Anything other than SDX will require the user to state how many of the available banks to use, however; this is to save the program having to look for and avoid RAM disks, etc.

Edited January 8, 2009 by flashjazzcat