+bhall408 Posted May 24, 2019 Share Posted May 24, 2019 What is the benefit of removing support for the ROM? I have a loader which relies on it, for example for block selection. So, an emulator w/o original ROM is useless. If you'd like to test it out, PM me. Quote Link to comment Share on other sites More sharing options...
sage Posted May 24, 2019 Share Posted May 24, 2019 What is the benefit of removing support for the ROM? I have a loader which relies on it, for example for block selection. So, an emulator w/o original ROM is useless. Did you try? Quote Link to comment Share on other sites More sharing options...
LordKraken Posted May 27, 2019 Share Posted May 27, 2019 (edited) Rebouncing on Cyprian original post, should https://github.com/b...rc-0.95-patched be considered the latest/most up-to-date windows version? From this thread it seems that is has more features (EEPROM support), more bug fixes and such. So apart from the sounds bug, it looks like the most advanced version, am I correct? Edited May 27, 2019 by LordKraken 1 Quote Link to comment Share on other sites More sharing options...
+bhall408 Posted May 27, 2019 Share Posted May 27, 2019 Rebouncing on Cyprian original post, should https://github.com/b...rc-0.95-patched be considered the latest/most up-to-date windows version? From this thread it seems that is has more features (EEPROM support), more bug fixes and such. So apart from the sounds bug, it looks like the most advanced version, am I correct? This is the version we decided to treat that way. We did a pull request last week. So far we have updated the Windows shell to the 2019 version of the compiler we have either fixed a bug or made a patch (depending on perspective) in Mikie.cpp to support 32BPP Android ARGB mode. We're working on load/save state related issues this week. There are at least 2 core bugs that we have logged (in our internal Jira) against it: Gates of Zendocon "Laughing Spider" sound not playing Ms. Pac-Man uneven speed issue (the game runs faster as you clear more dots - not present on Lynx II actual hardware) Quote Link to comment Share on other sites More sharing options...
LordKraken Posted May 27, 2019 Share Posted May 27, 2019 Ok nice, this is the version I'm planning to use (for EEPROM support actually). Is there a specific reason to upgrade the toolset to v142 (deprecating vs2015 and 2017)? I'm preparing a short PR to remove most warnings, if not all, from the code, as well as a modest contribution to have much better texture for the console background. Quote Link to comment Share on other sites More sharing options...
+bhall408 Posted May 27, 2019 Share Posted May 27, 2019 Ok nice, this is the version I'm planning to use (for EEPROM support actually). Is there a specific reason to upgrade the toolset to v142 (deprecating vs2015 and 2017)? Since we had 2013 on the machine, we needed to do *something*. Community Edition 2019 is free, which makes it an easier decision. I'm preparing a short PR to remove most warnings, if not all, from the code, as well as a modest contribution to have much better texture for the console background. Might be nice to have them available in debug builds... Quote Link to comment Share on other sites More sharing options...
LordKraken Posted May 28, 2019 Share Posted May 28, 2019 PR to review. All warnings for all 4 configs are fixed https://github.com/bspruck/handy-fork/pull/8 Quote Link to comment Share on other sites More sharing options...
LordKraken Posted May 28, 2019 Share Posted May 28, 2019 (edited) Also pushing new background in my fork later today. Edited May 28, 2019 by LordKraken Quote Link to comment Share on other sites More sharing options...
Cyprian Posted May 28, 2019 Author Share Posted May 28, 2019 looks cool Quote Link to comment Share on other sites More sharing options...
+bhall408 Posted May 28, 2019 Share Posted May 28, 2019 PR to review. All warnings for all 4 configs are fixed https://github.com/bspruck/handy-fork/pull/8 Ah, you meant compiler warnings, not runtime warnings/log messages? Those are good to fix... Thanks! Quote Link to comment Share on other sites More sharing options...
LordKraken Posted May 29, 2019 Share Posted May 29, 2019 Could you give me a concrete example of the bugs/warnings you would like to get rid of? I'm in no way a very technical programmer, so most of the handy code is like voodoo magic to me, but it could be fun to dig into that Quote Link to comment Share on other sites More sharing options...
LordKraken Posted May 29, 2019 Share Posted May 29, 2019 Also on a side note, if this patched version is de facto the latest of latest version of Handy, woulnd't that be easier to have a main repo and working with branches instead of each of us forking the repo? Quote Link to comment Share on other sites More sharing options...
Cyprian Posted May 29, 2019 Author Share Posted May 29, 2019 Also on a side note, if this patched version is de facto the latest of latest version of Handy, woulnd't that be easier to have a main repo and working with branches instead of each of us forking the repo?I definitely agree. Multiplying Handy's repos could be a bit misleading. Quote Link to comment Share on other sites More sharing options...
+bhall408 Posted May 29, 2019 Share Posted May 29, 2019 I definitely agree. Multiplying Handy's repos could be a bit misleading. The sage patched version is de-facto becoming the master. Perhaps sage should just rename it? We're currently working on making it 64-bit safe (it wasn't) and adding support for Big Endian/Little Endian 32BPP. 1 Quote Link to comment Share on other sites More sharing options...
drludos Posted June 25, 2019 Share Posted June 25, 2019 Sorry for the noob question, but, so is there a link somewhere to a windows binaires version of Handy with working EEPROM support? The Handy v0.971 I've tried doesn't seem to support it (i'm trying the EEPROM features with CC65 karri edition + Karri/Nop90 template) Also, where can I get the "developer version" mentioned in the first post? (windows binary too if possible :)) Thanks! Quote Link to comment Share on other sites More sharing options...
+bhall408 Posted June 25, 2019 Share Posted June 25, 2019 53 minutes ago, drludos said: Sorry for the noob question, but, so is there a link somewhere to a windows binaires version of Handy with working EEPROM support? The Handy v0.971 I've tried doesn't seem to support it (i'm trying the EEPROM features with CC65 karri edition + Karri/Nop90 template) Also, where can I get the "developer version" mentioned in the first post? (windows binary too if possible :)) Thanks! If you want to test with an Android version that has EEPROM/SD support, PM me... Quote Link to comment Share on other sites More sharing options...
sage Posted July 15, 2019 Share Posted July 15, 2019 On 5/29/2019 at 4:58 PM, bhall408 said: The sage patched version is de-facto becoming the master. Perhaps sage should just rename it? We're currently working on making it 64-bit safe (it wasn't) and adding support for Big Endian/Little Endian 32BPP. Sorry, I did not have time in the last month to follow this up, neither to merge the pull request to libretro. Might come back to this in September, but surely not before. Yes I would be happy to have *one* repo. My dream was somehow to get the architecture dependence out of the core, thus that you can use the core without too much changes in different emulator frontends. You just do not want to patch xxx frontends a time. plus, i would like to have the debug features available in a linux gui. because under wine the debugging is terribly slow (and i have no idea why). well anyway. currently i dont have the time. Quote Link to comment Share on other sites More sharing options...
+bhall408 Posted July 16, 2019 Share Posted July 16, 2019 On 7/15/2019 at 7:02 AM, sage said: Sorry, I did not have time in the last month to follow this up, neither to merge the pull request to libretro. Might come back to this in September, but surely not before. Yes I would be happy to have *one* repo. My dream was somehow to get the architecture dependence out of the core, thus that you can use the core without too much changes in different emulator frontends. You just do not want to patch xxx frontends a time. plus, i would like to have the debug features available in a linux gui. because under wine the debugging is terribly slow (and i have no idea why). well anyway. currently i dont have the time. No worries... Life can get busy! What do you recommend? One thing I have noticed, is that of 5 "core bugs" we have logged against the non-OpenGL version, 4, if not all 5 are not a problem with mednafen/OpenGL versions. So at some point we'll need to figure out why that is. 1 - Ms. Pac-Man speed issue (seems to run slower until you eat about 1/2 the dots. Chained SCB performance issue?) 2 - warbirds issue drawing horizon when rolling right (only) 3 - Gates of Zendocon "Laughing Spider" 4 - RoadBlasters flickering (if this were an Atari 800, I'd blame DLI palette swap implementation) 5 - European Soccer Challenge crashes emulator right after you pick 1 vs 2 player Quote Link to comment Share on other sites More sharing options...
Nop90 Posted July 17, 2019 Share Posted July 17, 2019 As I wrote in another thread, Handy doesn't support unused 6502 instruction values. On a standard 65c02 they are guaranteed to act as Nop, but with different numbers of cycles (1, 2 or 3) depending the value. Does the custom lynx chip works the same? If yes I'd like to see them implemented. Quote Link to comment Share on other sites More sharing options...
42bs Posted July 17, 2019 Share Posted July 17, 2019 Just checked: Lynx II does support SMBx/RMBx but Handy not (though it correctly disassembles it). Quote Link to comment Share on other sites More sharing options...
42bs Posted July 17, 2019 Share Posted July 17, 2019 28 minutes ago, Nop90 said: As I wrote in another thread, Handy doesn't support unused 6502 instruction values. On a standard 65c02 they are guaranteed to act as Nop, but with different numbers of cycles (1, 2 or 3) depending the value. Does the custom lynx chip works the same? If yes I'd like to see them implemented. Checked for $5c/$dc/$fc which are in the absolute addressing group. They have two dummy bytes and behave as 3 NOPs. But no benefit from writing 3 NOPs. So what? Quote Link to comment Share on other sites More sharing options...
+bhall408 Posted July 17, 2019 Share Posted July 17, 2019 9 hours ago, 42bs said: Just checked: Lynx II does support SMBx/RMBx but Handy not (though it correctly disassembles it). So what is Handy doing? Flag it, but not take into account the cycle count? Quote Link to comment Share on other sites More sharing options...
42bs Posted July 17, 2019 Share Posted July 17, 2019 It opens an error dialog (stops). Quote Link to comment Share on other sites More sharing options...
+karri Posted July 17, 2019 Share Posted July 17, 2019 I assumed that the compiler should generate 65SC02 CPU opcodes for both models. These are basically 65C02 without bit instructions. But obviously some bit instructions are then available in the Lynx II model. Correct? Or are you just talking about how many NOP's these instructions create? Quote Link to comment Share on other sites More sharing options...
42bs Posted July 17, 2019 Share Posted July 17, 2019 2 hours ago, karri said: I assumed that the compiler should generate 65SC02 CPU opcodes for both models. These are basically 65C02 without bit instructions. But obviously some bit instructions are then available in the Lynx II model. Correct? Or are you just talking about how many NOP's these instructions create? I have only a stereo Lynx II. On this, the "illegal" opcodes I tested are treated as NOPs but need as many bytes as the "legal" opcodes in the same group. Also as many cycles as the respective number of NOPs. So in the "absolute addressing mode" group, the illegal opcode skips 3 bytes. Which can be very handy ? in an if/then/else construct. But *hmm* it does not save cycles to bad. cmp #10 beq else sta $10 TRIPLE_NOP ; = dc.b $5c else: stz $10 TRIPE_NOP will skip over the "stz $10", otherwise one would write: cmp #10 beq else sta $10 bra endif else: stz $10 endif: But this does not work on Handy. It will bail out. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.