Jump to content
IGNORED

Handy emulator - the latest version and source code


Cyprian

Recommended Posts

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
Link to comment
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)
Link to comment
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.

Link to comment
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...

 

 

Link to comment
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.

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

  • 4 weeks later...

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!

Link to comment
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...

 

Link to comment
Share on other sites

  • 3 weeks later...
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.

Link to comment
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

Link to comment
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.

Link to comment
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?

 

 

 

Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

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.

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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