Re: Re: [stella] StellaX PAL detection

Subject: Re: Re: [stella] StellaX PAL detection
From: "Eckhard Stolberg" <Eckhard_Stolberg@xxxxxx>
Date: Wed, 30 Jan 2002 23:46:59 +0100
First a quick note to Glenn:

Brad doesn't seem to have abandoned Stella. He is still
adding stuff to the Stella project at sourceforge. Things
are going a bit slowly at the moment, so I don't know many
changes the Windows port is going to see for the next release,
but I'm confident that eventually it's goint to happen.

> Uhm... yet another Stella mailing list? Where is that?

You can find information about the Stella project and
links to the mailing lists at

> Say: Why don't you detect paddles that way too? Apart 
> from that one Omega Booster thing game, what would 
> prevent a proper paddle auto-detection?

Well, the keypad games and the Compumate keyboard also
access the paddle bits. Also some games read from these
ports accidentally. And a game might not read the paddle
until the gameplay has been started with the reset key,
so a reliable auto detection for paddle games would
probably be impossible.

> Since the functionality of the class I designed would 
> load a binary, I wasn't too sure what would happen with 
> multiloads. I've seen functions for that near the ones 
> that identify the BINs. So I don't know if something 
> like getNextBlock() was necessary for SC-Games. Or a 
> pointer to the current page/offset or something.

In Stella the different bankswitching schemes keep their
own data. When the emulator is initiated with a certain
bankswitching scheme installed, the data gets copied from
the loading buffer to the internal buffer for that BS scheme.
So there shouldn't be any problems with autodetecting the
ROM image through it's checksum.

> 1. One general idea is to provide a pure/uptodate 
> Windows emulator, that combines the best of both worlds.
> My idea was to re-port Stella to DirectDraw/Sound/Input 
> and to add things from Z26 into it, where Stella just 
> isn't accurate enough. 

If you want to make Stella faster and more acurate,
then you are probably more than welcome to join the
official development team. ;-)

And don't forget, that Stella is still under copyright
by Brad. You are still not allowed to distribute changed
versions of the emulator or the core source code. So if you
want to create your program for anyone but yourself,
you would need Brads approval.

> 2. That emulator is for cartridge developers. Therefore 
> it must not support SC Pitfall 2 and 20 different BS 
> schemes. It may, but it needs not. Generally I'm gonna 
> throw out all stuff that's making the thing unecessary 
> bloated like supporting single games like Pitfall 2 or 
> extra RAM or Mindlink controlers, or...stuff like 
> that...

I don't think this is going to gain you much. The main
reason for the huge size is the C++ nature of the emulator.
The different bankswitching schemes etc. don't add too much
size to it.

The other reason was that Stella had an outdated version
of the file compiled into it. This was fine
as long as there were regular updates, as you didn't need
an extra file to run most games. But nowadays when everyone
uses his own version of the file anyway, that is
just a waste of space, so Steve recently removed the build-in
properties. You now need to provide a properties file for
those games that don't work with the default values.

> 4. I'd like to integrate a debugger, DASM, DiStella as 
> well as an editor for text and probably editors/imports 
> for graphics/sounds.

I think Brian recently posted here that he had started
to add a debugger to Stella. Brad now added the nessessary
hook-ups for that to the official version, so that we might
see an official debugger in Stella in one of the future

As for all the other tools, I think it would be best to
design them as seperate programs and integrate them
through the text editor. That way you could delegate the
work for certain parts to other people. Also it would
help to keep the size small, if you don't need all the
tools in a certain situation.

> 5. I'd like to have a certain set of games built-in. 
> (Guess which... :-))

So you want to throw out support for certain bankswitching
schemes, because they use too much space, and then you want
to blow up the emulator again by adding your own games to it?
I guess everyone has his own priorities. ;-)

Ciao, Eckhard Stolberg

Archives (includes files) at
Unsub & more at

Current Thread