1090XL remake

[reifsnyderb]

6 hours ago, drac030 said:

I looked there again and I am afraid that you are a little bit too concerned with possible assumptions software is making while testing/accessing extended banks. There is no place for particular assumptions, a program has a procedure to count the banks, it then uses (or tries to) the banks it found and it is basically all.

 

The usual procedure consist of a loop which tries out all the possible combinations of the relevant bits of PORTB. SpartaDOS X is no exception. The procedure goes less or more thus:

 

1) bits 2,3,4 in PORTB are set to 0.

2) the remaining 4 bits (7,6,5,1) count from $0 to $F

3) each iteration checks if there is a new bank banked in

4) if so, it marks it as "seen", increases the bank counter and goes back to p. 2.

5) if not, it just goes to p. 2

6) after the 16th iteration the procedure quits.

 

As you can see, there is no special case for 192k, or anything else. It just increases the counter, writes PORTB and looks if anything changed.

 

And it might be worth checking, how many banks this procedure can see in your case. Just use the config above, start SDX in 64k mode, then do MEM /X at the DOS prompt (which will tell you the number of banks the system saw) and PEEK COMTAB+1C (for 192k the mask should be $5C, I think).

Perfect!  I was wondering what the scanning logic was.  Thanks!

[Mathy]

Hello guys

 

10 hours ago, ClausB said:

Maybe @Mathy could chime in on that.

 

I'll have think about that.  This is not an internal upgrade.

 

For now I'd say/ask, is it really a problem if the MMU switches in the Selftest bank?

 

Sincerely

 

Mathy

 

[reifsnyderb]

16 minutes ago, Mathy said:

Hello guys

 

 

I'll have think about that.  This is not an internal upgrade.

 

For now I'd say/ask, is it really a problem if the MMU switches in the Selftest bank?

 

Sincerely

 

Mathy

 

It would be a problem because the self test bank is within the 16k bank region.  I don't think there is any possibility of using PORTB bit 7 for banking, from a 1090 device, as the Refresh line is buffered.  So it is not possible to "turn off" the MMU by using the Refresh line.

[+David_P]

A rank amateur here - but if EXSEL is asserted, wouldn't that override any PORTB bit 7 issue?

[reifsnyderb]

41 minutes ago, David_P said:

A rank amateur here - but if EXSEL is asserted, wouldn't that override any PORTB bit 7 issue?

/EXSEL will only disable the internal memory.  The MMU will still enable the OS chip due to PORTB bit 7 being set low.  Below is the code for the MMU.  I've tested it in a ATF16V8B PLC and it works.   🙂

 

 

 

Name       800XL MMU;
Partno     CO61618;
Date       02/25/99;
Revision   00;
Designer   Bob Woolley;
Company    Atari Rulz!!;
Assembly   1200XL;
Location   U14;
Device     P16L8;

/******************************************************************/
/*    Stock Atari XL/XE MMU                                       */
/*                                                                */
/*                                                                */
/******************************************************************/
/*  Allowable Target Device Types: 16L8                           */
/******************************************************************/

/**  Inputs  **/

Pin  01      = A11          ; /* address bit 11            */
Pin  02      = A12          ; /* address bit 12            */
Pin  03      = A13          ; /* address bit 13            */
Pin  04      = A14          ; /* address bit 14            */
Pin  05      = A15          ; /* address bit 15            */
Pin  06      = MAP          ; /* PB7 diagnostic bit        */
Pin  07      = RD4          ; /* right cart. @ $8000-$9FFF */
Pin  08      = RD5          ; /* left cart. @ $A000-$BFFF  */
Pin  09      = REN          ; /* PB0 OS ram enable         */
Pin  11      = REF          ; /* DRAM refresh              */
Pin  14      = MPD          ; /* Math Pack Disable         */
Pin  18      = BE           ; /* Basic Enable              */

/**  Outputs  **/

Pin  12      = !S5       ; /* left cart. select         */
Pin  13      = !BASIC    ; /* Basic ROM select          */
Pin  15      = !OS       ; /* OS code select            */
Pin  16      = !CI       ; /* DRAM CAS inhibit          */
Pin  17      = !IO       ; /* I/O select @ $D000-$D7FF  */
Pin  19      = !S4       ; /* right cart. select        */

/**  Logic Equations  **/
/**  # is or **/
/**  ! is not **/

S4      = !A13 & !A14 & A15 & RD4 & REF;/* RD4 and addresses $8000-$9FFF */
S5      = A13 & !A14 & A15 & RD5 & REF;    /* RD5 and addresses $A000-$BFFF */

IO      = A12 & !A11 & !A13 & A14 & A15 & REF;   /* addresses $D000-$D7FF*/

CI      = !A13 & !A14 & A15 & RD4 & REF        /* right cart. */
        # A13 & !A14 & A15 & RD5 & REF        /* left cart. */
        # A13 & !BE & !A14 & A15 & !RD5 & REF    /* BE and $A000-$BFFF */
        # OS                    /* OS addresses */
        # A12 & !A11 & !A13 & A14 & A15 & REF    /* I/O addresses */
        # !REF;                    /* memory refresh */

OS      = A13 & A14 & A15 & REN & REF        /* addresses $E000-$FFFF */
        # !A12 & !A13 & A14 & A15 & REN & REF   /* addresses $C000-$CFFF */
        # A12 & A11 & !A13 & A14 & A15 & MPD & REN & REF /* addresses $D800-$DFFF */
        # A12 & !A11 & !A13 & A14 & !A15 & !MAP & REN & REF; /* addresses $5000-$5800 - mapped */

BASIC   = A13 & !BE & !A14 & A15 & !RD5 & REF;   /* BE and $A000-$BFFF */

 

[reifsnyderb]

Today, some more parts came in from mouser as I needed some chips for the boards I sell.  Included were 3 PLCC-32 sockets as I was waiting on one to try a 1090 firmware board I came up with.

 

Right now, this board is configured as a ridiculously over-complicated PacMan cartridge so I could do some basic tests.       (As another test, I was able to reduce my base memory from 64k to 16k.   lol   )

 

The left-most ATF16V8B is a MMU for the card.  It is configured in registered mode so it could be programmed with flip-flops.  It has inputs for A13, A14, and A15 as well D0, D1, D2, and a few other signal lines.  It controls /MPD, /EXTSEL, Data Bus Enable, 1090 RAM Disable, bank selection on the flash ROM (2 64k banks), and the chip enable for the flash ROM.

 

The second ATF16V8B is a decoder to decode common 1090 addresses (i.e.  $D8xx-$DFFF, $D1FF, $D100) and supply pulses for the flip-flops. 

 

There is a bank of header pins to give the card a device ID so the card can be programmed as a full 1090 card to 1090 specs.  Of course, it can be programmed to run code, on boot-up, from the 2k $D800-$DFFF region.  Since there are 2 64k ROM banks, it's quite possible to bank another 2k in or even bank in a larger region.

 

The concept is that this card could be used to swap out BASIC, the Math Pack, or even the OS.  It could be used to extend the OS by loading drivers.  Really, it could be used to run about anything you want from the ROM.  Since it can disable memory on both the computer and compatible 1090 memory cards, it could be programmed to run whatever can be imagined.

 

While I doubt there would be much use in re-programming the decoder chip as it's pretty specific to the card, it's easy to do.  Programming the MMU chip allows for a lot of options.  When properly programmed, the MMU chip can control the banking of the ROM, disabling RAM regions (8k at a time), banking the ROM, etc.

 

I can also envision a larger version of this board, with a CPLD in place of this MMU, so that it could shadow PORTB or even bank in other RAM for some custom purpose.  I figured I'd keep this board small so as to keep it as cheap as possible.  It's also 2 layers.

 

Presently, if I install this board, and boot the computer while holding down the Option key, I can play PacMan...and already have.   🙂    If I were to add the right code to the $D800-$DFFF region, and configure the board to the 1090 spec., the board could disable BASIC on boot-up so as to run PacMan without holding down that Option key.

 

One of the earlier 1090 specifications made mention of some sort of internal cartridges.  This board may come close.   🙂

 

The 1090 was so powerful, it's a shame it was never released.

 

Oh, yeah, I realized after I ordered the board that chip U45 messed up the decoding of the $D800-$DFFF region but I could just pull the chip and add a jumper to fix the problem.

 

Edited February 28, 2023 by reifsnyderb

[reifsnyderb]

Using the 1090 Firmware Board to upgrade the floating point math pack was a success!  The MMU, on the board, is now programmed with 2 latches.  One latch selects which bank of the flash ROM is used and the other latch remaps the floating point math ROM to the flash ROM.  So, it works as follows:

 

1.  On boot-up, the OS scans for and finds the Firmware Board.

2.  The OS runs the initialization code on the firmware board.

3.  The initialization code copies some code to Page 6.  (This code is only used temporarily to latch the firmware in place.)

4.  The temporary page 6 code is executed then the control returns to the OS.

 

Admittedly, using this board to upgrade the floating point math is somewhat abusing the capability as it comes with 2 caveats.  The first is that this board should be device 8 as any other parallel boards will have a conflict with this board in this configuration.  The second issue is that any boards that use the parallel port for I/O won't work.  So, if this is the only 1090 board installed that uses the $D800-$DFFF region, it will be fine.  Memory cards are exempt from these caveats.  That being said, this is a proof of concept and the board can easily be configured to do something else that doesn't conflict with the floating point region.  (i.e.  load drivers)  For a system that uses a 1090 as a memory expansion, for drivers, and/or for upgrading the OS without surgery there are possibilities.

 

A big problem was figuring out how to get the registers to work with the ATF16V8B chip.  The datasheet doesn't tell the whole story and that set me back some hours figuring out how to do so.

 

What I found out:

 

On power-up, a register's output is set high.  I was able to verify this and this is in the datasheet.

 

After power-up, the register's input (.d) equals the register's output. 

i.e.     register.d = register

This is not as per the datasheet.  The datasheet's diagram shows that register.d = !register

This appears to be undocumented.  As a result, the tiny bit of 6502 assembly I had to write was setting the registers the opposite of what they should have been set.

There is a possibility that the XOR gate is inverting the input to register.d  However, I did not find anything mentioning what an unused XOR gate is set to.

 

Here's the ca65 assembly code to get this working:

( The macros were ripped off from other sources.   🙂  )

 

.FEATURE    force_range, loose_string_term, labels_without_colons
.MACRO    TITLE    arg
.ENDMACRO
.MACRO    SUBTTL    arg
.ENDMACRO
.MACRO    LIST    arg1, arg2, arg3
.ENDMACRO
.MACRO    EJECT
.ENDMACRO
.define    EQU    =
.define    not    <~
.define    ASSERT(arg)    .ASSERT arg, error
.define    low    <
.define    LOW    <
.define high    >
.define    HIGH    >
.define    IF    .IF
.define    ELSE    .ELSE
.define    ENDIF    .ENDIF
.define    ORG    .ORG
.define LOC    .ORG
.define DW    .WORD
.define    DB    .BYTE

;  EQUATES
PDVMSK = $0247            ; Parallel device mask (indicates which are
SHPDVS=$0248            ; Shadow PDVS
PDIMSK = $0249            ; Parallel interrupt mask (not used in this
GPDVV = $E48F            ; Generic Parallel Device Vector

HATABS = $031A            ; Device handler table
CRITIC = $42                    ; Critical code section flag

DEVNAM = $00                ; Device name, E.G. T for “Telephone”.

.macro    FIX    address
    .if    * > address
    .error    .sprintf("$%04x precedes current origin counter of $%04x", address, *)
    .elseif * < address
    .out    .sprintf("$%04x free bytes from $%04x to $%04x", address-*, *, address-1)
    .res    address-*, $00
    .endif
.endmacro

ORG    $D800
; ROM vector table
                DW        0                            ; Optional ROM checksum
                DB        0                            ; Optional Revision number
                DB        $80                        ; Mandatory ID number
                DB        0                            ; Optional Name or Type
                JMP     NA                        ; Lo-level IO vector, which we don’t need
                JMP     NA                        ; IRQ handler vector, which we don’t need.
                DB        $91                        ; Mandatory ID number
                DB        DEVNAM            ; Device name
                DW        NA-1                    ; Open vector, which we don’t need.
                DW        NA-1                    ; Close vector, which we don’t need.
                DW        NA-1                    ; GET BYTE vector.
                DW        NA-1                    ; PUT BYTE vector.
                DW        NA-1                    ; GET STATUS vector.
                DW        NA-1                    ; SPECIAL vector, which we don’t need.
                JMP     INIT                        ; INIT vector at Power up or reset.
                DB        0                            ; NOT USED

; CODE STARTS HERE

; Initialize device
INIT
;Copy Math Pack initialization code to Page 6.
                LDX        #$00
LP            LDA        $D900,X
                CPX    #$80
                BEQ    DONE
                STA        $0600,X
                INX
                JMP    LP
DONE        JMP    $0600

                
; Do nothing                
NA            SEC                                ; Indicate we handled it.
                RTS
                
                
FIX    $D900
LOC    $0600
                LDA        #$00                    ;Set bits 0 and 1 to latch $D800 bank
                                                        ;and switch to upper ROM bank.
                STA        $D100                    ;Set device hardware register
                LDA        #$00                    ;Disable device
                STA        $D1FF        
                RTS                                ;Return control to OS
.END

 

Edited March 1, 2023 by reifsnyderb

[reifsnyderb]

When I order boards, I'll have one of these made.  🙂

 

This board is based on my 1090 Firmware Board.  I added a AS6C1008 chip to provide some memory and a 74F174 chip to provide registers for banking.  The plan is to modify some readily available printer spooler code to run from firmware installed in $D800-$DBFF.  (If I need more space, the card is already designed to allow me to use the entire $D800-$DFFF region and/or bank in more ROM.)  Then bank in 64k of RAM, for a printer buffer, from $DC00-$DFFF.  This card is designed to be compatible with existing 1090's as well as the XE Compatible 1090 I've designed.  On the back, there are solder pads to support the SST39SF010, SST39SF020, and SST39SF040 chips...depending upon availability.

 

 

 

 

 

[reifsnyderb]

1090 Card for a CX85 Numeric Keypad

 

I've had this card laying around for months and figured I'd tackle this project this week.  As you can see by all the jumpers, there were some problems.  For starters, I fried a programmable logic chip by putting it in backwards.  Then, I found out I screwed up and had the flash ROM chip wired with the write enable pin grounded.  (The ground traces were under the PLC socket and I decided to carefully locate them and drill through the board to break them.  Fun....)  This resulted in the ROM chip never enabling.  Some more experimentation was done to figure out what exactly was needed to handle IRQ's.  Then, I discovered I screwed that up as pressing a key, on the CX85, would flood the computer with IRQ requests.  But, after a lot of trial and error, troubleshooting, etc., I got it to work.   🙂

 

There are 4 programmable chips on the board.  The decoder chip decodes some common PBI addresses such as $D1FF.  The left hand chip handles a lot of the logic required by a 1090 and this board.  The "Input Buffer" chip handles putting the input from the CX85 onto the data bus. 

 

The ROM chip is initialized at boot and registers the IRQ handler code on the ROM chip so that when this board generates an IRQ the code within the ROM chip is executed.

 

Presently, all of the CX85 keys work.  No drivers are required as there is a driver on the ROM chip.

 

When a key is pressed, an IRQ is generated.  The OS handles the IRQ, scans the board to see if it generated the IRQ, then runs the code in the ROM chip.  The code on the ROM chip retrieves the input, translates into a keyboard code, and puts it in the OS's input key buffer.  While the code isn't that long, no drivers need to be loaded.

 

Thus far, I found 2 issues.  One is that the key repeat doesn't work.  This is because finding several free bytes of memory, that nobody ever used, is a major problem.  So, keeping track of key repeats isn't going to work well.  The key repeat also won't work because I had to program the "Input Buffer" chip with a latch so that it would not flood the IRQ line and basically hang the processor.  I really can't say that I use a key repeat feature, on a keypad, much anyhow.  The other issue is that software that does not use the OS for it's keyboard input won't function with this card. 

 

So far, it works with Speedscript 3.0, SpartaDOS-X, DOS 2.5, and Atari BASIC.  I found out it doesn't work with SinCalc, unfortunately.

 

I've already documented the important changes and will update the board.  When I order more boards, I'll get some of these made, too.    🙂

 

 

 

[+x=usr(1536)]

Just curious, since I lost track of where this project is some time ago: is the 1090 production-ready / already in production?

[reifsnyderb]

2 hours ago, x=usr(1536) said:

Just curious, since I lost track of where this project is some time ago: is the 1090 production-ready / already in production?

Hello,

 

I believe the main 1090 board is ready and there are essentially 3 versions:

  1.  The original 1090 XL Expansion System re-make.  Supports the XL's and all legacy cards.  Is almost identical to the original 1090 board.

  2.  The 2023 1090 XL/XE Expansion System.  This is based on, and almost identical to, the 1090 XL Expansion system board and is upgraded to support Atari XE's, improved mapping for 1090 memory cards, and an optional better location for the power switch.  This board is compatible with all legacy cards.  This board is very similar to the original 1090 board and should be able to be installed in a 1090.  (Given the rarity of the 1090, I doubt anyone would do this.   lol    )

  3.  The 1091 XL/XE Expansion System.  The smaller version of the 1090.  This board does not have the capability of handling 12 VDC and is good for smaller cards.  Basically, it's a smaller, modernized, 1090.

 

Boards that can be made and are proven to work:

 

Legacy boards:

  1.  64k card.

  2.  80 column card.  Note:  While proven to work on old monitors, I can't get a newer version (using more modern components) to work properly on a modern TV.

 

New boards:

  1.  320k RAM Card.  (RAMBO banking.)

  2.  XE Compatibility Card.  Supplies the missing /EXTENB signal for memory cards.  Not needed if the XE has a jumper from the MMU to Pin A of the ECI.  Not for use on the original 1090.

  3.  Firmware board.  Can be configured to supply drivers, firmware, etc., for use by the Atari.  Potentially could even swap out the OS with an OS running in RAM.

  4.  CX85 board.  Seems to work...may need a little more troubleshooting.  May have incompatibilities with some software.  i.e.  Doesn't work with SinCalc.

 

Boards in concept/design stage:

  1.  Printer spooler board w/64k of RAM.

  2.  80 column board w/video memory bank running a modified version of Ace 80XL software.  (Ported to ca65 and currently having problems getting software to compile and run.)

  3.  4MB Axlon compatible board.  (Concept...may work as long as $D301 is shadowed to only provide banks under certain circumstances.)

 

To the best of my knowledge, no case has been re-made as of this time.

 

 

 

 

Edited March 9, 2023 by reifsnyderb

[+x=usr(1536)]

2 hours ago, reifsnyderb said:

I believe the main 1090 board is ready and there are essentially 3 versions:

Awesome, and thank you.  Now I know what to start eyeing up next 

[reifsnyderb]

24 minutes ago, x=usr(1536) said:

Awesome, and thank you.  Now I know what to start eyeing up next 

🙂

 

I am trying to resolve the chicken/egg problem that exists with the 1090XL.  The 1090XL is really nice if it has cards but you don't have a use for the box without the cards.  So both the 1090XL and cards are needed for it to do anything.

[ClausB]

3 hours ago, reifsnyderb said:

2.  80 column board w/video memory bank running a modified version of Ace 80XL software.  (Ported to ca65 and currently having problems getting software to compile and run.)

I'll be happy to help with that. ACE80 code is tied to the banked ROM scheme and includes fluff like the title screen. Might be better off starting with E80 code.

[+Larry]

Is the 80-column character set 3 pixels wide + 1 pixel space?

[kenames99]

not the 80 column card for the 1090XL it is full 8 bits wide. 8 bits high too iirc.

 

Ken

 

[reifsnyderb]

I've been slowly adding more information to "The Comprehensive Guide to the Atari Parallel Bus".  Now added is known working code for the CX85 Numeric Keypad board (shows the code for an IRQ handler) and a section on memory modules to show the basics as how to get a memory module working either on the PBI or through the 1090 XL Expansion System.

 

Parallel Port Guide v0_92.pdf

[reifsnyderb]

On 12/21/2022 at 1:27 PM, Goochman said:

Was there a CP/M and MS-DOS card?

I was looking further into the CP/M Z80 card and not only does the 40 pin connector match the 1066 memory card but it appears the 6502 would have had some control over the 1066 memory from 2 different angles.  I started mapping out what the I/O would be on the Z80 card and discovered this:

 

$D1F0 - $D1F7 Alternate CPU Registers (1090 Z80 CP/M Card)

 

Note: Addresses $D1F0-$D1F7 are all the same register.

 

Bit 0 Write Z80 /RESET

Bit 1 Write Z80 /INT

Bit 2 Write Z80 /BUSRQ

Bit 3 Write Z80 RAM (Active High)

Bit 6 Read Z80 /BUSAK

Bit 7 Read Z80 D7

 

 

Setting $D1F0 bit 3 high results in the /MODSEL connection to the RAM card going low.  After looking at the schematic of the 1066 RAM card, it appears that setting /MODSEL low would result in the RAM being "disconnected" from the 1090 bus.  Also, bit 2 sends a /BUSRQ signal that results in the Z80 being paused and going into high-impedance mode.  So, it is possible for the Atari to control the RAM connection to both the 1090 bus and to the Z80 CPU.  /BUSAK is a signal, from the Z80, to let the Atari know the Z80 is now in high-impedance mode.  Finally, the RAM on a 1066 card could be banked into the 6502's address range by setting the correct bits at $D1FE.

 

Given this is the case, my belief is that the concept of the Z80 card was for the Atari to load the Z80's memory, on a 1066, and run the Z80 against it.  For I/O, I believe the Atari would have to pause the Z80 periodically to check certain memory locations in the Z80's 1066 then act upon it.  For example, the Z80 would have some sort of video memory in the 64k region, right?  So, if the Atari periodically paused the Z80, bank in and check the memory, the Atari could then display the contents on the screen.  The same idea would go along with a keyboard buffer and any other devices.  Combine this idea with using the 80 column card then the 1090 could be running a Z80 with 64k of memory.

 

It's also notable that the Z80 CP/M card only has access to memory via the 40 pin connector and does not have any I/O access.  Also the Z80 CP/M card doesn't follow the normal 1090 rules in that it doesn't have a ROM, it doesn't have RAM, and it doesn't use $D1FF to select it.

 

 

 

 

 

Edited March 20, 2023 by reifsnyderb

[reifsnyderb]

1090XL CX85 Numeric Keypad board is working!

 

I had this laying around and assembled for weeks.  Today, I re-programmed the ATF16V8's for the new board and it's working.  No more plugging the CX85 into the joystick ports for me.  This card is running on an XE compatible 1090XL main board.  Behind it, and partially visible, is the 320k SRAM card.  (64k base memory + 256k extended memory)  This CX85 card differs from my original CX85 board in that the heat sink is larger, the 74F74 is now reset from the system reset, and the problems have been fixed.  (Of course.)

 

I've got a newer version of the 1090XL to put together that is capable of being configured to function either exactly like the 1090XL remake or like a modernized 1090XL w/XE compatibility and some functionality improvements.  This modernized 1090XL board is 100% compatible with all known legacy 1090 board and is designed to function perfectly with the extra features of newer 1090 boards.  (i.e.  XE compatibility and a pin to disable the RAM on a compatible 1090 board for re-mapping purposes)  I've also got a 1091XL board to put together that is 100% compatible with the XE compatible 1090XL board.  The newer 1091XL board is just smaller, cheaper, and doesn't have a 12vdc supply.

 

 

Edited April 17, 2023 by reifsnyderb

[reifsnyderb]

I decided to put my 1091XL/XE Expansion System board together tonight...with all 5 card edge connectors installed.   🙂

 

Looking from front to back (or right to left...depending upon your perspective)...

 

1.  Empty

2.  XE Compatibility Board to recreate the /EXTENB signal that the XE doesn't supply.

3.  Firmware Board.  Right now, it loads PacMan if the Select key is held down when booting the system.

4.  320k SRAM board.  Upgrades my 16k 600XL to 320k.   🙂

5.  CX85 Numeric Keypad Interface.  Plug in the CX85 Numeric Keypad here.   🙂

 

The 1091, and all boards, are tested and functional.

 

Edit to add:  With the exception of the XE compatibility board, all boards will work on a 1090XL.

 

The firmware board is very versatile.  I have, as a test, configured the firmware board to load Altirra BASIC.  In one test, it was also able to upgrade the floating point math pack.  Other uses could be to load a RAM-based OS from the card, install an 80 column software-based system, add fast SIO to the existing OS, etc.

 

Edited April 18, 2023 by reifsnyderb

[_The Doctor__]

PBI doesn't limit itself to stuffing the internal Atari's ram with stuff, it can map in ROM sections as well yes?

[reifsnyderb]

17 minutes ago, _The Doctor__ said:

PBI doesn't limit itself to stuffing the internal Atari's ram with stuff, it can map in ROM sections as well yes?

The MMU ultimately controls what the PBI can do.  Officially, PBI devices can only control the MMU with either the /EXTSEL and/or /MPD signals.  Of course, PBI-based firmware can control some of the MMU functions via PORTB, as well.  But this could be undone by other software and/or firmware.

 

I understand that people have hacked the Atari, from the PBI, by grounding out the Refresh signal so as to shut down the MMU.  I am not too keen on that hack because it shorts out ANTIC.  I do understand, however, that the ANTIC chip supposedly isn't harmed by this.  Using the Refresh signal, in this fashion, would allow a PBI device to map anything.  Any PBI device that maps over 320k would have to use this hack...so it apparently is regularly and safely used.  The 1090XL doesn't allow for this hack as it uses the refresh signal as an input only.  It's interesting to note, too, that even though Atari supplied the refresh signal they never used it.  Atari's 1064 and 1066 had it's own delay lines.

 

Edit to add:  To use the firmware card to swap out the OS would require installing the OS in RAM and disabling the ROM via PORTB.  This could all be done easily with the firmware card.

Edited April 18, 2023 by reifsnyderb

[_The Doctor__]

yes and if we worry about it being shorted we could mute is using resistance instead. Then less of a worry and it still could be used to time things aware of that being the case. The device can amplify what is muted on the Main board, best of both worlds. Antic also could have had it's own memory instead of sharing, think sep ANTIC access as truly being sep memory.

Yes, Doc Brown goes to far...

Edited April 18, 2023 by _The Doctor__

[reifsnyderb]

21 minutes ago, _The Doctor__ said:

yes and if we worry about it being shorted we could mute is using resistance instead. Then less of a worry and it still could be used to time things aware of that being the case. The device can amplify what is muted on the Main board, best of both worlds. Antic also could have had it's own memory instead of sharing, think sep ANTIC access as truly being sep memory.

Yes, Doc Brown goes to far...

If we put a resistor in there, it may not bring the MMU pin low enough to do the job.  (I've tried something like that before.   lol   )

[_The Doctor__]

In any event low enough value won't get the job done? Even approaching zero?