Fceux Qt/SDL Port Testing

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

tepples
Posts: 22149
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Fceux Qt/SDL Port Testing

Post by tepples » Sun Nov 08, 2020 10:52 pm

I lack the time before bedtime to research answers to all of them. I'll answer some.
I have just merged an update into master for items 1 and 8.
Confirmed that 1 (ability to set Ctrl+R hotkey) is fixed. The behavior on 8 (frame advance should act as Run in debugger) appears different. I plan to let you know in more detail when I have a chance.
For item 2, can you describe in more detail what confused you about the gamepad config window. I have it setup when you can save different mapping profiles for various input devices.
I plan to give steps to reproduce when I have a chance.
For item 3, can you tell me how much CPU fceux is using when you are running the emulator with a loaded ROM? Use top command.
Somehow it stopped affecting me tonight even before I rebuilt it. It may be affected by something else in the environment. I plan to let you know when it affects me again.
For item 4, I'm trying not to hard code widget pixel sizes into the GUI since it I want it to try to auto scale to the resolution of the screen. But I will try to see what I can do about make the window more compact. One thing that I could do is put the entire window in a scrollable viewport so that it can be further shrunk down. But this would only really be valuable if you don't care to see the entire window all the time.
I could take another look at the new debugger window and find if smaller parts of it can be scrolled. I plan to let you know in more detail when I have a chance.
For item 5, is this the NTSC 2x special scaler that is mentioned on the website help pages?
Yes.
For item 6, do you just need an input device select window like the windows GUI has?
Yes.
For item 7, I wonder if bringing back the x2,x3, and x4 video prescalers would help with the hardware accel linear filtering? I can look into this.
Yes. I had been using Prescale 2x when not using NTSC 2x.

dienben2020
Posts: 32
Joined: Wed Sep 30, 2020 2:19 pm

Re: Fceux Qt/SDL Port Testing

Post by dienben2020 » Mon Nov 09, 2020 2:15 am

Mjbudd77 wrote:
Sat Nov 07, 2020 2:46 pm
I’m still looking for some more beta testers for this. For Linux or Mac fceux users out there, any feedback on the new Qt/SDL port of fceux would be most appreciated.
Hello,

I can make some test for Mac... To test, I can get the code in git (https://github.com/TASVideos/fceux)? Is it what you expect?

Quick question: do you need help to update the website?

Regards,

Ben

Mjbudd77
Posts: 23
Joined: Fri Oct 16, 2020 9:53 pm
Location: Tampa

Re: Fceux Qt/SDL Port Testing

Post by Mjbudd77 » Tue Nov 10, 2020 6:08 am

dienben2020 wrote:
Mon Nov 09, 2020 2:15 am

Hello,

I can make some test for Mac... To test, I can get the code in git (https://github.com/TASVideos/fceux)? Is it what you expect?

Quick question: do you need help to update the website?

Regards,

Ben
Yes. The url you mentioned has the latest stable development code. If you don't plan to breakpoint debug the emulator itself, then you really don't need the source. The mac osx dmg package from the autobuilds is updated every time I push new changes to the repo. I believe the first post in this thread has information on building. I will need to overhaul the SDL documentation on the website but wanted to wait until an official release was ready. I especially needed to remove all the old references to scons and gtk.

Mjbudd77
Posts: 23
Joined: Fri Oct 16, 2020 9:53 pm
Location: Tampa

Re: Fceux Qt/SDL Port Testing

Post by Mjbudd77 » Tue Nov 10, 2020 6:27 am

Sonny_Jim wrote:
Sun Nov 08, 2020 10:41 pm

This is different behavior than the Windows version, or rather, it's lacking functionality that's in the Windows version. I'll try to explain better what I mean:

Code: Select all

07:D41C: A5 12 LDA $0012 = #$00
In the Windows version, I can right click $0012 and it'll allow me to set a symbolic name for $0012. (In fact I think the Win trace logger window behaves like this as well)
In the Linux version, right clicking $0012 sets the symbolic name for $D41C, rather than $0012.

This is what I mean by having to set the symbolic name via the hex editor rather than the debug window. It's not a massive issue, but it sure is handy. Also I can't seem to select and copy text in the debugger/trace logger windows in the Linux version, but that might be down to how I built it.

EDIT: Another random one, the settings in the tracelogger window aren't saved/restored, so I have to turn on 'Symbolic Trace' each time I restart FCEUX
Wow, I learned something. Didn't realize any address in the assembly window could be selected. I just updated the Qt debugger code to account for this. The Qt debugger is a little different because I used a context menu to select those options. But for faster use I added shortcut keys that will allow for bypassing of the assembly context menu selection. You can see what the shortcut key values are in the context menu when it's open.

Why would you want to copy text from the debugger window? What is the use case for that?

I will setup some configuration parameters to save the trace logger settings.

Sonny_Jim
Posts: 13
Joined: Sat Jan 13, 2018 7:45 am

Re: Fceux Qt/SDL Port Testing

Post by Sonny_Jim » Tue Nov 10, 2020 4:58 pm

Why would you want to copy text from the debugger window? What is the use case for that?
Mostly copying and pasting stuff onto forums to ask what it does ;) Although I can always just set the tracelogger to write to file and do it that way.
Didn't realize any address in the assembly window could be selected. I just updated the Qt debugger code to account for this.
Just tried it out, it works fine for any address that does not currently have a symbolic name, but I couldn't get it to work for something that had already been named, for example:

Code: Select all

LDA $0018
LDA $my_var
Right clicking on 0018 brings up the context menu for 0018, but right clicking $my_var doesn't open the context menu.

Mjbudd77
Posts: 23
Joined: Fri Oct 16, 2020 9:53 pm
Location: Tampa

Re: Fceux Qt/SDL Port Testing

Post by Mjbudd77 » Tue Nov 10, 2020 8:42 pm

I did a more detailed comparison of the windows debug window symbolic debug behavior. It looks like both the hex value and symbol name get displayed on the disassemble line but only the hex value is clickable. I just made changes to the Qt GUI to match this behavior. I also added the RAM freeze functionality to the Qt hex editor. Just merged latest into master. Let me know what you think.

Sonny_Jim
Posts: 13
Joined: Sat Jan 13, 2018 7:45 am

Re: Fceux Qt/SDL Port Testing

Post by Sonny_Jim » Wed Nov 11, 2020 6:54 pm

Just tried the latest commit (well, 2nd latest, had to roll back the Chinese bootleg mapper commit as it was causing compilation errors). Freezing/unfreezing works, I haven't tested it extensively but it appears to do all the right things. I'll have a fiddle with it and see if it breaks.
It looks like both the hex value and symbol name get displayed on the disassemble line but only the hex value is clickable.
Not quite, or at least not on the version I'm using (Win 2.2.3).

Code: Select all

WinFCEUX 06:9693:95 A0     STA $A0,X @ bullet2_life = #$00

Code: Select all

LnxFCEUX 06:9693:95 A0     STA $A0,X @ bullet2_life = #$00
It shows the hex address and symbol name when it's indirectly addressed. This is now the same between Linux/Windows

Code: Select all

WinFCEUX 06:969B:86 8C     STX enemy_slot_current = #$00

Code: Select all

LnxFCEUX 06:969B:86 8C     STX $8C enemy_slot_current = #$00
When it's not indirectly addressed, it shows just the symbolic debug name in the windows version. The Linux version prints both the address and symbolic name. Also I can right click the symbolic name in Windows to edit. In Linux I have to right click the address (ie $8C)


One other teensy little thing is that the Code Data Logger doesn't seem to auto-start when loading a ROM, even when it's set to do so ('Auto-resume logging when loading ROMs'). If that box is ticked, the Windows version starts the CDL as soon as the ROM is loaded. In Linux I have to manually open the window and press Start, even though Auto-Resume is checked.

Mjbudd77
Posts: 23
Joined: Fri Oct 16, 2020 9:53 pm
Location: Tampa

Re: Fceux Qt/SDL Port Testing

Post by Mjbudd77 » Wed Nov 11, 2020 7:20 pm

Just pushed a commit that adds the video special scalers to the Qt GUI. Also fixed the build issue for the newly added mapper.
I kinda like having the hex value available on the display and it makes things alot easier from a code point of view. Any reason why I can't leave it this way? I will add the CDL auto-resume to the TODO list.

Mjbudd77
Posts: 23
Joined: Fri Oct 16, 2020 9:53 pm
Location: Tampa

Re: Fceux Qt/SDL Port Testing

Post by Mjbudd77 » Wed Nov 11, 2020 7:33 pm

Turns out the CDL auto-resume bug was really simple to fix. Will be merged shortly.

Sonny_Jim
Posts: 13
Joined: Sat Jan 13, 2018 7:45 am

Re: Fceux Qt/SDL Port Testing

Post by Sonny_Jim » Wed Nov 11, 2020 7:52 pm

Mjbudd77 wrote:
Wed Nov 11, 2020 7:20 pm
I kinda like having the hex value available on the display and it makes things alot easier from a code point of view. Any reason why I can't leave it this way?
No reason why it can't stay like it is, it's certainly better than it was before! I will counter whoever that it's pretty easy to read the hex value from the raw data on the left. It all depends if you want to feature match the Windows Debugger. But it any case, thanks for working on the Linux port, it's very much appreciated.

dienben2020
Posts: 32
Joined: Wed Sep 30, 2020 2:19 pm

Re: Fceux Qt/SDL Port Testing

Post by dienben2020 » Sat Nov 14, 2020 2:56 pm

Hello,

For info, I'm on Mac, just migrated to Big Sur, and the latest build crashes. I'm usingthe build with the git revision starting with a6df86 for now.

Tell me if I can help.

Regards,

Ben

Mjbudd77
Posts: 23
Joined: Fri Oct 16, 2020 9:53 pm
Location: Tampa

Re: Fceux Qt/SDL Port Testing

Post by Mjbudd77 » Sat Nov 14, 2020 6:11 pm

I did find a crash on Mac earlier today from the recent addition of the video scalers which required more memory. I was using a shared memory segment for video and I found that Linux OSs had no issue with the segment size but the Mac OSX did not like how large the segment was. The video memory is now 4MB to account for the 4x prescaler requirements. When I saw this, I moved away from shared memory in favor of a simple heap memory block via malloc. Are you sure you were running the latest commit from today? I apologize for not seeing this, I do most of my development on Linux and only switch over to Mac to test occasionally, I should have tested that on the other computer before pushing to the main repo.

I have more questions about this. Are you building from source or using the dmg package from the auto build? The dmg is built using the Catalina OS. I don’t know enough about Mac OS to say whether binary compatibility is maintained across versions. If you have the latest version and it is still crashing, I will need you to build from source with debug information built into the executable. And then get me a stack trace of the crash. I use vscode for debugging in both Linux and Mac. I can commit some config files and scripts for the project to integrate into vscode if it will help.

dienben2020
Posts: 32
Joined: Wed Sep 30, 2020 2:19 pm

Re: Fceux Qt/SDL Port Testing

Post by dienben2020 » Sun Nov 15, 2020 7:40 am

Hello,

First, thank you very much for your answer and your time dedicated to create tools for the community!

I've downloaded the following release: https://ci.appveyor.com/api/projects/ze ... &job=MacOS and it works!!

I've run basic checks:
- load a game
- open the PPU Viewer
- open the Name Table

Do not hesitate, if you need help to test, to ask and will try to test as fast as I can (depending of my availibility)!

Regards,

Ben

Mjbudd77
Posts: 23
Joined: Fri Oct 16, 2020 9:53 pm
Location: Tampa

Re: Fceux Qt/SDL Port Testing

Post by Mjbudd77 » Thu Nov 19, 2020 8:02 pm

tepples wrote:
Sat Nov 07, 2020 6:25 pm
6. Is connecting a Zapper through the GUI planned, or will it remain a command-line thing? The "Zapper test" activity in 240p Test Suite requires it.
Starting to think about this one. I can code up the input device config window in the Qt gui and make sure it sets the same variables that the command line switches set. After reading about the hardware required to make a zapper work with a modern tv, I don't think I'm going to be able to test this. If I make the gui modifications, are you able to test the zapper functionality?

tepples
Posts: 22149
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Fceux Qt/SDL Port Testing

Post by tepples » Thu Nov 19, 2020 8:49 pm

Zapper in emulators is typically bound to the mouse. This means yes, I can test the emulated Zapper, as I did for Zap Ruder and for the Zapper test in 240p Test Suite. I also have a vintage TV and PowerPak against which to compare game behavior.

Post Reply