|
Post by elmer on Dec 22, 2018 2:00:33 GMT
Quick question: The "TS" (time signature) value... what units is it in ? is it something like master clock cycles (i.e. 21.48 MHz) ? As far as I can tell, yes.
|
|
|
Post by elmer on Dec 22, 2018 21:25:20 GMT
Honestly, the white text on black background is probably harder on the eyes (for contrast related reasons) than the actual design of the screen. I totally agree ... my main screen colors for text editing are de-saturated specifically to avoid high-contrast text and to make things easier to read for long periods. I'll look at toning down the brightness a bit. Please remember though, you don't normally see the screen on full-black. It is semi-transparent against the emulated screen underneath. Can we change the font? I hate that font. I always have. You can change the disassembly font in mednafen.cfg, but you can't change the other font on the screen, or the font on the memory screen. You can't use any Windows or TTF fonts, only the fonts that are built into the program. After I posted my patches on the Mednafen forum a couple of years ago, Rypheca added new 6x9 and 6x12 fonts to the program, which you may personally prefer as they're a bit squarer. I prefer the 6x13 font that has been in Mednafen for years, and I created my own 6x9 font in the same style as that font, which I use to replace the new 6x9 font. All of the fonts in Mednafen are pure bitmapped-fonts that come from linux (the XFree86 project, IIRC).
|
|
|
Post by dshadoff on Dec 27, 2018 0:59:17 GMT
So I built this today on Ubuntu, and it worked OK basically withou intervention, but several things were a little different than expected. Don't take these as complaints; they're just notes. 1) Instead of grabbing via Git, I did a ZIP download from the Git site as the expected directory structure was slightly unclear; the Git ZIP file had "mednafen-happyeyes-master" as an (undesired) embedded directory, so everything built under that. Not the end of the world, but something to remember. This embedded directory may not be under your control (i.e. maybe the Git host does that while packaging the ZIP file). 2) I had to 'chmod u+x build_mednafen.sh'. Again, no big deal but probably should be in the README if you can't force the UNIX attribute from a Windows dev setup. 3) I needed to 'sudo apt install curl', as this was not part of build-essential, and not needed for any other development so far on my machine (only the happyeyes build script). 4) That script does a complete get and build (very nice !), but it meant that my effort to pre-obtain and position the Mednafen tar.xz file was wasted. 5) (this one is sort of alluded to in the README). Contrary to the normal Mednafen build cycle of ./configure / make install, which puts object files in the same directories as the source files, and the executable in (some directory)/mednafen/src , the object/executable output ends up in build/* . So, the executable ends up in mednafen-happyeyes-master/build/mednafen/src . (Not 'bin' as the README indicates, but 'build'). 6) For some reason, the new debug information looks really narrow - about 20% narrower than before (and of course, taller than before). The font is narrower now - the disassembly font is so tall and narrow that it's kind of squinty. I didn't expect this, since the panel retained the same aspect ratio (640x480 -> 800x600). Am I missing out on some sort of debug screen scaling factor somewhere in mednafen.cfg ?
|
|
|
Post by dshadoff on Dec 27, 2018 1:47:00 GMT
OK, I got a partial fix - I adjusted the pce.debugger.disfontsize in mednafen.cfg from 5x7 to 6x12, but the 800x600 panel is still narrow (800 horizontal pix = 15.6cm; 600 vertical pix = 17.5cm); would look a lot better if it was more like a 4:3 aspect ratio, similar to the game behind it.
Running on a 15.6" Macbook Pro under Ubuntu, (virtual) screen resolution set to 3360x2100, with pce.xscale and pce.yscale both set to 8.00 .
*** Update: This is directly related to the scaling factors applied to the debug window ("surface?") as it is displayed. Apparently, on the debug screen, the y axis and the x axis are given separately-calculated scaling multipliers (though I haven't found this in the code yet). The final window size on my 8*8 scale configuration is 2304 x 1856 The y-scaling turns out to be INT(1856/600) = 3 The x-scaling turns out to be INT(2304/800) = 2 -> these really should be the same for any window containing text; otherwise it becomes distorted.
Are you able to help me find how to correct this (without just hacking the draw area's Y-size value to make it fit) ? It appears to be a pre-existing condition on Mednafen's code (just rarer with smaller debug window numbers). I am not familiar with the SDL surface manipulation interface, or the Mednafen code (though the patches helped me a lot).
*** Update 2: Found it. See next message below.
Oh, and a game-related note: There is a bug in Dragon Slayer II, which causes it not to work on this version of Medanfen.
Symptom: For 'New Game', after the cinema, the game starts and the protagonist is in bed. He should move left and be greeted with "Ohayou", but the emulation goes berserk before he can do so. This issue does not happen on regular Mednafen.
Root Cause: Bug in the program consults $FFE5 (which reads $4C), and does some sort of memory check. It normally doesn't find memory there, and goes on its merry way. If it does find memory there, weird things happen. I think this was an attempt to determine whether it's running on a suitable System Card version (which should consult $FFF5 for start of regular RAM, and $FFF4 for start of Super RAM), but they never figured it out, so they probably changed the check to anti-sense (i.e. error if it's found, rather than error if it's not found).
Since this version of Mednafen puts RAM there, the game freaks out. Is there a configuration option to turn this on/off ?
*** EDIT: No, I see that this is fixed, not configurable.
Dave
|
|
|
Post by dshadoff on Dec 27, 2018 7:24:18 GMT
OK, I found it. drivers/debugger.cpp, line #738 allows y-scaling to be up to double that of x-scaling, but x-scaling cannot exceed y-scaling.
I think this may be appropriate for a novel, but not for a debug screen.
I think the correct line #738 should read: if(ym > xm) ym = xm;
...Would you be interested in putting this change into your patch ?
Since the mulitpliers are smaller now (due to the larger base panel), the overall debug screen came out a bit smaller (smaller text) - so I increased my mednafen.cfg multipliers to 8.5, and I was surprised to see that it all still looks OK, with a non-integer multiplier.
|
|
|
Post by dshadoff on Dec 27, 2018 8:07:38 GMT
Also, regarding my previous point on showing the flags... I wrote some quick, hackish demonstration code (PCE-specific too). Implementing it properly would be non-trivial because the register "special" function is used to build the long string displayed when the cursor is moved on top of the register (but an additional 'short special' element could be added to the register again.... but that would be tedious). Anyway, nothing needed to be shifted around on the screen ! Pretty much every CPU monitor program I've used since the '80s has displayed the status register's individual flags this way for convenient quick reference, so having to use keys to identify individual flags is too much of a tedious step. In src/drivers/debugger.cpp at line 420, immediately after: *details_ptr = std::string(details_string_buf); And immediately before: DrawText(surface, x + rname_width + rec->outdent * 6, y_offs, nubuf, eff_rval_color, which_font); This code should be inserted: if (strcmp(rec->name, "P") == 0) { if (regval & 0x80) nubuf[0] = 'N'; else nubuf[0] = '-'; if (regval & 0x40) nubuf[1] = 'V'; else nubuf[1] = '-'; if (regval & 0x20) nubuf[2] = 'T'; else nubuf[2] = '-'; if (regval & 0x10) nubuf[3] = 'B'; else nubuf[3] = '-'; if (regval & 0x08) nubuf[4] = 'D'; else nubuf[4] = '-'; if (regval & 0x04) nubuf[5] = 'I'; else nubuf[5] = '-'; if (regval & 0x02) nubuf[6] = 'Z'; else nubuf[6] = '-'; if (regval & 0x01) nubuf[7] = 'C'; else nubuf[7] = '-'; nubuf[8] = 0x00; DrawText(surface, x + rname_width + 2 * 6, y_offs, nubuf, eff_rval_color, which_font); } else (The DrawText becomes the 'else' branch of this if statement). Dave
|
|
|
Post by elmer on Dec 27, 2018 23:31:33 GMT
1) Instead of grabbing via Git, I did a ZIP download from the Git site as the expected directory structure was slightly unclear; the Git ZIP file had "mednafen-happyeyes-master" as an (undesired) embedded directory, so everything built under that. Yep, it shouldn't matter to the script what directory you build it in. Is that a problem? The point (for me) is that I build it in ~/tools/src/mednafen, and the output goes in ~/tools/bin/mednafen. It is part of creating a cohesive retrogaming development infrastructure, with the source code located in ~/tools/src/<someprogram> and the binary output in ~/tools/bin/<someprogram> or just ~/tools/bin/ depending upon whether I'm compiling a simple program, or a more complex package. 2) I had to 'chmod u+x build_mednafen.sh'. Good point, I'll try to fix that in github. Thanks! 3) I needed to 'sudo apt install curl' Another great point, I'll have to fix the documentation. Thanks! 4) That script does a complete get and build (very nice !), but it meant that my effort to pre-obtain and position the Mednafen tar.xz file was wasted. Yep, I've tried to make it easy. I guess that the behavior should be documented. 5) ... So, the executable ends up in mednafen-happyeyes-master/build/mednafen/src . (Not 'bin' as the README indicates, but 'build'). The "build" directory is a temporary directory, not the output directory. I've been trained to prefer to avoid building in the source tree, it's too messy. Having the "build" directory separate from both the source and the final destination make it easy to delete it and clean up everything. Yes, the binary will get built in the "build" tree, and you can find a copy in there, but the mednafen's "make install" should put it into the output "../../bin/mednafen/" directory. NOTE CAREFULLY ... that is ABOVE the base level of the patches/download tree that you're executing the build script from. I suspect that you'll find that the directory has been created on your system, and you've just missed it. Either that, or something went wrong with the script. 6) For some reason, the new debug information looks really narrow - about 20% narrower than before (and of course, taller than before). As you've found (in later posts), this is a combination of mednafen's built-in scaling on your amazingly-large screen, plus you already having a mednafen.cfg file in your ~/.mednafen directory, causing you to use the old default settings, and not the new default settings ... i.e. you're still using the ugly 5x7 font instead of the 6x13 font. If you delete your ~/.mednafen/mednafen.cfg, then a new one will be created when you run the program again, and you'll get the new default settings, including the larger font. BTW ... my custom 6x9 font on the debug screen is specifically designed to look like mednafen's 6x13 font, and not like mednafen's 6x12 font.
It's up to you to choose whatever font you like for the disassembly, but I urge you to pick the 6x13 that I have set as the new default. It'll look better, and you're massively-unlikely to miss the extra line or two of disassembly.
|
|
|
Post by elmer on Dec 27, 2018 23:51:41 GMT
Oh, and a game-related note: There is a bug in Dragon Slayer II, which causes it not to work on this version of Medanfen. ... Root Cause: Bug in the program consults $FFE5 (which reads $4C), and does some sort of memory check. It normally doesn't find memory there, and goes on its merry way. If it does find memory there, weird things happen. I think this was an attempt to determine whether it's running on a suitable System Card version (which should consult $FFF5 for start of regular RAM, and $FFF4 for start of Super RAM), but they never figured it out, so they probably changed the check to anti-sense (i.e. error if it's found, rather than error if it's not found). This issue was actually found first on the TED2 card when using it with my TED2 System Card image which runs with the 1MB of cartridge space as RAM. It was reported on PCEFX. From what I diagnosed, it's some left-over debugging code for running on a development system. I may well patch the TED2 System Card image (someday) to get around this (and patch the Dragon Slayer program when it loads), but I have no intention of changing the extra PCE RAM that I've added to Mednafen. As you've found, it is compiled-in, and isn't a trivial change to make it optional. You can just remove the extra-memory patches from your copy of the build script if you like, that's why I've separated the patches by functionality. If you're looking a Dragon Slayer II in terms of doing a translation, then I suggest that patching the ISO to avoid that development-system check would be one of the 1st starting points. It's the same with the Tenshi no Uta games ... they both check for development-system hardware on startup. That causes Tenshi 1 to fail on the US System Card and only run on the Japanese System Card. Tenshi 2 also starts running some crazy dev code, but it manages to recover and still run on the US System Card. Either way, they should both just be patched to not run the development system code.
|
|
|
Post by elmer on Dec 28, 2018 0:08:15 GMT
I think the correct line #738 should read: if(ym > xm) ym = xm; ...Would you be interested in putting this change into your patch ? Nice find! Yes, I'll put that change into the patches, thanks! Also, regarding my previous point on showing the flags... I wrote some quick, hackish demonstration code (PCE-specific too). Implementing it properly would be non-trivial because the register "special" function is used to build the long string displayed when the cursor is moved on top of the register (but an additional 'short special' element could be added to the register again.... but that would be tedious). Thanks for the patch. I understand your point, and can see that it would be a nice feature to have, but I can't just hack it into the main debugger file like that. I would like to see if Rypheca will be willing to add at-least a few of the changes that I've made into the official Mednafen release, and there's no way that she would accept a systemwide hack like that. If I can figure out how to do get the flag display to work "legally", then I'll try to implement it. As it is, I really do need to update github soonish to include some changes to the PCE disassembly, and the new "Disassemble to File"/"Hex Dump to File" functions which have been invaluable in tracing what is going on in the Tenshi games.
|
|
|
Post by dshadoff on Dec 28, 2018 1:35:15 GMT
1) Instead of grabbing via Git, I did a ZIP download from the Git site as the expected directory structure was slightly unclear; the Git ZIP file had "mednafen-happyeyes-master" as an (undesired) embedded directory, so everything built under that. Yep, it shouldn't matter to the script what directory you build it in. Is that a problem? The point (for me) is that I build it in ~/tools/src/mednafen, and the output goes in ~/tools/bin/mednafen. It is part of creating a cohesive retrogaming development infrastructure, with the source code located in ~/tools/src/<someprogram> and the binary output in ~/tools/bin/<someprogram> or just ~/tools/bin/ depending upon whether I'm compiling a simple program, or a more complex package. Oh, I can move things from mednafen-happyeyes-master; it's just that I didn't expect that directory to be automatically created when unzipping the ZIP file. As it is, I have to either rename the directory or move the files. (It would have been easier to just unzip it in place). I see your point on the build of a larger infrastructure; this is usually accomplished by "make install", but I see from your other responses that you're already using that as well. The separate object directories reminds me of TurboC in the 90's, before I was using UNIX in my dayjob, and makefile became the thing to use, performing builds based on dependency trees (whose dependency comparisons are easier if performed in the same directory). Again, probably just due to the UNIX-versus-Windows nature of our pasts. Your point about ~/tools/src/mednafen is the part that initially confused me about the directory structure though... because 'src' is subordinate to 'mednafen', not the other way around. Do you in fact mean that the mednafen source lives in your environment at ~tools/src/mednafen/src ? Again, not a big deal after building it once, I'm just saying that this could be clarified a bit - especially for somebody who has already compiled mednafen. Actually, I had originally expected the UNIX build script to simply apply the patches (perhaps from a sister directory); optionally, it could run the original make, but that wouldn't be necessary. No worries, all is understood now. If you delete your ~/.mednafen/mednafen.cfg, then a new one will be created when you run the program again, and you'll get the new default settings, including the larger font. BTW ... my custom 6x9 font on the debug screen is specifically designed to look like mednafen's 6x13 font, and not like mednafen's 6x12 font. I already had several hard-fought changes invested in mednafen.cfg, so I didn't want to lose them. I know that the font adjustment is documented somewhere in your information, but just making a central note (say the README) to "remember to change your debug font" might help. It occurred to me pretty quickly because I had read it somewhere, just not in the last thing I read (which was the README). Oh, and a game-related note: There is a bug in Dragon Slayer II, which causes it not to work on this version of Medanfen. This issue was actually found first on the TED2 card when using it with my TED2 System Card image which runs with the 1MB of cartridge space as RAM. It was reported on PCEFX. If you're looking a Dragon Slayer II in terms of doing a translation, then I suggest that patching the ISO to avoid that development-system check would be one of the 1st starting points. This was more of a public-service announcement; it's just for awareness. It's the same with the Tenshi no Uta games ... they both check for development-system hardware on startup. That causes Tenshi 1 to fail on the US System Card and only run on the Japanese System Card. Tenshi 2 also starts running some crazy dev code, but it manages to recover and still run on the US System Card. I was actually not aware of these. Thanks for letting me know ! Also, regarding my previous point on showing the flags... I wrote some quick, hackish demonstration code (PCE-specific too). Implementing it properly would be non-trivial because the register "special" function is used to build the long string displayed when the cursor is moved on top of the register (but an additional 'short special' element could be added to the register again.... but that would be tedious). I understand your point, and can see that it would be a nice feature to have, but I can't just hack it into the main debugger file like that. I would like to see if Rypheca will be willing to add at-least a few of the changes that I've made into the official Mednafen release, and there's no way that she would accept a systemwide hack like that. If I can figure out how to do get the flag display to work "legally", then I'll try to implement it. Yes, I did say that it was hackish... It seems to me that the "proper" way would be to extend what you have already done - in debug.h, you added an "outdent" item in the "RegType" struct. In the same way, a function pointer to a display function would make sense. And in 99% of the functions, it could be the default trio_snprintf() that exists in the debug display. Then outdent could be calculated based on (length_available - length_of_name - length_of_displayable). Or, a slightly less universal way, could be to extend the (*GetRegister)() function to add a "char *short_special" as a display override. Anyway, both of these would have taken more time/effort than I wanted to invest last night, as they apply to many systems and may registers. Easier to demonstrate via hack. Dave
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 10, 2019 2:33:27 GMT
I need to check this out later, I got tired of having to put it in Fullscreen every time I needed to debug it pretty quickly!
Now if someone would program label functionality feeding from PCEAS output...
|
|