JetSetIlly

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.

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

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.

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.

That would work well.

Oh yes! Thanks. It was very useful. 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. That would be the best solution of all. A symbols file that is well structured and does a better job of differentiating symbol types.

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:

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

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.

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

To associate the two symbols with one another. I can't figure out how to get DASM to generate that line. IMO, this is a lot simpler than the previous idea in which the ORG and RORG are manipulated.

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.

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.

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?

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?

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.

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?

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.

Full release notes for v0.23.0 https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.23.0 Summary 1) Performance improvements This version has significant improvements to how monitor VSYNC is handled. I've had good reports from Mac and Windows users as well as improved performance on my development machine. If you've tried Gopher2600 and been left disappointed by its performance it's worth looking at this version to see if it has improved. The VSYNC options are in the Preferences window (press F10) and is under the "Playmode" tab. "Sync with vertical retrace" and "Adapative VSYNC" should both now produce better results but if not, the new "Ticker" option is worth trying I should emphasis that in all cases, best results are obtained if you set your monitor to 60Hz. 2) Screenshots Better screenshot modes. I had previously experimented with short, long and very long "exposures". This sort of worked but it produced disappointing results in some cases, particularly ROMs with highly flickering displays. In particular it was difficult to get good screenshots of @Andrew Davie's Wenhop. The new 'composite' mode produces better results in some cases. For example, the title screen of a recent version of Wenhop This new mode is also quite good at capturing motion blur. For example, fast moving wabbits. The third mode is called 'motion' and is another good way of capturing motion, phosphor effects and stabilising flickering displays. For example @johnnywc's Zookeeper and Elevator Agent Not all modes will suit all ROMs in all situations. I'll add a way of previewing the results and altering parameters in the near future.

I wonder if it's a problem in a batch of 6507s and there are other 2600s in the same run that have the same issue. Depending on how they tested in the factory it's quite likely the hardware would pass.

Under emulation: When changing the function of the Program Counter by forcing bit 13 to low, I can replicate the bug described in the original post. It matches the result @DEBRO found when reassembling with rombase $d000. More importantly, all ROMs used in regression testing pass. There are many ROMs I haven't tested of course. I think the analysis by @alex_79 is correct and that bit 13 in the PC is "broken" This is the result for PC_test.bin:

Here are three more examples, the fanfares from Zookeeper @johnnywc, Draconian @SpiceWare and MsPacman. zookeeper_audio.asmdraconian_audio.asmms_pacman_audio.asm Compile with DASM in the normal way for your platform. Improvements required: Currently, the driver in these standalone binaries can only really deal with audio that is updated once per frame per channel. It shouldn't be too difficult to adapt the outputted program to accommodate more complex audio. Data representation of the audio is inefficient. At the very least, control and volume values can be squished into one byte. Detection of musical loops would be a good efficiency saving. Code in the audio_ripping branch on Github

I've been thinking some more about this and made some progress. The idea is for the emulator to output a 2600 asm file that can be compiled and run as a standalone program. Other formats might be an MP3 recording or a MIDI file. It needs a lot of work so that it's accurate in all situations but the idea works. Some examples: frogger_audio.asm man_goes_down_audio.asm snoopy_audio.asm They're only short and will repeat when the audio data ends. The code is in the audio_ripping branch on Github if anyone wants to experiment or to make a contribution.

It's a great idea but I was really looking for something that can be used in the source code to a BatariBasic program or in regular 6502 assembly. MIDI data representation would be too complex for that I think.

There arn't many visible differences in today's v0.22.0 but there are some important bug fixes. Change log on the release page https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.22.0 ARM disassembly is improved in this release. Thumb-2 disassembly is in the process of being improved and 32bit functions in particular are given their canonical mnemonic. Also, a snapshot of the ARM registers is preserved on every ARM step. This is much needed work to help debug the emulation of the more advanced ARM CPU found in the Uno/PlusCart. Previously, debugging of the emulation was laborious and unappealing. The macro system requested by @Gemintronic is in this version. It's very rudimentary but may be useful to some people. Documentation here: https://github.com/JetSetIlly/Gopher2600-Docs/wiki/Macro-System I've also done some work on the "audio tracker". Currently, this is just a way of viewing audio information, rather than a tracker through which you can edit (although that remains the goal). But added in this version is a way of replaying a section of audio. This is useful for isolating a sound effect and being able to see exactly what the changes to the audio registers are. I went back to this after reading about the work done in the following thread. It inspired me to look for a way of saving data from a ROM such that it can be added to source code for another game. I've experimented with that feature but I've nothing satisfactory so far. If anyone wants to help/advise me on standard representation of audio data it would be very helpful.