Stella 3.8 released

[+stephena]

1) Is there any way to convert a save state from 2.82 to 3.X? Or anything you can do if I send you the st0 file on one-time only basis?

 

Unfortunately not. There has been a ridiculous number of changes from 2.8 to 3.8, in some areas almost a complete re-write of some of the code. As such, there's now some stuff saved in newer state files that didn't even exist in older ones, and some other stuff that was removed because it's no longer relevant. So they aren't compatible at all. It might be possible to hack the file so that it will load in newer versions, but no guarantees that it would be correct. I suppose you could send it, but no promises ...

 

2) Randomization in Dragonstomper appears to not be working. 3-4 years back it was stuck on the "version" in which the Cross gives healing. You fixed that after 2.8x or 3.0 I think ? [see link below]. Now it seems to be only the Staff that will heal. Of course the staff is the hardest to aquire the cross was the easist. I've tried 5 times with 3.81 and same result [staff]. On an actual system the cross seem to seem to server as healing 2x as much the other objects.

 

This shouldn't be happening again, as I don't think that part of the code was changed. I'll look into it.

 

EDIT: As suspected, nothing in this area of the code has changed; the randomization still seems to be working as it did before. I guess I would have to try compiling the 2.8.1 version as well, to see what differences are occurring. It might be that the randomization *isn't* the actual problem. One other thing to try is to turn the 'ramrandom' setting on and off, and see if it makes a difference. It probably shouldn't, but I have no idea otherwise ???

 

I'm not really familiar with this game, and would need to play it extensively to even see what you're talking about. Can anyone else volunteer to play this game, or offer some ideas on what the problem could be.

[+stephena]

Stephen, I noticed your latest check-in changes regarding better DiStella support.

 

Just one note: Why do you want to output illegal opcodes with byte code? DASM supports the mnemonics for maybe 10 years now.

 

I'm just doing what the Distella code does. In the cases where an instruction (eg, $02 for JAM) is stored in its internal array, beginning with a dot, as ".jam", the output is ".byte $02" and not ".jam", or "jam". Otherwise, it seem DASM doesn't recognize the instruction.

 

Now I'll admit that I don't fully understand DASM, and it may be that I'm using it wrong and that there's a commandline argument to override this. In any event, this functionality in Stella can be easily overrided by commenting out that small (5 line) section of code.

 

I refer to the mnemonics as described at the bottom of this file. In my case, the illegal opcodes are lowercase instead of beginning with a dot, but the concept is exactly the same.

 

EDIT: The current code does this conversion on lines 359 - 366.

[Thomas Jentzsch]

I'm just doing what the Distella code does. In the cases where an instruction (eg, $02 for JAM) is stored in its internal array, beginning with a dot, as ".jam", the output is ".byte $02" and not ".jam", or "jam". Otherwise, it seem DASM doesn't recognize the instruction.

You are right, that should be done for duplicate mnemonics like JAM and certain NOPs (best with mentioning the mnemonic and instruction type as a comment).

 

But for all unique opcodes (e.g. LAX ZP), I would suggest no different handling than for normal opcodes.

 

I also don't know how Distella handles that. Probably it doesn't know illegal opcodes at all, because it was done for original games. But in Stella we now use the functionality for all kinds of ROMs. Therefore illegal opcodes should somehow be handled.

 

I refer to the mnemonics as described at the bottom of this file. In my case, the illegal opcodes are lowercase instead of beginning with a dot, but the concept is exactly the same.

Yup, those are the common names for the illegal opcodes.

 

I am always using this table to lookup the mnemonics.

[+stephena]

You are right, that should be done for duplicate mnemonics like JAM and certain NOPs (best with mentioning the mnemonic and instruction type as a comment).

 

But for all unique opcodes (e.g. LAX ZP), I would suggest no different handling than for normal opcodes.

 

I also don't know how Distella handles that. Probably it doesn't know illegal opcodes at all, because it was done for original games. But in Stella we now use the functionality for all kinds of ROMs. Therefore illegal opcodes should somehow be handled.

 

The issue here is DASM. I can easily comment out the code mentioned above, or convert some of the opcodes from lowercase to uppercase (in which case they'll be treated as 'normal' opcodes). But in the end, it all depends on what DASM will accept. I guess I'd need to look at their source code and see what opcodes it accepts.

[+stephena]

Mmm, it seems only the 'jam' opcode isn't supported by DASM (and of course, that's the one that popped up in my testing). So it's easy enough to work around that one.

[Omegamatrix]

I've done quite a few changes to DiStella over the years to make my own personal hacked copy. Maybe some of the concepts could be ported over to this new planned output from Stella (not the debugger listing, but the assembly file output).

 

 

I don't have time to list all the changes ATM, but the significant ones are:

 

 

- listing ram as lda ram_AE instead of lda $AE. All other cases are handled too like jmp.ind (ram_AE). This makes it a lot easier to change the names of ram locations.

- handling of ram and TIA mirrors. sta $0110 becomes sta RESP0 | $100 or something like that.

- A static count of the number of places each ram location is used. So if ram_AE is listed 10 times in the rom, it will display a 10 beside it in the listing at the top. This is useful for quickly telling what locations might be underutilized and freed up.

- using ds for ram, so that it can quickly be moved around

- having branches use 2³ and 2³+1 for crossing page boundaries

- I had some static always branch prediction, but that code is ugly and big

- having labels appear on separate lines from the code.

- underscoring WSYNC's with a commented line. Useful for cycle counting in a kernel. I also made WSYNC's one after the other suppress this line, except for the very last one.

 

There's probably more, but I'm running out the door and this is off the top of my head.

[+stephena]

I've done quite a few changes to DiStella over the years to make my own personal hacked copy. Maybe some of the concepts could be ported over to this new planned output from Stella (not the debugger listing, but the assembly file output).

 

As with most things, some of the stuff you mention is easy to do, some not so much. I guess we should start another thread asking about what would be nice to have in the output. But keep in mind that my main goal at this point is in getting the output working correctly for single-bank ROMs. Then I'd look at some multi-bank ROMs (the common ones, F8/F6/F4, etc), and then finally adding new features as you suggest. I don't know how much of this will be done before 3.9; maybe it should be spread out over a few releases.

[Thomas Jentzsch]

I've done quite a few changes to DiStella over the years to make my own personal hacked copy.

Same here, quite similar to most of your changes.

[Omegamatrix]

As with most things, some of the stuff you mention is easy to do, some not so much. I guess we should start another thread asking about what would be nice to have in the output. But keep in mind that my main goal at this point is in getting the output working correctly for single-bank ROMs. Then I'd look at some multi-bank ROMs (the common ones, F8/F6/F4, etc), and then finally adding new features as you suggest. I don't know how much of this will be done before 3.9; maybe it should be spread out over a few releases.

I think the only hard implementation I had was the static branch prediction. Otherwise it was pretty easy to implement all this. Yes a new thread should be started for this.

 

 

Same here, quite similar to most of your changes.

I also did some stuff to handle loading the cx registers when they were $0x instead of $3x. Distella always defaulted to using $3x IIRC, and if something was at $0x it would use the write label. So lda INPT4 would be lda REFP1. One issue I ran into was Qbert Qubes used INPT4 as $3C in one bank, and another zero page mirror in the other. I think a simple solution would be to take the minimum possible register as the base, in this case $0C for INPT4, and OR every mirror after that.

 

So:

lda INPT4 ; input 4 = $0C

 

or:

lda INPT4|$30 ; input 4 = $3C

lda INPT4|$70 ; input 4 = $7C

lda INPT4|$0100 ; input 4 = $010C

...and so on.

 

There was some discussion on whether TIA.h should use $3x or $0x for the tia read baseline many years ago. In my experience I have found about half the old era roms use $3x for the baseline, and the other half use $0x. I believe the argument at the time for TIA.h was to use $3x because that is how it is defined in the Stella's programmer guide. Then READ_TIA_BASELINE = 0 (or something like that) would be used for games that that have $0x for the read base. But that wouldn't have worked for Qbert Qubes as the other INPT4 was at the mirror of $7C.

[+stephena]

I think the only hard implementation I had was the static branch prediction. Otherwise it was pretty easy to implement all this. Yes a new thread should be started for this.

 

I'm not sure what static branch prediction is in this context, so I'll leave it for now. As for starting a new thread, feel free to do so. Most of you will have better ideas about this stuff, so better if you lead the discussion.

 

I also did some stuff to handle loading the cx registers when they were $0x instead of $3x. Distella always defaulted to using $3x IIRC. One issue I had was Qbert Qubes used INPT4 as $3C in one bank, and another zero page mirror in the other. I think a simple solution would be to take the minimum possible register as the base, in this case $0C for INPT4, and OR every mirror after that.

 

I just checked in code a little while ago that properly process mirrors in the $7F range. So, for example, if the code was "A5 3C", it would display as "LDA INPT4.30" instead of "LDA INPT4". But I didn't consider mirrors above $100. Is this really useful in practice??

 

BTW, here's the current progress of the debugger output for River Raid:

rr.asm

[Omegamatrix]

I'm not sure what static branch prediction is in this context, so I'll leave it for now.

 

Stella dynamically resolves code. To statically determine if a branch was always taken I would look for branches that were opposite conditions of each other, with no label in-between:

 

bcc .here

bcs .there ; always branch

 

A label inbetween complicates things:

bcc .here

.myEntryPoint:

bcs .there ; too hard to determine if it's unconditional by a static run...

 

And then I expanded it to other condtions like bne, beq, bpl, etc..

lda #$34

bne .there ; always branch

 

lda #0

beq .there ; always branch

 

These were all done with the caveat that no checks for indirect jumps were in place. All in all it seemed to perform well, grabbing roughly 75% percent or more of the unconditional branches I'd usually hunt for after the disassembly ran.

 

 

I just checked in code a little while ago that properly process mirrors in the $7F range. So, for example, if the code was "A5 3C", it would display as "LDA INPT4.30" instead of "LDA INPT4". But I didn't consider mirrors above $100. Is this really useful in practice??

 

Oh yes, take a look at Jungle Hunt for example. 7 places in the rom it does this. Dig Dug does this 30 times in the rom. There's more roms also, but I can't think of them at the moment.

 

Most of the time homebrews will use a absolute zero page address instead of a mirror, i.e sta.w RESP0, but I have found these old Atari roms seemed to prefer mirrors.

[Thomas Jentzsch]

Most of the time homebrews will use a absolute zero page address instead of a mirror, i.e sta.w RESP0, but I have found these old Atari roms seemed to prefer mirrors.

I suppose the assemblers back then didn't support address mode overwrites.

[+stephena]

Oh yes, take a look at Jungle Hunt for example. 7 places in the rom it does this. Dig Dug does this 30 times in the rom. There's more roms also, but I can't think of them at the moment.

 

Most of the time homebrews will use a absolute zero page address instead of a mirror, i.e sta.w RESP0, but I have found these old Atari roms seemed to prefer mirrors.

 

Ok, then I'll need to rework this. It's not hard, but is additional work and will slightly slow down processing.

 

EDIT: If you're willing, please send me the source to your modified Distella. I may find some better, more efficient ways of implementing some of this stuff.

[enthusi]

I appreciated the byte codes for illegal OPcodes since I often used i.e. the XA-assembler instead of DASM. DASM is super-common for Atari-users but much less so in the active C64 scene for example. But I agree, other assemblers can/should adopt

Just a note that at least one guy like the option to omit the A in LSR and the 'option' to putput byte-codes

As of Stella: Id love to see it alive. It features the best debugger I saw for ANY emulator so far. Great work.

I shall donate something as well now

[Thomas Jentzsch]

Just a note that at least one guy like the option to omit the A in LSR ...

Make that two!

[JL]

Unfortunately not. There has been a ridiculous number of changes from 2.8 to 3.8, in some areas almost a complete re-write of some of the code. As such, there's now some stuff saved in newer state files that didn't even exist in older ones, and some other stuff that was removed because it's no longer relevant. So they aren't compatible at all. It might be possible to hack the file so that it will load in newer versions, but no guarantees that it would be correct. I suppose you could send it, but no promises ...

 

 

 

This shouldn't be happening again, as I don't think that part of the code was changed. I'll look into it.

 

EDIT: As suspected, nothing in this area of the code has changed; the randomization still seems to be working as it did before. I guess I would have to try compiling the 2.8.1 version as well, to see what differences are occurring. It might be that the randomization *isn't* the actual problem. One other thing to try is to turn the 'ramrandom' setting on and off, and see if it makes a difference. It probably shouldn't, but I have no idea otherwise ???

 

I'm not really familiar with this game, and would need to play it extensively to even see what you're talking about. Can anyone else volunteer to play this game, or offer some ideas on what the problem could be.

 

"One other thing to try is to turn the 'ramrandom' setting on and off"

 

Hi,

 

That seems to work. I tuned it to false by editing stella.ini

 

Will anything in other games be different if I leave it that way and is it setting via UI?

[+stephena]

I appreciated the byte codes for illegal OPcodes since I often used i.e. the XA-assembler instead of DASM. DASM is super-common for Atari-users but much less so in the active C64 scene for example. But I agree, other assemblers can/should adopt

Just a note that at least one guy like the option to omit the A in LSR and the 'option' to putput byte-codes

 

Almost all the options from Distella are currently in the code (-a, -r, etc), but many of them aren't yet exposed in the debugger UI. This will be fixed before the next release.

 

As of Stella: Id love to see it alive. It features the best debugger I saw for ANY emulator so far. Great work.I shall donate something as well now

 

Thanks for the support and donation

[+stephena]

"One other thing to try is to turn the 'ramrandom' setting on and off"

 

Hi,

 

That seems to work. I tuned it to false by editing stella.ini

 

Will anything in other games be different if I leave it that way and is it setting via UI?

 

It shouldn't have made a difference, but obviously the randomization in the game is also dependent upon what's stored in RAM. Settings ramrandom to false sets zero-page RAM to all zeros, while true would randomize the contents. The problem is, some consoles do one and some do the other. Hence the reason for making this a configurable option. I'm not entirely sure how to proceed. Maybe Supercharger ROMs should automatically turn the setting off. Or maybe such ROMs would fail on a real system where this happened??

 

Anyway, it shouldn't hurt anything to leave it off. If you see some regressions in other games, then you'll probably know what caused it Also, I need to get this added to the UI, so you don't have to edit the INI file to change it ...

[+stephena]

I'm logging off for tonight and probably a good part of tomorrow, as I'm still fighting a bad cold here. Feel free to keep the discussion going.

[Omegamatrix]

Ok, then I'll need to rework this. It's not hard, but is additional work and will slightly slow down processing.

 

EDIT: If you're willing, please send me the source to your modified Distella. I may find some better, more efficient ways of implementing some of this stuff.

Yeah, I'll send you what I have, but be warned it is a true bare metal hack job. I was new to C programming at the time and it is a mess.

 

 

Still you should be able to get some value out of it. I actually partially had a new switch going. The -l switch I put in was for disassembling illegal opcodes. I also put some checks in for "skip" conditions. I would look for jumps or branches between an operand and opcode. If it was I might do something like this:

 

 

.byte $2C ; BIT, skip 2 bytes

LF345:

lda ram_9F

 

Instead of:

bit $9FA5

 

I think I did this for illegal nops, bits, and cmps. It should probably be extended to a more general case though. As to how common this is, I point to one nightmare called "Pete Rose Baseball".

[Omegamatrix]

I appreciated the byte codes for illegal OPcodes since I often used i.e. the XA-assembler instead of DASM. DASM is super-common for Atari-users but much less so in the active C64 scene for example. But I agree, other assemblers can/should adopt

Just a note that at least one guy like the option to omit the A in LSR and the 'option' to putput byte-codes

As of Stella: Id love to see it alive. It features the best debugger I saw for ANY emulator so far. Great work.

I shall donate something as well now

 

Thirded. I usually use -pasf switches in Stella to the point that I inverted those switches in my hacked copy of Distella because I hated typing them out each time.

[mkiker2089]

I'm having trouble getting the Genesis controller to work. I changed the setting in the rom file to Genesis but no second button works. The 5 on the keyboard does, but nothing on my controller. My controller isn't a Genesis controller but is a dual shock style controller instead. Is that the problem?

[+stephena]

I'm having trouble getting the Genesis controller to work. I changed the setting in the rom file to Genesis but no second button works. The 5 on the keyboard does, but nothing on my controller. My controller isn't a Genesis controller but is a dual shock style controller instead. Is that the problem?

 

By default, this button is assigned to the '5' key only; you need to map it to some button on your gamepad. While in the game, press TAB and then go to "Input Settings". Scroll down to 'P0 Booster Handle Grip', and notice that it is currently mapped to button 5. Simply click "Map", then press a button on your gamepad, and the mapping should be complete.

[Rastignac]

Is it possible to add a "very-too-much interlaced display mode" in Stella ?

 

ie: in "zoom x2", the first line is drawn as a displayed line then a black line, the second line is displayed as a displayed line then a black line, etc. Next frame will show the first line as a black line then a displayed line, the second line as a black line then a displayed line. Etc, etc, odd, even, odd, even.

 

 

Result animation will be a flickering/interlaced picture, near of TV's hardware.

 

Sometimes a homebrew game is perfect on the emulator but sucks on TV, because of TV's interlacing. Simulating such a behavior would be helpful (ie: it will also suck on the emulator, so the programmer can try to fix it).

 

Note: the phosphor effect can also be added to this mode (ie: real line then ghost of previous line, real line then ghost of previous line, etc; then ghost of previous line then real line, then ghost of previous line then real line, etc).

 

Note: it would be possible only with x2 zoom (or x4).

 

Thanks.

Edited June 24, 2013 by Rastignac

[+stephena]

I won't be touching that part of the code until I move to SDL2, which will be included in Stella 4.0. The reason being, some parts of the graphics code have to be refactored then, and that's the perfect time to do it. But adding an interlace mode is something I've been wanting to do for some time.