Jump to content
IGNORED

Distella configuration files


stephena

Recommended Posts

I was going to post today to see how you were doing. :)

 

I tried Skiing first. The Activision logo in Skiing are not showing up as GFX. They are here:

 

    XXXXXXXX    XXXXXXX            ;  $F76C, $F76D, $F76E, $F76F
X     X   X   XX                  ;  $F75C, $F75D, $F75E, $F75F
XXX XX X X X  XX  XXX X XXX X  X   ;  $F74C, $F74D, $F74E, $F74F
X X X  X X X XX X X   X X X XX X   ;  $F73C, $F73D, $F73E, $F73F
XXX X  X X XXX  X XXX X X X XXXX   ;  $F72C, $F72D, $F72E, $F72F
X X X  X X XX   X   X X X X X XX   ;  $F71C, $F71D, $F71E, $F71F
X X XX X X X    X XXX X XXX X  X   ;  $F70C, $F70D, $F70E, $F70F

 

 

Then I tried Skeet Shoot, and found the numbers weren't being marked in the rom as playfield GFX. I did a little digging in Skeet Shoot and it looks like the GFX are loaded into ram, and then loaded into PFx registers. In another case the data gets pushed onto the stack a bunch of times before it gets used. If you open Skeet Shoot up and follow it as it draws the numbers you'll see what I mean.

 

I couldn't see any dashes in any of the games I tried for PFx. Is there a particular game you were testing with it? I want to see how they look. ;)

 

I can't pick out the labels too well from the regular addresses. This is because I'm colorblind. A slight bold to the labels might help if you want to try. I can't say for sure until I see it though.

 

The GFX really pop out now. I was wondering if had considered black boxes with a little gap inbetween?

 

 

Good progress here, Stephena.

Link to comment
Share on other sites

I think you'll find a lot of conflicts with Distella and Stella. I'm hard pressed to think of more then a handful of games that don't need a configuration file for Distella. This is mostly because of the unconditional branching or indirect jumps. Distella will go happily about its way disassembling data because it doesn't know the code has stopped. Stella is superior as it can mark bits of code as it is processed, and will always be much more accurate.

 

 

There will be many, many conflicts between Distella and Stella. I find marking them in the debugger window distracting, to be honest. Is there a good use for them that I'm just not thinking of? What is the idea behind marking these, Stephena?

Link to comment
Share on other sites

Then I tried Skeet Shoot, and found the numbers weren't being marked in the rom as playfield GFX. I did a little digging in Skeet Shoot and it looks like the GFX are loaded into ram, and then loaded into PFx registers. In another case the data gets pushed onto the stack a bunch of times before it gets used. If you open Skeet Shoot up and follow it as it draws the numbers you'll see what I mean.

Determining if an address is GFX or PGFX is being done as you suggested; tracking accesses to the A/X/Y registers on LDx, and marking on STx. So it's not surprising that it doesn't work when the data is stored in an intermediate location; there's no allowance for that all yet. I'm not even sure how we'd do it, to be honest.

 

I couldn't see any dashes in any of the games I tried for PFx. Is there a particular game you were testing with it? I want to see how they look. ;)

I tested them in River Raid, mostly.

 

I can't pick out the labels too well from the regular addresses. This is because I'm colorblind. A slight bold to the labels might help if you want to try. I can't say for sure until I see it though.

Yes, I'm not entirely satisfied with the colouring yet. Making it bold would be nice, but that would necessitate using another font. Colouring is easier, but will obviously cause a problem if one is colour-blind. I have to think about this some more.

 

The GFX really pop out now. I was wondering if had considered black boxes with a little gap inbetween?

They basically are black boxes, just with the corners rounded a little. I played around with it, and those look the best IMO. Also, I have to make them different from the playfield graphics and also different from all other characters. With 8 pixels of width to play with, we don't have much variation.

 

I think you'll find a lot of conflicts with Distella and Stella. I'm hard pressed to think of more then a handful of games that don't need a configuration file for Distella. This is mostly because of the unconditional branching or indirect jumps. Distella will go happily about its way disassembling data because it doesn't know the code has stopped. Stella is superior as it can mark bits of code as it is processed, and will always be much more accurate.

True, but there are times that Distella helps too. Specifically, if code hasn't yet been executed in emulation core and Distella can see it as code, it should be disassembled as such. Otherwise, you may not realize it's code until the code path is followed, with may only happen under certain (unknown) circumstances. Maybe you'd have to lose a life, switch difficulty settings, use 2-player mode, etc.

 

There will be many, many conflicts between Distella and Stella. I find marking them in the debugger window distracting, to be honest. Is there a good use for them that I'm just not thinking of? What is the idea behind marking these, Stephena?

For CODE sections, I thought it would be useful to differentiate between addresses that are definitely CODE (as determined by the emulation core), and those that are tentatively CODE (as determined by Distella). This is useful when you see a sequence of weird looking results. If they're real CODE, they should be left alone. But if they're from Distella, it could indicate a mis-disassembly (or a bug in Stella itself). I guess I could make it optional with a right-click menu item, but I definitely see a use for it.

 

Related to that last part, there's still some work to do here. For example, if the emulation core definitively marks something as DATA/GFX/PGFX after a relative branch, we should override Distella tentatively marking it as CODE. In other words, things defined definitively should always override those defined tentatively. I haven't implemented this yet, as it makes things more complicated. Not only do we have the hierarchy mentioned above, but now we have to consider the source of marking the address.

 

As well, I haven't finished this infrastructure for more esoteric bankswitch schemes, so in those cases you'll always see '*' in the disassembly (because the results are entirely from Distella, without regard to the emulation core).

Link to comment
Share on other sites

So it's not surprising that it doesn't work when the data is stored in an intermediate location; there's no allowance for that all yet. I'm not even sure how we'd do it, to be honest.

 

The only way I can think of is to store the address of the data in a table as it is stored in ram. This could work for the PLA as well, but all those PHA/PLA in a row are a problem. However I don't think that particular situation is all that common, but in general storing PFx graphics in ram to be used later is.

 

Also, I just noticed you added a "source" for A,X,Y. Thank you for that!! It is a brilliant idea. It is a huge headache to calculate the offset sometimes. That really is usefult. :D

 

 

I tested them in River Raid, mostly.

 

I tried it, but still haven't seen any dashes??

 

 

Yes, I'm not entirely satisfied with the colouring yet. Making it bold would be nice, but that would necessitate using another font. Colouring is easier, but will obviously cause a problem if one is colour-blind. I have to think about this some more.

 

I'll probably just use the existing toggle switch that shows the labels only. The labels jump out just fine for me that way. :)

 

 

They basically are black boxes, just with the corners rounded a little. I played around with it, and those look the best IMO. Also, I have to make them different from the playfield graphics and also different from all other characters. With 8 pixels of width to play with, we don't have much variation.

 

If you could somehow stretch the dots vertically it might join them together better. I think the gap between the rows is throwing my eyes off a little bit. Looking horizontally at the sprite the dots look great, but up and down they are quite spaced apart.

 

 

Specifically, if code hasn't yet been executed in emulation core and Distella can see it as code, it should be disassembled as such. Otherwise, you may not realize it's code until the code path is followed, with may only happen under certain (unknown) circumstances. Maybe you'd have to lose a life, switch difficulty settings, use 2-player mode, etc.

 

Actually, I just realized how useful this is for spotting unused code areas too. If we ever get to the point of doing some global configuration files this might be a great way to mark garbage code. Just leave that area out of the configuration file and it'll still be marked by DiStella and conflicted by Stella.

 

 

to that last part, there's still some work to do here. For example, if the emulation core definitively marks something as DATA/GFX/PGFX after a relative branch, we should override Distella tentatively marking it as CODE. In other words, things defined definitively should always override those defined tentatively. I haven't implemented this yet, as it makes things more complicated. Not only do we have the hierarchy mentioned above, but now we have to consider the source of marking the address.

 

Thinking of it now, how about just using the Stella determination for the debugger? I mean don't use the Distella code at all. As the code gets marked it appears and remains code in the debugger, GFX would be marked as GFX, etc... It sure would simplify things. The global config files would help in this case as the game would be able to mark places it hadn't discovered yet with them.

 

This just gave me another idea. Eventually, at the end of this project, add a command line (or button) to have a disassembly outputted straight from Stella. The command line would be better as you could make changes to the disassembly, choose switches, etc... But basically the global config file would be checked first, then the current findings from Stella, and finally Distella would be used to fill in all the gaps. What do you think?

Link to comment
Share on other sites

The only way I can think of is to store the address of the data in a table as it is stored in ram. This could work for the PLA as well, but all those PHA/PLA in a row are a problem. However I don't think that particular situation is all that common, but in general storing PFx graphics in ram to be used later is.

Seems like it could work, but I have to think about it a little more. I want to stabilize the new code before I consider adding this.

 

Also, I just noticed you added a "source" for A,X,Y. Thank you for that!! It is a brilliant idea. It is a huge headache to calculate the offset sometimes. That really is usefult. :D

Yes, I initially added it to make sure the stores to GRPx and PFx were working correctly. But in general, it's a useful feature anyway.

 

I tested them in River Raid, mostly.

I tried it, but still haven't seen any dashes??

One set starts at $FC58, and another at $FD07.

 

If you could somehow stretch the dots vertically it might join them together better. I think the gap between the rows is throwing my eyes off a little bit. Looking horizontally at the sprite the dots look great, but up and down they are quite spaced apart.

I just made them a little higher, but even if they were full height, there's still a gap between lines themselves.

 

Thinking of it now, how about just using the Stella determination for the debugger? I mean don't use the Distella code at all. As the code gets marked it appears and remains code in the debugger, GFX would be marked as GFX, etc... It sure would simplify things. The global config files would help in this case as the game would be able to mark places it hadn't discovered yet with them.

It might simplify things, but it wouldn't give as nice results, IMO. I think it's nice to see all the code, even stuff that hasn't run yet. Besides, I'm mostly finished with this now, and ripping out Distella would be moving backwards.

 

This just gave me another idea. Eventually, at the end of this project, add a command line (or button) to have a disassembly outputted straight from Stella. The command line would be better as you could make changes to the disassembly, choose switches, etc... But basically the global config file would be checked first, then the current findings from Stella, and finally Distella would be used to fill in all the gaps. What do you think?

I'll consider this after the 3.3 release. The disassembly that Stella shows isn't exactly valid for DASM (it doesn't contain ORG statements, certain things aren't commented out, etc), and this would have to be fixed first.

Link to comment
Share on other sites

Yes, I initially added it to make sure the stores to GRPx and PFx were working correctly. But in general, it's a useful feature anyway.

 

It sure is!!

 

One set starts at $FC58, and another at $FD07.

 

Okay, now I see it. I had a .cfg file in there before that was overriding it. I thought they were the same dots as the player's GFX at first. I'm anxious to see how the new GFX for players look stretched! I realize there will still be a little gap, but I think it'll look more like a complete GFX and be easier to recognize. If the stretched dots look good maybe you could use them for both GFX and PGFX, but maybe color code the dots a dark green for the PGFX to differentiate? Green symbolizes lawn to me, and I sort of think of that when I think of playfield. As long as it's not a light, bright green I should be able to see it. Black is a great color for player GFX. Anyhow sorry about not seeing them in River Raid before. That was my bad.

 

 

I'll consider this after the 3.3 release. The disassembly that Stella shows isn't exactly valid for DASM (it doesn't contain ORG statements, certain things aren't commented out, etc), and this would have to be fixed first.

 

I think this is the way to go. I mean why have a separate Distella program? I agree with getting everything working well before looking at this.

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

OK, I've made some more progress on the register tracking. Registers modified with LAX, TAX, TAY, TXA and TYA are now processed, similar to LDx. Still TODO is PHA, PHP, PLA and PLP, and to somehow track items that are saved to ZP RAM first. I hope to get both these latter ones done before the next release, so if anyone has any advice on how to proceed, now is the time to let me know. Otherwise, I'll be doing a new release in the next week or so, and will have to push the remaining stuff to post 3.3.

Link to comment
Share on other sites

I've now implemented register tracking for TXS and TSX, but I'm not sure all cases are being taken care of. I've also added support for ORA, but again, I'm not entirely sure if this is way it should be done. It does allow to catch all addresses in Skiing (as described above), but I'm not sure of the semantics for arithmetic/logical opcodes. Up to this point, I was only modifying 'move' opcodes, where it's clear what should be done. Still have to look at PHA and friends ...

Link to comment
Share on other sites

Here's another test release: Stella-3.3_test11-windows.zip

 

This one has the fixes mentioned above. Skiing now properly marks all relevant sections as GFX (or at least the ones I know about). This was because of missing register tracking support for ORA, TSX and TXS. Skeet Shoot uses an intermediate location first, and probably won't be implemented for this release.

 

In fact, I may be ready to do a new release soon, even if this stuff isn't finished. This was/is a very big undertaking, and I suspect there's much more testing required before everything is rock-solid. My plan is to get all accesses working where the address of GFX is direct (ie, a straight load from ROM to gfx register). Once that's complete, then I'll consider intermediate accesses (ie, loading to RAM first, then storing to gfx registers). But all of this depends on testing from multiple sources ...

Link to comment
Share on other sites

This is great work, Stephena. I have been extremely busy with real life at the moment or I would have replied sooner. It's good to have Skiing now show the GFX, but I haven't tested it.

 

 

 

With the ram locations I think you need to create an array that holds the source address for every write to them. Then when you load A, X, or Y from a ram location you look up the source address and store it as a temp variable. It will work, the only problem is how much overhead?

 

 

 

Keep up the good work, Stephena!!

Jeff

Link to comment
Share on other sites

This is great work, Stephena. I have been extremely busy with real life at the moment or I would have replied sooner. It's good to have Skiing now show the GFX, but I haven't tested it.

 

 

 

With the ram locations I think you need to create an array that holds the source address for every write to them. Then when you load A, X, or Y from a ram location you look up the source address and store it as a temp variable. It will work, the only problem is how much overhead?

 

 

 

Keep up the good work, Stephena!!

Jeff

Yes, that's pretty much what I figured for the RAM locations. I need to think about this a little more, and also address potential slowdowns, so I'm going to do the 3.3 release first. I'll then deal with these issues in either 3.3.x or 3.4.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...