Jump to content
Bones-69

RXB - Rich Extended Basic

Recommended Posts

30 minutes ago, Willsy said:

If you got the double byte thing from TurboForth, know that I got it from the original driver/utility routines supplied by the original SAMS guys (the names of whom escape me right now) - there was a bunch of machine code source files supplied on disk and I simply copied the technique. ☝️

I think I used the same document and I looked at TF. Seemed like a consensus. :) 

Share this post


Link to post
Share on other sites

That double-byte thing is a function of the 74LS612 page selection routine. The odd address byte is written first (and is basically lost on 1M and smaller boards, but is meaningful with the 4M and larger implementations). The even byte then sets up the selection registers within the 256 pages of a 1M card.

 

One note: yes, 4M SAMS cards do exist (that capability is one hardware revision past the cards I've sold in the past), but getting the memory chips that support it is getting seriously difficult/expensive. Lately, they've been about $100 for two chips and no guarantee they work as they're pulls (usually work) or fakes from China (often fail). That's double what they cost when I started looking to increase the memory size in 2016. @FALCOR4 has built a couple of them using the 2M chips and verified the operation in 4M mode, as have I. Any boards I sell in the future will have the capability to be expanded to 4M (switch the jumpers and install 2M chips), but will be delivered in the 1M configuration to ensure delivery of functional cards at reasonable cost. Though it is "technically" possible to upgrade the older 1M boards, it requires some significant board surgery and isn't generally advisable for those with limited soldering skills.

  • Like 4
  • Thanks 2

Share this post


Link to post
Share on other sites
8 hours ago, retroclouds said:

I wasn’t aware there are any SAMS boards out there that have DSR memory. Did I miss something?

Buy yeah, I also wondered how SAMS is able to do an initial mapping of SAMS pages itself upon startup.

Well my SAMS 1 Meg card never needed to be Initialized it defaulted to pass mode 2,3,A,B,C,D,E,F like it was supposed to as 32K card

And in Map mode defaulted to 2,3,A,B,C,D,E,F unless you changed a Register.

So if you changed say 2 and 3 to 45,46 it would stay there on 45 and 46 even if you powered down the Console but did not turn off P-box.

So upon restart of Console it would default back to Pass mode and 2 and 3, thus only when you switched to Map mode did you get 45 and 46.

Share this post


Link to post
Share on other sites
8 hours ago, retroclouds said:

I wasn’t aware there are any SAMS boards out there that have DSR memory. Did I miss something?

Buy yeah, I also wondered how SAMS is able to do an initial mapping of SAMS pages itself upon startup.

Sorry there is a misunderstanding.

The SAMS memory card uses DSR space for the Mapper mode and Pass mode and is accessed with CRU just like any DSR.

Share this post


Link to post
Share on other sites
On 1/3/2021 at 5:29 AM, TheBF said:

Rich,

 

I have been feeling my way along with the same SAMS card as Wolhess in my Forth project.

 

What I noticed was that on Classic99 which has a 32Mb SAMS card I can run my SAMSINI routine only with a single byte as the page number, for example: >1F00, incrementing the pages by adding >0100.

But on the real hardware I have to use a double byte. (>1F1F)  At least this is what seemed to work.  I didn't dig any deeper than that.

 

 

 

Yea I never have used any address but >4000 up,  so I never have used >5FFE address to change any Pages or Banks.

And by Pages I mean first byte is Page and second byte is Bank.  

Share this post


Link to post
Share on other sites
3 hours ago, Willsy said:

If you got the double byte thing from TurboForth, know that I got it from the original driver/utility routines supplied by the original SAMS guys (the names of whom escape me right now) - there was a bunch of machine code source files supplied on disk and I simply copied the technique. ☝️

My entire Machine Code is here:

***********************************************************
* CPU PROGRAM FOR >8300 SCATCH PAD SUBROUTINE AMSCRU      *
***********************************************************
*                 *        AORG >8300
AMSCRU DATA >8302 * AMSCRU DATA >8302     * First address.
       DATA >C04C *        MOV  R12,R1    * Save R12 
       DATA >020C *        LI   R12,>1E00 * Load CRU bits
       DATA >1E00 *
       DATA >1D00 *        SBO  0         * Set bits ones
       DATA >C301 *        MOV  R1,R12    * Restore R12
       DATA >04E0 *        CLR  @>837C    * Clear for GPL
       DATA >837C *
       DATA >045B *        RT             * Return to GPL.
                  *        END
***********************************************************
* CPU PROGRAM FOR >8300 SCRATCH PAD CPU ISR HOOK ON       *
***********************************************************
*                  *        AORG >8300
GISRON DATA >8302  *        DATA >8302
       DATA >C820  *        MOV  @>834A,@>83C4
       DATA >834A  *
       DATA >83C4  *
       DATA >04E0  * EXIT   CLR  @>837C
       DATA >837C  *
       DATA >045B  *        RT
*                  *        END
***********************************************************
* CPU PROGRAM FOR >8300 SCRATCH PAD CPU ISR HOOK OFF      *
***********************************************************
GISROF DATA >8302 *        DATA >8302
       DATA >C820 * ISROFF MOV  @>83C4,@>83C4
       DATA >83C4 *
       DATA >83C4 *
       DATA >1305 *        JEQ  NHOOK
       DATA >C820 *        MOV  @>83C4,@>834A
       DATA >83C4 *
       DATA >834A *
       DATA >04E0 * NHOOK  CLR  @>83C4
       DATA >83C4 *
       DATA >04E0 *        CLR  @>837C
       DATA >837C *
       DATA >045B *        RT
*                 *        END
***********************************************************
* CPU PROGRAM FOR >8300 SCATCH PAD SUBROUTINE EXECUTE     *
***********************************************************
*                          AORG >8300                 *
CPUPGM DATA >8302 * CPUPGM DATA >8302  First address. *
       DATA >0420 *        BLWP @>834A Switch contex  *
       DATA >834A *                    FAC not used   *
       DATA >04E0 *        CLR  @>837C Clear for GPL  *
       DATA >837C *                                   *
       DATA >045B *        RT          Return to GPL. *
                  *        END                        *
*******************************************************

These all reside at >8300 up to >839B in scratchpad that way they work even without a 32K, but only the case for CALL EXECUTE and CALL ISRON or CALL ISROFF.

Share this post


Link to post
Share on other sites

Ok so first I have installed into start up of RXB 2021 this:

***********************************************************
* RXB PATCH FOR GAZOO HARDWARE CART TO SET ROMS
***********************************************************
MENU   DCLR  @>6000        SET ROM BANKS FOR GAZZO CART
       DST   VRAMVS,@>836E Set VDP STACK DEFAULT
       DST   VRAMVS,@>8324 Set VDP STACK DEFAULT
       DST   VRAMVS,[email protected] Set VDP STACK DEFAULT
* RXB PATCH CODE FOR PMEMORY UPPER 24K
       DST   CPUBAS,[email protected] Set XB RAM END ADDRESS
       DST   >FFE7,@RAMTOP Set XB RAM START ADDRESS 
***********************************************************
* INITILIZE SAMS FOR 4MEG CARDS
***********************************************************
       CALL AMSON
       DST  >5FFE,@FAC        Start SAMS Register
       ST   >0F,@FAC2         Value to load
AINITL MOVE 1,@FAC2,@0(@FAC)  Load value in Register
       DDECT @FAC             Register address-2
       DEC  @FAC2             Value-1
       BR   AINITL            No, loop
       CALL AMSOFF
       CALL AMSMAP
       BR    TOPLEV        Restart but below CLR bytes
***********************************************************

This should fix the issue with 4Meg or smaller cards.

Next I fixed the loader of SAMS with this:

       CALL MAPAMS         * AMS MAP
       CALL ONAMS          * AMS ON
* TEMP has RAM address >A000 up to >F000 
* Shift address to be 2* value for SAMS register
* i.e. >F0 would be >1E so >401E would be register
       SRL  3,@TEMP        * MOVE TO LOWER NIBBLE
       EX   @TEMP,@TEMP+1  * SWAP BYTES 
       EX   @FAC1,@FAC     * SWAP BYTES
       ST   @FAC1,@>4001(@TEMP) * SET BANK
       ST   @FAC,@>4000(@TEMP)  * SET PAGE
       CALL OFFAMS        * AMS OFF

I load the ODD BYTE first then the Even byte.

That should fix this issues entirely and no need for CALL AMSINIT anymore as it is done each time you start the RXB 2021 Module fresh restart.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Thanks, Rich. Once all is stable for a while, I'll have to make an UberGROM image for the new RXB. . .and some of the cartridges too :)

  • Like 3

Share this post


Link to post
Share on other sites
17 hours ago, Ksarul said:

Though it is "technically" possible to upgrade the older 1M boards, it requires some significant board surgery and isn't generally advisable for those with limited soldering skills.

Hi @Ksarul

 

is there a description for changing my SAMS card from 1MB to 4MB capability?
It is a revision 4A Board, see post #1147.

 

Wolfgang

  • Like 1

Share this post


Link to post
Share on other sites
9 hours ago, Ksarul said:

Thanks, Rich. Once all is stable for a while, I'll have to make an UberGROM image for the new RXB. . .and some of the cartridges too :)

Yes please.

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, wolhess said:

Hi @Ksarul

 

is there a description for changing my SAMS card from 1MB to 4MB capability?
It is a revision 4A Board, see post #1147.

 

Wolfgang

I have not yet written down (or tested) all of the necessary changes to the revision 4A boards. I know it will require several trace cuts, some of which would require removal and replacement of existing chip sockets to get access to the cut points. It would also require two pairs of chips to be stacked (and a lot of flying wires) to add the necessary bits to the selection circuitry.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
9 hours ago, Ksarul said:

I have not yet written down (or tested) all of the necessary changes to the revision 4A boards. I know it will require several trace cuts, some of which would require removal and replacement of existing chip sockets to get access to the cut points. It would also require two pairs of chips to be stacked (and a lot of flying wires) to add the necessary bits to the selection circuitry.

Ok, I think I don't want to do that. Nevertheless, thank you very much for the answer

Share this post


Link to post
Share on other sites
16 minutes ago, wolhess said:

Ok, I think I don't want to do that. Nevertheless, thank you very much for the answer

you will also gain no benefit other than having ram that's not used.. nothing uses more than 1mb.. and only two things seems to use all of that

 

Share this post


Link to post
Share on other sites
3 hours ago, arcadeshopper said:

you will also gain no benefit other than having ram that's not used.. nothing uses more than 1mb.. and only two things seems to use all of that

 

Maybe it's just me but I find it starts to get weird with such a slow processor and all that memory.

For example, I am sure it could be a bit faster (2x?) in all Assembler, but using two Assembler routines, one to select the page and one to fill a 4K page, it takes 20 seconds to fill the upper 239 pages of the 255 pages using a Forth loop.

That is a best case. Times go up when you have actually load something real.

 

However if you just swap in a multiple blocks of pre-loaded pages with a short ASM routine, it is pretty fast so maybe that's the secret of how to use it. 

I am still playing. 

 

(Damn.. Now I gotta try this in machine Forth)  :) 

 

 

 

  • Like 4

Share this post


Link to post
Share on other sites
6 hours ago, TheBF said:

Maybe it's just me but I find it starts to get weird with such a slow processor and all that memory.

For example, I am sure it could be a bit faster (2x?) in all Assembler, but using two Assembler routines, one to select the page and one to fill a 4K page, it takes 20 seconds to fill the upper 239 pages of the 255 pages using a Forth loop.

That is a best case. Times go up when you have actually load something real.

 

However if you just swap in a multiple blocks of pre-loaded pages with a short ASM routine, it is pretty fast so maybe that's the secret of how to use it. 

I am still playing. 

 

(Damn.. Now I gotta try this in machine Forth)  :) 

 

 

 

Yea if you use SCSI or IDE or RAMDISK or TIPI it is pretty fast:

RXB 2018 CALL SAMS DEMO - YouTube

SAMSDEMO1 RXB 2018 - YouTube

 

As you can see here RAM is fast even in XB!

  • Like 2
  • Thanks 2

Share this post


Link to post
Share on other sites

UPDATE:

RXB 2020C is in works and turns out NOTHING IS WRONG WITH RXB using SAMS except SIZE does not report PAGES correctly.

The SAMS is INITIALIZED by RXB 2020C but I am having a issue of reading SAMS pages due to REAL IRON vs Classic99.

The 1Meg SAMS just refuses Pages to be read correctly as it duplicates PAGES to the BANKS even though THERE ARE NO BANKS!

This does not happen in Classic99 of the 1Meg SAMS, but on REAL IRON it does do this HARDWARE BUG!

Has taken days to try and get around this issue.

 

Share this post


Link to post
Share on other sites

If I understood Tursi correctly, Classic99 behaves like it has a 32M (?) card and so it uses both bytes to reference all that memory.

The 1Mb card decoder needs the bytes duplicated for initializing. 

I have found once that is done, you can get at the memory pages with just putting one byte in the low order byte of the register.

Don't know why. Don't really need to know why at this stage. But I get memory pages when I ask for them. :) 

  • Like 1

Share this post


Link to post
Share on other sites

Make sure you are initializing /all/ SAMS registers before you start to use the card - if you just go as you need them, then you are relying on the Classic99 initialization, which is going to be different on different hardware.

 

  • Like 1

Share this post


Link to post
Share on other sites
7 hours ago, TheBF said:

If I understood Tursi correctly, Classic99 behaves like it has a 32M (?) card and so it uses both bytes to reference all that memory.

The 1Mb card decoder needs the bytes duplicated for initializing. 

I have found once that is done, you can get at the memory pages with just putting one byte in the low order byte of the register.

Don't know why. Don't really need to know why at this stage. But I get memory pages when I ask for them. :) 

Yes 32Meg and no issues with SAMS in Classic99, plus no need to initialize Registers.

Real Iron is a mess at best. Never had a problem with REAL IRON switching pages just the stupid mess made by having to Initialize Hardware Registers.

RXB 2001 worked fine with AMS and SAMS later, but to have more then 1Meg it required to bank switch pages of 1Meg up to 256 Banks or 1Meg.

It would make sense to allow for this in the original design, they did not. i.e.  (high byte) BANKS:PAGES (low byte)

But the stupid original AMS put the byte in high and low byte, just a badly thought out design.

 

Share this post


Link to post
Share on other sites
4 hours ago, Tursi said:

Make sure you are initializing /all/ SAMS registers before you start to use the card - if you just go as you need them, then you are relying on the Classic99 initialization, which is going to be different on different hardware.

 

It is a very odd quirk of REAL IRON to put the high byte in low byte also, so I have to make a special routing for 1Meg SAMS.

And another for any SAMS larger then 1Meg. This is rather aggravating to have to do the same device.

Share this post


Link to post
Share on other sites
On 1/22/2021 at 1:30 AM, RXB said:

It is a very odd quirk of REAL IRON to put the high byte in low byte also, so I have to make a special routing for 1Meg SAMS.

And another for any SAMS larger then 1Meg. This is rather aggravating to have to do the same device.

Unfortunately I don't have real iron AMS to inspect, I suspect the reason has more to do with compatibility across the various TI systems than the hardware checking both bytes (ie: TI and Geneve write the two bytes in different orders). Classic99 is based largely on convention.

 

But to that end I wonder - if you didn't double up the bytes but did a SWPB before writing, would real hardware suddenly start working?

 

It's probably not the best idea since, if my theory was true, it would not work on a Geneve anymore, but I'm very curious.

 

(And if I'm way off base and it's not a MOV being used, then just ignore me... ;) )

 

  • Like 1

Share this post


Link to post
Share on other sites
On 1/22/2021 at 3:27 AM, RXB said:

Yes 32Meg and no issues with SAMS in Classic99, plus no need to initialize Registers.

Real Iron is a mess at best. Never had a problem with REAL IRON switching pages just the stupid mess made by having to Initialize Hardware Registers.

RXB 2001 worked fine with AMS and SAMS later, but to have more then 1Meg it required to bank switch pages of 1Meg up to 256 Banks or 1Meg.

It would make sense to allow for this in the original design, they did not. i.e.  (high byte) BANKS:PAGES (low byte)

But the stupid original AMS put the byte in high and low byte, just a badly thought out design.

 

Rich, this has nothing to do with a stupidly thought out design. It is a physical limitation of the bank switching chip. The original AMS and SAMS cards only used one byte of the 12-bit address space, making the four high-order bits invisible to programs and the users. In order to get the results they needed, they had to write the address byte twice to ensure that the address they wanted was populating the registers. The first write was shifted to the high-order register when the low order byte was written in--but it had no function as there were no outputs tied to the four high-order bits. This is a requirement of the 74LS612, as it MUST have both bytes written to it for it to work. The original design reflected this limitation of the hardware--it is definitely NOT a bug, it is a feature that programmers have to wrap their minds around to get the card to respond properly.

 

Expansion to 4M uses two of those high-order bits, and expansion to 16M would use all four, so that high-order byte now actually DOES something when it is shifted into the registers. Tursi's variant actually uses one additional high-order bit that isn't available on the 74LS612 to expand the space to 32M. Rich, I have a thought: when writing to set the registers on a 1M SAMS, if you write zeroes in the first byte sent (the high-order byte), it should not try to switch you to bizarro pages that don't exist, as now there won't be spurious ones in the high-order byte. Same goes for the high-order byte in largr cards, always make sure unused bits are set to zero in the first byte sent to set the registers. Following this convention at all times should allow just a single SAMS management routine (set up a variable that identifies card size and mask all necessary initial bits to zero, which will also eliminate potential issues with cards smaller than 1M too).

 

I am really glad you are working to integrate large SAMS support into RXB, as it opens a lot of possibilities for the user community. Thank you!

  • Like 5
  • Thanks 1

Share this post


Link to post
Share on other sites
5 hours ago, Tursi said:

Unfortunately I don't have real iron AMS to inspect, I suspect the reason has more to do with compatibility across the various TI systems than the hardware checking both bytes (ie: TI and Geneve write the two bytes in different orders). Classic99 is based largely on convention.

 

But to that end I wonder - if you didn't double up the bytes but did a SWPB before writing, would real hardware suddenly start working?

 

It's probably not the best idea since, if my theory was true, it would not work on a Geneve anymore, but I'm very curious.

 

(And if I'm way off base and it's not a MOV being used, then just ignore me... ;) )

 

I assume it just a oddball quirk of the hardware as the older cards do not use the same chips. i.e. old cards 1Meg max vs new cards over 4Meg max.

 

I have a new SIZE routine that forced me to do this:

***********************************************************
* SAMS REGISTERS
SR2P   EQU  >4004             SAMS REGISTER PAGE
SR2B   EQU  >4005             SAMS REGISTER BANK
SR3P   EQU  >4006             SAMS REGISTER PAGE
SR3B   EQU  >4007             SAMS REGISTER BANK
SRAP   EQU  >4014             SAMS REGISTER PAGE
SRAB   EQU  >4015             SAMS REGISTER BANK
SRBP   EQU  >4016             SAMS REGISTER PAGE
SRBB   EQU  >4017             SAMS REGISTER BANK   
SRCP   EQU  >4018             SAMS REGISTER PAGE
SRCB   EQU  >4019             SAMS REGISTER BANK
SRDP   EQU  >401A             SAMS REGISTER PAGE
SRDB   EQU  >401B             SAMS REGISTER BANK
SREP   EQU  >401C             SAMS REGISTER PAGE
SREB   EQU  >401D             SAMS REGISTER BANK
SRFP   EQU  >401E             SAMS REGISTER PAGE
SRFB   EQU  >401F             SAMS REGISTER BANK  
***********************************************************
*
* SHOW SAMS PAGES & BANKS USED
*
SAMSZ  CALL ISROFF            * TURN OFF ISR HOOK
       CALL AMSMAP            * TURN ON MAPPER
       CALL AMSON             * TURN ON WRITE REGISTERS
       CLR  [email protected]>03D0           * Clear buffer
       MOVE 32,[email protected]>03D0,[email protected]>03D1 * ripple it
* Check if larger then 1 Meg SAMS
       DST  @SRCP,@PAD        * Save PAGE:BANK >C000 for use
       ST   2,@SRCB           * Set 2 BANK to >C000
       DCEQ >0202,@SRCP       * 1MEG SAMS?
       BR   MEGUP             * No, above 1Meg
       DST  @PAD,@SRCP        * Restore PAGE:BANK >C000
* 1Meg or less
       ST   @SR2P,[email protected]>03D1     * >2000 PAGE   
       ST   @SR3P,[email protected]>03D3     * >3000 PAGE
       ST   @SRAP,[email protected]>03D5     * >A000 PAGE
       ST   @SRBP,[email protected]>03D7     * >B000 PAGE
       ST   @SRCP,[email protected]>03D9     * >C000 PAGE
       ST   @SRDP,[email protected]>03DB     * >D000 PAGE
       ST   @SREP,[email protected]>03DD     * >E000 PAGE
       ST   @SRFP,[email protected]>03DF     * >F000 PAGE
       BR   DISAMS
* 2 Meg or more
MEGUP  DST  @PAD,@SRCP        * Restore PAGE:BANK >C000
       ST   @SR2P,[email protected]>03D1     * >2000 PAGE
       ST   @SR2B,[email protected]>03D0     * >2000 BANK
       ST   @SR3P,[email protected]>03D3     * >3000 PAGE
       ST   @SR3B,[email protected]>03D2     * >3000 BANK
       ST   @SRAP,[email protected]>03D5     * >A000 PAGE
       ST   @SRAB,V@>03D4     * >A000 BANK
       ST   @SRBP,[email protected]>03D7     * >B000 PAGE
       ST   @SRBB,[email protected]>03D6     * >B000 BANK
       ST   @SRCP,[email protected]>03D9     * >C000 PAGE
       ST   @SRCB,[email protected]>03D8     * >C000 BANK
       ST   @SRDP,[email protected]>03DB     * >D000 PAGE
       ST   @SRDB,[email protected]>03DA     * >D000 BANK
       ST   @SREP,[email protected]>03DD     * >E000 PAGE
       ST   @SREB,[email protected]>03DC     * >E000 BANK
       ST   @SRFP,[email protected]>03DF     * >F000 PAGE
       ST   @SRFB,[email protected]>03DE     * >F000 BANK
* Display pages and banks
DISAMS DCLR  @PAD             * INDEX POINTER DISPLAY 
SAMREG XML   SCROLL           * SCROLL SCREEN
       DST   [email protected]>03D0(@PAD),@ARG2 * REGISTER WORD
       CALL  SDISO            * SHOW IT
       DINCT @PAD             * POINTER+2
       DCEQ  16,@PAD          * DONE? 
       BR    SAMREG           * LOOP
*************************************
* FOR SAMS SIZE
SPAGES FMT
        SCRO >60
        ROW 15
        COL 4
        HTEX '* PAGE NUMBER = LOCATION *'
        ROW+ 1
        COL  10
        HTEX 'Page = >2000 - >2FFF'
        ROW+ 1
        COL  10
        HTEX 'Page = >3000 - >3FFF'
        ROW+ 1
        COL  10
        HTEX 'Page = >A000 - >AFFF'
        ROW+ 1
        COL  10
        HTEX 'Page = >B000 - >BFFF'
        ROW+ 1
        COL  10
        HTEX 'Page = >C000 - >CFFF'
        ROW+ 1
        COL  10
        HTEX 'Page = >D000 - >DFFF'
        ROW+ 1
        COL  10
        HTEX 'Page = >E000 - >EFFF'
        ROW+ 1
        COL  10
        HTEX 'Page = >F000 - >FFFF'
       FEND
*
NOAMS  DCZ  @FAC              * ISR?
       BS   NOISR             * No
       CALL ISRON             * Turn on ISR HOOK
NOISR  CALL AMSOFF            * TURN OFF DSR    
*

 

Share this post


Link to post
Share on other sites

I wonder why they built the databus multiplexer in the console this way, low-before-high. Not only the 9995 does high-before-low, also the 9980A. So it seems it is the TI-99/4A console that deviates from the order.

  • Like 2

Share this post


Link to post
Share on other sites
29 minutes ago, Ksarul said:

Rich, this has nothing to do with a stupidly thought out design. It is a physical limitation of the bank switching chip. The original AMS and SAMS cards only used one byte of the 12-bit address space, making the four high-order bits invisible to programs and the users. In order to get the results they needed, they had to write the address byte twice to ensure that the address they wanted was populating the registers. The first write was shifted to the high-order register when the low order byte was written in--but it had no function as there were no outputs tied to the four high-order bits. This is a requirement of the 74LS612, as it MUST have both bytes written to it for it to work. The original design reflected this limitation of the hardware--it is definitely NOT a bug, it is a feature that programmers have to wrap their minds around to get the card to respond properly.

 

Expansion to 4M uses two of those high-order bits, and expansion to 16M would use all four, so that high-order byte now actually DOES something when it is shifted into the registers. Tursi's variant actually uses one additional high-order bit that isn't available on the 74LS612 to expand the space to 32M. Rich, I have a thought: when writing to set the registers on a 1M SAMS, if you write zeroes in the first byte sent (the high-order byte), it should not try to switch you to bizarro pages that don't exist, as now there won't be spurious ones in the high-order byte. Same goes for the high-order byte in largr cards, always make sure unused bits are set to zero in the first byte sent to set the registers. Following this convention at all times should allow just a single SAMS management routine (set up a variable that identifies card size and mask all necessary initial bits to zero, which will also eliminate potential issues with cards smaller than 1M too).

 

I am really glad you are working to integrate large SAMS support into RXB, as it opens a lot of possibilities for the user community. Thank you!

Yea I was using GPL DST command and found it crashed the older AMS cards, so I moved to ST as it worked fine with Classic99 and older AMS cards.

What is really odd is the page and bank switch did not need to be changed, just the SIZE command. This is what frosts my balls.

 

I now assume it is GPL only works with BYTES even if you use DST (word) instead of ST (byte) thus it writes a single byte each time like MOVE does.

 

OMG I hope the real hardware 4Meg and up cards do not need a whole new rewrite again!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...