Release of FCEUXD SP 1.02

Programming stuff

Sunday, July 17. 2005

Posted by sp in FCEUXD SP

Comments (10)
Trackbacks (0)

12759 hits

Here's version 1.02 of FCEUXD SP:

- New: Added hotkey F6 to open hex window.
- New: Added bookmarks to the hex window.
- New: Debugging data like breakpoints or bookmarks are automatically saved and restored when games are closed / opened.
- New: Increased the size of the mouse-over information area below the diassembly window
- New: Added name list file information for addresses to the mouse-over information area
- New: It's now possible to give breakpoints a brief description/name.
- Bugfix: Inline Assembler works for all lines again.
- Bugfix: Deleting breakpoints correctly updates breakpoint conditions now.

For a more detailed description of what's new check the readme file.
Click here to get the FCEUXD SP Windows binary file.
Click here to get the FCEUXD SP source code.

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

Nice work sp!
I admire your work! I'm motivated to learn the fceuxd sp source code.. can you tell me where to start? I have a basic C++ knowledge and a 8051 assembler knowl. I know thats enough.. but what u sugest?
(I know.. a good english its a begin)
Lol
cya!

#1 Jack Stuard on 2005-07-18 08:50 (Reply)

Hi,

at first you should of course attempt to get FCEUXD SP to compile. Check the latest update for a guide on how to do that.

Once you manage to build the program you should try to think of some features you'd like to add. Then try to locate the best place where to add them. The features I add, for example, are all debugging related. All changes I've made so far are located in the root directory or in the drivers/win directory of the source code. Especially the drivers/win directory is very important for me, it contains the Windows GUI stuff which I need to extend the debugger.

To get a general idea of Windows API Programming in C I suggest the book Windows Programming by Charles Petzold.
To learn more about NES programming check out NesDev.

#1.1 sp on 2005-07-18 14:38 (Reply)

FCEUXD SP crashes when I close the Hex Editor.

#1.1.1 Keith Weisshar on 2005-07-23 16:26 (Reply)

I'm looking into it but I'd appreciate if you could give me more information. For example what breakpoints you've set in the debugging window, what bookmarks you have defined (both debugging window and hex editor), the exact message from the crash window.

The best case would be if you could create a minimum scenario that makes FCEUXD crash. (Example: Open XYZ.nes, open hex editor, set bookmark with description "Foo" at offset $0000, close hex editor, crash).

#1.1.1.1 sp on 2005-07-23 16:43 (Reply)

Awesome! When I saw you're post on the message board, I had to check out the new release. Hacking the NES has just became even easier.

#2 Ice Ranger (a.k.a. Chill Penguin) on 2005-07-20 06:37 (Reply)

Greetings,

I found a tiny annoyance (I couldn't find a proper term, since it's not really a bug

) while using symbolic debugging in FCEUXD SP 1.02.

[NL file]

$10#var_PPUReg1#RAM copy of PPU hardware register $2000

[Code with SD disabled]

$C867:85 10 STA $10 = #$10

[Code with SD enabled]

$C867:85 10 STA var_PPUReg1 = #var_PPUReg1

---

I assume you perform a replace of addresses for symbols on the disassebmly's output (on a per-line basis). I don't know much about FCEUXD's source code so I'm not sure if the added information ( = #$nn, et al) is avoidable when replacing addresses for symbols.

I hope I was clear enough.

Keep up the great work,
TFG

#3 TFG (Homepage) on 2005-07-24 04:21 (Reply)

Sorry I had to add a new comment to elaborate on my last one.

Additional debugging information symbol replacing is useful when it comes to addresses.

Example:

$F22D:B1 00 LDA ($00),Y @ dat_TitleScreen = #$3F

What I meant with my last comment is: it's not "good" to have constants replaced when they're misinterpreted as zero page addresses.

So, no, I didn't suggest to disable added debugging information address replacement.

Thanks,
TFG

#4 TFG on 2005-07-24 04:49 (Reply)

Hi,

thanks for your input. I know exactly what you mean and I can tell you it's been fixed in version 1.03 (which will hopefully be released soon).

I've fixed it by changing the assembler code for zero-page instructions like "LDA $10" to "LDA $0010". This might not be 100% correct if you're a 6502 assembler purist but it's an easy way to distinguish real addresses from byte values and I think for basically all practical purposes it should be irrelevant (I only perform a string replacement; you guessed correctly).

#4.1 sp on 2005-07-24 09:45 (Reply)

NOTE: I wasn't able to post this on the 'Release of FCEUXD SP 1.02' topíc becase comments were disabled for that particular entry (that's what the blog has to say about me trying to add the comment). So, sorry about adding this sort-of-off-topic comment here but I didn't have much options. Post your e-mail address or add a generic message board somewhere else ;)

Suggestion for FCEUXD SP 1.03

[Scenario]

The level data of X game is located at (CPU) $C000.
NL file: $C000#dat_Level#Level data block

-

With the provided information, the debugger would output something among these

lines: (for a fake level loading routine, anyway)

LDA dat_Level,Y @ dat_Level = #$10
STA var_SomewhereElse
INY

//New output after executing previous code

LDA dat_Level,Y @ $C001 = $#54
STA var_SomewhereElse
INY

For this particular addressing mode, it's easy to calcuate the address that's

being read. You are still able to read the stated symbol. On this next

addressing mode, that's not the case:

LDA ($00),Y @ dat_Level = #$10
STA var_SomewhereElse
INY

//New output after executing previous code

LDA ($00),Y @ $C001 = #$54
STA var_SomewhereElse
INY

Farewell symbols

I think the code is self-explanatory. Regardless, I'll steal some more webspace

and propose a solution.

[Possible solution]

Add a new "column" to NL entries which sole purpose is to specify an array's

size. Example:

The level data of X game is located at (CPU) $C000.
NL file: $C000.10#dat_Level#Level data block

-

Debugger's output

LDA ($00),Y @ dat_Level[0] = #$10
STA var_SomewhereElse
INY

//New output after executing previous code

LDA ($00),Y @ dat_Level[1] = #$54
STA var_SomewhereElse
INY

-

Since the array size is, most likely, not going to be used all the time, it's

not practical to add extra user-side hassle by adding an extra '#' every line.

I guess the optional '.' is a bit more elegant.

Thanks for your time,
TFG

#5 TFG (Homepage) on 2005-07-31 01:40 (Reply)

Hey,

that's a very good idea. I'm leaning towards the "." option (but maybe with a "/" instead of a "." ) because that wouldn't break compatibility with older versions / nl files. I'll try to implement that later.

The blog software is apparently a bit buggy, that's why you couldn't post the comments in the correct thread. I'll try to figure that out and move your comment and my one over to the real thread.

#5.1 sp on 2005-07-31 08:43 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	Enclosing asterisks marks text as bold (word), underscore are made via _word_. Standard emoticons like :-) and ;-) are converted to images. BBCode format allowed
	Remember Information? Subscribe to this entry
Submitted comments will be subject to moderation before being displayed.