JetSetIlly
-
Posts
763 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by 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.
I don't have access to Windows. I can compile dasm here though if you want to share a git branch.
-
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.
-
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.
-
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 ... ENDMThat would work well.
-
1
-
-
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.
-
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} ENDMThe 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:
-
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
-
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.
-
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.
-
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.
-
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 d2e6The 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 ENDMIdeally, 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.
-
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?
-
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} ENDMA 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} ENDMI 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?
-
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.
-
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?
-
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.
-
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.
-
5
-
2
-
-
4 minutes ago, alex_79 said:
That's why this issue is so weird: a fault in any CPU register would normally cause almost all games to crash. Instead here it would pass mostly unnoticed. I think Activision's "Decathlon" would likely fail as well, as the bankswitching relies on the return address pushed onto the stack, and maybe an handful of other games too, but most of them would run just fine.
Without knowing in advance what chip was the culprit, @DEBRO's findings would have led me to suspect the RIOT (bad bit in zeropage ram), but surely not the CPU.
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.
-
10 hours ago, alex_79 said:
Here is a simple one I put together:
PC_test.zip 1.43 kB · 3 downloads
It just displays two columns of 8 hex values each.
The program jumps to an address with the high nybble (4 most significant bits) corresponding to a value in the left column, then calls a subroutine from there and reads those same bits of the return address pushed onto the stack (right column).
On a working console, the two columns will always show identical values.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:
-
1
-
-
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
-
4
-
-
10 hours ago, JetSetIlly said:
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.
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:
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.
-
1
-
-
4 hours ago, stepho said:
Since we mostly want to store frequency, volume and modulation effects, that's a pretty good match for MIDI.
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.
-
1
-
-
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.
-
4
-
2
-
I do not understand the fundamentals of your idea.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Stella break command
in Atari 2600 Programming
Posted
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.