Jump to content
IGNORED

XEGS ROM Geometry


Recommended Posts

I've just fixed an XEGS with a bad ROM and MMU, and have got it going temporarily by flashing four copies of the XEGS OS to a 27C128. Naturally it boots straight to the Self-Test, since there's no BASIC or Missile Command. I can't seem to find out what the ROM layout is supposed to be, however, on a 32K chip (i.e., is it BASIC, Missile Command, OS ROM, or OS ROM, Missile Command, BASIC?). Needless to say I've also been unable to locate a complete 32K dump of the XEGS ROM, otherwise I wouldn't be asking how to manually assemble one. :)

 

Link to comment
Share on other sites

I found this 2016 post by Rybags that contains an untested 32KB XEGS ROM dump, and followup enlightening (as usual) posts by phaeron :)

http://atariage.com/forums/topic/259483-xegs-game-rom/?p=3639787

 

The order of components can probably be easily determined by inspecting the dump.

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

It should be OS ROM, Missile Command then Basic.

 

OS ROM being 4K that would appear at $C000 then the 2K of Self-Test, then the 2K FPP.

Then the 2K character set and 8K high part of OS ROM.

 

This is from an image called xegs_alt that I've got configured in Altirra which it recognises as XEGS firmware.

 

Easy eyecatcher signs of what part of the Rom you're looking at:

The low part of the OS Rom should have a bunch of zero bytes just before offset C00 as well as the 8 zero bytes @ C00 for start of the second character set.

Similarly the high part of the OS Rom will have 9 zeros then several hex 18, 00, 18, 00 (space then ! character)

 

The Missile Command game is actually only 6K, so there will be 2K worth of leading zeros.

Game and Basic ROM should have the normal bunch of vectors and flags at offset 1FFA in their parts of the image.

  • Like 1
Link to comment
Share on other sites

That´s quite easy - but the organisation is strange.

 

ROM offsets:

 

$0000-$1FFF - 8 KB Missile Command

$2000-$3FFF - 8 KB BASIC

$4000-$7FFF - 16 KB Operating System

 

The MMU is a little bit different from the XL one, it uses the PB6 bit for selecting Missile Command / BASIC and managed the addressline A13 for a working O.S. access.

 

I´ve made an standard XL MMU for usage of standard 16 KB O.S. (so no problems with memory expansions using PB6). Here´s the code:

CHIP   MMU_XEGS   GAL16V8   COMPLEX_MODE

A11  A12  A13  A14     A15  MAP  RD4  RD5  REN  GND
REF  S5   PB6  ROMSEL  OS   CI   IO   BE   S4   VCC

/S4  = /A13 & /A14 & A15 & RD4 & REF;
/S5  =  A13 & /A14 & A15 & RD5 & REF;

/IO  = /A11 & A12 & /A13 & A14 & A15 & REF;

/OS  =  A13 &  A14 &  A15 &  REN &  REF                       /* $E000-$FFFF */
     + /A12 & /A13 &  A14 &  A15 &  REN & REF                 /* $C000-$CFFF */
     +  A11 &  A12 & /A13 &  A14 &  A15 & REN & REF           /* $D800-$DFFF */
     +  A13 & /A14 &  A15 & /RD5 &  /BE & REF                 /* Atari-Basic */
     + /A11 &  A12 & /A13 &  A14 & /A15 & /MAP & REN & REF;   /* Selbsttest */

/CI  = /A13 & /A14 &  A15 & RD4 & REF
     +  A13 & /A14 &  A15 & RD5 & REF
     + /A11 &  A12 & /A13 & A14 & A15 & REF
     + /OS
     + /REF;

ROMSEL = A13 &  A14 & A15
       + A13 & /A14 & A15 & /BE;
 

BR Jurgen

MMU_XEGS ohne PB6.jed

  • Like 7
Link to comment
Share on other sites

OK, well that's a bit weird.

 

The ROM I posted in that thread Nezgar just pointed to has MC, Basic then the OS.

 

"Logically" you'd probably do it that way but given the MMU is producing the select signals for the 2 msbs to the ROM it sort of doesn't matter - in theory they could have ordered it any way they wanted.

Link to comment
Share on other sites

Thanks all. I'd noticed the MMU's RS (ROM select) pin on the schematic, connected to A13, but couldn't figure out the organisation on the chip. Nice thing about putting this on an EPROM is that the customer can have Altirra BASIC and a different game if they want. :)

 

@Jurgen: thanks for the MMU GAL code as well. Most useful, and I almost had to resort to a GAL in order to repair this machine.

  • Like 1
Link to comment
Share on other sites

For what it's worth: the info I have about the XEGS ROM I have (same CRC32 as the one mentioned above)

 

 

ATA_XEGS.ROM = ATARI XEGS O.S.

8K : Missile Command
8K : BASIC Rev.C
16K : ATARI OS. Rev.4

Match: XEGS.ROM (Freddy Offenga)

CRC32: D50260D1

  • Like 1
Link to comment
Share on other sites

Unfortunately this XEGS was sent direct from Hell, since it worked (with an EPROM OS), was elaborately modded with a DIN-5 monitor jack and Y/C video, booted to show a beautiful display, and promptly died. It's booted about twice out of 100 tries since, while I scour the board for shorts and breakages. :(

Link to comment
Share on other sites

My N.O.S. XEGS came with a faulty O.S. out of it's factory sealed box. After putting in an EPROM, with 4 times Rev4 O.S. in it just to get it running, it turned out to be a very flaky bitch. It probably has some more hidden "features" I don't know about.

 

Have another one from the same batch but don't know how this one behaves as I never unpacked it.

 

Judging outside views from a third one, this one probably works o.k, or at least did for a period of time. Never opened it up, or even connected the thing to see if still works.

Link to comment
Share on other sites

A friend of mine got an XEGS for Christmas in 1987 or so and after his mother returned two or three of the things which arrived DOA from the catalogue company, his dad took him to Curry's and bought him a 65XE.

 

Just took ANTIC off this one and put a socket under it since it seemed to be the last VLSI which would stop the system dead in its tracks, but it didn't help.

Link to comment
Share on other sites

Not sure it will help at all but I've found that

OS eprom speed need to be 200ns and above or they get

flaky enough to behave as if they aren't even there.

Sort of like yours? Had several OS projects fail

and then discovered this anomaly with no issues

since. No explanation for it of course.

  • Like 1
Link to comment
Share on other sites

Unfortunately this XEGS was sent direct from Hell, since it worked (with an EPROM OS), was elaborately modded with a DIN-5 monitor jack and Y/C video, booted to show a beautiful display, and promptly died. It's booted about twice out of 100 tries since, while I scour the board for shorts and breakages. :(

 

I´ve also had some XEGS with issues like that. The half of issues I can fix with changing the DRAMsm the other with OS-ROM and MMU. it´s strange... I never must change DRAMs (as long the right power supply was used :-D ) at the Atari 130 XE mainboards using 2 (800XE) or 4 (130XE) DRAM 41464 models, but the XEGS - with same DRAM type - has a lot defects.

 

Also the OS-ROM was faulty some times, in the most cases the MMU (PAL16L8) was defect - typically on or more of the outputs can´t sink, they remain at high level forever.

 

My personal thoughts are, that the XEGS - the last production line - was populated with all the sediments Atari found in their production warehouses :-o

  • Like 1
Link to comment
Share on other sites

Not sure it will help at all but I've found that

OS eprom speed need to be 200ns and above or they get

flaky enough to behave as if they aren't even there.

Sort of like yours?

I've lacked faith in these EPROMs since the get go, after my TL866 failed to write a TMS 27PC512 which would have been a perfect fit. I then resorted to windowed EPROMs. I may simply pull the OS ROM of another XEGS board here to definitively rule out the ROM as a source of issues. Thanks for the tip!

 

I´ve also had some XEGS with issues like that. The half of issues I can fix with changing the DRAMsm the other with OS-ROM and MMU. it´s strange... I never must change DRAMs (as long the right power supply was used :-D ) at the Atari 130 XE mainboards using 2 (800XE) or 4 (130XE) DRAM 41464 models, but the XEGS - with same DRAM type - has a lot defects.

 

Also the OS-ROM was faulty some times, in the most cases the MMU (PAL16L8) was defect - typically on or more of the outputs can´t sink, they remain at high level forever.

At first I was convinced the thing had taken a hit from a Commodore PSU, and therefore aimed for RAM and MMU first. It's only later I noticed corrosion at the front edge of the board (looks like all the console keys are kaput), and evidence of someone working on the board beforehand (although the poor soldering appears confined to innocuous areas around the joystick ports).

 

My personal thoughts are, that the XEGS - the last production line - was populated with all the sediments Atari found in their production warehouses :-o

I agree. It's a shame, since the component count is comparatively low and there is a lot of copper on the board, but it appears what's soldered to it is basically junk.

Link to comment
Share on other sites

I have always been a fan of the xegs. I have quite some of these friendly looking cases with their colourful buttons and external keyboard. The ones I have also have a very good and crisp default video output.

 

I hated the power switch and the lack of pbi though. The space inside for upgraded is nice.

 

I haven't had a single bad experience with my xegs's although that does not mean a lot. I haven't experienced a lot of trouble at all with a8. MY worst Atari was a PAL 800xl with 256kb upgraded using a handful of TTL-IC's and a lot of wires. In combination with a black box this machine was meant to crash and be unstable. Except for this, lots of success stories here... even with the xegs.

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

We've both been quite lucky, then, since I have two working XEGS machines here too. One even survived a 128K upgrade. As I say: I have no particular complaints about the XEGS motherboards, since they have high thermal mass and don't seem to part with traces easily. But the ICs and fittings appear to have varied in quality from one batch to the next.

 

In any case: I swapped the OS ROM from my own machine. No difference. Even if I were able to fix this machine, it's no longer a cost-effective proposition.

  • Like 1
Link to comment
Share on other sites

  • 2 years later...
On 4/5/2018 at 8:04 AM, tf_hh said:

That´s quite easy - but the organisation is strange.

 

ROM offsets:

 

$0000-$1FFF - 8 KB Missile Command

$2000-$3FFF - 8 KB BASIC

$4000-$7FFF - 16 KB Operating System

 

The MMU is a little bit different from the XL one, it uses the PB6 bit for selecting Missile Command / BASIC and managed the addressline A13 for a working O.S. access.

 

Your replacement MMU version below doesn't require PB6, and has freed it up for other uses (e.g., extended ram). Since PB6 was previously used for doing some additional ROM selection, has this functionality been sacrificed in the XEGS?

 

On 4/5/2018 at 8:04 AM, tf_hh said:

I´ve made an standard XL MMU for usage of standard 16 KB O.S. (so no problems with memory expansions using PB6). Here´s the code:


CHIP   MMU_XEGS   GAL16V8   COMPLEX_MODE

A11  A12  A13  A14     A15  MAP  RD4  RD5  REN  GND
REF  S5   PB6  ROMSEL  OS   CI   IO   BE   S4   VCC

/S4  = /A13 & /A14 & A15 & RD4 & REF;
/S5  =  A13 & /A14 & A15 & RD5 & REF;

/IO  = /A11 & A12 & /A13 & A14 & A15 & REF;

/OS  =  A13 &  A14 &  A15 &  REN &  REF                       /* $E000-$FFFF */
     + /A12 & /A13 &  A14 &  A15 &  REN & REF                 /* $C000-$CFFF */
     +  A11 &  A12 & /A13 &  A14 &  A15 & REN & REF           /* $D800-$DFFF */
     +  A13 & /A14 &  A15 & /RD5 &  /BE & REF                 /* Atari-Basic */
     + /A11 &  A12 & /A13 &  A14 & /A15 & /MAP & REN & REF;   /* Selbsttest */

/CI  = /A13 & /A14 &  A15 & RD4 & REF
     +  A13 & /A14 &  A15 & RD5 & REF
     + /A11 &  A12 & /A13 & A14 & A15 & REF
     + /OS
     + /REF;

ROMSEL = A13 &  A14 & A15
       + A13 & /A14 & A15 & /BE;
 

BR Jurgen

MMU_XEGS ohne PB6.jed 1.11 kB · 56 downloads

 

Thanks for any info you can provide.

 

Link to comment
Share on other sites

10 hours ago, mytek said:

Your replacement MMU version below doesn't require PB6, and has freed it up for other uses (e.g., extended ram). Since PB6 was previously used for doing some additional ROM selection, has this functionality been sacrificed in the XEGS?

So normally PB6 is the Missile Command enable bit on the XEGS, but only if BASIC is not enabled. (0 for enable, 1 for disable.) I think tf_hh's XEGS MMU modification is mostly to allow a 16K EPROM with OS only to work reliably in the XEGS, if you don't have a replacement with the full 32KB like a 27256. (But then I guess both no BASIC or game would be available) And also to prevent weirdness like losing 8K of RAM to partial OS being mapped to the cartridge area when no keyboard is attached.

 

It appears the "Game" portion of the XEGS ROM (Missile Command) would be the only loss with a full 32KB ROM. This modified MMU would no longer take any action based on PB6. This would be convenient for a memory upgrade to use the PB6 without having to worry about the Missile Command ROM banking in at $A000-$BFFF whenever it's set to 0.

 

Most modern memory upgrades already latch or disable (set to 1) PB1 and/or PB7 while xram is enabled, so an XEGS-Aware memory upgrade should do the same for PB6 as well. If installing a non-PB6 aware memory upgrade that uses PB6, this MMU hack could come in handy... I'm not sure if you could still force-enable missile command (or an alternative BASIC 8K ROM) with an external switch.

  • Thanks 1
Link to comment
Share on other sites

24 minutes ago, Nezgar said:

It appears the "Game" portion of the XEGS ROM (Missile Command) would be the only loss with a full 32KB ROM. This modified MMU would no longer take any action based on PB6. This would be convenient for a memory upgrade to use the PB6 without having to worry about the Missile Command ROM banking in at $A000-$BFFF whenever it's set to 0.

That works for me, so long as the 8K BASIC section of the ROM is still activated when desired, I don't really care or need the 8K GAME allocation.

 

One last question. Can pin-13 of the MMU (formally PB6) be left floating or should it be tied to either ground or VCC?

 

Edit: when I say MMU, I'm referring to the GAL with Jurgen's code.

 

Link to comment
Share on other sites

32 minutes ago, mytek said:

One last question. Can pin-13 of the MMU (formally PB6) be left floating or should it be tied to either ground or VCC?

I'm not sure about leaving pin 13 floating, but if you tie pin 13 to Vcc (with the original connection to PB6 severed for use elsewhere) shouldn't the game ROM be effectively permanently disabled even with the original MMU?

  • Like 1
Link to comment
Share on other sites

10 hours ago, Nezgar said:

I'm not sure about leaving pin 13 floating, but if you tie pin 13 to Vcc (with the original connection to PB6 severed for use elsewhere) shouldn't the game ROM be effectively permanently disabled even with the original MMU?

 

10 hours ago, Rybags said:

If PB6 was to be redefined then why not just add a hard switch that gives you an 8K option to normal Basic.

Such examples might be a game or Atari's AsmEd cart.

 

Both good points. So essentially pin 13 on the 'stock' XEGS MMU could be labeled as /GE for Game Enable, similar to how pin 18 is designated as /BE for Basic Enable. Then a pull-up resistor could be connected to the /GE input combined with a switch going to ground.

 

And if I understand the logic correctly things should look like this?

 

MMU-LOGIC.png.ba7e11389d360fedcbaf62853f3beeef.png

 

If this is all there is too it, that's great ? .

 

I looked up the price on a XEGS MMU and OSROM at Best and they are both kind of pricey (especially the MMU).

 

MMU_and_OS.png.2df55785b38817bcc1c84eeef2ebc56f.png

 

Of course both items can be replaced with a GAL (MMU) and an EPROM (OS), which can be gotten for cheap from eBay.

 

Does anyone have the JED file for the stock XEGS MMU? And while we're at it, also the XEGS ROM code?

 

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