Atari 800 Personality Board -- RAMROM 2022

[reifsnyderb]

When I posted about getting a Newell RAMROD board, some discussion arose about another personality board for the Atari 800.

 

https://forums.atariage.com/topic/341566-newell-atari-800-ramrod-personality-board/

 

So, I designed and ordered the board.  The goal is to have the following:

 

1.  Sockets for the original Atari OS chips.

2.  A flash chip socket for customized OS's and/or options such as Omnimon or Omniview.

3.  An option to use $C000-$CFFF with the flash chip.  (i.e.  Omniview)

4.  An option for RAM at $C000-$CFFF

5.  An option to turn the RAM into Mosaic banking with 128k.

6.  Add a battery backup to the RAM.

7.  There were 2 extra DIP switches so I made 4 banks for the flash chip.

8.  Header pins for to add a switch for the flash chip banks.  (Optional)

9.  Header pins to breakout /S6 and /S7 to allow for other boards to utilized these select pins.

 

Today, UPS delivered the chips and I got the boards on Saturday.  So, the board was assembled and tested.  I already knew there was a problem because the Atari personality board schematic I used as a reference was wrong.  So, I had to hack the board to fix that problem.  I discovered, through testing, that I reversed /S6 and /S7 to the OS chips so the board had to be hacked again.  I also discovered I screwed up the banks for the Flash chip and had to hack the board yet again.  So, now there's 7 extra jumper wires on this mess.

 

It mostly works.  I say "mostly" because I can't get all the cartridges to work.  So, here's a list of everything that's been tested to work thus far:

 

1.  Original Atari RAM boards up to 48k.

2.  My 48k SRAM board.

3.  The 3 OS chips sockets.

4.  Flash ROM bank 0.  (OS and Omniview work)  I presume that Flash ROM bank 1 through 3 work as changing banks with a switch is pretty simple.

5.  Onboard SRAM.  Basic testing using POKE and PEEK at some addresses.  Not comprehensive for reasons listed later.

6.  Mosaic banks via POKE and PEEK appear to work.  Not comprehensive for reasons listed later.

7.  BASIC Cartridge

8.  Donkey Kong Cartridge

9.  M.U.L.E. loads and runs off of floppy disk.  (I include this here to show how functional this is thus far and for troubleshooting purposes.)

 

What doesn't work:

 

1.  PacMan Cartridge (It partially works, corrupted screen.)

2.  Star Raiders

3.  SIDE3 (both to menu and to SpartaDOS-X)

 

I spent a lot of time looking into why the above 3 cartridges don't work and came up with nothing.  If it was RAS timing, I don't think the Atari RAM would work.  I used 74LS chips for the timing elements just to be sure that wasn't the problem.  (74F chips can cause timing problems or fix timing problems depending upon the application.)  I looked into the size of Donkey Kong and PacMan and discovered that Donkey Kong works (16k) but PacMan doesn't (8k).  SIDE3 doesn't work at all.  I have no idea why at the moment.  PacMan almost appears to be a timing issue but I can't find anything wrong with the timing circuits as they are identical to Atari's and Newell's.  All the solder connections look good.  When I tested the cartridges, I used a very basic configuration.  (OS only...nothing else.)  That M.U.L.E. works shows that a complicated game that loads via disk works.  If the Atari memory didn't work, I'd look more closely at RAS timing.  Since Star Raiders fails, I don't think it's related to cartridge control.  At this time, I am out of ideas.

 

I still need to test the battery backed-up RAM.  Also, the 2 position DIP switch didn't arrive yet but that only allows you to use the SRAM if you don't have a chip for the battery back-up by turning on both switches.

 

Something odd was that when I POKE'd a memory location, the first time after boot-up I had to POKE it twice.  After that it worked fine.  I am wondering if this is bug in BASIC Rev. A.  I didn't spend much time testing this problem, though.  I do need to see if it is only on the SRAM or if it is a problem with other locations as well.

 

Edit:  I just confirmed the problem with POKE is actually the PEEK command.  I had to PEEK it twice the first time.

 

Here's a picture of the board:

 

 

The board is currently configured to use the flash chip and to use mosaic memory banks.

 

 

 

 

Edited October 14, 2022 by reifsnyderb

[reifsnyderb]

I just got it working.  SIDE3 is now loading and I can view the system with SimpleCheck.  31 Mosaic banks are showing up with a total RAM of 176k.

 

I am now guessing there is a bad solder joint somewhere as I had the computer turned on for a while before I tried again.  I'll see what happens after the computer has been shut down for a while.

[+Larry]

Impressive features!  Should this board work with your 1056K Axlon Board?  (latest revisions.)

 

 

[reifsnyderb]

2 hours ago, Larry said:

Impressive features!  Should this board work with your 1056K Axlon Board?  (latest revisions.)

 

 

It works with the 1056 Axlon Board.  However, if C000-CFFF is set for RAM or Mosaic then there will be problems if anything uses memory in the Axlon register.

 

The latest revision of the 1056 board has a connection for another card.  That connection is to allow another card to turn off Axlon memory and for it to turn on main memory.  This card doesn't use those features.  I do have a "1056 Personality Card" that I am working on that would work with the latest revision of the Axlon board.  I want to make some changes to it and get another version made at some point.

 

I am also wondering if it would be useful to have a battery backed-up version of the 1056 Board (Axlon board)...

[reifsnyderb]

I finally got a battery for the battery backed-up RAM.  It works and keeps the data.   🙂

 

I think the original problem was caused by a bent pin on the floating point chip.  Everything is working great now.   🙂

 

[reifsnyderb]

Boards ordered.   🙂

[tep392]

On 10/14/2022 at 7:19 AM, reifsnyderb said:

I am also wondering if it would be useful to have a battery backed-up version of the 1056 Board (Axlon board)...

I added battery backup to my 512K sram based Axlon compatible board so I wouldn't lose files if my machine locks while working on a program.  I assemble code from the ramdrive since it is so much quicker.  I pulled the board out while testing another Axlon board, and when I put the thing back in a few days later, the files were still there.  The geek in me loved that.

[reifsnyderb]

47 minutes ago, tep392 said:

I added battery backup to my 512K sram based Axlon compatible board so I wouldn't lose files if my machine locks while working on a program.  I assemble code from the ramdrive since it is so much quicker.  I pulled the board out while testing another Axlon board, and when I put the thing back in a few days later, the files were still there.  The geek in me loved that.

Does this work with any ramdrive software or is this a special situation?  

 

All I need to do is add a chip and a battery and it will have the battery backup.  It would be really cool to be able to boot from the battery backed-up RAM drive.

[tep392]

4 hours ago, reifsnyderb said:

Does this work with any ramdrive software or is this a special situation?  

 

All I need to do is add a chip and a battery and it will have the battery backup.  It would be really cool to be able to boot from the battery backed-up RAM drive.

It is a function of the DOS to retain the contents of the battery backed RAM before it attempts to initialize the Ramdisk.  For example when SDX boots, it will check if the Axlon RAM is formated as a ramdisk and will retain it's contents if it is.  If not, it will initialize the ramdisk if you have it setup to do so.  I've seen other DOS ramdisk drivers do this also but don't recall off the top of my head which ones.  

 

Booting from a ramdisk is another matter.  I think there would need to be some support in the OS for this.  The R and L versions of Omnimon have ramdisk support and do actually have a function to boot from the ramdisk.  I have not tried that out yet, but I hope to spend some more time soon investigating the capabilities of the L+U Omnimon I have in my Ramrod board.

[reifsnyderb]

11 hours ago, tep392 said:

It is a function of the DOS to retain the contents of the battery backed RAM before it attempts to initialize the Ramdisk.  For example when SDX boots, it will check if the Axlon RAM is formated as a ramdisk and will retain it's contents if it is.  If not, it will initialize the ramdisk if you have it setup to do so.  I've seen other DOS ramdisk drivers do this also but don't recall off the top of my head which ones.  

Sounds like a good feature to add at some point.

 

11 hours ago, tep392 said:

 

Booting from a ramdisk is another matter.  I think there would need to be some support in the OS for this. 

This was my thought too.  It should be possible to boot from a ramdisk on an XL, though, through the PBI.  

11 hours ago, tep392 said:

The R and L versions of Omnimon have ramdisk support and do actually have a function to boot from the ramdisk.  I have not tried that out yet, but I hope to spend some more time soon investigating the capabilities of the L+U Omnimon I have in my Ramrod board.

I'll have to look into that as well.

 

 

Edited October 20, 2022 by reifsnyderb

[tep392]

This versions L and R Omnimon feature looks interesting.

[+David_P]

12 hours ago, reifsnyderb said:

 

This was my thought too.  It should be possible to boot from a ramdisk on an XL, though, through the PBI.  

 

Yes, you can boot off a MIO RAMDISK.

[+Larry]

12 hours ago, David_P said:

Yes, you can boot off a MIO RAMDISK.

Just curious -- did you swap the drives in the MIO menu to make the ramdisk D1:?  Or was there some other means?

[+Larry]

@reifsnyderb

Can the flash chip be programmed in the 800, or will it need to be removed and flashed in another device?  Are the flash modules full OS, or do they represent 4, 4K modules for Omnimon, Romdos, etc.?

[reifsnyderb]

1 hour ago, Larry said:

@reifsnyderb

Can the flash chip be programmed in the 800, or will it need to be removed and flashed in another device?  Are the flash modules full OS, or do they represent 4, 4K modules for Omnimon, Romdos, etc.?

The flash chip has to be removed and programmed on another device.  The electronics needed to do otherwise would have been rather complicated and there was no space on the board.

 

The flash chip is a 128k SST39SF010 with 64k used and divided into 4 banks of 16k each.

 

A bank, when selected, is mapped to $C000-$FFFF.  The DIP switches select the bank and control whether the OS/floating point region and/or $C000-$CFFF region is used.  (i.e.  You could use the sockets for the OS/floating point and the flash chip for a 4k Omnimon.)

 

Best Regards,

 

Brian

 

 

 

 

 

 

 

[+David_P]

15 hours ago, Larry said:

Just curious -- did you swap the drives in the MIO menu to make the ramdisk D1:?  Or was there some other means?

It's been a while, but as I recall, yes, boot, init the RD, install a DOS on it, swap from the menu, reboot from the MIO.

[reifsnyderb]

Board are in!  I've assembled one and started testing it.

 

The feature set is as follows:

 

1.  Sockets for the original Atari OS chips.

2.  A flash chip socket for customized OS's and/or options such as Omnimon or Omniview.

3.  An option to use $C000-$CFFF with the flash chip.  (i.e.  Omniview)

4.  An option for RAM at $C000-$CFFF

5.  An option to turn the RAM into Mosaic banking with 128k.  (With 48k of base RAM this is 176k of RAM.)

6.  Optional battery backup for SRAM.  (If the battery backup chip isn't installed, there is a DIP switch to allow for operation without it.)

7.  There were 2 extra DIP switches so I made 4 banks for the flash chip.

8.  Header pins for to add a switch for the flash chip banks.  (Optional)

9.  Header pins to breakout /S6 and /S7 to allow for other boards to utilized these select pins.

10.  Proper RASTime and -WriTime outputs and timing so as to support Atari's original memory modules in addition to modern, SRAM, modules.

11.  A connection point for an external battery SRAM battery backup.

 

Number 10 is important and I found out if I have 74F chips installed instead of 74LS chips in the timing circuits that SIDE3 fails.  It just goes to show how important it is to have the correct chip speeds in some circuits.  (I've also found on other boards that this makes a difference if R/W Late is being used for timing as well.)

 

I need to make up a standard install for the flash chip.

 

I am thinking of loading it up as follows:

 

Bank 1:  Atari OS A, Atari floating point, $C000-$CFFF ??

Bank 2:  Atari OS B, Atari floating point, $C000-$CFFF ??

Bank 3:  Atari OS B, Fast Chip floating point, $C000-$CFFF Omniview

Bank 4:  Atari OS B, Fast chip floating point, $C000-$CFFF Omnimon

 

I am thinking of trying Altirra floating point to compare with Fast Chip.  If Alitirra's floating point is faster, I'll use that.

 

Is there any reason I shouldn't just load the fastest floating point math pack in all banks?

Would there be any better combinations of features to load on the flash chip?

 

Thanks!

 

 

 

 

 

Edit:  Picture added.  Board is configured to use the OS on the flash chip, SRAM is enabled at $C000-$CFFF, Mosaic memory banking is enabled, and the SRAM battery backup is installed.

 

The red DIP switches can be set to the on position to use the SRAM without a battery backup chip in the little socket below it.

 

 

Edited October 27, 2022 by reifsnyderb

[+Larry]

So there really is no reason to need to swap the OS & Math pack chips out of our original boards? 

 

Suggest bank one has Romdos + Fastchip.  Bank two -- completely "stock."  Yes, Altirra is fine if it is faster. 

 

Nice!!!

[reifsnyderb]

4 minutes ago, Larry said:

So there really is no reason to need to swap the OS & Math pack chips out of our original boards? 

 

Suggest bank one has Romdos + Fastchip.  Bank two -- "stock."  Yes, Altirra is fine if it is faster. 

 

Nice!!!

No, there is no reason to swap the OS and Math chips out if the desired OS is flashed in a bank on the chip.

 

RomDos is an interesting option.  Do a lot of people use it?

[+Larry]

43 minutes ago, reifsnyderb said:

No, there is no reason to swap the OS and Math chips out if the desired OS is flashed in a bank on the chip.

 

RomDos is an interesting option.  Do a lot of people use it?

No, I seriously doubt it.  But it was what the original board was all about (along with Omnimon) in 1982 or 1983.  OTOH, it should not be difficult for most users to put in what we want if we want other than what you build into the board.

 

BTW, what programmer are you using to program the flash?

[ivop]

Will RESET/SELECT (for SuperMon and OminMon) also work with this board. Does it do the same as the daughter board I was told to exist to intercept the OS ROM vectors?

 

Otherwise it only works with a ROMDOS bootdisk, or OmniView aware software that enables the 80 column mode.

 

 

Edit: I mean the 6502 vectors at $FFFA-$FFFF.

Edited October 27, 2022 by ivop

[reifsnyderb]

40 minutes ago, Larry said:

No, I seriously doubt it.  But it was what the original board was all about (along with Omnimon) in 1982 or 1983.  OTOH, it should not be difficult for most users to put in what we want if we want other than what you build into the board.

 

BTW, what programmer are you using to program the flash?

XgPro

[reifsnyderb]

4 minutes ago, ivop said:

Will RESET/SELECT (for SuperMon and OminMon) also work with this board. Does it do the same as the daughter board I was told to exist to intercept the OS ROM vectors?

 

Otherwise it only works with a ROMDOS bootdisk, or OmniView aware software that enables the 80 column mode.

 

 

My guess is it will work fine as there aren't any pins related to reset and/or select that go to any personality card.  To the best of my knowledge, any interception of OS ROM vectors would be firmware related.

 

Unless, of course, this other daughter board had a couple jumpers soldered to the main board somewhere...

[ivop]

1 minute ago, reifsnyderb said:

My guess is it will work fine as there aren't any pins related to reset and/or select that go to any personality card.  To the best of my knowledge, any interception of OS ROM vectors would be firmware related.

 

Unless, of course, this other daughter board had a couple jumpers soldered to the main board somewhere...

@tep392 can perhaps tell more about it. Omnimon, for example, should work with just a 4kB ROM and an unpatched OS-B. Notice unpatched. But there's apparently a daughter board that connects to the OS socket and intercepts the 6502 RESET/NMI/IRQ vectors to point directly to the code at $C000-$CFFFF so it can intercept key presses.

[reifsnyderb]

22 minutes ago, ivop said:

@tep392 can perhaps tell more about it. Omnimon, for example, should work with just a 4kB ROM and an unpatched OS-B. Notice unpatched. But there's apparently a daughter board that connects to the OS socket and intercepts the 6502 RESET/NMI/IRQ vectors to point directly to the code at $C000-$CFFFF so it can intercept key presses.

Hopefully, @tep392 will post about this, then.  I never saw anything about it in any documentation, posts, etc., and there was no sign on my Newell board that there was anything I was missing or any socket to add another feature.

Edited October 27, 2022 by reifsnyderb