furrykef in #nesdev ran them through Google Translate, got "démarrage à froid" (cold boot) and "démarrage à chaud" (warm boot), and then confirmed their usage in Google Search and in a French Wikipedia article.

@dullahanI've fixed the path finding issue - the code will now go up the path looking for the files until it reaches the drive's root folder.

As for transforming the labels, I guess the simplest way would be to allow the user to setup regular expressions to parse & replace portions of the text?It's not the most user friendly method, but it is a debugger and all..

@Myask & @tepplesI probably should have mentioned this earlier, but I'm a French native.To be honest, while "Démarrage à froid" and "Démarrage à chaud" are probably the correct terms technically speaking, I don't believe I've ever heard anybody using them in my life. (To be fair, I am from Quebec - people from France and the like may very well use these).For the moment, I've settled on "Arrêt & redémarrage" (litt. Stop & restart), which I feel conveys the meaning, and should be understandable for anybody, whether or not they know the technical term for it.

I also ended up using the same logic for Japanese - 停止と再起動 - which is also just "stop and restart".

That amount of errors is pretty impressive! If you had labels in the debugger, then my guess is that it was unable to load the source files.This would probably be due to the path in the "name" tag for the "file" directives.Currently the regex I'm using only allows the following characters in paths:0-9, a-z, A-Z ( ) _ . - : / \ Any chance the paths you have in your DBG file (should be at the very top) contain something outside of these?

Nope, the paths are very normal. Also, I think it was able to load some of the source files at least (can't bother to test again now, but I think I saw some of my source code).

Nope, the paths are very normal. Also, I think it was able to load some of the source files at least (can't bother to test again now, but I think I saw some of my source code).

Alright, thanks. Either way, I've changed the import's code slightly in the release I just did (0.6.0) which might fix this (no promises though).

There are still some suggestions that were given in this thread that haven't been added to 0.6.0, I have them written down and will get to them eventually.I've been working on the debugger for dozens of hours over the past few weeks and need to take a break from it!

Thanks again for all the feedback, and if anyone has any other suggestions, don't hesitate to post them!

I just spent most of the day on this and am mostly finished rewriting the memory viewer tool in Mesen.Preview build: downloadNote: This build is Windows-only, because making a Linux+Windows package takes a lot more time - Linux users can compile from the latest source code on GitHub, it includes all the changes. (note: I did not test Linux at all yet)

The memory viewer is now a proper hex editor - everything can be edited:-NES built-in 2k RAM-PRG ROM, Work RAM, Save RAM-CHR ROM & RAM-Palette RAM-Primary/secondary OAM-Nametable memory (via the PPU Memory dropdown option)Note: Attempting to write to addresses mapped to registers or not mapped at all has no effect.

It's now also possible to display a text representation of the binary data.It supports TBL files, and defaults to ASCII conversion when no TBL file is loaded.The TBL mappings are saved in the debugger's workspace (independent for each rom debugged)

Example with AllPads rom (which contains ascii encoded text):

Attachment:

hexedit1.png [ 65.81 KiB | Viewed 2789 times ]

Example with FF3 (J) with a TBL file loaded to convert to kana:

Attachment:

hexedit2.png [ 69.86 KiB | Viewed 2789 times ]

It's possible to search for hex values, or text.When searching for text, the TBL values are used to produce the corresponding binary data, so you can search for a Japanese string and find it in FF3's text.

The text column supports variable-width characters (and multiple characters per byte) and highlights the right text based on the hex selection:

Attachment:

hexedit3.png [ 87.79 KiB | Viewed 2789 times ]

This is one of the main features that was still lacking from Mesen's debugger at this point.Anyone have any feedback and/or suggestions to improve it?And please let me know if you get any crashes or find any bugs, too.

PS: Main things left on my todo list at this point: -A simple visual CHR editor-Ability to save edited PRG/CHR ROM back to a .nes file-"Jump list" (i.e like the callstack tool but for all jumps, useful to trace back the execution)-Scripting-Add some way to compile/run assembly code, or edit the existing code

Having a Monitor mode would really help with these issues and be nice in general(IMHO). That way I can D CCD4 and see the code I want. or doing the debug display in a live window so I can move up and down a few bytes and it disassembles from the address at the top of the screen. If you have a monitor that lets you specify labels, breakpoints, watches then you can put a custom file on the the command line params, which then lets you open Mesen, add a bunch of labels, breakpoints etc from an external tool. Having an option to open the debugger on BRK would be nice also, so I can add a BRK into code and then have the debugger fire on it from my code editor. Also assemblers will pad unused areas with 00, so if the code hits lala land it will stop. CPU history command is the nectar of the gods. What it does is, it keeps a trace of the last N instructions the CPU performs, so if you code goes bad and you end up in lala land, you can type CHIS and it will show you exactly how it got to lala land - for example this is what it looks like

While you have the logger, you have to set it up and it starts to eat RAM and file space and then you have to wade through it all to get what you want, just having a last 64/128 commands on a single command is enough to save the day.

With the hex editor, showing Blue - execute, Green - Read, Red - Write, Yellow Read/Write and being able to turn off decay and then Mark the areas already highlighted. This way you can play game for bit, mark access, do new thing. Immediately see which bit of code was run when you did the thing and which memory locations it accessed to do it. Also handy for finding if code indexes over an array boundary.

Having HardReset/ColdBoot/ColdStart also reloading the ROM file would be worth its weight in gold. I.e see bug, change code, assemble, then ColdStart, where WarmStart just keeps the current code. FYI VICE has the terms RESET > HARD SOFT and its translated into a stupid number of languages so you could look at what they have. I think the way it gets away with it, is it has a parent menu Reset then then opens to options for Hard, Soft, Drive 8, Drive 9, Drive 10, Drive 11 so it doesn't have to translate or show Hard Reset, Soft Reset.

Uppercase opcodes is the CBM standard, mainly because the PET and other computers of the era that followed, TRS-80, Apple ][ only had uppercase character sets so the monitors and assmeblers of the day also did uppercase, once we got to the C64 era where we did have upper and lower case modes, it was such a standard and BASIC was done in all uppercase it just stuck. Although on a PC I type all my code lowercase.

I'm not sure what you mean - the debugger keeps track of what it knows to be code. If it cannot tell with certainty that something is code, it is displayed in an unknown block until it can be certain that it is in fact code (e.g usually after it has been executed at least once). The more code you run, the more accurate it becomes.

Oziphantom wrote:

If you have a monitor that lets you specify labels, breakpoints, watches then you can put a custom file on the the command line params, which then lets you open Mesen, add a bunch of labels, breakpoints etc from an external tool.

You can already import labels from CC65 - I'm not sure what you would import breakpoints & watches from?

Quote:

Having an option to open the debugger on BRK would be nice also, so I can add a BRK into code and then have the debugger fire on it from my code editor.

Adding breakpoints on specific instructions should be easy, I'll see what I can do.

Quote:

What it does is, it keeps a trace of the last N instructions the CPU performs

This should be easy to add as well.

Quote:

With the hex editor, showing Blue - execute, Green - Read, Red - Write, Yellow Read/Write and being able to turn off decay and then Mark the areas already highlighted.

This should be much easier to implement than before with the new hex editor.

Quote:

Having HardReset/ColdBoot/ColdStart also reloading the ROM file would be worth its weight in gold.

I'm not sure what you mean - the debugger keeps track of what it knows to be code. If it cannot tell with certainty that something is code, it is displayed in an unknown block until it can be certain that it is in fact code (e.g usually after it has been executed at least once). The more code you run, the more accurate it becomes.

Well the code highlighted I'm 95% sure had run by the time I took the screenshot, but then later when it has the data which it shows as code with illegals LAX, SLO etc, would have been accessed but defiantly not executed, looking at the code you can see it would crash the system if it had. BTW it is Duck Hunt(world).nes ROM

Sour wrote:

Oziphantom wrote:

If you have a monitor that lets you specify labels, breakpoints, watches then you can put a custom file on the the command line params, which then lets you open Mesen, add a bunch of labels, breakpoints etc from an external tool.

You can already import labels from CC65 - I'm not sure what you would import breakpoints & watches from?

A text editor. What you can do if your IDE doesn't have it own system, is make special labels so for example if we look at this code

Which has a lot of sub branches and some of the paths don't have convenient labels to latch onto. Say I want to break after the 'lda BirdEnts.alive beq _noFlyAway' check up the top. I would normally set a break point to the parent function 'birdUpdate' then when it fires, search through the code till I find the part I want then move the breakpoint. What I can do instead is

Then I have a script that parses the label file the assembler spits out. I should at this point mention how VICE works. The Label file runs Commands, where the AddLabel command ( abbreviated to al) is used as

Code:

al .birdUpdate $0a9eal .birdUpdate__doFlyAwayCheck $0ab6 (note I just made the addr up )....

but you can put any monitor commands in the file. So I scan for file for _BREAK_ which in this case will be al .birdUpdate__BREAK_ $0aa9 to which I then append a 'break $0aa9' to the labels file. When the LoadLabels(ll) is executed ( as a command line argument ) it then adds all the labels then adds the break points. This way I can set breakpoints from my code editor, they are set before the code runs, and I don't have to keep setting and adjusting every time. Also when I change the code and shift everything down as I added some code, the breakpoints get reset in the correct position by me just doing the 'll' command again. You can also set up watches. Given a variable is defined as, you can then do

Where this then finds an appends a 'watch load/store address' command to the labels file. Load = watch read, Store = watch load allowing me to track watches on variables from the text editor as well. Given the variables are assigned dynamically by the assembler it lets me easily set them without having to look it up live in the emulator. VICE also exposes a TELNET interface to the monitor, so you can "remote debug", however IDE's such as CBM Studio use the telnet to allow dynamic breakpoints. I.e you run code then click on the line you want to break on, since it has its own internal assembler it can work out where it is in RAM, then via the telnet connection it will send a 'break ADDR' command to running VICE to add the break point, VICE then send back what number breakpoint it is, so when you click the breakpoint to remove it, the IDE can send 'delete NUM' to remove it. Although I personally don't use the IDEs ( as their internal assemblers are too weak for my tastes ) a lot of newbies and people returning to the scene head straight for them as they are comfy and help get them back up to speed quickly and let them get things happening.

Probably not something you can really do for CC65 but CA65 should be able to support it.

Sour wrote:

Quote:

Having HardReset/ColdBoot/ColdStart also reloading the ROM file would be worth its weight in gold.

PPU viewer: Added a lightweight tile editing tool in the CHR viewer. The selected tile (select by clicking on it in the left-side view) is drawable, can press 1-4 to select palette for left button, right button is color 0. Changes are "live" and can be done while the emulator is running.

Trace Logger: This now shows recently executed instructions (keeps the last 30k instructions in memory) - this works even if the trace logger window is not opened (but the debugger window must be opened for the instructions to be logged)

Attachment:

tracelogger.png [ 60.76 KiB | Viewed 2674 times ]

Debugger: -Added "break on unofficial opcodes" and "break on BRK" options (breaking on other OP codes is possible via conditional breakpoints)-Added a "Save ROM as..." option to save ROM file containing any modifications done to PRG ROM or CHR ROM (including via the tile editor tool). (Only works on .nes files for now)-Conditional breakpoints: Greatly improved performance - can still run at well over 60fps with several conditional breakpoints executing on every CPU instruction

tepples wrote:

This would be killer, particularly if you were to make an oldskool UI reminiscent of Genecyst.

Sorry, it doesn't look very oldskool!

Oziphantom wrote:

Well the code highlighted I'm 95% sure had run by the time I took the screenshot

The debugger needs to be opened while the code runs for it to be properly registered as code - that's probably what happened.As for importing breakpoints/watch values, I can probably come up with a fairly simple format for it - though I don't expect to go much further than that (e.g: telnet, a console, and the like would take far too much time to add - there are a lot of other things I still want to add to Mesen that would take priority over this)

Features:-Edit existing code in PRG ROM (or anywhere) You can multi-select lines in the code window and right-click"Edit selected code" to start editing it. (I also added a small feature to copy the selected code to the clipboard.)

-Allows you to assemble and add new code anywhere (ram, rom)-Supports labels & comments (but they are not kept once the code is updated)-Automatically assembles as you type-Validates syntax and warns you of errors (as you type the code)-Any change done to PRG ROM will be saved to the ROM file if you save it (File->Save ROM as)

I've also added a feature that lets you type code in the assembler and run it right away on the CPU ("Execute" button in the screenshot below).Whatever code you execute ends up being mapped to $3000-$3FFF (it steals the address range from the PPU temporarely) and executes until a write to $3000 is done (or the last list of the code is reached)After the write to $3000, execution returns to wherever the PC was before.Registers and the like are not restored, so it's up to the code you use to save/restore values/registers you don't want to alter.This basically lets you alter the state of anything by using 6502 assembly.

Attachment:

assembler.png [ 38.62 KiB | Viewed 2628 times ]

Attachment:

codewindow.png [ 40 KiB | Viewed 2628 times ]

Last edited by Sour on Tue Mar 14, 2017 8:30 am, edited 1 time in total.

If you could add some nice Syntax Sugar, delete on a row, NOPs it. Handy for removing a JSR line when hunting or trying to figure out what makes something go wrong. Having a restore from ROM option would be nice as well.

I remember the SN Systems debugger for PS3 had this feature. It was pretty handy sometimes.

Perfect for getting rid of an Assert that is somebody else's problem - and is firing 5 times a frame

With the Trace history could you expand the P from being a hex byte to show the flags, it is really obtuse. Also is it in 6502 silicon order or 6502 Datasheet order? If you are worried about space you could only show active signals ie.

Thanks for the feedback - I've added an option to select the output format for the status register: "Hexadecimal", "Text" or "Text (Active only)" - which corresponds to the original format + the 2 suggested alternatives (I didn't update the download yet though)

The removed code is already turned into NOPs - deleting a line will add a corresponding number of NOPs at the end of the edited block. It would be relatively complex to insert the NOPs where the deletion(s) occurred, considering you can also delete/insert/modify other portions of the code as well.As is, you can already re-edit the code, delete the NOPs at the bottom & add the line you had deleted back. You do have to remember the erased code's exact location to be able to do this, though.

I'll also add "Discard PRG changes" and "Discard CHR changes" when I get a chance (to reset code/graphic modifications done with the hex/chr/code editors)

Who is online

Users browsing this forum: No registered users and 3 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum