Stella Version 2.2 released

[Shannon]

Well after farting around a little bit the following settings seem to be satisfactory.

 

freq = 31400

tiafreq = 15700

 

It does cause some minor popping sounds in ms.pacman, but the "ghost" sounds in Jr. Pacman are back!

 

I tried setting clipvol to true but then I got no sound at all.

 

Regardless. I don't have a clue technically how those params are supposed to work/interact, but the above worked for me.

[bluetriforce]

Can stella have 100% perfect emulation with 64 bit processor for windows in the future? How fast a Computer has to be to have 100% perfect emulation?

[+stephena]

Can stella have 100% perfect emulation with 64 bit processor for windows in the future?

The issue isn't the type of CPU, or the OS you use. Stella has already been ported to 64-bit systems for, well, forever. SGI, Sparc, etc have unofficial ports, and I personally develop it on a 64-bit Linux system. It's just C++ code, that doesn't care what OS or CPU you have (for the most part).

How fast a Computer has to be to have 100% perfect emulation?

I'm not sure, since I don't think it's ever been tried for a 2600 emulator (I guess you'd have to emulate the chips at the transistor level to get 100% functionality). The main problem with Stella's 'less than accurate' emulation is the same reason for all other emulators; there aren't enough people reporting bugs, and even when they are reported, there aren't enough people working on the project to fix them. The latter is much more important, since we currently have a list of bugs that's getting longer, and less and less people to actively work on the project.

 

If this sounds ominous to you, then you'd be right. If we don't get some steady help soon, the project will slow down even more ...

 

Edit: Oh, and one other thing I forgot, that's actually related to number of developers; Stella is a cross-platform emulator, and as such, some concessions have to be made for it to work everywhere. The only other solution is to have complete forks for each different platform, as it was in the past. But seeing as we don't have the manpower to properly handle the current codebase, I can't see how making more ports would help.

Edited April 18, 2006 by stephena

[Zach]

Please note a slight bug that causes Four-Play to display incorrectly...

Update: I fixed the Four-Play kernel by setting the B bit myself with PLP, and that is safer than assuming the Atari's state on startup. Don't know why I didn't think of it before.

[pkblack]

It be better if all the emulator guys would agree to all work on one emulator instead of reinventing the wheel each time wouldn't it??

[JL]

It be better if all the emulator guys would agree to all work on one emulator instead of reinventing the wheel each time wouldn't it??

 

I do not agree. Through the diversity of different emulators for a given system, new and fresh ideas surface. It allows for approaches from different angles and no ideas are surpressed. Plus "competition" is good and healthy and encourages the developers to "one-up" the other guy. Which we all benefit from.

[+batari]

It be better if all the emulator guys would agree to all work on one emulator instead of reinventing the wheel each time wouldn't it??

 

I do not agree. Through the diversity of different emulators for a given system, new and fresh ideas surface. It allows for approaches from different angles and no ideas are surpressed. Plus "competition" is good and healthy and encourages the developers to "one-up" the other guy. Which we all benefit from.

z26 and Stella are not really in competition so much. Plus, the developers of the two emulators do not try to "one-up" each other - they share ideas, and in some cases, code.

 

Stella is intended as a portable multi-platform emulator and is written in C++. It has been ported to many different systems. In doing so, the codebase must be more general, so it is slower than z26. In turn, some games do not even run full-speed on my 1.7 GHz PC.

 

z26, OTOH, is written for the PC only, as much is in x86 assembly. It is much faster, more efficient and has slightly better compatibility than Stella. In z26, basically all games will run full-speed even on old computers, but you'll probably never be able to use z26 on a PSP, for instance.

[+stephena]

z26 and Stella are not really in competition so much. Plus, the developers of the two emulators do not try to "one-up" each other - they share ideas, and in some cases, code.

Yes, this is true. Also, there's not really much competition, since there isn't much active development on either one at this point.

Stella is intended as a portable multi-platform emulator and is written in C++. It has been ported to many different systems. In doing so, the codebase must be more general, so it is slower than z26. In turn, some games do not even run full-speed on my 1.7 GHz PC.

This is also true, but I think there's a pathological case when games don't run on a 1.7GHz PC. I'd be interested in feedback on such games, since my testing on systems as slow as 500MHz show no problems. Most of the slowdowns in Stella come from rendering an image onscreen, not in the emulation itself. We're working on ways to improve that. So aside from certain corner cases (Pitfall2, for example), the speed of the emulation itself hasn't been an issue for quite some time.

z26, OTOH, is written for the PC only, as much is in x86 assembly. It is much faster, more efficient and has slightly better compatibility than Stella. In z26, basically all games will run full-speed even on old computers, but you'll probably never be able to use z26 on a PSP, for instance.

Again, I'd be very interested in having you beta-test some possible solutions to these problems. Stella for the GP2X runs on a 200MHz machine with no slowdowns (except for Pitfall2), so I know the codebase can be fast. In some cases, it's an apples to oranges comparison anyway, since z26 doesn't have 3x and 4x rendering modes, while Stella does. How do both compare on your PC when each one is run at 1x or 2x?

Edited April 23, 2006 by stephena

[+batari]

Again, I'd be very interested in having you beta-test some possible solutions to these problems. Stella for the GP2X runs on a 200MHz machine with no slowdowns (except for Pitfall2), so I know the codebase can be fast. In some cases, it's an apples to oranges comparison anyway, since z26 doesn't have 3x and 4x rendering modes, while Stella does. How do both compare on your PC when each one is run at 1x or 2x?

Most games indeed run just fine. Some (like my own game Superbug) run slow only at 3x or 4x. But one of the most egregious examples I have come across is the binary from Paul Slocum's music kit. It runs slow no matter what video settings I use, while in z26 it runs like a top.

songmain.bin

[+stephena]

Again, I'd be very interested in having you beta-test some possible solutions to these problems. Stella for the GP2X runs on a 200MHz machine with no slowdowns (except for Pitfall2), so I know the codebase can be fast. In some cases, it's an apples to oranges comparison anyway, since z26 doesn't have 3x and 4x rendering modes, while Stella does. How do both compare on your PC when each one is run at 1x or 2x?

Most games indeed run just fine. Some (like my own game Superbug) run slow only at 3x or 4x. But one of the most egregious examples I have come across is the binary from Paul Slocum's music kit. It runs slow no matter what video settings I use, while in z26 it runs like a top.

There seems to be a correlation with games that change 'a lot' onscreen. This is one of them, and it generated the slowdown. Could you try the same ROM, but switch on the phosphor effect (with Alt-p)? On my system, this (unintuitively) speeds up the rendering, even though phosphor indicates a full screen update, and the normal rendering mode is through dirty rects (partial updates only).

 

If this fixes your problem, I think the dirty updater code isn't optimal for you. Are you using Windows? What type of video card? Maybe you could try toggling 'Use dirty rects' in the Video settings in Stella. Feel free to respond by email if you like.

[Albert]

I'm running 2.2 and I'm still seeing problems with the directory listing. For instance, I have four games named:

 

BEAM.BIN

BEAM1.BIN

BEAM2.BIN

BEAM3.BIN

 

They show up in the file viewer as:

 

BEAM.BIN

BEAM.BIN

BEAM.BIN

BEAM.BIN

 

This happens with other files as well, such as ROBOT.BIN, ROBOT1.BIN, ROBOT2.BIN, and ROBOT3.BIN. They all show up in the listing as ROBOT.BIN. I tried clicking on "Options" and then "Reload ROM Listing", but that does not help.

 

Here's a screensot.. You can also see two 'colony7.bin' files, even though one is 'colony7.zip' in the actual directory:

 

 

This is in OS X, btw.

 

..Al

[+stephena]

I'm running 2.2 and I'm still seeing problems with the directory listing. For instance, I have four games named:

 

BEAM.BIN

BEAM1.BIN

BEAM2.BIN

BEAM3.BIN

 

They show up in the file viewer as:

 

BEAM.BIN

BEAM.BIN

BEAM.BIN

BEAM.BIN

 

This happens with other files as well, such as ROBOT.BIN, ROBOT1.BIN, ROBOT2.BIN, and ROBOT3.BIN. They all show up in the listing as ROBOT.BIN. I tried clicking on "Options" and then "Reload ROM Listing", but that does not help.

 

Here's a screensot.. You can also see two 'colony7.bin' files, even though one is 'colony7.zip' in the actual directory:

 

 

This is in OS X, btw.

 

..Al

Try turning on 'ROM Settings -> Browse Folders'.

[freakygeeky]

I run (or am trying to run) Stella 2.2 on a dual Athlon MP 2600+ machine running Windows XP with an ATI Radeon 9700 Pro. The last release that has worked properly on my machine is 2.0.1. The problem is specifically with OpenGL mode. I either get black screens or crashes after I switch from software to OpenGL. I really want the OpenGL mode to work, as that's the only way I can see to get the proper aspect ratio out of the software.

 

Any ideas?

 

Do any of the Stella devs frequent this board? I'd be more than happy to run any diagnostic code or whatnot in an attempt to fix the problem. That is, if I'm not the only one having the problem...

[Albert]

I'm running 2.2 and I'm still seeing problems with the directory listing. For instance, I have four games named:

 

BEAM.BIN

BEAM1.BIN

BEAM2.BIN

BEAM3.BIN

 

They show up in the file viewer as:

 

BEAM.BIN

BEAM.BIN

BEAM.BIN

BEAM.BIN

 

This happens with other files as well, such as ROBOT.BIN, ROBOT1.BIN, ROBOT2.BIN, and ROBOT3.BIN. They all show up in the listing as ROBOT.BIN. I tried clicking on "Options" and then "Reload ROM Listing", but that does not help.

 

Here's a screensot.. You can also see two 'colony7.bin' files, even though one is 'colony7.zip' in the actual directory:

 

 

This is in OS X, btw.

 

..Al

Try turning on 'ROM Settings -> Browse Folders'.

That fixed the problem, but I'd still consider it broken when you don't have "Browse folders" selected.

 

..Al

[Urchlay]

Hey, this is B. Watson, the Stella debugger guy.

 

I created an account last night, just so I could reply to this... Apologies

for the long post.

 

A few comments about non-working items in the debugger.

 

1. As Zach noticed (see his bloggy), this conditional break doesn't work:

breakif *PF2==$00

 

The debugger sees what the CPU would see. Reading from PF2 doesn't return

the value you wrote to PF2 because PF2 is a write-only location... you'll

get whatever garbage value (AKA "bus noise") you'd get if your program

did "LDA $0F" (probably, you'll get $0F, since there's no TIA read-only

register at $0F).

 

2. The TIA Tab:

 

a) I also noticed that, contrary to the docs, the TIA strobe buttons

don't work.

 

Really? I'll look into that...

 

...time passes...

 

...well, the WSYNC strobe at least works. Click it, then do a Step,

then click it again, do a Step, etc... should be obviously working: the

TIA should draw a new scanline for each Step. However, multiple clicks

don't do anything, because the TIA isn't running until you step some code

(the WSYNC strobe won't occur until the emulation starts running again,

and there's no place inside the TIA to "queue up" multiple strobes that

occur between clock cycles).

 

In fact, that's generally true for all the strobes: they don't have any

effect until you step some code, because the TIA is paused while you're

in the debugger. I should make the buttons light up when they're clicked,

then reset them when the emulator runs. That might make their function

a little more obvious...

 

The RESP0 and P1 strobes also definitely work. I just managed to totally

mangle a 6-digit score by hitting RESP0 in the middle of the scanline

 

There's one possible reason why the strobes are working for me but not

for you: I'm using Linux, and you're (probably) using Windows. I can't

really check the Windows version right now (the only Windows box in the

house is being used by my roommate to play "City of Villains", probably

for the next 6 hours non-stop), but I will when I get a chance. Stella

is supposed to be 100% cross-platform, but nothing's perfect.

 

One other thing you might try: see if the latest nightly build from

http://www.hardcoders.org/stella_nightly/ shows the same symptoms. I

haven't changed anything in the debugger since 2.2 was released (or

even since 2.1), but Stephen may have fixed the bugs you found without

me noticing.

 

Also, you can't edit GRPx or PFx directly, either by

(double-)clicking on the little boxes or by directly entering values

in,

 

Huh? I just tried it, double-clicking the boxes, and it worked fine.

There's not really a place to enter GRPx values directly in the TIA tab,

though you can use "poke GRP0 aa" or whatever in the prompt.

 

If you can tell me how to duplicate the problem with setting GRP0 via

the boxes (with a common ROM, breaking at a specific address, etc), I'll

take a look.

 

and the top-line of TIA values is mislabelled - according to the

docs, they should show the values read by the CPU but when you click

on one of them the label below shows the *read* label (VSYNC instead

of CXM0P, etc).

 

I assume you meant to say "shows the *write* label"...

 

The label issue is a known problem. The trouble is, the debugger's

list of labels just contains the label name and the address, with no

indication of whether the label is meant to be for reading, writing,

or both. So when it goes to look up the label name for a given address,

it gets the name that occurs "first" in the list (and since it's a hash

table, the order isn't necessarily predictable, either).

 

The label issue is even worse when you're using a DASM symbol file:

In Poker Squares, I've got a symbol called PAL, whose value is set to 0

in the NTSC build of the ROM... when I click on the leftmost TIA byte,

the label that gets displayed is PAL, not CXM0P nor VSYNC.

 

Ugh, and I've just discovered something else: Removing the symbol with

"undef PAL" doesn't help.

 

The next version of the debugger will be smarter about this...

 

And further, though I haven't looked too deeply into

what is going on, the values in the top-line TIA registers surely don't

reflect the state of the TIA, since they all change drastically just when

single-stepping through code that doesn't effect the TIA, read or write,

at all!

 

They return the same value the CPU would see, including "bus noise"

caused by reading unconnected data lines. Bits 0-5 aren't connected to

anything in any of the TIA read locations (and bit 6 isn't connected in

about half of them). The unconnected bits will read as whatever value

was last on the data bus, which will be the low byte of the address

you're reading from... If you watch while single-stepping through code

that doesn't affect the TIA, you should see that the top bit (bit 7)

doesn't change in any of the values, and that bit 6 doesn't change in the

registers where it's connected (all the CX* collision regs except CXBLPF).

Only bits 7 and possibly 6 will reflect the TIA state, because the other

bits aren't really part of the TIA at all (they're effectively wires

that hang in the breeze).

 

This is really the same thing as you're seeing in #1 about the breakif,

above: the debugger sees what the CPU would see (because it's actually

using the emulated CPU to do the reads). This might seem confusing

at first...

 

I could change this behavior, but I thought it'd be better for the

debugger to work this way. If the debugger shows one value, but the CPU

sees another, it'd be even more confusing (or so it seems to me).

 

I could also get rid of the raw display of the TIA bytes entirely,

if they don't seem useful to anyone... all the same information is

available in decoded form (or will be, when we add the INPTx register

display). However I think seeing the raw bytes will be useful, and is

worth the learning curve.

 

b) Also, the checkbox editing of the ENAMx and ENABL is kind of worthless

since the values are immediately reset (to whatever they were before)

once you step through any code.

 

Hm. That's not supposed to happen, will have a look.

 

c) Checking the RESET flag for M0/M1 has odd behavior: It looks to me like

checking that flag has no effect, but after checking it, stepping through

one line of code, unchecking it, and then stepping through another line of

code sets the missile position to the appropriate player position + *16*

 

Again, not supposed to happen... I didn't write (and don't fully

understand) the TIA emulation core, so I probably screwed up the

interaction between the debugger and the TIA.

 

I haven't been very active in Stella development the past few months.

Hopefully that will change soon.

 

--

B.

[+SpiceWare]

First off - many thanks for the debugger - even with it's current limitations it rocks!

 

The label issue is even worse when you're using a DASM symbol file:

In Poker Squares, I've got a symbol called PAL, whose value is set to 0

in the NTSC build of the ROM... when I click on the leftmost TIA byte,

the label that gets displayed is PAL, not CXM0P nor VSYNC.

 

In relation to this, while working on Medieval Mayhem I've come across an issue with setting a breakpoint. My display kernel is unrolled due to the castles and ends up taking 2 banks of ROM with the game processing occuring in a 3rd bank. When I set a breakpoint I end up hitting the breakpoint up to 3 times per frame. It would be most excellent if in a future update the breakpoint is defined by Bank & PC instead of just PC.

[+batari]

First off - many thanks for the debugger - even with it's current limitations it rocks!

 

The label issue is even worse when you're using a DASM symbol file:

In Poker Squares, I've got a symbol called PAL, whose value is set to 0

in the NTSC build of the ROM... when I click on the leftmost TIA byte,

the label that gets displayed is PAL, not CXM0P nor VSYNC.

 

In relation to this, while working on Medieval Mayhem I've come across an issue with setting a breakpoint. My display kernel is unrolled due to the castles and ends up taking 2 banks of ROM with the game processing occuring in a 3rd bank. When I set a breakpoint I end up hitting the breakpoint up to 3 times per frame. It would be most excellent if in a future update the breakpoint is defined by Bank & PC instead of just PC.

If you use different RORGs for your banks you won't run into this problem.

[Urchlay]

First off - many thanks for the debugger - even with it's current limitations it rocks!

 

You're welcome... The fact that people are actually using it makes me a happy camper

 

In relation to this, while working on Medieval Mayhem I've come across an issue with setting a breakpoint. My display kernel is unrolled due to the castles and ends up taking 2 banks of ROM with the game processing occuring in a 3rd bank. When I set a breakpoint I end up hitting the breakpoint up to 3 times per frame. It would be most excellent if in a future update the breakpoint is defined by Bank & PC instead of just PC.

 

One thing you could do would be to use:

 

breakif { _pc==yourLabel && _bank==0 }

 

...instead of a simple breakpoint. The downside of this is that you can't just click on the disassembly to toggle a breakif, so you end up having to type it again when you want to enable it again (or at least you have to find it by hitting the up-arrow a lot).

 

...or you could use different RORGs for your banks as batari suggests.

 

At some point, though, I do want to use bank+PC for regular breakpoints. It'd be quicker than using breakif, and more intuitive.

[+SpiceWare]

If you use different RORGs for your banks you won't run into this problem.

I'm using the following

MAC JUMP_TABLE; put this at the start of every bank
RORG $F000
InitSystem
cmp SelectBank5  ; inits system then goes to the menu
jmp InitSystemCode
VerticalBlankMenu
cmp SelectBank6
jmp VerticalBlankMenuCode
VerticalBlankGame
cmp SelectBank1
jmp VerticalBlankGameCode
KernelGame
cmp SelectBank8   ; draws score, top castles, dragons
jmp KernelGameCode
KernelGameDragon
cmp SelectBank5   ; draws bottom castles
jmp KernelGameDragonCode
KernelGameBottom
cmp SelectBank5   ; draws bottom castles
jmp KernelGameBottomCode
OverscanMenu2			; Menu Entry Point if user hits SELECT 
cmp SelectBank6  ; or RESET during a game
jmp OverscanMenu2Code
OverscanGame
cmp SelectBank7
jmp OverscanGameCode
ENDM

...

;Bank 1
  ORG $8000
  JUMPTABLE
...
;Bank 2
  ORG $9000
  JUMPTABLE
 

and so on. What would I use instead?

[+SpiceWare]

One thing you could do would be to use:

 

breakif { _pc==yourLabel && _bank==0 }

Ah - that's not bad. I have a suspicion that different RORGs might cause me problems with my JUMPTABLE macro.

[+batari]

You could pull the RORG's out of your macro:

;Bank 1
  ORG $8000
  RORG $1000
  JUMPTABLE
...
;Bank 2
  ORG $9000
  RORG $3000
  JUMPTABLE

...
...

;Bank 8
  ORG $F000
  RORG $F000
  JUMPTABLE
 

[+SpiceWare]

If I'm not mistaken, InitSystem would then be defined as 8 different values and the compile would fail.

[+SpiceWare]

breakif { _pc==yourLabel && _bank==0 }

Works great - but I had to use breakif { pc==yourLabel && _bank==0 } else it complained about Invalid Word Argument

[+batari]

If I'm not mistaken, InitSystem would then be defined as 8 different values and the compile would fail.

Yeah, you're right. I could suggest a kludgy way to make it work but it sounds like you've got a good solution going.

[Urchlay]

breakif { _pc==yourLabel && _bank==0 }

Works great - but I had to use breakif { pc==yourLabel && _bank==0 } else it complained about Invalid Word Argument

 

Heh, it's been so long since I did anything with the debugger, I forgot my own syntax...

 

One thing I want to add to a future version of the debugger is a way to disable breakif's without actually removing them from the list. That way you won't have to type "breakif { pc==yourLabel && _bank==0 }" over and over again.

 

I should probably go ahead and make "_pc" a synonym for "pc" (and do the same with the other registers). There actually is a good reason why "_bank" has the leading underscore and "pc" doesn't, but it does make it annoying to remember which gets the _ and which doesn't.