Stella break command

[Just Jeff]

Good Morning,

 

I have an issue in Stella where the break command fails to break at the spot in the code.  Stella seems to be confused by the bank switching.  For example it thinks this label is in bank one but its really in bank four:

 

But its in 4

 

 

I've verified that it is running through the PackRAM routine.. Does anyone know how to fix this?  Thanks!

 

 

Edited May 29, 2023 by Just Jeff

[Thomas Jentzsch]

The break you did set will only work in bank 1 (see output, IIRC it uses the current bank as default). If you want to break in bank 4, you have to add the bank as additional parameter.

 

The problem is, that DASM doesn't provide any bank information. So Stella cannot know in which bank the label is located.

[JetSetIlly]

On 5/29/2023 at 5:03 PM, Thomas Jentzsch said:

The break you did set will only work in bank 1 (see output, IIRC it uses the current bank as default). If you want to break in bank 4, you have to add the bank as additional parameter.

 

The problem is, that DASM doesn't provide any bank information. So Stella cannot know in which bank the label is located.

Has anyone tried to adapt DASM so that it does export bank information in the symbols file? I suppose it would require new assembly directives but it would be worth the 2600's programmers time to add that information.

[Thomas Jentzsch]

14 minutes ago, JetSetIlly said:

Has anyone tried to adapt DASM so that it does export bank information in the symbols file? I suppose it would require new assembly directives but it would be worth the 2600's programmers time to add that information.

I had suggested this to the DASM team, but it got dismissed.  

 

We (emulator developers) could define our own, 2600 specific, bank-switching pseudo-ops. Then the emulators could look for these in the .sym files (using -T1 = sorted by address/value). 

 

We could e.g. reserve __BANK_<num> for the start of a new bank and maybe provide a set of macros for making use of it. But would that be enough or would we need more info?

 

@JetSetIlly What are your thoughts here?

[JetSetIlly]

15 minutes ago, Thomas Jentzsch said:

We could e.g. reserve __BANK_<num> for the start of a new bank and maybe provide a set of macros for making use of it. But would that be enough or would we need more info?

 

@JetSetIlly What are your thoughts here?

I think that would probably be enough. All we want to say is "this symbol belongs to this bank".

 

I've not thought it through, but I don't think the segmented/relocatable schemes would need any special handling either. The symbol belongs to the specified bank regardless of it's address.

 

What kind of macros do you think might be useful?

[Thomas Jentzsch]

14 minutes ago, JetSetIlly said:

What kind of macros do you think might be useful?

I think, as long as DASM has no option for unsorted .sym output, we have to sort the RORGs, so that the addresses are ascending order. Unfortunately that will only work up to 8 4K banks. So we probably should define a macro for the start of a new bank. Which keeps track of the current bank and uses the correct RORG (and ORG). 

 

[JetSetIlly]

17 minutes ago, Thomas Jentzsch said:

I think, as long as DASM has no option for unsorted .sym output, we have to sort the RORGs, so that the addresses are ascending order. Unfortunately that will only work up to 8 4K banks. So we probably should define a macro for the start of a new bank. Which keeps track of the current bank and uses the correct RORG (and ORG).

I see. So you'd have a BANK macro that outputs the __BANK_N symbol and also the correct ORG and RORG. That would be neat.

 

 

[Thomas Jentzsch]

36 minutes ago, JetSetIlly said:

I see. So you'd have a BANK macro that outputs the __BANK_N symbol and also the correct ORG and RORG. That would be neat.

Yes, but only if I can convince DASM to work like I want it to work.  

[JetSetIlly]

15 hours ago, Thomas Jentzsch said:

Yes, but only if I can convince DASM to work like I want it to work.  

I'm thinking something as simple as this would work:

 

; BANK.H
; Version 1.00, 31/May/2023

VERSION_BANK         = 100

            MAC BANK ; usage: BANK n
	ORG ({1} * $1000)
	RORG ({1} * $2000) + $1000
__2600BANK_{1}
            ENDM

 

 

A couple of macros might be useful too:

 

; BANK.H
; Version 1.01, 31/May/2023

VERSION_BANK         = 101

__2600BANK SET -1
__2600BANK_ORG SET $0000
__2600BANK_RORG SET $1000

		MAC BANK ; usage: BANK n
			IF {1} > 7
				ECHO "BANK: bank number", {1}, "is too high"
				ERR
			ENDIF

__2600BANK SET {1}
__2600BANK_ORG SET (__2600BANK * $1000)
__2600BANK_RORG SET (__2600BANK * $2000) + $1000

	ORG __2600BANK_ORG
	RORG __2600BANK_RORG
__2600BANK_{__2600BANK}
		ENDM

		MAC BANKNEXT
			IF __2600BANK == 7
				ECHO "BANKNEXT: cannot advance past bank 7"
				ERR
			ENDIF

__2600BANK SET __2600BANK + 1
__2600BANK_ORG SET (__2600BANK * $1000)
__2600BANK_RORG SET (__2600BANK * $2000) + $1000

	ORG __2600BANK_ORG
	RORG __2600BANK_RORG
__2600BANK_{__2600BANK}
		ENDM

		MAC BANKOFFSET ; usage: BANKOFFSET $0000 to $0FFF
			IF {1} > $0FFF 
				ECHO "BANKOFFSET: offset is out of range", {1}, "for bank", __2600BANK
				ERR
			ENDIF
	ORG __2600BANK_ORG + {1}
	RORG __2600BANK_RORG + {1}
		ENDM

 

 

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.

 

A further enhancement would be to add a macro to specify the bank size, allowing for use with the segmented banking schemes.

 

Have I missed/misunderstood anything?

 

[Thomas Jentzsch]

Looking good. And yes, segmented banking schemes should be supported too. Therefore I wouldn't limit the number of banks.

 

Maybe the macros should support the (most common) bankswitching formats and automatically define bank sizes, offsets etc. E.g. the RORG calculations will be more complex for segmented ROMs. And the RORG of a bank cannot always be calculated, but has to be defined by the developer instead (e.g. a 1K bank #1 which is coded to be mapped into segment 0). 

 

Finally it would be nice, if the macros allowed keeping track of ROM space. I have some macros for doing so. Therefore we should define MY_ORG & MY_REORG as ORG & RORG initially, and use them instead. Then one can simply plugin advanced macros for ORG & RORG.

[JetSetIlly]

20 hours ago, Thomas Jentzsch said:

Maybe the macros should support the (most common) bankswitching formats and automatically define bank sizes, offsets etc. E.g. the RORG calculations will be more complex for segmented ROMs. And the RORG of a bank cannot always be calculated, but has to be defined by the developer instead (e.g. a 1K bank #1 which is coded to be mapped into segment 0).

I'd like to do more work on this but I have zero experience with building a ROM with a segmented bank switching scheme. I've done plenty of work on the emulation side but as you know building the ROM is different. Do you know of any disassemblies of ROMs that used one of these schemes so I can see what the best practice is?

 

[JetSetIlly]

This is an alternative approach that is more flexible because it leaves the task of setting ORG and RORG and the details of the bank switching scheme to the ROM programmer.

 

To reiterate the problem: we want to associate a symbol with a bank number. The previous attempt does this but it relies on RORG never being reused. This limits the number of banks we can use and would present significant problems for segmented banking schemes.

 

So we need another way to encode the bank-symbol relationship.

 

This solution outputs three symbols:

 

1) the supplied symbol (output verbatim)

2) a string containing the bank number and a "key"

3) the supplied symbol and the "key"

 

An example section of a symbols file (from an adapted Fatal Run asm file) produced using this method

 

WinnersDontUseDrugsOne_1003 d212                  
__2600BANK_6_1003        d212                  
WinnersDontUseDrugsOne   d212              (R )
WinnersDontUseDrugsTwo   d27c              (R )
WinnersDontUseDrugsTwo_1004 d27c                  
__2600BANK_6_1004        d27c                  
William_F_Sessions_FBI_One_1005 d2e6                  
William_F_Sessions_FBI_One d2e6              (R )
__2600BANK_6_1005        d2e6                  

 

The three symbols defined here are:

 

1) WinnersDontUseDrugsOne   (key 1003)

2) WinnersDontUseDrugsTwo   (key 1004)

3) William_F_Sessions_FBI_One  (key 1005)

 

From an emulator point of view, connecting the symbol with the bank number is just a string manipulation problem.

 

The macro file:

 

; BANKSYMBOL.H
; Version 1.00, 1/June/2023

VERSION_BANK         = 100

__2600BANK SET -1
__2600BANK_KEY SET 1000

		MAC BANK ; usage: BANK n
__2600BANK SET {1}
		ENDM

		MAC BANKSYMBOL ; usage : BANKSYMBOL symbol
			IF __2600BANK == -1
				ECHO "BANKSYMBOL: bank number has not been set"
				ERR
			ENDIF

.arg SETSTR {1}
			ECHO "outputting", .arg, "as a bank aware symbol for bank", __2600BANK

__2600BANK_KEY SET __2600BANK_KEY + 1

; verbatim output of symbol
{1}

; the bank number and the symbol are conected by the value of __2600BANK_KEY
__2600BANK_,__2600BANK,"_",__2600BANK_KEY
{1}_,__2600BANK_KEY

		ENDM

 

 

Ideally, we would simply output something like the following, but I couldn't get DASM to create an appropriate dynamic label

 

__2600BANK_6_WinnersDontUseDrugsOne d212                            
WinnersDontUseDrugsOne   d212              (R )

 

 

 

As stated, the beauty of this solution is that it leaves the details of the bank switching scheme entirely up to the ROM programmer. There will still be problems with segmented bank switching schemes that I've not thought through, but I think if we standardise the way bank/segments are specified, there shouldn't be too many problems.

[JetSetIlly]

The downside to the solution I should mention is that it's not a drop in solution. You need to specify symbols with the BANKSYMBOL macro, which some people may find objectionable.

 

[Dionoid]

On 5/30/2023 at 8:02 PM, Thomas Jentzsch said:

I had suggested this to the DASM team, but it got dismissed.  

Your suggestion is actually still an open issue, see https://github.com/dasm-assembler/dasm/issues/1

(this was the very first issue reported after DASM moved to GitHub)

Edited June 1, 2023 by Dionoid

[Thomas Jentzsch]

24 minutes ago, Dionoid said:

Your suggestion is actually still an open issue, see https://github.com/dasm-assembler/dasm/issues/1

(this was the very first issue reported after DASM moved to GitHub)

I remembered it as dismissed. Probably because there was no further reaction to the arguments provided, after giving more details.

Edited June 1, 2023 by Thomas Jentzsch

[Thomas Jentzsch]

2 hours ago, JetSetIlly said:

This is an alternative approach that is more flexible because it leaves the task of setting ORG and RORG and the details of the bank switching scheme to the ROM programmer.

Sorry, I cannot follow your thoughts /solution here. Why do you need that key?

2 hours ago, JetSetIlly said:

Ideally, we would simply output something like the following, but I couldn't get DASM to create an appropriate dynamic label

__2600BANK_6_WinnersDontUseDrugsOne d212                            
WinnersDontUseDrugsOne   d212              (R )

What's not working here?

 

BTW: We should try not to create that long labels. A simple prefix like "6_" should do. Else the disassembly will become hard to read (and space is limited too).

2 hours ago, JetSetIlly said:

As stated, the beauty of this solution is that it leaves the details of the bank switching scheme entirely up to the ROM programmer. There will still be problems with segmented bank switching schemes that I've not thought through, but I think if we standardise the way bank/segments are specified, there shouldn't be too many problems.

That's probably the better solution, before we make things too complex.

Edited June 1, 2023 by Thomas Jentzsch

[JetSetIlly]

Just now, Thomas Jentzsch said:

Sorry, I cannot follow your thoughts /solution here. Why do you need that key?

To associate the two symbols with one another.

Just now, Thomas Jentzsch said:

What's not working here?

I can't figure out how to get DASM to generate that line.

Just now, Thomas Jentzsch said:

BTW: We should try not to create that long labels. A simple prefix like "6_" should do. Else the disassembly will become hard to read (and space is limited too).

 

That's probably the better solution, before we make things too complex.

IMO, this is a lot simpler than the previous idea in which the ORG and RORG are manipulated.

 

[JetSetIlly]

4 minutes ago, Thomas Jentzsch said:

BTW: We should try not to create that long labels. A simple prefix like "6_" should do. Else the disassembly will become hard to read (and space is limited too).

You wouldn't include the two symbols with the "key" in the disassembly.

[Thomas Jentzsch]

6 minutes ago, JetSetIlly said:

You wouldn't include the two symbols with the "key" in the disassembly.

Call me stupid, but why do we need the key then?   I do not understand the fundamentals of your idea.

Edited June 1, 2023 by Thomas Jentzsch

[Thomas Jentzsch]

11 minutes ago, JetSetIlly said:

IMO, this is a lot simpler than the previous idea in which the ORG and RORG are manipulated.

I was referring to your idea of leaving things to the developer (agreeing with your reasoning).

[Thomas Jentzsch]

And now I am slowly beginning to understand.  You create three symbols per label and then the emulator uses the three symbols to sort out which symbol belong into which bank.

 

What I do not understand is, why you do not want to create one symbol instead of two or three? E.g.

6_WinnersDontUseDrugsOne   

 

[JetSetIlly]

3 minutes ago, Thomas Jentzsch said:

Call me stupid, but why do we need the key then?   I do not understand the fundamentals of your idea.

Ideally, we would have just one additional symbol but I can't figure out how to get DASM to do that (the rules around dynamic labels aren't as flexible as I hoped). So, the two symbols are a way around what.

 

The real symbol can be connected to the first meta-symbol by the name:

 

Real Symbol:    foo

Keying Symbol:   foo_1001

 

That gives us a key into the bank information:

 

Keying Symbol: foo_1001

Bank Symbol:  __2600BANK_3_1001

 

It's just a way of associating "foo" with bank 3. Once we know that, we can forget about the two additional symbols and simply record in the emulator for disassembly purposes that "foo" is in bank 3. This means that we only need to show that symbol (have breakpoints on, etc.) for that address in that bank.

 

I'd love it if the rules around dynamic labeling were more flexible but I just can't get it to work in any other way. Maybe that would be a good development for DASM.

[JetSetIlly]

3 minutes ago, Thomas Jentzsch said:

And now I am slowly beginning to understand.  You create three symbols per label and then the emulator uses the three symbols to sort out which symbol belong into which bank.

 

What I do not understand is, why you do not want to create one symbol instead of two or three? E.g.

6_WinnersDontUseDrugsOne   

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

[JetSetIlly]

If we're just looking for a standard which emulators can use, as opposed to any fancy symbol manipulation, then this third way is perhaps the most flexible of all:

 

; BANKSYMBOL.H
; Version 1.01, 2/June/2023

VERSION_BANK         = 101

__2600BANK SET -1

		MAC BANK ; usage: BANK n
__2600BANK SET {1}
		ENDM

		MAC BANKSYMBOL ; usage : BANKSYMBOL symbol
			IF __2600BANK == -1
				ECHO "BANKSYMBOL: bank number has not been set"
				ERR
			ENDIF

.arg SETSTR {1}
			ECHO "outputting", .arg, "as a bank aware symbol for bank", __2600BANK
   
; verbatim output of symbol
{1}
		ENDM

 

The ECHO will be included in the lst file. The disassembler just then needs to look for the known ECHO pattern in the lst file.

 

The ROM source will still need to use the BANK symbol and BANKSYMBOL macro as before. Example:

 

 

 

 

Edited June 2, 2023 by JetSetIlly
added the "verbatim output of symbol"

[Omegamatrix]

Interesting topic. I have a few thoughts (2 cents) on this as well.

 

I always felt the behaviour of Stella breaking on a mirror of a PC label was flawed. IMHO the correct behavor should be that the break occurs when the address label matches, and not break otherwise. This change along with a homebrewer RORGing each bank would work for up to 32K as noted. Myself, I have always just added an extra paramanter for the bank when breaking on PC label in a multibank game (but hated doing that).

 

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.

 

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.

Example for constants in a source:

SPEED_5     F23A 023A

SPEED_5     F26B 026B

SPEED_5     BC78 2C78

SPEED_5     D034 3034