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

[LordKraken]

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-eeprom-newbackgrounds.7z

[Songbird]

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.

[sage]

yes

[LordKraken]

Here it is

handy-dev-0.98alt-eeprom-newbackgrounds.7z

[Songbird]

Perfect! Thanks so much.  

[elfor]

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

[LordKraken]

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.

 

 

[sage]

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

lot of graphic glitches

[LordKraken]

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 June 3, 2020 by LordKraken

[GadgetUK]

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 June 25, 2020 by GadgetUK
Missed stuff

[LordKraken]

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 June 25, 2020 by LordKraken

[GadgetUK]

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?

[LordKraken]

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.

 

[GadgetUK]

What other changes were done to the main branch there do you know?

[LordKraken]

Some bugs fixing I think, Bjorn would know better obviously

You can see more here https://github.com/bspruck/handy-fork/pulls

(and also the pending PR :D)

[sage]

yeah too busy and lazy.

Edited June 25, 2020 by sage

[Songbird]

@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 June 26, 2020 by Songbird

[LordKraken]

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!

[Igor]

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?

 

[LordKraken]

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 June 29, 2020 by LordKraken

[+karri]

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.

[sirlynxalot]

I think the new backgrounds look great!

[Igor]

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.

[LordKraken]

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

[firebottle]

Windows says Handy is not a valid Win32 application...