Jump to content
LordKraken

Handy latest version (0.98) for Windows (eeprom support, new backgrounds)

Recommended Posts

Hi all,

 

Since it seems the latest binary for Handy on Windows are a bit difficult to find, I compiled the latest source this morning.

 

It has eeprom support (that's for you Carl but you will need to tag your rom by using the latest version of Lynxdir, see https://atariage.com/forums/topic/305458-lynxdir-193-for-vs-2019-windows-binary/).

 

It has 2 minor differences from the "official" version.

- There is a crash fix that occured when you did not choose a rom on start (the emulator might be in a weird state, but it does not crash at least)

- There are new backgrounds of better quality, see pictures.

 

handy-0.98alt-1.png.1812d8902f9b7f273c20831763415991.png

 

handy-0.98alt-2.thumb.png.07724928892ba4812fbbd63e340c3978.png

 

 

handy-0.98alt-eeprom-newbackgrounds.7z

  • Like 5
  • Thanks 2

Share this post


Link to post
Share on other sites

Thanks for this! Do you also have the debugger version of Handy? Need to step through my code to see why it's not behaving. :)

 

Isn't EEPROM support in the Handy header as simple as updating byte 60? I have a $41 there which I believe indicates 93c46 EEPROM support.

Share this post


Link to post
Share on other sites

Is your build based on Sages fork, which i guess is the most up-to-date?

Share this post


Link to post
Share on other sites

Yes it is! Ideally I would prefer to do a pull request and then merge fixes and new features into a unique repo. Not necessarily a big fan of forking, especially with this project.

 

 

Share this post


Link to post
Share on other sites

hm ... at least under wine it is not running very good 😕

lot of graphic glitches

Share this post


Link to post
Share on other sites
Posted (edited)

What do you mean exactly? The only delta here are the bakground and the crash fix when you dont select a rom but in this case some initialization do not happen and you have a black screen with some glitches indeed, better than a crash though :) 

 

I think Handy frontend would benefit from a major refactor but going back in 25 yo windows 95 code is really not a lot of fun...

Edited by LordKraken

Share this post


Link to post
Share on other sites
Posted (edited)

Just tried that version - great work, it's lacking some of LX NET fixes  I think, lacks the sound fixes too I think.  I can send you my old source if you want - may help you merge those fixes into this version.

 

I vaguely remember fixing some bug related to the display and it stretching incorrectly too. ie. 1 row of pixels getting stretched or squashed due to the a bug in resizing somewhere.

Edited by GadgetUK
Missed stuff

Share this post


Link to post
Share on other sites
Posted (edited)

I would rather have one repo only instead of multiple forks, but not sure if there is any motivation for that (my PR is one year old now ^^).

Well, if not we could keep working in my fork, I would love to add some cool user stuff as well (for instance  a visual list with game boxes and information where you just click to start the game - maybe a cooperation with atarigamer? What do you think @Igor :D)

Edited by LordKraken

Share this post


Link to post
Share on other sites

I am not talking about a fork - I am talking about changes that were done to it prior to you doing your changes, that could be merged with your version - a single version.  You could just compare between the source versions and spot the differences pretty easily.  If you want I can PM you with a link?

Share this post


Link to post
Share on other sites

Oh yes that I understood, but since my repo is already a fork from the most "advanced" version of Handy, the risk here is to make this fork diverge too much from the original repo. Thus creating 2 "advanced" versions of Handy.

 

Share this post


Link to post
Share on other sites
Posted (edited)

yeah too busy and lazy.

Edited by sage

Share this post


Link to post
Share on other sites
Posted (edited)

@LordKraken since you have Handy building, I have a couple of quality-of-life requests for the debugger version if doable. If the user enters a "reg" command in the debugger window, he sees the current 65c02 registers like this:

>reg
PC=$26e3 SP=$ff PS=0x20 A=0x01 X=0xc0 Y=0x0a
>step

>reg
PC=$26c5 SP=$ff PS=0x20 A=0x01 X=0xe0 Y=0x0a

However when the user issues a "step" command, the command window is silent and just presents the user with another prompt. Could you please make "step" always execute an implicit "reg" so the user sees the registers without having to type "reg" again?

 

Likewise, it would be nice if a breakpoint is hit, then an implicit "reg" would be executed and shown on-screen.

 

Thank you for your consideration. :)

 

Edited by Songbird

Share this post


Link to post
Share on other sites

That sounds like a reasonable request, at least not too hard on paper :) And if @GadgetUK helps me integrating the missing fixes and features, we could try to get a new version out!

Share this post


Link to post
Share on other sites
On 6/25/2020 at 11:26 PM, LordKraken said:

I would rather have one repo only instead of multiple forks, but not sure if there is any motivation for that (my PR is one year old now ^^).

Well, if not we could keep working in my fork, I would love to add some cool user stuff as well (for instance  a visual list with game boxes and information where you just click to start the game - maybe a cooperation with atarigamer? What do you think @Igor :D)

Sounds good, I've been thinking of exposing an API on my site so this is definitely something I can do...but is there any chance of this working on a Mac as well?

 

Share this post


Link to post
Share on other sites
Posted (edited)

well I don't know if you looked at the source but it's fairly old-fashion C/C++ code so should compile anywhere... well that's for the emulation part because the UI part is a different story, and digging into that sounds like opening an old can of worms to me (but others did since most lynx emulators are using handy core right?).

 

I guess you're interested for a MacOs port to get access to the debugger?

Edited by LordKraken

Share this post


Link to post
Share on other sites

The cc65 can export all that is required for symbolic debugging in both asm and C. So writing debug support to some IDE like Visual Studio would be pretty cool.

Share this post


Link to post
Share on other sites
On 6/29/2020 at 5:30 PM, LordKraken said:

well I don't know if you looked at the source but it's fairly old-fashion C/C++ code so should compile anywhere... well that's for the emulation part because the UI part is a different story, and digging into that sounds like opening an old can of worms to me (but others did since most lynx emulators are using handy core right?).

 

I guess you're interested for a MacOs port to get access to the debugger?

Yep that's right. I do have a windows laptop here but it's not set up. I mostly work on my Macs.

Share this post


Link to post
Share on other sites

Sounds like a lot of work just cleaning up the code from all windows specific stuff...

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