Jump to content
IGNORED

32 in 1 OS from AtariMax


rchennau

Recommended Posts

Here is the options that came with my 32-in-1 out of the box, with a little more intelligible description of each:

 

A     APE Warp+ OS (XL/XE)                               APE Warp+ OS
B     Atari XL/XE OS (REV A)                             XL/XE (REV A)
C     Atari XL/XE OS (REV B)                             XL/XE (REV B)
D     Atari XL/XE OS (REV C)                             XL/XE (REV C)
E     Atari XEGS OS (REV D)                              XEGS (REV D)
F     Atari 800 OS-B                                     800 (OS-B)
G     Atari 400 OS-A                                     400 (OS-A,P)
H     Atari 800 Compatible OS                            800 Compatible
I     Atari XL/XE OS w/ Reverse BASIC (REV A)            XL/XE (R-A,RB)
J     Atari XL/XE OS w/ Reverse BASIC (REV B)            XL/XE (R-B,RB)
K     Atari XL/XE OS w/ Reverse BASIC (REV C)            XL/XE (R-C,RB)
L     Atari XEGS OS w/ Reverse BASIC (REV D)             XL/XE (R-D,RB)
M     Atari 1200XL OS (REV 11)                           1200XL (REV 5)
N     Atari 1200XL OS (REV 10)                           1200XL (REV 10)
O     Atari XL/XE Arabic OS                              ARABIC XL/XE
P     ARGS-OS (Ralf David ROM-Disk: Select+Reset)        ARGS-OS
Q     Atari XL/XE OS w/ Pal Mods (REV A)                 XL/XE (R-A,P)
R     Atari XL/XE OS w/ Pal Mods (REV B)                 XL/XE (R-B,P)
S     Atari XL/XE OS w/ Pal Mods (REV C)                 XL/XE (R-C,P)
T     Atari XEGS OS w/ Pal Mods (REV D)                  XEGS (R-D,P)
U     Atari XL/XE OS w/ Pal Mods + Reverse BASIC (REV A) XL/XE(R-A,P,RB)
V     Atari XL/XE OS w/ Pal Mods + Reverse BASIC (REV B) XL/XE(R-B,P,RB)
W     Atari XL/XE OS w/ Pal Mods + Reverse BASIC (REV C) XL/XE(R-C,P,RB)
X     Atari XEGS OS w/ Pal Mods + Reverse BASIC (REV D)  XEGS(R-D,P,RB)
Y     QMEG OS V3 (c)87 S.Dorndorf                        QMEG TEST ROM
Z     David Young OmnimonXL (C)1984                      OMNIMON TEST
0     David Young OmnimonXL (C)1984 w/ Reverse BASIC     OMNIMON R-Basic
1     David Young OmniView XE w/ Reverse BASIC           OmniView 80
2     MyIDE 3.1e                                         MyIDE 3.1e
3     MyIDE 3.1i                                         MyIDE 3.1i
4     Warp+ OS r11                                       Warp+ OS r11

 

Ya, this is what I have too.

Is there a thread that would have more detail about the differences between the versions. reverse basis is obvious. But the differences (I assume they are bug fixes) like between XL/XE Ver A,B,C, and what do all these type of code mean,(R-A,P,RB) ?

Link to comment
Share on other sites

Is there a thread that would have more detail about the differences between the versions. reverse basis is obvious. But the differences (I assume they are bug fixes) like between XL/XE Ver A,B,C, and what do all these type of code mean,(R-A,P,RB) ?

R-A = Revision A: 800 OS has a Rev A, and B. XL/XE OS has Rev A,B,C,D.

P = PAL

RB = Reverse BASIC (as you already surmised)

 

The differences between 800 OSA and OSB,and the 4 XL/XE OS versions have definitely been covered in previous threads such as: http://atariage.com/forums/topic/239011-atari-xl-and-xe-kernel-os-roms/

 

800 OSA: uses different cassette start block and inter-block delays, maybe incompatible with OSB for loading/saving from cassette?

800 OSB: did this one fix a random delay that would cause a 9 minute hang during some I/O like printing?

 

XLXE:

Rev A: Inserting a cartridge causes an immediate cold-reset

Rev B: Dos not coldstart on insertion of a cartridge.

Rev C: Added support for extra 64K of 130XE in Self-Test memory test (due to bug in PIA bits used, it only actually tests 2 of the 4 banks) and shortening of the delay loops so that the test performs faster. Also has a fix for a bug in SIO that can occasionally cause transfers to time out and retry.

Rev D: Select key and keyboard attached state affect startup behaviour. (BASIC vs Missile Command).

 

Probably some other things too.

 

According to this post in that thread http://atariage.com/forums/topic/239011-atari-xl-and-xe-kernel-os-roms/?p=3249781the PAL OS's are not original - they are probably hacked for NTSC systems with an ANTIC swapped with a PAL one for better I/O timing of cassette loading/saving.

Link to comment
Share on other sites

I'm waiting for a PLCC adapter for my TL866 programmer so I can dump and re-program the chip on my 32-in-1. I'd like to have OS's like a stock OS with HIAS' highspeed routines, BOSS XL, TURBOSS, and Shoestring's RAM tester.

 

If there's no longer a pre-built tool to do this, I imagine the OS's are merely arranged as 32 consecutive 16KB blocks and can just be replaced/overwritten on the 16K boundaries ?

 

Then, probably have to manually hex-edit the menu selection names to match. Hopefully checksums are not performed on that area.

 

Am I on the right track if anyone has done this before?

 

If you ever get around to doing this could you post the BIN here for us to try as well? Thanks

  • Like 1
Link to comment
Share on other sites

R-A = Revision A: 800 OS has a Rev A, and B. XL/XE OS has Rev A,B,C,D.

P = PAL

RB = Reverse BASIC (as you already surmised)

 

The differences between 800 OSA and OSB,and the 4 XL/XE OS versions have definitely been covered in previous threads such as: http://atariage.com/forums/topic/239011-atari-xl-and-xe-kernel-os-roms/

 

800 OSA: uses different cassette start block and inter-block delays, maybe incompatible with OSB for loading/saving from cassette?

800 OSB: did this one fix a random delay that would cause a 9 minute hang during some I/O like printing?

 

XLXE:

Rev A: Inserting a cartridge causes an immediate cold-reset

Rev B: Dos not coldstart on insertion of a cartridge.

Rev C: Added support for extra 64K of 130XE in Self-Test memory test (due to bug in PIA bits used, it only actually tests 2 of the 4 banks) and shortening of the delay loops so that the test performs faster. Also has a fix for a bug in SIO that can occasionally cause transfers to time out and retry.

Rev D: Select key and keyboard attached state affect startup behaviour. (BASIC vs Missile Command).

 

Probably some other things too.

 

According to this post in that thread http://atariage.com/forums/topic/239011-atari-xl-and-xe-kernel-os-roms/?p=3249781the PAL OS's are not original - they are probably hacked for NTSC systems with an ANTIC swapped with a PAL one for better I/O timing of cassette loading/saving.

 

Very helpful !!!

many thanks!!

Link to comment
Share on other sites

  • 2 weeks later...

Got my PLCC32 adapter, and successfully read out the 32-in-1 ROM. (Ordered Sep 4 from eBay/China, received Nov 16th... warp speed!! :) )

 

The geometry is indeed simply the first 31 back-to-back 16KB OS ROMs, with the last (32nd) block being the menu/APE utility OS, for a total of 512KB. The 31 OS names are listed in a single block in this last OS, so it shouldn't be too difficult to overlay particular OS's by hand and edit the names there.

 

FJC suggested the OS names were hidden under the registers 2K block at $D000... You were close! But I can confirm $D000-$D799 is all 00's in the last OS, and data continues at $D800, with the keyboard letters and OS names starting at $DCCD.

 

Alterations for another night. Cheers!

post-53052-0-30922400-1542521837_thumb.jpg

post-53052-0-01238700-1542521846_thumb.png

  • Like 4
Link to comment
Share on other sites

FJC suggested the OS names were hidden under the registers 2K block at $D000... You were close! But I can confirm $D000-$D799 is all 00's in the last OS, and data continues at $D800, with the keyboard letters and OS names starting at $DCCD.

Yes: that was basically a transcription error on my part, since I was looking at the supposed menu data in the $D800-$DFFF area in a hex editor anyway. Common sense dictated that the boot menu would occupy the $D000-$D7FF region in the last slot (the proviso being that the last slot would have to be occupied by a 400/800 OS which has no content in this region), but indeed it's actually under the math pack.

 

This does not change the fact that the menu data on my chip dump does not correspond directly to what appears on the screen, with several strings present in the boot menu (Speedy, MyIDE, etc) completely absent from the binary dump of what is apparently the list of strings.

 

If anyone can see 'MYIDE' in this lot, I would be most interested to hear about it:

 

post-21964-0-75728300-1542559373_thumb.png

 

Hence my assumption that some kind of simple (but far from transparent) tokenisation system is used.

Edited by flashjazzcat
  • Like 1
Link to comment
Share on other sites

If anyone can see 'MYIDE' in this lot, I would be most interested to hear about it:

Hmm, my screenshot above shows a couple MyIDE OS's - and do match up with my actual menu. Your hex screenshot doesn't show any MyIDE options - does yours actually present MyIDE options in the menu when used? (or other options that dont match?)

 

Yours says "© 2003 Steven Tucker", mine says "c2003 Steven Tucker" - suggesting maybe different revs of the code.. I acquired mine in 2016...

  • Like 3
Link to comment
Share on other sites

...does yours actually present MyIDE options in the menu when used? (or other options that dont match?)

Yes: as I wrote above. The moment I noticed that the binary dump was discrepant in several areas with what appeared on the screen, I concluded that there was not necessarily a direct 1:1 relationship between the two. It was not worth my time to spend more than a couple of hours investigating the matter further. Here is the binary dump from the device I was looking at:

 

32-in-1.BIN

 

And here is a screenshot of the same device's menu:

 

post-21964-0-23942600-1542566995_thumb.jpeg

 

Note only 31 entries in that menu...

Edited by flashjazzcat
  • Like 1
Link to comment
Share on other sites

looks like flash didn't erase before writing, or some other such mucky thing, sometimes you just don't know what's been done to a thing.... I'd just use the newer tools and/or start with nezgars rom. Reminds me of folks blaming a game disk they created and the protections fail... as they try to figure out what's going on there is remnants of this or that there. Then make ideas based on what they see... really making life more difficult than it ever was. If the disk had been a blank unformatted disk they would see exactly what's going on and be able to do whatever copy protected disk that works or cracked disk with protections truly removed more easily.

Edited by _The Doctor__
Link to comment
Share on other sites

What are you talking about? You can search all 512KB of that BIN image for the string 'MYIDE' and you'll only find it in the MYIDE OS ROM itself (as part of 'FDISK for MYIDE'). The screenshot I posted does not depict 'left behind' data, but the raw menu data as it appears in the hex editor.

 

I can assure you I didn't set out to 'make life more difficult' when first opening the dumped ROM in a hex editor. I expected to find the raw data for the menu, easily understand how the entries were organised and thus the order of the actual OS ROMs on the chip, and proceed to edit the thing accordingly. On the other hand, since giving up, I have heard nothing but how easy this task actually is from others (some of whom have little or no experience of a hex editor), so presumably I was dealt a bad hand with this particular ROM.

  • Like 1
Link to comment
Share on other sites

I'd say yes you were dealt a bad hand. Which is kind what was stated when sometimes you don't know what has happened to a thing. As for who knows how to use a hex editor? Let that person identify themselves for hanging I mean well if they haven't used a hex editor... seriously.... Having used hex editors since 1983 various very stupid things (like kilroy was here on dodgy software for transfer) or better things like smart card correction for other purposes. I wonder who the comment was directed at and for what purpose. I think most folks want to learn. I'd think that's a better idea than 'you can't have any ice cream' 'you don't know how to scoop it'

 

I get it, you don't like something. If you did you'd make a program for the everyday user to do it all in a convenient way. I am sure Steve could have done the same. At the time he didn't and probably had his reasons. It's great that all these many years later there are easy flash in circuit items that have come along. No reason to constantly come up with peaves about hardware that come along many many many years ago.

Edited by _The Doctor__
Link to comment
Share on other sites

I programmed FJC's ROM into a blank chip I ordered specifically for messing with the 32-in-1... And all I could get was a green-screen on powerup, same as if there was no OS rom present at all.. Then I worried that I put the PLCC in backwards or something, but it was correct. I then programmed the same chip with my original dump, and it works just fine. So I know the new chip is good at least...

 

Which makes me wonder why mine would be incompatible with FJC's ROM ?? Different hardware?? Is the dump bad? Anyhow.. Attaching my ROM for you to try.

 

Here is my menu options of my ROM as seen from the Atari:

post-53052-0-69849700-1542607477_thumb.jpg

 

 

Note only 31 entries in that menu...

 

Heh, yeah, the 32nd OS is the OS Menu Selector, and the not-so-obvious "APE Remote Control System v2" if you hold Option+Select on system power on:

post-53052-0-95856600-1542607467_thumb.jpg

Another 32-in-1.zip

  • Like 1
Link to comment
Share on other sites

I seem to recall in discussions with Jon, that the one I sent him for examination had a peculiarity all of its own.

I may be confused here, but I think it was down to it being an Amic chip and a compatibility issue with these.

 

Apparently they (Amic) will only work with the boards they were "built on".

 

So essentially, an Amic only works with an Amic build, and all others won't work with Amic built (boards).

Is that the gist of it Jon?

 

 

what do you get if you run (my) 32-in-1 file - that Jon dumped - through your Hex Editor?

Edited by Guest
Link to comment
Share on other sites

what do you get if you run (my) 32-in-1 file - that Jon dumped - through your Hex Editor?

I see the same thing Jon did in the hex editor... Text for entries that don't match up with what's on the screen... For example.. the text "Arabic XL OS" in his screen shot is not found in his/your ROM dump anywhere - but "ARABIC XL/XE" is consistent on screen and in the ROM in my dump... Hence why I'm wondering about the integrity of the dump...

 

My flash EPROM from AtariMax is an AMD AM29F040B-150JC, and the ebay one I got is same, but -120JC V. Which AMIC chip is it? I would hope the ROM data would remain compatible, even if the board was redesigned at some point to use a different flash chip...

 

EDIT: ...... And what happens if you program your chip with my BIN?

Link to comment
Share on other sites

Well last bank versus first bank on cold start might be the issue.. try setting bank bits to 7F (127) on init. if that doesn't work try zero... but don't do it for every bank we want it to stay in bank where it's selected on warm starts and resets.... init just on config/power up.

 

Something still don't look right... so it's probably fubar... time to rebuild it.

 

There is either a PIC or Gal chip that could be reprogrammed for whatever flash chip is in use as another alternative it should match the whichever cold start bank the flash chip starts in as well... I think that more than anything is why he would say just send it in for a swap if there were any issues initially. Reprogramming the gal/pic was considered beyond the scope a normal user would be able to do, so not much else to say about that. While Jon, Nezgar, or myself can do these things having the programmers and such. Most users don't.

Edited by _The Doctor__
Link to comment
Share on other sites


Which AMIC chip is it?

 

Here's a photo of the Amic ROM from Martin's board (thanks Martin):

 

post-21964-0-13749900-1542629461_thumb.jpeg

 

I flashed the dump from this chip to an SST and AMD flash ROM and they both resulted in a green-screen hang on boot. Flashing the same dump back to the Amic ROM and putting that flash ROM back in the device resulted in a working device. If the Amic dump I posted earlier was corrupt, my memory of flashing it back to the Amic which is now in Martin's working board would have to be incorrect. Not entirely impossible, but having worked on several 32-in-1 modules in the past and found them to work only with the flash ROM type they shipped with, I wonder if there may be another explanation. Sadly I don't have the device (nor any 32-in-1) here; if Martin wants to send it back so I can verify the ROM dump, I'd be happy to do so.

 

Alternatively, someone could simply try uploading the BIN to Steve's online editor and see a) if it's rejected by the editor and b) if it can be edited, and what changes occur to the data following edits.

 


So essentially, an Amic only works with an Amic build, and all others won't work with Amic built (boards).
Is that the gist of it Jon?
Unless the BIN is corrupt, yes.

No reason to constantly come up with peaves about hardware that come along many many many years ago.
Please stop misrepresenting my commentary. People should purchase whatever they like, but they should also be aware of the relative pros and cons of devices which incorporate similar functionality. Apropos the widely held belief - even among those who do not profess to be 6502 programmers or even to have familiarity with hex editors - that the 32-in-1 is easy to customise. Even in the event I was somehow saddled with a bad ROM dump, the editor for the 32-in-1 is well hidden and password protected. You later mention PIC programming, etc, being the preserve of a select few: this exclusivity also applies to the 32-in-1 ROM editor, which is 'eyes only' for a handful of people. Nevertheless, I would not invest time in creating an editing tool for the 32-in-1 precisely because one already exists, and because the requirement to customise the device is extremely niche. We are not dealing with the Rosetta Stone here: it's a boot menu for an OS changer. Nevertheless we're now into week three or so of an extended discussion straddling two forums. Hurling speculation about uninitialised memory and unerased sectors (which would resist reprogramming anyway unless all locations read $FF) into the discussion is unhelpful. The variable factor here is not whether someone pre-edited the ROM or whether junk exists in empty spaces, but the validity of the dump itself, which I am now beginning to doubt (thanks to my findings apparently holding no weight whatsoever) but have no means of verifying.
I was about to suggest loading the BIN I posted above into the online editor, but now that I try this myself, I can see no obvious means of doing so (i.e. of loading an existing ROM dump into the online editor for the purpose of editing it). If this is indeed impossible, it is hilarious. :)

 

  • Like 1
Link to comment
Share on other sites

we have the login.

 

this is not just about swapping OSs in/out of the menu, is also about

■ what it's ossible to do with the menu itself, layout/colours etc

■ the peculiarities of changes in PLCC chips and incompatibility between Amic and other brands.

Link to comment
Share on other sites

Question aimed mainly at Jon but anyone can answer..

 

As said in another thread I was thinking of getting a 32 in 1 but Jon kindly pointed out a few very helpful details and suggested the U1MB as a more than viable alternative. I said I'd read up but the purchase would be put back does to car fines, well I've read up and watchedthe very nice Nir Dary demonstration video and the ultimate looks really great but the single question is, are there any compatibility problems I should be aware of once its in the 130XE, not really worried about other exotic hardware add ons, more with booting games / utils etc that the U1MB could directly affect.

 

Obviously if its set to a wrong OS there could be issues, that I can understand and sort, I purely mean stuff that the U1MB can interfere with by its working?

 

Here's hoping for a really handy "there's nothing it affects"...

 

Really appreciate any help...

 

Paul..

 

Loads of edits as I got carried away with the word nice in the post, 6 uses...Madness :)

Edited by Mclaneinc
Link to comment
Share on other sites

...the single question is, are there any compatibility problems I should be aware of once its in the 130XE, not really worried about other exotic hardware add ons, more with booting games / utils etc that the U1MB could directly affect.

There should be nothing to worry about where compatibility is concerned. The U1MB is controlled by a single register in the PIA memory space which is locked before the OS starts, so it's essentially invisible aside from the optional features such as extra RAM, SpartaDOS X, PBI HDD, etc. You can turn all of that stuff off.

 

If you want to know about extreme corner-case anomalies such as 'Non-canonical PIA access incompatibility', you can read about them in Avery's Hardware manual, but they are a 'don't care' as far as day to day use and 99.99 per cent of software is concerned.

Edited by flashjazzcat
  • Like 2
Link to comment
Share on other sites

I seem to recall in discussions with Jon, that the one I sent him for examination had a peculiarity all of its own.

I may be confused here, but I think it was down to it being an Amic chip and a compatibility issue with these.

 

I didn´t own one of these 32-in-1 OS switchers, so just "something completely different" (by Monty Python :) )... I´m remembering such problems when Steven changed the Flash-ROMs from AMIC to AMD - new, special flash write routines were needed to make the newer AtariMax 8 MBit Flashcarts work fine.

 

How the changed (selected) OS is stored? Does anybody knows this? Maybe the selection is stored in the "first" OS (the menu) itself. Maybe his code checks the access to the flash-chip. This would be one reason why changing to another flashchip won´t work.

 

Just an idea...

Link to comment
Share on other sites

There should be nothing to worry about where compatibility is concerned. The U1MB is controlled by a single register in the PIA memory space which is locked before the OS starts, so it's essentially invisible aside from the optional features such as extra RAM, SpartaDOS X, PBI HDD, etc. You can turn all of that stuff off.

 

If you want to know about extreme corner-case anomalies such as 'Non-canonical PIA access incompatibility', you can read about them in Avery's Hardware manual, but they are a 'don't care' as far as day to day use and 99.99 per cent of software is concerned.

 

Thank Jon, nope, that's all I needed to know re its functionality...I'm not a mega utility user and I don't have any upgrades as it stands in the 130XE so as long as it places nicely with it and games etc work then I'm more than happy..

 

Thank you..

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...