Stella break command

[Omegamatrix]

On 5/31/2023 at 4:54 AM, JetSetIlly said:

I don't have that much experience with creating multi-bank ROMs but I used the FatalRun disassembly as a test case and it seems to work as expected. The symbols file is organised nicely.

It is nice to see someone using one of my old disassemblies! 😀

[Thomas Jentzsch]

8 hours ago, JetSetIlly said:

It's not a choice 🙂 I'd love it if we could

I know DASM can be pretty unruly.  

 

It is not nice, but we could do the following:

  MAC BANKLABEL ; label
{1}
    IF __2600BANK == 0
0_{1}
    ENDIF
    IF __2600BANK == 1
1_{1}
    ENDIF
    IF __2600BANK == 2
2_{1}
    ENDIF
  ...

  ENDM

 

[Thomas Jentzsch]

deleted

Edited June 2, 2023 by Thomas Jentzsch

[Thomas Jentzsch]

deleted

Edited June 2, 2023 by Thomas Jentzsch

[JetSetIlly]

48 minutes ago, Omegamatrix said:

It is nice to see someone using one of my old disassemblies! 😀

 

Oh yes! Thanks. It was very useful.

 

51 minutes ago, Omegamatrix said:

 

I'm in the camp where it would be hugely beneficial to have DASM create extra parameters that could be used to tell where a label is located. I wonder if it would be easier just though to have the label as it is now in the symbol table (follows RORG), and another column that has the actual rom location (follows ORG).

example:

foo       F034  0034

 

Why this and not the bank? Well it probably is easier to implement in DASM without telling it what bank scheme it needs to follow. On the emulator side there could be a routine that figures out banks, slices, etc... as sometimes those get really exotic.

I don't think we would need to indicate the bank scheme. You just need a way of numbering the bank.

 

Using the Supercharger format as an example: When we disassemble the binary, we've already identified which bank switching scheme we need. The (hypothetical) symbols file provides an address and bank number. The scheme information (in the emulator) knows what the possible origins for each bank is. Using the symbol information and the internal emulator information we can create a symbol table for each bank regardless of where it is in memory. In the case of Supercharger, would have two entries per symbol - one for each origin address.

 

51 minutes ago, Omegamatrix said:

With DASM what really bothers me about the symbols list is that literally everything defined (rom labels, constants, zp ram, vcs registers, and other segments...) is all thrown into the same soup. It would be so much better if the symbol table was broken up into sections, or multiple files. I found it off-putting whenever I have used a symbol table in Stella because lots of constants have the same value, and it often renames constants different to my source because (obviously it has no way to determine which is which). If DASM could list each address a constant is used at, then it would completely clear up that issue. It doesn't bother me if the table gets really long as the benefit would outweigh the length IMHO. Maybe just make a new type of symbol file and list it all.

That would be the best solution of all. A symbols file that is well structured and does a better job of differentiating symbol types.

 

 

[JetSetIlly]

13 minutes ago, Thomas Jentzsch said:

I know DASM can be pretty unruly.  

 

It is not nice, but we could do the following:

  MAC BANKLABEL ; label
{1}
    IF __2600BANK == 0
0_{1}
    ENDIF
    IF __2600BANK == 1
1_{1}
    ENDIF
    IF __2600BANK == 2
2_{1}
    ENDIF
  ...

  ENDM

 

That would work well.

[Thomas Jentzsch]

7 minutes ago, JetSetIlly said:

That would be the best solution of all. A symbols file that is well structured and does a better job of differentiating symbol types.

Yes, but how would DASM know that, without further extensions?

[JetSetIlly]

4 minutes ago, Thomas Jentzsch said:

Yes, but how would DASM know that, without further extensions?

Well, it would't. It needs a new directive. Something like BANK or GROUP or similar, to effectively say "all symbols from this point until the next BANK or the end of the file, will have the BANK number specified in the symbols file". I think that would be a good improvement for DASM.

 

edit: Obviously, the BANK directive would be written as "BANK 6" or whatever. It wouldn't even have to be numeric.

Edited June 2, 2023 by JetSetIlly

[Thomas Jentzsch]

1 minute ago, JetSetIlly said:

Well, it would't. It needs a new directive. Something like BANK or GROUP or similar, to effectively say "all symbols from this point until the next BANK or the end of the file, will have the BANK number specified in the symbols file". I think that would be a good improvement for DASM.

And if the GROUP would have a label, then we could use well defined labels for our disassemblers. Maybe that's a good suggestion to the DASM team?

[JetSetIlly]

7 minutes ago, Thomas Jentzsch said:

And if the GROUP would have a label, then we could use well defined labels for our disassemblers.

I believe the disassembler only needs to know the bank number. So, literally just "GROUP 1" or "BANK 5" or whatever they settle on. Representation in the symbol file might be as simple as:

 

William_F_Sessions_FBI_One d2e6 /6             (R )

 

But that may break other tools that rely on the existing sym format. It would probably be better to have a command line switch to indicate which sym file version to use.

 

 

Edited June 2, 2023 by JetSetIlly

[Thomas Jentzsch]

1 hour ago, JetSetIlly said:

I believe the disassembler only needs to know the bank number. So, literally just "GROUP 1" or "BANK 5" or whatever they settle on. Representation in the symbol file might be as simple as:

 

William_F_Sessions_FBI_One d2e6 /6             (R )

 

But that may break other tools that rely on the existing sym format. It would probably be better to have a command line switch to indicate which sym file version to use.

An option for labels ordered by their appearance in the code would help. Then we could define the groups ourselves.

 

I think, that could solve the bank and the label problems.

Edited June 2, 2023 by Thomas Jentzsch

[Thomas Jentzsch]

@JetSetIlly Are you using Windows? If so, I compiled a modified version which allows sorting the symbol table by order of first appearance in code. 

 

Please let me know what you think about it.

 

dasm.exe

Edited June 2, 2023 by Thomas Jentzsch

[JetSetIlly]

2 hours ago, Thomas Jentzsch said:

@JetSetIlly Are you using Windows? If so, I compiled a modified version which allows sorting the symbol table by order of first appearance in code. 

 

Please let me know what you think about it.

dasm.exe 284.23 kB · 0 downloads

I don't have access to Windows. I can compile dasm here though if you want to share a git branch.

[Thomas Jentzsch]

21 minutes ago, JetSetIlly said:

I don't have access to Windows. I can compile dasm here though if you want to share a git branch.

Branch

Pull Request

Edited June 2, 2023 by Thomas Jentzsch

[JetSetIlly]

12 minutes ago, Thomas Jentzsch said:

Branch

Pull Request

Is this just sorting by line number? I think that's sufficient.

 

 

There might be a case of being able to reopen a group later in the listing. For example, you might want to define constants at the beginning, middle and end of the listing. This isn't really a dasm issue but it's something to consider for the naming protocol we come up with.

 

A simple solution would be to be able to say DASM_CONSTS and then later on, DASM_CONSTS__1, etc.. This prevents dasm from complaining about a duplicate symbol and the disassembler can ignore the double-underline and anything after it.

[Thomas Jentzsch]

5 minutes ago, JetSetIlly said:

Is this just sorting by line number? I think that's sufficient.

Exactly.

5 minutes ago, JetSetIlly said:

There might be a case of being able to reopen a group later in the listing. For example, you might want to define constants at the beginning, middle and end of the listing. This isn't really a dasm issue but it's something to consider for the naming protocol we come up with.

 

A simple solution would be to be able to say DASM_CONSTS and then later on, DASM_CONSTS__1, etc.. This prevents dasm from complaining about a duplicate symbol and the disassembler can ignore the double-underline and anything after it.

Yup. I thought about this too. We are totally free here, the logic is in our code.

 

So, which groups do we need?

• Constants: We probably have to split the constants between e.g. color or game constants and hardware registers. 
• Variables: Should we split this between ZP and extended RAM?
• Banks: Just numbering them seems sufficient, no?
• How about e.g. macros and subroutines, will they break anything?
• ...?

Edited June 2, 2023 by Thomas Jentzsch

[JetSetIlly]

48 minutes ago, Thomas Jentzsch said:

Exactly.

Yup. I thought about this too. We are totally free here, the logic is in our code.

 

So, which groups do we need?

• Constants: We probably have to split the constants between e.g. color or game constants and hardware registers.

Being able to split constants into colors and other variables would be useful.

 

You don't *need* a hardware registers group. If you know the bank switching scheme then you know the registers. But I suppose if the ROM programmer defines them then they need a group to go in.

 

48 minutes ago, Thomas Jentzsch said:

• Variables: Should we split this between ZP and extended RAM?

The addresses should give sufficient information. So one variable group would seem fine to me.

 

48 minutes ago, Thomas Jentzsch said:

• Banks: Just numbering them seems sufficient, no?

I think it is sufficient. All schemes basically boil down to having numbered banks, regardless of bank size or placement.

 

48 minutes ago, Thomas Jentzsch said:

• How about e.g. macros and subroutines, will they break anything?

If you want to encode information about macros and subroutines then I think we're looking at something more complex than a symbol file. It would be very nice to have but if you want to go down that road it might worth thinking about a new format altogether.

[JetSetIlly]

It might be best if we simply say the following pattern is reserved

 

2600CONST_<group>

 

and then allow the programmer to define the groups as they see fit.

 

 

Same with variables:

 

2600VARIABLE_<group>

 

 

Banks would have to be limited to numeric information I think

 

2600BANK_0

2600BANK_1

...

 

 

edit: Or maybe allow a bank label

 

2600BANK_0_<label>

 

or just

 

2600BANK_0

 

if the ROM programmer doesn't want one.

 

 

 

Edited June 2, 2023 by JetSetIlly

[Thomas Jentzsch]

14 minutes ago, JetSetIlly said:

You don't *need* a hardware registers group. If you know the bank switching scheme then you know the registers. But I suppose if the ROM programmer defines them then they need a group to go in.

 

The addresses should give sufficient information. So one variable group would seem fine to me.

But e.g. RESP0 is a constant just like YELLOW (both = $10). The disassembler should know which to use in which case (lda #YELLOW, sta RESP0). Some TIA registers are for reading and some for writing. But for the assembler they are all just constants.

14 minutes ago, JetSetIlly said:

If you want to encode information about macros and subroutines then I think we're looking at something more complex than a symbol file. It would be very nice to have but if you want to go down that road it might worth thinking about a new format altogether.

I was just afraid if these might break the general idea.

[Thomas Jentzsch]

15 minutes ago, JetSetIlly said:

It might be best if we simply say the following pattern is reserved

 

2600CONST_<group>

I would prefer a DASM prefix (DASM_GROUP_<group> for simple groups), since we are talking about DASM's sym files. But I won't insist.  

 

But for the 8-bit symbols, we need extra info:

• Hardware register, usually not immediate used, read or write, (e.g. WSYNC vs. CXP0FB)
• Variable, usually not immediate used (>= $80, read and write)
• "normal" constant, usually immediate used

15 minutes ago, JetSetIlly said:

Banks would have to be limited to numeric information I think

...

2600BANK_0_<label>

 

or just

 

2600BANK_0

 

if the ROM programmer doesn't want one.

That's fine.

[Omegamatrix]

13 hours ago, JetSetIlly said:

I don't think we would need to indicate the bank scheme. You just need a way of numbering the bank.

I would advocate that the emulator itself should be the tool to figure out what bank an address label belongs to by using the origin address of that label. Consider an E0 game that is 8K. There are 4 slices within a 4k bank size. If the emulator knows the game is E0 then it can assign slice numbers to the labels, and all the additional information the emulator really needs is the origin address for each label. This would be less complicated then trying to get DASM to figure out banks or having the user add more macros.

 

In thinking it over today I feel the optimal solution from a user perspective is keeping the .sym file as is in DASM, and having DASM creating additional files for detailed labels, constants, etc... That way nothing breaks for any user that incorporates the .sym files today and existing emulators would also be okay. Older versions of Stella would not be affected by a changed .sym file for example. I don't know why anyone would object to a branch like this if nothing breaks for backward compatibilty and is an improvement going forward.

 

The new files from DASM should at minimum be a standalone address label listing file for ROM. Another good file would be a symbol file with addresses for defined operands. In that file it would be a simple substitution for the emulator for COLUBK, myVariables, MY_CONSTANTS, etc... as each symbol has the origin addresses where it is used, and again this gets around the issue of mulitple different constants with the same value. It also won't be 2600 specific code as DASM would just be listing the operand symbol defined by the user at addresses it is used.

[Thomas Jentzsch]

17 minutes ago, Omegamatrix said:

I would advocate that the emulator itself should be the tool to figure out what bank an address label belongs to by using the origin address of that label.

If that would be possible, we would have done so already.  E.g. one problem is, that banks frequently share the same origin. And there are only 8 different origins available.

17 minutes ago, Omegamatrix said:

Consider an E0 game that is 8K. There are 4 slices within a 4k bank size. If the emulator knows the game is E0 then it can assign slice numbers to the labels, and all the additional information the emulator really needs is the origin address for each label. This would be less complicated then trying to get DASM to figure out banks or having the user add more macros.

If two banks are designed for the same slice, they will have the same 13 bit address.

 

DASM doesn't have to figure out anything, it just lists the symbols in programming order. That way, unlike today, the symbol order reflects the code order. And the developer provides the required 2600 specific, extra info by using some well defined labels (with or without macros).

17 minutes ago, Omegamatrix said:

In thinking it over today I feel the optimal solution from a user perspective is keeping the .sym file as is in DASM, and having DASM creating additional files for detailed labels, constants, etc... That way nothing breaks for any user that incorporates the .sym files today and existing emulators would also be okay. Older versions of Stella would not be affected by a changed .sym file for example. I don't know why anyone would object to a branch like this if nothing breaks for backward compatibilty and is an improvement going forward.

The new sym-file ordering will not break anything. And adding extra platform specific files (and code) to a multi-platform assembler will not be easily accepted. Just adding a new sort option is much less invasive. And it provides all the info the disassemblers need.

[Omegamatrix]

1 hour ago, Thomas Jentzsch said:

If that would be possible, we would have done so already.  E.g. one problem is, that banks frequently share the same origin. And there are only 8 different origins available.

Sorry Thomas, what makes it impossible? To be clear here when I am talking about origin I am referering to the physical rom address, i.e. if you were looking at it in a hex editor.

 

The simple idea here is that the emulator loads the rom and the new symbol files from DASM, and then it creates a new reference for itself for defined address labels, and defined operands. How the linkage for this reference is maintained is up to the emulator, but does not have to be complicated. Certainly banks shift in and out (E0 for example has slices that move around), but the linkages are built from the physical rom.

 

  

1 hour ago, Thomas Jentzsch said:

DASM doesn't have to figure out anything, it just lists the symbols in programming order. That way, unlike today, the symbol order reflects the code order. And the developer provides the required 2600 specific, extra info by using some well defined labels (with or without macros).

It sounds like a lot more effort on the coding side to get well defined labels with macros, so I don't know how well it would be recieved especially if we could do it another way and be fully automated. I will say also that it would not solve the issue of having constants defined wrong in the emulator as there is still no reference for them. I.e. many things could be #$07.

 

  

1 hour ago, Thomas Jentzsch said:

The new sym-file ordering will not break anything. And adding extra platform specific files (and code) to a multi-platform assembler will not be easily accepted. Just adding a new sort option is much less invasive. And it provides all the info the disassemblers need.

The point is the new files would NOT be platform specific. Just the opposite, they are just a list of address labels like the sym file with the physical rom origin added. The other file is a list of defined operands and the physical rom location they are used. DASM doesn't know they are for the 2600 or anything.

[JetSetIlly]

This is a good time to summarise my thoughts on this thread:

 

For me, this thread is about enforcing a protocol between DASM and the disassembler by way of the symbols file. What Omegamatrix outlines in his last post would work, but it would not be clear to me from a ROM programmers point of view how to deal with for example, small banks. Yes, there is a way to do it but personally, I believe a BANK directive in the assembler would be a better solution because it enforces the rule.

 

(The reason Stella or any other emulator hasn't tied symbols to addresses is because it's not at all clear that this is a standard way of doing things. Making a declaration now that this is how should work wouldn't change that, IMO 🙂 )

 

In the absence of a BANK directive, the macros have been a way of exploring different ways of achieving the same goal. The implementations are messy but I believe Thomas' new sort method is good enough to allow simple macros to be created. The macros would be contained in a "standard" 2600 header file, maybe macro.h or maybe a new header file.

[Thomas Jentzsch]

8 hours ago, Omegamatrix said:

Sorry Thomas, what makes it impossible? To be clear here when I am talking about origin I am referering to the physical rom address, i.e. if you were looking at it in a hex editor.

The problem is, that the symbols are not coming with their physical ROM address. And they are currently (re)ordered, either by name or by (logical) value/address. Therefore you can have multiple symbols with the same logical address. So the disassembler can only make a best guess, which label belong to a certain address.

8 hours ago, Omegamatrix said:

It sounds like a lot more effort on the coding side to get well defined labels with macros, so I don't know how well it would be recieved especially if we could do it another way and be fully automated.

I also wish this would work, but see above.

8 hours ago, Omegamatrix said:

I will say also that it would not solve the issue of having constants defined wrong in the emulator as there is still no reference for them. I.e. many things could be #$07.

Exactly. By creating groups with a certain meaning, we can solve that problem. 

8 hours ago, Omegamatrix said:

The point is the new files would NOT be platform specific. Just the opposite, they are just a list of address labels like the sym file with the physical rom origin added. The other file is a list of defined operands and the physical rom location they are used. DASM doesn't know they are for the 2600 or anything.

Looking at the DASM code, it seems like this would be a pretty invasive change. Everything is based on symbols, the physical ROM address is not available at multiple places. Maybe have a look at the code yourself.