Distella configuration files

[Nukey Shay]

I like the idea of including the opcode name alongside the byte value...however, it might be better to just put the cycle count just as what is done for all other program opcodes, since the opcode chosen is usually not as important as how many cycles are involved to do the skipping:

 

.byte $2C ;4

 

 

Alternately, you could adjust cycle count vs. those used by the instructions being skipped...so it matches when counting them manually top-to-bottom:

 

.byte $2C ;-1

lda ($80),y ;5

 

 

Anyway, no updates on my end. I was finishing the first pass of the HES 2-paks when I began asking myself "what is it good for?" a little too often. Those that know how to run a disassembly can do so without automation...those that don't have no real need for a detailed breakdown anyway.

 

But here's the merged HES disassemblies. All data is still labelled as GFX, since I'd lost interest at that point.

HES-2pak.zip

[+stephena]

With the global config files, I honestly don't know how many more I'll make. It just takes time away from my normal programming and hacking. However that being said, I do believe I will come back to them from time to time and add a bunch. Makes sense to me to leave it as an on-going project that anyone can contribute to. The real meat and potatoes is in Stella being able to have these passed to it, so an individual user can make one for themselves.

I agree. From my end, my main concern is adding infrastructure to Stella to view this information, not necessarily in creating a comprehensive cfg collection for every ROM in existence. That's why I want a concrete, final description of the directive names and how they operate.

 

I've been thinking of renaming 'BLOCK' to 'ROW'. The directive name 'SKIP' I'm quite happy with.

I'll leave it as BLOCK for now in the code. When/if you change it, it's just a simple change in the codebase. But please discuss it among yourselves exactly which you prefer, then let me know.

 

As for output (in Stella):

 

$DF30-$DF33 is GFX

$DF34-$DF3F is ROW

$DF40-$DF49 is DATA

 

A 'SKIP' should be displayed as such in Stella for a BIT skipping 2 bytes:

 

.byte $2C (BIT, skip 2 bytes)

 

likewise:

.byte $0C (NOP, skip 2 bytes)

.byte $24 (BIT, skip 1 byte)

 

and so on...

I like the idea of including the opcode name alongside the byte value...however, it might be better to just put the cycle count just as what is done for all other program opcodes, since the opcode chosen is usually not as important as how many cycles are involved to do the skipping:

So ROW/BLOCK is exactly how DATA works now, and DATA is simply split to one item per line? If so, that should be very easy to do. As for SKIP, since there's still some discussion, please decide amongst yourselves how you want it to look, then let me know.

 

Anyway, no updates on my end. I was finishing the first pass of the HES 2-paks when I began asking myself "what is it good for?" a little too often. Those that know how to run a disassembly can do so without automation...those that don't have no real need for a detailed breakdown anyway.

I've asked myself that question many times when developing for Stella, since much of the functionality I include is stuff I'll never personally use. However, if I don't do it, nobody else will, so I guess that's why I stick with it (for now at least, as 10 years is a long time to be involved with a project). But I do understand your feelings.

 

As for the overall purpose, I think it's basically to differentiate areas marked as GFX, BLOCK, and SKIP. The most recent changes I've made to Stella track whether an address is CODE during emulation itself, so the output is extremely accurate (more accurate than Distella could ever be, since it's running the code itself to get the info). So with that part being taken care of, the real purpose of this project is to fine-tune areas not marked as CODE. But as you say, is it a useful pursuit?? I don't really know ...

[+Omegamatrix]

Okay, lets talk about the 'SKIP' directive. I did a mock-up on how I think it should look in the debugger. For the moment I'm only talking about Stella, and not Distella.

 

 

 

My one underling thought is that I really want this to jump out at you. As you are scrolling through the debugger it should kind of slap you in the face that something unusual is happening here. To that end I have left a blank line above the SKIP instruction. I also left no ';' after the hex value. This is to make less clutter around the opcode, and have it stand apart more.

 

 

Again, this is strictly for the debugger window. If it was a Distella output then you would need a ';' after the byte value, but since this is the debugger window we are going for readability.

 

 

Finally I also left the cycle count as 4. It makes more sense to me like this (in the debugger window). I left the column of hex values to the far right as it should be. Specifically only the hex values on that line in the debugger are shown on the far right.

 

 

What do you guys think?

[+stephena]

Here's another test release (Stella-3.3_test6-windows.zip), which includes the following improvements:

 

- The emulation core now tracks all access to code sections and marks them as such, making the disassembler output much more accurate.
  This means you don't need to run the code in the debugger before it's recognized as a CODE section.
  For now, several of the more esoteric bankswitch schemes aren't yet supported (AR, 4A50, FE, MC).

- Added ability to toggle showing of opcode/instruction addresses.  This is tied to the 'showaddr' commandline argument and a right-click menu item in the disassembler output.

- Fixed bug with relative opcodes where the resolved address was being shown, instead of the signed offset that created it.

I'm particularly proud of the auto-code tracking, as it generates very accurate disassembled results. This allows to produce config files much easier, and revealed many areas of River Raid that I never thought were CODE areas.

 

Next I'm going to look at the DATA/BLOCK/SKIP directives, so please come to a consensus on its functionality as soon as you get a chance.

[+Omegamatrix]

The most recent changes I've made to Stella track whether an address is CODE during emulation itself, so the output is extremely accurate (more accurate than Distella could ever be, since it's running the code itself to get the info). So with that part being taken care of, the real purpose of this project is to fine-tune areas not marked as CODE.

 

 

You know, you are one step away from doing much everything I wanted to do with the global files. A fine tuned auto-disassembly is a million times better, and you are close. All you need is hierarchy for disassembly. Something like:

 

 

1) SKIP

2) CODE

3) GFX

4) DATA

5) ROW

 

 

I'll break this explanation into a few posts, working from the bottom up in hierarchy. I'm going to be using lots of photos to give a visual for everyone to follow.

 

 

5) Everything starts with the default of 'ROW'. ROW is for anything that is never used. Since garbage data is never used, it becomes separate from valid data/gfx/code. It would look like this in Stella:

 

 

The idea with having it display horizontal is that it takes up less space, and gives a differentiation from valid data. Valid data will now be on individual lines with the address beside it. One important note is that ROW should never have the address following it (labels are fine though). The reason is because there will be cases where only a single byte is garbage data (unused space). This most often occurs before a new page. For example:

 

 

Here byte $1DFF is unused. Bytes $1DF5-$1DFE have been referenced as DATA by Stella, and bytes $1E00-$1E0D has been referenced as GFX. Since the garbage data is only one byte long my only distinction from the regular data is in that no hex address is displayed after it.

 

Ideally if the debugger left a blank line between sections of gfx/code/data/row then it becomes even easier to spot.

 

 

Those spaces are only between the different sections, not between individual bytes. I'm repeating that because I want the distinction clear. Here is a different example which again only has spaces between gfx/code/data/row sections:

 

 

Ignore the address in the above photo, because it was done with cutting and pasting in Paint. I'm only trying to demonstrate the visual separation.

[+Omegamatrix]

Next comes:

 

3) GFX

4) DATA

 

If there is a conflict between a byte being referenced as DATA or GFX, then GFX should win. The difference between in the debugger for DATA and GFX is in the striking visualization. GFX has a beautiful preview of the sprite, and the value is in binary so it's easy to directly hack it in Stella. DATA looks way different the GFX as it's value is in hex, and as you scroll through the debugger you will immediately know when you reach as a section of DATA or GFX:

 

 

Again ignore the mock up addresses in the above photo. It's just me copying and pasting for the visual.

 

 

I'm guessing it'd be pretty straight forward to mark loaded rom as DATA. GFX has the higher priority though, so that you can clearly see everything being used on the screen. I imagine the easiest way to do this is to keep track of the address for bytes loaded into A,X, and Y. Whenever a new byte is loaded the address is updated. If the A,X, or Y is stored into GRP0 or GRP1 mark the address as GFX. Don't bother to check if that address has previously been marked as DATA as ROW because they have a lower priority. Only worry about the higher priorities which I will explain next.

[+stephena]

The most recent changes I've made to Stella track whether an address is CODE during emulation itself, so the output is extremely accurate (more accurate than Distella could ever be, since it's running the code itself to get the info). So with that part being taken care of, the real purpose of this project is to fine-tune areas not marked as CODE.

 

You know, you are one step away from doing much everything I wanted to do with the global files. A fine tuned auto-disassembly is a million times better, and you are close. All you need is hierarchy for disassembly.

Well, it may seem like I'm close, but that's usually when hard-to-solve problems pop up Specifically, it's relatively easy (both as an algorithm and run-time performance) to track CODE sections. I just modify the PEEK instructions to note whenever the program counter is referenced (the idea being, all code must be present in the PC at some point). Or put another way, the fact that something appears in the PC makes it CODE. And there are no IF statements to execute; the code is modified to track (at compile time) if this event occurs.

 

Things aren't quite as simple with GFX. You say that we'd need to track accesses to GRPx. But that will require an IF statement. And tracking accesses to the CPU registers will again require IF statements. This has to be done at runtime for every instruction executed, and may cause slowdowns.

 

My intention was to accurately track CODE, and have the other directives 'fill in the blanks'. Now, while I agree that having the disassembler do everything would be the ideal solution, I cannot sacrifice runtime performance to do it. So we need to think about how to approach this in a very efficient way. And maybe there won't be an efficient way to do it.

 

EDIT: I should add that I have no problems with adding code to Distella to do this stuff. Distella is run from the debugger, and as such I don't mind if it takes a little performance hit. My only real objection is modifying the emulation core itself to track GFX/DATA/ROW areas. Doing it for CODE was relatively easy, and indeed even necessary. But doing it for the other directives will probably slow down the emulation. Remember, I have to consider those users that have no idea what the debugger is, or how to use it. General emulation shouldn't be slowed down (too much) in service of the debugger.

[+Omegamatrix]

Next is:

 

2) CODE

 

 

CODE has precedence over all gfx/data/row. Simply put, if a byte was marked as DATA and then later used as code then it should be upgraded in the hierarchy to CODE, and remain fixed as CODE (never reverted to data/gfx/row).

 

A section of code used as data is common. Some games use sections of code for creating random GFX for example. I think Yars' Revenge might do this to draw it's wall. Not 100% sure. Anyhow once it's code it should stay as code.

 

There is only one conflict I can think of, and that's a table that is jumped into (like Subterranea).

 

    bpl    L1332                 ; 2³
   jmp.ind ($00F4)              ; 5   jump into the "DelayCycles" table below.



;This table's function is to waste a variable amount of cycles
;before entering the drawing loop for the "HEXUPLEX".

DelayCycles:
   .byte $A9        ; +8 cycles    lda #$A9, lda #$A9, lda $EAA5
   .byte $A9        ; +7 cycles    lda #$A9, lda #$AD, lda $EA
   .byte $A9        ; +6 cycles    lda #$A9, lda $EAA5
   .byte $A9        ; +5 cycles    lda #$AD, lda $EA
   .byte $AD        ; +4 cycles    lda $EAA5
   .byte $A5        ; +3 cycles    lda $EA
   .byte $EA        ; +2 cycles    nop



   ldy    #$0F                  ; 2
L1341:
   ldx    #3                    ; 2
L1343:
   dex                          ; 2

 

For this example lets say the code goes through at +8 cycles. Stella would mark this all as code. It would look like this:

 

lda #$A9

lda #$A9

lda $EAA5

 

But (and here comes the problem), on the next time through it jumps in at +7 cycles. This is jumping between a previous defined operator and operand. In such a case Stella should revert the previous instruction from code doing something like this:

 

.byte $A9

lda #$A9

lda #$AD

lda $EA

 

This is a case where code has been reverted, and is the only instance I can think of this happening. Now I think it should only be that one instruction that gets reverted. If we had gone through a pass off +8 cycles followed by a pass of +5 cycles it would look like this:

 

lda #$A9

.byte $A9

lda #$AD

lda $EA

 

So only the broken instruction gets reverted. And in summary only CODE should be able to revert CODE (or SKIP, but that's next).

[+Omegamatrix]

Finally:

 

1) SKIP

 

If a section is marked as code, but the BIT, NOP, CMP, etc... has a jump or branch into it, then the operator becomes a SKIP instruction. It can't be reverted back to CODE, but the operand it previously held is up for grabs as CODE.

 

 

[+Omegamatrix]

Things aren't quite as simple with GFX. You say that we'd need to track accesses to GRPx. But that will require an IF statement. And tracking accesses to the CPU registers will again require IF statements. This has to be done at runtime for every instruction executed, and may cause slowdowns.

 

My intention was to accurately track CODE, and have the other directives 'fill in the blanks'. Now, while I agree that having the disassembler do everything would be the ideal solution, I cannot sacrifice runtime performance to do it. So we need to think about how to approach this in a very efficient way. And maybe there won't be an efficient way to do it.

 

EDIT: I should add that I have no problems with adding code to Distella to do this stuff. Distella is run from the debugger, and as such I don't mind if it takes a little performance hit. My only real objection is modifying the emulation core itself to track GFX/DATA/ROW areas. Doing it for CODE was relatively easy, and indeed even necessary. But doing it for the other directives will probably slow down the emulation. Remember, I have to consider those users that have no idea what the debugger is, or how to use it. General emulation shouldn't be slowed down (too much) in service of the debugger.

 

 

I just had an idea. It's the best idea I had all morning, besides brewing a second pot of coffee.

 

 

First, I think we all can agree that getting Stella to differentiate all of these non-code areas into data/gfx/row would be as slick as shit. It would look really great in the Debugger! So the problem is performance. I completely agree we can't take away performance one bit but here is a compromise:

 

Stella already has switches that can be invoked real time like alt ',' for the fixed colors debug mode. How about a switch that forces Stella into super refinement mode in real time? The user would be doing this in a situation where they don't care about performance. They are simply trying to create the be all end all .cfg file. Stella would run in super refinement mode until the switch is hit again (releasing the mode). At that time the a new global .cfg file is created (or amended to).

 

So this would be win-win. Stella would only slow down when desired, and mega-refined .cfg files could be created. A big message could be displayed in the middle of the screen while this mode is running like:

 

 

"Forced disassembly refinement mode enabled, press alt-f to escape"

 

I don't know what the actual switch name would be, but the point is that the message stays on the screen until the user presses the switch. This will be good for the common user that accidentally hits alt-f.

 

Now if Stella was set up like this we could create all the global .cfg files in mass beforehand. All we would have to do is play each game a little bit in super refinement mode. Then all the created global .cfg files could be included with the next Stella release. So even if the user never chooses this mode, the global .cfg files will still be pretty good on its own.

 

 

What do you think?

[+stephena]

Stella already has switches that can be invoked real time like alt ',' for the fixed colors debug mode. How about a switch that forces Stella into super refinement mode in real time? The user would be doing this in a situation where they don't care about performance. They are simply trying to create the be all end all .cfg file. Stella would run in super refinement mode until the switch is hit again (releasing the mode). At that time the a new global .cfg file is created (or amended to).

Interesting that you should pick the example of fixed debug colours, since it's one that doesn't cause any slowdowns at all (it just swaps pointers to reference a different palette). If only the debugger stuff was so easy

 

Now if Stella was set up like this we could create all the global .cfg files in mass beforehand. All we would have to do is play each game a little bit in super refinement mode. Then all the created global .cfg files could be included with the next Stella release. So even if the user never chooses this mode, the global .cfg files will still be pretty good on its own.

 

What do you think?

Sounds good in theory, but it might not be that easy. Tracking these things isn't (usually) just a simple matter of "do this or don't do this". It might require a rewrite of the instruction decode and execute loop. In any event, I can't say how easy or hard this will be, or how much of a performance hit it will be until I experiment some more. But I agree that it would be extremely cool to have it done that way.

 

And besides, there's nothing saying I can't track this in Distella itself yet. If Distella (aka, a static analysis) is enough to give us what we want, then the problem may be moot (except for me actually writing the code, of course).

 

So before I begin experimentation, I need a clear, unambiguous way to detect the different cases:

 

1) CODE is detected if it's been used in the PC. That one is easy, and is already done.

 

2) GFX is detected by accessing the GRPx registers. Is this the only way, and if not, how else?

 

3) DATA is detected by ???

 

4) ROW is if it doesn't match anything else??

[+Omegamatrix]

Sounds good in theory, but it might not be that easy. Tracking these things isn't (usually) just a simple matter of "do this or don't do this". It might require a rewrite of the instruction decode and execute loop. In any event, I can't say how easy or hard this will be, or how much of a performance hit it will be until I experiment some more. But I agree that it would be extremely cool to have it done that way.

 

And besides, there's nothing saying I can't track this in Distella itself yet. If Distella (aka, a static analysis) is enough to give us what we want, then the problem may be moot (except for me actually writing the code, of course).

 

 

I'm really excited about the possibility of super-refined .cfg files. I'm really glad you like this idea too. Now it's only a matter of if it is possible or not.

 

It's powerful to know right off the bat what areas of code have never been called (and could be garbage data). It's easy enough for me to produce manual .cfg files that separate code from non-code. However I might discover that a piece of code is never executed only when I'm deep in the disassembly. I would never be able to pick this out as easily as Stella could. So a super refined disassembly is extremely useful to me.

 

With the GFX being separated from the data it would be a snap to find pointers, etc... It would also be good as it would show GFX that didn't appear to be GFX at first. Look at the score digits in Subterranea. I would never know where they lay if I scrolled through the rom in HOM3 or BitHacker. But with Stella putting them in the GFX format I know that something is going on there.

 

Simply put, Stella using its artificial intelligence to distinguish all of these areas is vastly superior. A static run of Distella has no chance to even compete with Skynet Stella.

[+stephena]

It's powerful to know right off the bat what areas of code have never been called (and could be garbage data). It's easy enough for me to produce manual .cfg files that separate code from non-code. However I might discover that a piece of code is never executed only when I'm deep in the disassembly. I would never be able to pick this out as easily as Stella could. So a super refined disassembly is extremely useful to me.

 

With the GFX being separated from the data it would be a snap to find pointers, etc... It would also be good as it would show GFX that didn't appear to be GFX at first. Look at the score digits in Subterranea. I would never know where they lay if I scrolled through the rom in HOM3 or BitHacker. But with Stella putting them in the GFX format I know that something is going on there.

All these are good reasons to have the functionality we want. But as you say, the question is now "can it be done, and if so, how slow will it be".

 

Simply put, Stella using its artificial intelligence to distinguish all of these areas is vastly superior. A static run of Distella has no chance to even compete with Skynet Stella.

That's unfortunate, as I was hoping to side-step the slowdown issue. I probably can still get around it, but the solution will be more complicated.

 

Now, I just need the questions from my previous post answered. I need a complete algorithm for detecting the various directive types before I even attempt to experiment. Something along the lines of "if it's been in the PC, it is CODE". Clear and unambiguous ...

[+Omegamatrix]

2) GFX is detected by accessing the GRPx registers. Is this the only way, and if not, how else?

That's the best way I can think of. Example in super refined mode:

 

LDA ($FE),Y // store the address being accessed in a variable called last_Address_Accumulator

STA NUSIZ0

LDA #$AE // NULL last_Address_Accumulator, because this is an immediate mode

STA GRP0 // check address from last load of A, if NULL do nothing

LDA ($FC),Y // overwrite last_Address_Accumulator

LDX #$ED // immediate, NULL last_Address_Xreg

STX GRP0 // if NUll do nothing

NOP

STA GRP0 // check last_Address_Accumulator, mark that address as GFX if not marked as SKIP or CODE

 

3) DATA is detected by ???

Any read of rom space becomes data at the address. That is unless it is a already marked with a higher priorty (ie SKIP,CODE,GFX). If the address was marked as ROW it would be upgraded to DATA.

 

4) ROW is if it doesn't match anything else??

Yes, however ROW is also the default. So begin by marking every single location of the rom as ROW, and then upgrade in priority from there.

[+Omegamatrix]

That's unfortunate, as I was hoping to side-step the slowdown issue. I probably can still get around it, but the solution will be more complicated.

 

 

I was hoping to side-step the slowdown issue with this switch. If enabled the user is accepting that there will be slowdown.

[+stephena]

2) GFX is detected by accessing the GRPx registers. Is this the only way, and if not, how else?

That's the best way I can think of. Example in super refined mode:

 

LDA ($FE),Y // store the address being accessed in a variable called last_Address_Accumulator

STA NUSIZ0

LDA #$AE // NULL last_Address_Accumulator, because this is an immediate mode

STA GRP0 // check address from last load of A, if NULL do nothing

LDA ($FC),Y // overwrite last_Address_Accumulator

LDX #$ED // immediate, NULL last_Address_Xreg

STX GRP0 // if NUll do nothing

NOP

STA GRP0 // check last_Address_Accumulator, mark that address as GFX if not marked as SKIP or CODE

 

3) DATA is detected by ???

Any read of rom space becomes data at the address. That is unless it is a already marked with a higher priorty (ie SKIP,CODE,GFX). If the address was marked as ROW it would be upgraded to DATA.

 

4) ROW is if it doesn't match anything else??

Yes, however ROW is also the default. So begin by marking every single location of the rom as ROW, and then upgrade in priority from there.

OK, it's beginning to make a lot more sense now. I can't guarantee this will be finished for the 3.3 release, but if not it's definitely something for 3.4. And I think I have a way quickly toggle this, as you suggest. Basically have two functions the do fetch/decode/execute, with one of them being more comprehensive and doing the operations you explain above. And who knows, for a sufficiently fast computer, it might be fine to turn on that option and leave it on. I probably wouldn't notice it on my development system (3GHz quad-core, 8GB RAM), but I want to consider those using sub 1GHz, single core systems.

 

Anyway, I'll be logging off for tonight soon, so I'll get to this in the next week or so. BTW, I just implemented ranges for the trap/trapread/trapwrite commands in the debugger

[+Omegamatrix]

to avoid slowdown I would begin by duplicating your instruction decode and execute loops. Then you put in a flag to switch between super refined mode and normal mode. That way you don't have to check the flag constantly.

 

 

So I don't know if Stella is following a somewhat similar routine to what Distella does, but for Distella you could detect a SKIP by doing this:

 

inside: void disasm(unsigned long distart,int pass)
inside: case ABSOLUTE:

if (pass == 3) {
   if (( op==0x0C || op==0x2C || op==0xCC || op==0xCD || op==0xEC ) 
                   && ( labels[pc-2] & (REFERENCED | VALID_ENTRY)) == REFERENCED ) {
             mark(pc-2,VALID_ENTRY);   // tell Distella that it can disassemble the address as code,
             pc = pc-2;                // and move the PC back two places so that it will get disassembled next.
   }
}

 

Skip has the highest priority. Don't bother checking if it was previously marked as code/gfx/data/row. Just mark that byte as 'SKIP'. Next you do something similar for zero page, checking zero page BIT's, illegal zero page NOP's, and zero page CMP's (CPX and CPY too).

 

I would only check for SKIP's in super-refinement mode.

[+Omegamatrix]

BTW, I just implemented ranges for the trap/trapread/trapwrite commands in the debugger

 

 

:lust:

[+stephena]

Just an update on the latest status of this stuff in Stella.

- What was previously known as 'DATA' is now output as 'ROW' (ie, 16 bytes per line, non-editable, what was previously known as 'BLOCK').

- Added 'DATA' directive, which generates output very similar to 'GFX', except the X's aren't shown, and the disassembled bytes are always in hex.
  Currently, this can only be set by a manual cfg.

- I think I've found a way to track CODE and DATA sections in the emulation core *without* creating a separate fetch/decode/execute loop
  (ie, it will be fast enough to do in the general case).

- I have some ideas how to track 'GFX' in real-time as well.  If that works out, then we won't need another mode at all for tracking this stuff.

So long story short, when it comes to automatic tracking, CODE and ROW are pretty much complete, the infrastructure for DATA is 90% complete, there's a good chance (50%) for GFX, and SKIP may be pushed to the next release (after 3.3).

[+stephena]

OK, here's Stella-3.3_test7-windows.zip, which has some nice updates:

 

- As mentioned before, the trap/trapread/trapwrite commands now accept a range as well as a single value.

- Added type debugger prompt command, to show the disassembled type for an address as detected by the emulation core and Distella.

- The emulation core now keeps track of how an address is accessed, greatly improving the disassembly output.

- ROW functionality has been implemented, with output the same as what the external Distella app calls 'DATA' (16 bytes per line).

- DATA functionality has been implemented, with output as described in a previous posting (basically, like GFX except the individual bits
  aren't shown, and the disassembled bytes are always in hex.  This is used to show all addresses that are accessed, but are not CODE.
  This is automatically tracked.

- GFX functionality is partially implemented, but already in good shape.  Basically works as described in a previous posting, where
  LDA/LDX/LDY addresses are remembered, and writes to GRPx using STA/STX/STY (in zero-page mode) mark those addresses as GFX.
  More testing is definitely required, but it's already very useful as-is.

[+Omegamatrix]

It looks like good progress is being made here! I downloaded the lastest test build, but it crashed on me. Specifically I tried playing Alien (NTSC). I opened the debugger, and exited. Then I tried to re-enter the debugger and that's when it crashed. I'm using Windows7 32 bit. HP Pavilion dv6000 laptop with a 2.00GHz Intel Centrino duo core T2450. I also tried deleting the Stella.ini file and doing a fresh start. It did the same thing.

 

 

Tracking GRPx in real time is awesome. Is PF0, PF1, and PF2 also being tracked? Those are GFX as well. Anyhow I've been busy with Thanksgiving here, and I wish you a happy Thanksgiving as well, Stephena!!

[+stephena]

It looks like good progress is being made here! I downloaded the lastest test build, but it crashed on me. Specifically I tried playing Alien (NTSC). I opened the debugger, and exited. Then I tried to re-enter the debugger and that's when it crashed. I'm using Windows7 32 bit. HP Pavilion dv6000 laptop with a 2.00GHz Intel Centrino duo core T2450. I also tried deleting the Stella.ini file and doing a fresh start. It did the same thing.

Confirmed for me in WinXP 32bit as well, but not in Win7/64 bit. It's definitely related to software rendering mode, though, so maybe try switching to OpenGL instead for now.

 

Tracking GRPx in real time is awesome. Is PF0, PF1, and PF2 also being tracked? Those are GFX as well. Anyhow I've been busy with Thanksgiving here, and I wish you a happy Thanksgiving as well, Stephena!!

Nothing is being done yet for PFx, since we never considered them before. I suppose it's simply a matter of tracking writes to PF0/PF1/PF2 in the same place in the code were GRP0/GRP1 is checked?

 

One thing that would be nice, though, is to have another directive for this. Perhaps PGFX for playfield stuff, and GFX for normal stuff? The reason being, a different directive would allow to output the disassembly slightly differently, based on the type. In fact, I've already been considering not using 'X' for GRPx bits, but something more graphical. Maybe blocks or something, and with colour too. Differentiating this output between GRPx and PFx would be visually striking, and hence very easy to spot.

[+stephena]

OK, here's Stella-3.3_test8-windows.zip. which addresses the crashes in Windows in the previous build. Note that you can continue using OpenGL if you like. In fact, if your system supports it, OpenGL tends to work much nicer (YMMV).

[+Omegamatrix]

Nothing is being done yet for PFx, since we never considered them before. I suppose it's simply a matter of tracking writes to PF0/PF1/PF2 in the same place in the code were GRP0/GRP1 is checked?

Yes, they should be treated the same as GRPx. Missiles are too tricky to treat like GFX. I always leave them as data. It's just the best way. You'll often find missile enables doubled up with other data. Then you've got to pick out which NUSIZx writes are being used when the missiles are enabled.

 

To me GFX is directly editible bit by bit which means GRP0, GRP1, PF0, PF1, and PF2.

 

 

One thing that would be nice, though, is to have another directive for this. Perhaps PGFX for playfield stuff, and GFX for normal stuff? The reason being, a different directive would allow to output the disassembly slightly differently, based on the type. In fact, I've already been considering not using 'X' for GRPx bits, but something more graphical. Maybe blocks or something, and with colour too. Differentiating this output between GRPx and PFx would be visually striking, and hence very easy to spot.

 

I like the idea of blocks instead of bits, but it's much better once I get a visual to capture your vision. Distella of course is fine with X's, but Stella's debugger could certainly expand on that. Hard to believe all of this came out of an initial idea to pass configuration files to the debugger, eh? I like it.

[+stephena]

Time for another test release: Stella-3.3_test9-windows.zip. This one has some nice improvements:

 

- Added PGFX directive, which is used for playfield graphics (as opposed to GFX, which is for player graphics).

- Added pgfx, row, and skip commands to the debugger prompt, which manually set the specified directives
  (SKIP won't be implemented until the next release).

- The hierarchy for directives is as follows: first manual directives, then results from the emulation core (dynamic analysis),
  then from Distella (static analysis).

- GFX are now shown with a large 'period', and PGFX are shown with a large 'dash'.  This looks a lot nicer than using 'X',
  and serves to differentiate the two.

- Sometimes Distella will mark an address as CODE even if the emulation core doesn't agree (usually occurs after a
  relative branch).  Two cases are possible:
   (1) it actually is code, but it hasn't been run yet
   (2) it is something else, DATA, ROW, etc, and will never be run as CODE
  Since we have no way of conclusively knowing which one is true, the disassembly is shown as code, but a '*' is appended
  to it, indicating that the results are tentative.
  Large blocks of such results with weird disassembly probably means it isn't actually code at all.

- PC labels as addresses are now aligned with string labels, and are shown in a different color.  These can still be
  toggled on or off, of course.

 

Anyway, that's it for now. Barring any major problems with this code, I'd like to do a 3.3 release soon.