Re: [stella] Dumping ROM images

Subject: Re: [stella] Dumping ROM images
From: "Russell Babylon" <rbabylon@xxxxxxxxxxxx>
Date: Sun, 13 Mar 2005 11:37:11 -0500
OW! OW!  stop twisting my arm.  I see your point.  When I dumped these I
tried them out on PCAE and they worked so I didn't think any more about it.
Things like this just make the Atari scene more interesting don't you think?

----- Original Message ----- 
From: "Eckhard Stolberg" <Eckhard_Stolberg@xxxxxx>
To: <stella@xxxxxxxxxxxxxxxxxx>
Sent: Sunday, March 13, 2005 5:13 AM
Subject: Re: [stella] Dumping ROM images

> > It will work with bank switch games at least for the 'simple' bank
> > switching
> > schemes.   As I said in my original message, and you alluded to below, I
> > dumped an 8K game.  I did not mention that I had some LEDs hooked to the
> > data lines so I could literally see what data was being accessed in the
> > ROM
> > and I had a pot for the timing resistor on the 555.  I would set the pot
> > to
> > a high resistance so it was clocking at a verrrry slow speed.  Sometimes
> > the
> > ROM would power up in bank one and sometimes in bank two.  I read each
> > bank
> > out separately and then made a quess as to which one was bank one and
> > concatenanted the second file to the first.  I believe the data after
> > hot spots in the ROM was the same for both banks, even if it wasn't you
> > could manually edit the few remaining bytes if need be.  Thinking about
> > the vectors after the hot spot would have to be the same, at least for
> > start up address, if the ROM was to power up consistently.  As I said
> > originally this was a very simple method that required a fair amount of
> > knowlege as to the nature of the ROMs and their data structure.  It was
> > not
> > a plug and chug.
> OK, this would allow you to read the major part of both banks.
> But you still would have a problem with reading the system vectors
> for the first bank, because if you read all addresses from $1000
> to $1fff, you are always accessing $1ff9 before you are are reading
> the system vectors from $1ffa to $1fff. Therefore the cart logic
> would always switch to the second bank before you can read these
> addresses. If you could start the reading at $1ffa and have the
> addresses wrap around to $1000 at $1fff, your method might work.
> Most games actually have different system vectors in both banks.
> They only have a initializing routine in one bank. In the other
> bank they only have a small routine that will switch into the first
> bank and jump to the real initializing routine there.
> Of course you could disassemble the code for the first bank in an
> 8K game with F8 bankswitching, and try to find the entrance point
> for the system vectors. But apparanetly someone didn't do that
> for the two games you mentioned. ;-) And if a game used the
> unneeded IRQ and BRK vectors for small data tables, you would have
> a hard time guessing the correct values.
> I don't know if these two ROMs were the ones you dumped, but
> several people did send these two binaries to us because they
> didn't work with older versions of z26. We found out that they
> didn't work because the system vectors in the first bank (we
> started all bankswitched games in the first bank) were the same
> as the ones in the second bank, which pointed to bad routines
> in the first bank. We figured it might be better to special case
> these two games with their own bankswitching, because it's
> difficult to replace games that are already in circulation, and
> there might be other games with the same problem. But so far
> Moonsweeper and Sir Lancelot were the only games that people
> complained about because of this. ;-)
> Ciao, Eckhard Stolberg
> Archives (includes files) at
> Unsub & more at

Archives (includes files) at
Unsub & more at

Current Thread