Atari Cart + ECI bus Memory Expansion ideas...

[gianlucarenzi]

Hello, everybody!

 

After 30+ years I would like to keep my ATARI Systems up and running!!

 

I am an Computer Science and Electronic Engineer specialized in microcontrollers and microprocessors. Last year I discovered all my 8-bit systems was kept in the basement of my parents' house. They seemed to be yellowed, the capacitors seems to be NOT LEAKING (but I will replace them ASAP). So I was thinking about to build a memory expansion. I was wondering if anyone will be interested in a PLUG-AND-PLAY (no soldering, no open cases, no drills, no CPU change or whatever) 512K/1M/2M/4M memory expansion using the cartridge bus and the ECI bus present in the rear case of the 130xe. May be with a 50 pin header + edge connectors it can be easly adapted to use in a 800XL and maybe in a 600XL too, but I need to check out everything.

 

This expansion will be COMPLETELY OPENSOURCE, with schematics, Kicad project, Firmware, part list (mouser and digikey and others). It will be a banking scheme type-of-expansion with the memory window at 0x4000 - 0x7FFF without using the PORTB (0xD301) memory control register. In my plan it uses the address @ 0xD530 for banking control, and @ 0xD531 for enable/disable expansion.

Actually I cloned the atari800 github project, added the drivers for my expansion and try some memory access on emulator. It works!

 

Application Programming Interface

To enable memory expansion write 1 at bank control register @ D531:

in C:
unsigned char * bankctl = (unsigned char *) 0xd531;
*(bankctl) = 1;

in ASM:
lda #1
sta $d531

 

in BASIC:

POKE 54577, 1

 

To disable, simply write 0 at the same register.

To select the bank (window will be at 0x4000-0x7fff address) write the
correct bank number @ register bank select D530:

in C:
unsigned char * banksel = (unsigned char *) 0xd530;
unsigned char * ramwindow = (unsigned char *) 0x4000;

*(bankctl) = 12;
/* Write at the window of bank 13 */
memcpy(ramwindow, data1, 0x4000); /* Max size will be 16K!!! */

*(bankctl) = 7;
/* Write at the window of bank 8 */
memcpy(ramwindow, data2, 0x4000); /* Max size will be 16K!!! */
...
...

in ASM:
; BANK 13
lda #12
sta $d530
; Do some stuff at address $4000-$7fff
...
; BANK 8
lda #7
sta $d530
; Do other stuff ad address $4000-$7fff
...

 

in BASIC:

REM BANK #8

POKE 54576, 7

....

REM BANK #13

POKE 54576, 12

Pretty simple... ;-P

We can have up to 256 memory banks available, so the register can have
a number between 0 (bank #0) up to 255 (bank #256).

In this way any other memory expansion can be used. In a plain 130XE computer
the total amount of memory will be 4096K + 128K - 16K (for the addresses
overlapped at the memory window): 4208k!!

Basic/ANTIC/... other stuff can be co-exists in this way.

Now, I can need some awesome software (MyDOS, SpartaDOS, demos, etc.,) which
this expansion can be used.

 

I need feedback please!

 

Thanks!

Edited January 12, 2019 by gianlucarenzi

[Mathy]

Hello gianluca

 

It sounded very interesting, because I've been thinking about a cart+ECI/PBI memory expansion myself for years. (I lack the knowledge to turn it into reality) But I'd like to use the addresses the MIO uses. We already have Axlon compatible expansions for the 800, 130XE type ($d301) expansions and the MIO. All using different addresses. You would be adding different addresses yet again. The MIO-methode can also handle up to 4MB as is. And IIRC, the MIO has an address (where you read/write the data) that automatically increases the bank number used, so you don't have to select the next bank number used as long as that bank number is the previous bank number +1.

 

Sincerely

 

Mathy

[+Nezgar]

My first thought was that if a new control register is used, different that existing upgrades, no existing software would be compatible with the RAM.

 

But then Mathys comment about the MIO shows another way - if it registers itself as a full PBI device, it can provide its own handler to work as a RAM disk like the MIO. It would still only really be usable as a ramdisk then, and would require new software written to use it directly for other applications...

[flashjazzcat]

Would it not be preferable to keep the control register away from CCTL since this is a PBI device anyway? You could place it anywhere (say - higher up in the PIA address range or in $D1xx) and it would not interfere with cartridge banking control (some carts use the entire $D5xx range).

[Mathy]

Hello Nezgar

 

But then Mathys comment about the MIO shows another way - if it registers itself as a full PBI device, it can provide its own handler to work as a RAM disk like the MIO. It would still only really be usable as a ramdisk then, and would require new software written to use it directly for other applications...

 

"Full PBI device" also means it'll play nice with other PBI devices that respect the rules, which always is a good idea. And since we're using the same addresses as the MIO, we're practically making the RAM upgrade compatible with the RAM inside the MIO. Which would mean that software that can handle the RAM in the MIO would also be able to handle the RAM in this new RAM upgrade and vice versa.

 

Sincerely

 

Mathy

Edited January 12, 2019 by Mathy

[Faicuai]

Would it not be preferable to keep the control register away from CCTL since this is a PBI device anyway? You could place it anywhere (say - higher up in the PIA address range or in $D1xx) and it would not interfere with cartridge banking control (some carts use the entire $D5xx range).

EXACTLY! Right on the money, there: away from $D5XX range.

 

But I will still wonder about compatibility with past and present SW that relies / addresses extended memory, though...

[Gunstar]

What's the maximum on PBI/ECI memory the way SysCheck 2.2 does it? 1088K? Couldn't it be switchable between the fully Rambo compatible SysCheck way via PBI for legacy software, and the MIO standard for the future and current MIO software?

Edited January 12, 2019 by Gunstar

[flashjazzcat]

EXACTLY! Right on the money, there: away from $D5XX range.

 

But I will still wonder about compatibility with past and present SW that relies / addresses extended memory, though...

Ideally, have some RAM accessible via PORTB and other RAM accessible via a different address. This way, software can make full use of PORTB RAM in the usual fashion without destroying the contents of the protected RAM (RAMdisk, fancy custom OS, ANTIC display buffer, etc).

 

As mentioned: if the device adheres to the PBI protocol, the possibility of conflicts with other hardware is greatly reduced (special RAM could be accessible only when the PBI device is selected).

[gianlucarenzi]

Ideally, have some RAM accessible via PORTB and other RAM accessible via a different address. This way, software can make full use of PORTB RAM in the usual fashion without destroying the contents of the protected RAM (RAMdisk, fancy custom OS, ANTIC display buffer, etc).

 

As mentioned: if the device adheres to the PBI protocol, the possibility of conflicts with other hardware is greatly reduced (special RAM could be accessible only when the PBI device is selected).

Thank you for any of your suggestions: all are ok and you surely know what you are talking about. The biggest issue here, is any user who ALREADY HAD an internal expansion on PORTB address (as myself, I have a 576K 130xe done back in the days) will be forced to loose any hardware expansion and de-solder/disconnect everything from their Atari Motherboard.

Writing a PBI device I do not see any advantage at all for a memory banked expansion: the driver need to be written anyway.

Different story if the expansion is a some kind of GPIO expander, or some sort of sensors like temp sensor or humidity sensors...

Regarding the expansion maybe simulating access at $D304 as BANKCTL and $D305 as BANKSEL can be a better option? I suppose any acces in the shadowing address logic (as PORTA and PORTB uses this address too) is not a very good idea. Anyway the access must be written anyway,because no software is using those registers...Another option is to DO NOT CARE what exists inside the Atari and use the PORTB all 8 bits. I suppose some bus contentions for the same addresses or even worstthe memory window at $4000-$7FFF can have sometime the expansion data, and other times the inside-motherboard-chip ram data...Mmmmhhh... Another solution can be use the D1xx access as the Mapping the Atari says...To me the best viable solution is to move the registers up to $D5FE and $D5FF for bankctl and banksel... What hardware is using those two addesses?Regards,Gianluca

[flashjazzcat]

The biggest issue here, is any user who ALREADY HAD an internal expansion on PORTB address (as myself, I have a 576K 130xe done back in the days) will be forced to loose any hardware expansion and de-solder/disconnect everything from their Atari Motherboard.

Yes: it would be useful to disable the external PORTB expansion via a DIP switch or via software configuration.

 

Writing a PBI device I do not see any advantage at all for a memory banked expansion: the driver need to be written anyway.

I think the idea here is that if the target machine has no expanded RAM, providing external extended RAM via PORTB would allow software intended for standard PORTB RAM expansions to work unaltered. There is quite a bit of software around which works with extended RAM without the use of drivers (this is perhaps unfortunate, but it's the situation).

 

When the U1MB was being designed, I asked for a means of splitting up the 1MB of RAM between PORTB access and some special 'hidden' register, but it never happened. The idea here was to allow XL/XE software uninhibited access to PORTB RAM, while not disturbing the RAM accessible via the special register. Of course your device would provide the 'protected' RAM, but it will depend on the target machine first having an internal PORTB RAM expansion to be much use with any existing software.

 

Regarding the expansion maybe simulating access at $D304 as BANKCTL and $D305 as BANKSEL can be a better option? I suppose any acces

in the shadowing address logic (as PORTA and PORTB uses this address too) is not a very good idea. Anyway the access must be written anyway,

because no software is using those registers...

$D304 and $d305 sound reasonable, although I'm sure someone who designs hardware (I don't) may be able to offer better advice than I.

 

To me the best viable solution is to move the registers up to $D5FE and $D5FF for bankctl and banksel... What hardware is using those two addesses?

I can see no compelling reason whatsoever to use $D5xx for banking control when the PBI device can decode its control registers anywhere in the hardware region. It would make sense were this a cartridge-based RAM expansion (since carts are limited to the cart banking window and CCTL).

 

The AtariMax 8MBit cartridge will disable itself when $D5FE/FF are written, IIRC.

Edited January 13, 2019 by flashjazzcat

[gianlucarenzi]

Yes: it would be useful to disable the external PORTB expansion via a DIP switch or via software configuration.

 

 

I think the idea here is that if the target machine has no expanded RAM, providing external extended RAM via PORTB would allow software intended for standard PORTB RAM expansions to work unaltered. There is quite a bit of software around which works with extended RAM without the use of drivers (this is perhaps unfortunate, but it's the situation).

 

When the U1MB was being designed, I asked for a means of splitting up the 1MB of RAM between PORTB access and some special 'hidden' register, but it never happened. The idea here was to allow XL/XE software uninhibited access to PORTB RAM, while not disturbing the RAM accessible via the special register. Of course your device would provide the 'protected' RAM, but it will depend on the target machine first having an internal PORTB RAM expansion to be much use with any existing software.

 

 

$D304 and $d305 sound reasonable, although I'm sure someone who designs hardware (I don't) may be able to offer better advice than I.

 

 

I can see no compelling reason whatsoever to use $D5xx for banking control when the PBI device can decode its control registers anywhere in the hardware region. It would make sense were this a cartridge-based RAM expansion (since carts are limited to the cart banking window and CCTL).

The AtariMax 8MBit cartridge will disable itself when $D5FE/FF are written, IIRC.

 

But it will be a cartridge based RAM expansion (as the cart slot is used and the ECI bus too...). For the beginning I will plan these options:

 

1- Using PORTB $D301 as bank selector (6-bits) ) so 64 banks can be used (1024k). The other banks selection can go @ $D305... So anyone can use more than 1024k easily... In this case old software can use 1024k and the new one can go up to 4Meg

 

2- Using PORTB $D301 for total 8 bit. Results will be unpredictable as no OS nor BASIC... ??? I will check with emulator (atari800)

 

3- Using $D305 for total 8 bits. In this case the only drawback is what will happen using shadowed registers for PIA access...

 

4- Using $D530 and $D531. PBI device are not banked over here. They can use the address between MPD MathPack and $D800 or other addresses but NO $D5xx (only RTC-8 I think, but not at $30 and $31...)

 

How the Antonia 4Meg works? It need to be installed inside the motherboard?

[flashjazzcat]

Just because the XE's ECI connector comprises the cartridge port plus the adjacent connector does not make an external device which connects to both simultaneously 'cartridge based'. A cartridge-based RAM expansion would necessarily have the control register at $D5xx and the RAM would have to appear somewhere between $8000-$BFFF. But it's a semantic point.

[Mathy]

Hello Gianlucca

 

Writing a PBI device I do not see any advantage at all for a memory banked expansion: the driver need to be written anyway.

...

...Mmmmhhh... Another solution can be use the D1xx access as the Mapping the Atari says...

 

I do:

 

a) It'll be compatible to the memory inside the MIO (and therefor does not create a new bank select methode)

b) It doesn't mess with the cartridges used. One reason not to mess with $D5xx is that OSS cartridges only check 4 bites instead of the whole byte. "Though the control range is $D500 to $D50F, the cartridge address decode logic is only four bits wide. This means that any access (read from, write to, or otherwise manipulate) a $D5xy address affects the cartridge which ignores the "x". OSS cartridges react to the whole $D500 page based on the low four bits of the address." (John Picken)

 

$D1xx is used by PBI devices.

 

2- Using PORTB $D301 for total 8 bit. Results will be unpredictable as no OS nor BASIC... ???

 

Just multiplex the bits used to control OS ROM/RAM and BASIC (and the Selftest and (in the XEGS) Missile Command).

 

Sincerely

 

Mathy

[Frankie]

 

How the Antonia 4Meg works? It need to be installed inside the motherboard?

Yes, you plug it in to where the CPU chip goes and then a ribbon cable to the MMU.

[gianlucarenzi]

Here I am again!!

Last week I spent a couple of e-mails with Mathy Van Nisselroy talking about MIO's ICD interface and its RAM up to 1Meg.

Yesterday I had a mumble mumble and... voila'! Here is my last project!

An expansion board for any Atari XE (Having ECI + CART) which sports a UnoCart and a MIO Expansion memory compatible plus a new registers for adding the 2 or 4 megabytes support.

It's called DUO Cart (as opposing UNOCart which in italian UNO means ONE, and DUO means TWO ).

Its firmware can do all stuff like UNOCart does, plus a MIO Memory expansion.

 

In attachment there are some information and 3d renderings. As soon as the prototypes are ready I will be glad to share everything with you!

 

I hope MyDOS will include this memory expansion driver as it will be 100% compatible, but need a register more to add the extra 2Meg or 4Meg RAM Chips!

 

 

Best Regards,

Gianluca

MIO-Registers-Extended.pdf

[_The Doctor__]

there might be room for a serial/lan port on this as well, this is so close to being an all in one device

[+Nezgar]

Wow this is really neat, lots of progress in a short amount of time. MyDOS (or any DOS) shouldn't need a 'memory expansion driver' as, at least in the MIO, the RAM disk is installed via PBI BIOS, and will 'just work' in any DOS. Being there's an SD card, there could be a 'default ramdisk' image that's loaded with whatever pre-set ramdisk contents.

 

I see EXTPRW1 leads, so maybe the RAMdisk would be static, as long as external power is supplied? What would 12V be necessary for?

 

For convenience, the MIO would also automatically format the RAMdisk with an empty SpartaDOS file system if it detected it was blank from a cold start. Nothing stopping you from re-formatting it to a different DOS (ie MyDOS) or sector copying a bootable disk to it. This could be an ultimate 'ATR' capable loader, as the PBI bios can do drive redirection to RAM based disk(s) much better than cart only solutions.

 

There would need to be some software configurable way of selecting the # of RAM disk(s) and drive numbers.

[Lynxpro]

Here I am again!!

Last week I spent a couple of e-mails with Mathy Van Nisselroy talking about MIO's ICD interface and its RAM up to 1Meg.

Yesterday I had a mumble mumble and... voila'! Here is my last project!

An expansion board for any Atari XE (Having ECI + CART) which sports a UnoCart and a MIO Expansion memory compatible plus a new registers for adding the 2 or 4 megabytes support.

 

 

Go for 8MB because the Apple II scene is getting way too uppity ever since they got their 8MB upgrade solution*.

 

 

*Only counting 6502-based Apple II models, not 65816-based IIgs models....

[gianlucarenzi]

there might be room for a serial/lan port on this as well, this is so close to being an all in one device

It should be possible if:

- the uart ports are still available in the very few pins available,

- someone gives me the 850 R: specifications (xio ioctl codes for setting the baud rate, rts-cts stuff, etc.,...) just to write the right handler.

[gianlucarenzi]

 

Go for 8MB because the Apple II scene is getting way too uppity ever since they got their 8MB upgrade solution*.

 

 

*Only counting 6502-based Apple II models, not 65816-based IIgs models....

This expansion will be the first of the series. If someone need more ram I should use the Stm32f42x line just to connect ddr2 chip to it and share memory with 6502. It should not so difficult. For now I will focus on a diy project. Bga are too difficult to solder.

 

Can you point me to the apple ii memory expansions?

[Lynxpro]

This expansion will be the first of the series. If someone need more ram I should use the Stm32f42x line just to connect ddr2 chip to it and share memory with 6502. It should not so difficult. For now I will focus on a diy project. Bga are too difficult to solder.

 

Can you point me to the apple ii memory expansions?

 

I'm having problems finding it on the net. They do rave about it over in the Apple II group over on Facebook; it appears it's built in Russia based upon the cyrillic lettering of the person's name who posts there...

 

Here's a readily-available 4MB upgrade from a different vendor:

 

https://www.reactivemicro.com/product/ramworks-iiii/

 

 

I wanted to distinguish the 6502 based Apple II line versus the 65816 Apple IIgs because it's rather "easy" to have 16MB upgrades for 65816 based systems in comparison...

[ivop]

This expansion will be the first of the series. If someone need more ram I should use the Stm32f42x line just to connect ddr2 chip to it and share memory with 6502. It should not so difficult. For now I will focus on a diy project. Bga are too difficult to solder.

 

Can you point me to the apple ii memory expansions?

 

Perhaps one of the next in the series could support banking $0000-$7fff at once (32kB) which includes the stack and ZP. This would be a great addition for multi-tasking OS's like FUZIX or something still to be made.

[gianlucarenzi]

Thanks for any advice you gave me. I appreciate them very much. I was looking at the specifications for MIO, and the layout is driving me crazy: let's do an example.

I want to write $de $ad at first two bytes of the Bank no.1, then write $be $ef at the address @$80 of bank no.258, then read @$fe of the 25th bank.

I will do:

 

lda #1 << 5 ; bit 5 is ram enable

sta $d1e2

 

lda #0

sta $d1e0

lda #0

sta $d1e2

...write $de $ad @ $d600

 

lda #$02

sta $d1e0

lda #$01

sta $d1e2; $0102 = 258

...write $be $ef @ $d680

 

lda #$19

sta $d1e0

lda #0

sta $d1e2

...read @ $d6fe

 

As you can see the ram enable bit will go high the first time, then all subsequent write in this register $d1e2 is low.

 

Is it to stay 1 for every ram access?

 

This thing is going me crazy.

 

Are out there some MIO user?

[+Nezgar]

I have a 1MB MIO, but I'm not a programmer and won't be much help, except for testing... If you want to try out how an MIO works, I can suggest trying MIO emulation in Altirra, which simulates one very accurately. The 1.42 MIO ROM is on rasterlines site I believe.

 

I also just found my original MIO manual, it may be online already, if not I can try to scan and upload it. Pretty sure it has programming information.

 

Edit: heres one on AtariMania if you didn't find it already... http://www.atarimania.com/documents/ICD_Multi_IO_Board_Manual__Rev_5_20_1987_.pdf

[_The Doctor__]

the black box serial port handles rts/cts better than the mio, but len spencers fixes help both of them work better. so long as you make the best serial/lan hardware possible... some crafty people will come up with drivers etc....