Activity for mi-chi
-
mi-chi posted a comment on discussion Feature suggestions
First off, thank you for all the hard work on this amazing app—it's packed with features and has been a great tool for many of us! I wanted to share a small usability issue that’s caused me a bit of heartache: more than once, I thought I was recording a video, only to later discover I had taken a still photo instead. Those missed moments are tough to lose, especially when they were meant to be captured in motion. Many camera apps use a clear tab-style selector (e.g. Photo, Video, Portrait, etc.)...
-
Sorry for being late on that. Tested with 4.3.0 #14184, and the output looks good. That fixed the issue.
-
Ah, now I get it. Not decimal... xD
-
Possible FIX: Looks like copying and pasting the code from Index HEX (\sdas\linksrc\lkout.c -> ixx()) to Motorola SREC (\sdas\linksrc\lks19.c -> s19()) works as expected. The output is (again with spaces): Copying and replaceing the whole from the whole "if (i)" branch and replacing "iflush()" with "sflush()" and "IXXMAXBYTES" with "MAXBYTES" results in the output: S1 10 0000 FD210D00FDCB0026FDCB0116C9 2E S1 07 0011 07000900 D7 S9 03 0000 FC
-
Possible FIX: Looks like copying and pasting the code from Index HEX (\sdas\linksrc\lkout.c -> ixx()) to Motorola SREC (\sdas\linksrc\lks19.c -> s19()) works as expected. The output is (again with spaces): Copying and replaceing the whole from the whole "if (i)" branch and replacing "iflush()" with "sflush()" results in the output: S1 10 0000 FD210D00FDCB0026FDCB0116C9 2E S1 07 0011 07000900 D7 S9 03 0000 FC
-
Buggy output in Motorola SREC Format (Z80)
-
Wrong area flag handling in linker
-
I found an optimization regression on the Z80 between SDCC v4.2.2 and the current, v4.2.14, but this seems to be there for quite a while, at least v4.2.8 produces the same code as v4.2.14. Here's the code in question (AddExperience.c): typedef unsigned char uint8_t; typedef unsigned int uint16_t; extern struct LevelData_t *pExperienceData_; struct LevelData_t { uint8_t level; uint16_t currentExp; // progress in current level }; // Experience required per level before raised static const uint16_t...
-
I found an optimization regression on the Z80 between SDCC v4.2.2 and the current, v4.2.14, but this seems to be there for quite a while, at least v4.2.8 produces the same code as v4.2.14. Here's the code in question (AddExperience.c): typedef unsigned char uint8_t; typedef unsigned int uint16_t; extern struct LevelData_t *pExperienceData_; struct LevelData_t { uint8_t level; uint16_t currentExp; // progress in current level }; // Experience required per level before raised static const uint16_t...
-
That's a terrific model, so no cycles need to be wasted to save and restore things that don't need to, and nothing needs to be taken care of when coding an ASM routine, except for the stack frame ix. Thanks for the info!
-
Is there a definition about which registers need to be preserved when interfacing with assembly functions on Z80, specifically where a C routine calls an ASM function. As an ASM function does not know which registers are used by the caller - in fact, it can be called from different contexts - I'm looking for a ruleset about which registers need to be preserved and restored before returning from an ASM function. In the end, I don't want to add any unnecessary push / pop instructions in a hand-written...
-
Ah, typo, replace the parameters at the end in the line: 40 PUT SPRITE I,(I*8,I*2),I+2,0 I updated the post above.
-
Hmmm, getting a bit theoretical now. Considering 16x16 sprites to be the default (as is now with RECOIL), you would only need the text file for screens that require an 8x8 sprite. On the other hand, MSX uses 8x8 sprites as the default, unless otherwise specified. And - for the sake of completeness, getting very MSX-technical now - think about the 4 sprites per line limit. This prevents an accurate conversion from 8x8 to 16x16 sprites lossless. The following code shows 8 (eight) 8x8 sprites in 8x8...
-
Ah, typo, replace the parameters at the end in the line: 40 PUT SPRITE I,(I*8,I*2),I+2,15 I updated the post above.
-
Hmmm, getting a bit theoretical now. Considering 16x16 sprites to be the default (as is now with RECOIL), you would only need the text file for screens that require an 8x8 sprite. On the other hand, MSX uses 8x8 sprites as the default, unless otherwise specified. And - for the sake of completeness, getting very MSX-technical now - think about the 4 sprites per line limit. This prevents an accurate conversion from 8x8 to 16x16 sprites lossless. The following code shows 8 (eight) 8x8 sprites in 8x8...
-
Hmmm, getting a bit theoretical now. Considering 16x16 sprites to be the default (as is now with RECOIL), you would only need the text file for screens that require an 8x8 sprite. On the other hand, MSX uses 8x8 sprites as the default, unless otherwise specified. And - for the sake of completeness, getting very MSX-technical now - think about the 4 sprites per line limit. This prevents an accurate conversion from 8x8 to 16x16 sprites lossless. The following code shows 8 (eight) 8x8 sprites in 8x8...
-
Good point by SD Snatcher. Only I wouldn't want even more extensions. Here's a more descriptive proposal: Look for an accompanying text file with the same base name but a generic extension (e.g. ".txt" to make it obvious that this is a text file). That file contain meta-information that belong to the image, e.g. specifications like"SPRITE_SIZE=8x8". So for the example: LOTUSF3.SC2 <- image LOTUSF3.TXT <- meta-data file with the sprite size Pros: extensible - more specifications may be added in the...
-
Good point by SD Snatcher. Only I wouldn't want even more extensions. Here's a more descriptive proposal: Look for an accompanying text file with the name base name but a generic extension (e.g. ".txt" to make it obvious that this is a text file). That file contain meta-information that belong to the image, e.g. specifications like"SPRITE_SIZE=8x8". So for the example: LOTUSF3.SC2 <- image LOTUSF3.TXT <- meta-data file with the sprite size Pros: extensible - more specifications may be added in the...
-
OK, that was the problem: I didn't install XnView (using the setup.exe), but used the .ZIP package to extract it into the Program Files (x86) folder, so that "Uninstall" registry key didn't exist. I only activated the Explorer context-menu ("Browse with XnView"). Using the Setup.exe made the Recoil installation locate the correct folder for the XnView plugin. The plugin in now installed to the proper location - but still doesn't work. XnView doesn't show any files with MSX extension (SC2-SCC, GE5,...
-
Sorry, the notification email got somehow lost. Attached is a screenshot with the XnView Classic selected where you can see the installation at the bottom. As a side Note: My experiences with the MSI installer were always horrible. Even the simplest things always turned out to be a nightmare to do... Not to mention that you cannot mix 32 and 64 bit installations. Ultimately lead me to be using the much better (free) install system Inno Setup (has a simple point-and-click IDE and is yet scriptable)....
-
Now THAT's an excellent idea!!! Take my vote for that!
-
Missing option to select sprite size for MSX screens
-
Thanks for your quick reply! The problem is not the preview / thumbnail browser (like in your screenshot), but in the single image tab that opens when double-clicking / pressing enter (see screenshot). Normally, I can navigate to the next / previous file with the mouse-wheel (which is set to previous / next file), or with keyboard Page-up/down or cursor left/right, but I can't when viewing files supported only by the Recoil plugin (e.g. MSX .SC2). As can be seen in the screenshot the navigation buttons...
-
Thank you for your quick reply! I tried with Windows 10 - 64 bit, XnView Classic 2.49.5 using Min. Setup and Ext. Setup. Recoil is "recoil-6.0.0-win64.msi". I found that Recoil installs the XnView plugin to "C:\Program Files\XnView\Plugins", while my XnView is installed in "C:\Program Files (x86)\XnView\Plugins" (note the " (x86)"). I'm using it to watch MSX images, e.g. ".SC2" and ".GE5". Now I tried 3 things: I moved the file (Xrecoil.usr) from the "Plugins" folder of the Recoil installation to...
-
Cannot browse in XnViewMP "View" mode
-
XnView Plugin not working (Windows, XnView 32 bit)
-
I see. The code is working with MSVC 2017 (compiler ver 19.16.27034) and IAR C for Z80 (compiler ver V4.06A, 2001), but they are probably not the best source of reference. I ran into that when building some legacy code with SDCC, and agree that using undefined types should result in an error. That said, the error message, stating that type 'x' cannot be converted to type 'x", where 'x' is identical in both cases, wasn't really helpful to identify the problem. Consider the issue as "no fix required"....
-
Build error with undefined pointer to struct param in declaration
-
Thanks for the quick fix, but still buggy: Only HL is correct now, DE is swapped twice now and BC not at all. Second DE block should work on BC registers.
-
uCsim simulator (Z80) bug in EXX instruction
1