Question about two roms not working properly with Handy

[advfan]

Of all the commercial games that were released for the Lynx most ROMS seem to work fine with Handy but two.

 

One is BASEBALL HEROES that doesn't even load. Is it because it was badly dumped? If so, can someone try to redump it again? Or is there some kind of incompatibility between this game and the Handy emulator?

 

The other one is S.T.U.N. Runner. This one loads, but there are very apparent graphic glitches from the beginning. The questions for the previous game also apply here.

 

Do you know of another commercial game that has problems with Handy?

[matashen]

Use the Original Hardware for more fun and true sound (Handy has bad noise).

 

I dont has some problems with that games on my Lynx-I and Lynx-II

 

Stay Lynx

 

Stay ATARI

 

Regards

 

Matthias

[108 Stars]

A true fan speaking.

 

Another game that looks very flitchy is Roadblasters.

[The_Laird]

I seem to remember that STUN Runner was one of the games that didn't work on Plynx

[ThomH]

I think Handy just isn't a particularly accurate emulator overall, though from a quick poke about the code I think at least some of that is to do with the host machine performance limits at the time that Handy was written — this is particularly true of the line-by-line display update (which causes the high-colour demos not to work) and the inaccurate sound. Other stuff looks like could have in principle been done more accurately but subject to accurate timing info being derived (eg, CPU_RDWR_CYC is a constant, even though the docs clearly state that the number of cycles the CPU takes to access memory depends on whether the next access will predictably be on the same page, albeit without giving any prediction logic).

 

It'd be a huge project, but a newer emulator from someone with millions of spare hours, access to a flash cart and no qualms about their emulator being an order of magnitude slower than Handy (probably doesn't matter now) could be a great improvement.

[+karri]

The biggest problem in Handy is still sound emulation. There are also old versions out there that do not initialize memory properly. I fixed lots of bugs years ago, submitted patches but nobody seems to maintain Handy anymore.

 

--

Karri

[sage]

I think Handy just isn't a particularly accurate emulator overall, though from a quick poke about the code I think at least some of that is to do with the host machine performance limits at the time that Handy was written — this is particularly true of the line-by-line display update (which causes the high-colour demos not to work)

 

this affects only the ones where the color plaette is updated in-line.

 

For the other you might want to see them on mednafen.

[ThomH]

this affects only the ones where the color plaette is updated in-line.

 

For the other you might want to see them on mednafen.

Either you've done a thorough investigation of every Lynx program ever written or you're making an inference and stating it as though fact. Facts:

 

• the Lynx collects pixel bytes on demand, so it'll collect one byte, output two pixels, collect another byte, output another two pixels, etc;
  
• Handy collects 80 bytes instantaneously (in a way that the Lynx bus isn't even physically capable of) and plots 160 pixels simultaneously
  

 

It's trivial to come up with code that, as a result of this, will produce a different display on the Lynx than on the emulator. The best you can say is that probably code wouldn't be too adversely affected if it was written in the way you expect 99.99% of it was written.

[ThomH]

Sorry, can't edit so need to post again. From a quick root around the mednafen sources (which are largely taken from Handy, and still bear its copyright messages in places — see e.g. susie.h), like Handy the CPU applies a fixed number of clock ticks per memory access (this may be slightly obscured by the source; key notes are that the 6502 and derivatives access memory every single cycle, irrespective of whether they achieve anything useful by doing so and the ADDCYC macro in c65c02.cpp simply multiplies opcode lengths by 4) and like most similar emulators, it's CPU driven. The CPU does one, whole, complete opcode, then the system checks if anything interesting was supposed to have happened during the duration of that opcode then pretends it happened immediately after the opcode. That gives a variable precision of between 2 CPU cycles and 7 CPU cycles for all non-CPU events, which means 8 and 28 cycles in Lynx land if you pretend that all CPU cycles take 4 main clock cycles (which isn't true, but is what this emulator assumes).

 

Such emulators are also prone to make much more subtle mistakes. A classic example is:

 

CLI

SEI

 

With an interrupt pending and the interrupt flag initially set. Most emulators will read the CLI and clear the interrupt flag (and it's an interrupt disable flag on the 6502, so this means "start paying attention to maskable interrupts"). Then they'll do the "what interesting things are happening" test and spot the interrupt. P and the PC are pushed to the stack, the interrupt handler is entered, etc. Assuming normal coding patterns, following the next RTI the emulator will return to the SEI and set the interrupt flag.

 

A real 6502 (or derivative) checks the status of the interrupt flag one cycle before the end of the opcode and based on that test they go to the interrupt handler after the opcode is finished if necessary. Both CLI and SEI both change the interrupt flag on their very final cycle. So what should happen is most of CLI executes, the 6502 spots that the interrupt flag is set and does nothing further. Then it clears the interrupt flag, fetches SEI, checks the interrupt flag and spots that it needs to enter the interrupt handler. So it finishes executing SEI and performs the interrupt.

 

What difference is visible within the machine? In the first example, P on the stack has the interrupt flag clear. In the second, it has it set. In the first, the PC on the stack is pointing at SEI. In the second it's pointing at the instruction after SEI.

 

You can hack around that by, z80 style, pretending there's a one instruction delay to setting the interrupt flag. But then what happens if the interrupt is signalling during the penultimate cycle of CLI but not after SEI? You miss the interrupt. In fact, what if the interrupt is signalling during the penultimate cycle of CLI but not at the completion of CLI?

 

Besides those sort of things (and it's just one example) that crop up as soon as you try to make assumptions about how inaccurate you can afford to be, there are a bunch of things that Handy and mednafen don't even try to get right. Suzy multiplies take 44 or 54 ticks to complete on a Lynx. On both emulators they execute in 0 ticks.

 

Getting much of this stuff right tends to make an emulator substantially more complicated and slower. The former is why people tend not to do it now, the latter was a very valid reason not to do it in 1997 (ie, when Handy was originally in development). I'm not even sure that it's realistic to expect a hobbyist to get all this stuff right for a machine of the Lynx's complexity. This is absolutely a comment on the hardware and why the existing emulator(s) aren't so accurate and absolutely not an indictment of the excellent efforts of people like K. Wilkins.

[Horst]

Sorry, can't edit so need to post again. From a quick root around the mednafen sources (which are largely taken from Handy, and still bear its copyright messages in places — see e.g. susie.h), like Handy the CPU applies a fixed number of clock ticks per memory access (this may be slightly obscured by the source; key notes are that the 6502 and derivatives access memory every single cycle, irrespective of whether they achieve anything useful by doing so and the ADDCYC macro in c65c02.cpp simply multiplies opcode lengths by 4) and like most similar emulators, it's CPU driven. The CPU does one, whole, complete opcode, then the system checks if anything interesting was supposed to have happened during the duration of that opcode then pretends it happened immediately after the opcode. That gives a variable precision of between 2 CPU cycles and 7 CPU cycles for all non-CPU events, which means 8 and 28 cycles in Lynx land if you pretend that all CPU cycles take 4 main clock cycles (which isn't true, but is what this emulator assumes).

 

Such emulators are also prone to make much more subtle mistakes. A classic example is:

 

CLI

SEI

 

With an interrupt pending and the interrupt flag initially set. Most emulators will read the CLI and clear the interrupt flag (and it's an interrupt disable flag on the 6502, so this means "start paying attention to maskable interrupts"). Then they'll do the "what interesting things are happening" test and spot the interrupt. P and the PC are pushed to the stack, the interrupt handler is entered, etc. Assuming normal coding patterns, following the next RTI the emulator will return to the SEI and set the interrupt flag.

 

A real 6502 (or derivative) checks the status of the interrupt flag one cycle before the end of the opcode and based on that test they go to the interrupt handler after the opcode is finished if necessary. Both CLI and SEI both change the interrupt flag on their very final cycle. So what should happen is most of CLI executes, the 6502 spots that the interrupt flag is set and does nothing further. Then it clears the interrupt flag, fetches SEI, checks the interrupt flag and spots that it needs to enter the interrupt handler. So it finishes executing SEI and performs the interrupt.

 

What difference is visible within the machine? In the first example, P on the stack has the interrupt flag clear. In the second, it has it set. In the first, the PC on the stack is pointing at SEI. In the second it's pointing at the instruction after SEI.

 

You can hack around that by, z80 style, pretending there's a one instruction delay to setting the interrupt flag. But then what happens if the interrupt is signalling during the penultimate cycle of CLI but not after SEI? You miss the interrupt. In fact, what if the interrupt is signalling during the penultimate cycle of CLI but not at the completion of CLI?

 

Besides those sort of things (and it's just one example) that crop up as soon as you try to make assumptions about how inaccurate you can afford to be, there are a bunch of things that Handy and mednafen don't even try to get right. Suzy multiplies take 44 or 54 ticks to complete on a Lynx. On both emulators they execute in 0 ticks.

 

Getting much of this stuff right tends to make an emulator substantially more complicated and slower. The former is why people tend not to do it now, the latter was a very valid reason not to do it in 1997 (ie, when Handy was originally in development). I'm not even sure that it's realistic to expect a hobbyist to get all this stuff right for a machine of the Lynx's complexity. This is absolutely a comment on the hardware and why the existing emulator(s) aren't so accurate and absolutely not an indictment of the excellent efforts of people like K. Wilkins.

 

Thank you for your post. I've learned a lot from it, don't understand all of it, but learned nonetheless.

[sage]

this affects only the ones where the color plaette is updated in-line.

 

For the other you might want to see them on mednafen.

Either you've done a thorough investigation of every Lynx program ever written or you're making an inference and stating it as though fact. Facts:

 

 

As I have written them e.g. knowing what the code is doing, yes, I am sure what is diplayed (more of less) correctly on the emulator.

Its even displayed correctly if handy is running fast enough for 75Hz updates on a LCD monitor. You can even check by making Screendumps if you like.

Please, before you claim things on these highcolor demos oyu might check what they are really doing!

 

now to the other stuff:

Esp in the multiply/divide engine there are a lot of mistakes in the emulation. Same for the sprite engine. Not to forget the "unoffical" cpu opcodes.

[ThomH]

As I have written them e.g. knowing what the code is doing, yes, I am sure what is diplayed (more of less) correctly on the emulator.

Its even displayed correctly if handy is running fast enough for 75Hz updates on a LCD monitor. You can even check by making Screendumps if you like.

Please, before you claim things on these highcolor demos oyu might check what they are really doing!

An inference is a conclusion reached on the basis of evidence and reasoning. Your counter-argument that you have some evidence therefore isn't particularly compelling. Compare and contrast with a fact. A fact is something for which no counter examples exist. If I can establish that 99.99% of human beings are less than 3m tall, I can infer that no human being is 3m or taller. However, that doesn't make it a fact. In truth, I have no idea whatsoever whether it's a fact.

 

Unless you disagree with the following then I don't think there is substantial difference between our positions:

• the ideal goal of an emulator is to reproduce exactly the original machine's operating environment;
  
• derivations from that ideal for whatever reason are the cause of software incompatibilities;
  
• not all derivations are equally likely to produce software incompatibilities; but
  
• (i)disallowing mid-line palette changes, and (ii) fetching all video data in a single cycle rather than as the scan progresses are two of the differences between the operation of a real Lynx and the operation of Handy.
  

 

I'm concerned this thread is going to go a bit ad hominem. Please excuse my failure to respond subsequently if it does so.

[sage]

However, that doesn't make it a fact. In truth, I have no idea whatsoever whether it's a fact.

 

Useless discussion.

[advfan]

I want to thank everyone that replied in this thread, but somehow the discussion has derailed from the original question. I still don't know why 99% of all commercial games do work with Handy but BASEBALL HEROES has issues. Does anyone know? Is it a problem of Handy? Of the game or its dump?

If it's the second, can a new dump solve the problem?

[108 Stars]

Your question WAS answered. Handy is far from perfect, so not everything runs perfectly.

[ThomH]

I want to thank everyone that replied in this thread, but somehow the discussion has derailed from the original question. I still don't know why 99% of all commercial games do work with Handy but BASEBALL HEROES has issues. Does anyone know? Is it a problem of Handy? Of the game or its dump?

If it's the second, can a new dump solve the problem?

From the way that it fails to load then I'll wager it's a bad dump. Having had a quick poke in HandyBug, the CPU does a comparison between two values then because they fail to be equal, enters an explicit infinite loop.

[advfan]

From the way that it fails to load then I'll wager it's a bad dump. Having had a quick poke in HandyBug, the CPU does a comparison between two values then because they fail to be equal, enters an explicit infinite loop.

 

So, is anyone there that has the ability to try to make another dump of this game?

Edited October 27, 2009 by advfan