Jump to content
Cyprian_K

Handy emulator - the latest version and source code

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 by LordKraken
  • Like 1

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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...

 

 

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites
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...

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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?

 

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...