pouët.net

I'm guessing I'm not the first to fall into this one:

I was coding along with some more ZX81 stuff yesterday, using no$zx81 with it's built in assembler.
I had a (what I at the time thought was) brilliant idea on a new trick that I implemented. It worked fine and I was happy and coded along. Then several hours later I for some reason decided to fire up the effect in another emulator (EightyOne). Did not work. Uh oh...
You can see where this is going. Converted the binary to a wav, then to an mp3, copied this to my mp3 player and used that to load it on the real hardware. Yep, you guessed it, didn't work there either. :(
So X number of hours wasted because I was lazy and put too much trust in an emulator. Or more precisely I put my trust in the WRONG emulator.

Any of you others have stories of inadvertently coding emulator-only stuff? :)

Oh, and to add something to this post other than blog-style ranting:
I think it is time to drop no$zx81, I would prefer to use sjasmplus for assembling anyway, but it doesn't support linking to ZX81 binaries. Anyone know of a stand-alone ZX81 linker, or will I be forced to write my own?

Plenty of modern Amiga demos run nowadays better/only on WinUAE. :)

I remember, when the first GBA emulators came out, people were coding demos (were, mostly technical demos, or one effect presentation) that wouldn't even run later on the real thing. Not even the later more compatible versions of the same emulator :)

Guilty as charged. Though this was back when the GBA hadn't even been released (late 2000, early 2001). The only testing environment available was firefly's gbaemu. Then came VGBA, iGBA, VisualBoy Advance, no$gba and all the rest..

Oh, and when developing for the NES you can definitely fall into the emulator trap. Even with an extremely accurate emulator like Nintendulator, there's still the possibility of glitches that you won't discover until you run your ROM on HW.
With emulators of more recent machines (the 32-bit generation and onwards) the main issue is with execution speed, because most emulators are written to run as fast as possible, so memory access latencies and whatnot may not be correctly emulated.

it's just plain stupid to trust on emulators. okay, it can be a pain in the ass to test on the real thing all the time, but at least do somewhat frequent testing.

and for c64 people there's CodeNet... so you can crossdev, and then send/exec the code on your c64.. over ethernet ;_)

Weird things can happen on real hardware too.
I heard Longshot from Logon System found a trick that allowed hundreds of colors on screen with an Amstrad CPC, but only worked when plugged to an Atari monitor. Whoops.

Anyways, always use the real machine to test the effects, and when it works you can switch to an emulator if you want to do the linking of various effects there.

And, is the zx81 binary format so complicated ? Adding an header to a file should not be a big problem, maybe it could even be done with some unix hackery using dd...

I have almost fallen into the trap on a couple of occasions while coding Amiga 4ks in WinUAE. But somehow I have always been lucky. :)

I always try to speed test the code on the real thing to check that the speed is not completely hopeless, and to check that any potentially dubious hacks work as expected. But my real Amiga has sometimes been out of reach or just not working, so in some cases this testing has been minimal.

Some incidences:

- The first time I saw Ikanim running correctly on a real Amiga was on the big screen in the compo.
- Planet Loonies has a very weird stuttering glitch in the shade cluster part on most A1200s (not on mine for some reason). Luckily, the compo machine was an A4000. :)

That being said, I find WinUAE remarkably accurate in many areas. Even for crazy things like relying on the exact ratio between the video and audio frequencies, it seems to agree with my real Amiga.

Here is my emulator story.

I've once coded a sideborder stuff and tested it with both Vice and CCS64 emulators. In PAL mode both of them worked fine. But my intro was also working in NTSC mode. In NTSC mode both emulators showed different behaviour (on the left sideborder when sprite goes below 0). I thought one of them was correct. When I sent my two alternative versions to a guy who has an NTSC Commodore 64, he told me both of them failed! So, I've corrected my routine according to his reports and it worked on the real thing fine. Then I reported this bug to both Vice and CCS64 emulator developers. Vice team was extremely fast. They solved the bug in couple of days. But I think CCS64 still suffers from that bug.

Yeah, it's pretty simple. I did some reverse engineering and there was a couple of pointers in the header that needed to be set, but it was quickly solved by a little C program of 60 or so lines.
So now I can start using sjasmplus, which is nice since I get stuff like the LUA scripting etc. Yay!

I was coding an effect for a future WonderSwan Color demo while I had no way to test in HW. but there were 3 pretty accurate emulators for it that ran commercial games without problems - WScamp, cygne and OSwan.

Coded the effect and tested to make sure it works on ALL 3 emulators while using a DMA trick that we made up. ~3 months away, the project was abandoned, but I had the opportunity to buy a WSC flash cart (really rare, invested 250$ on it) and started flashing all of our effects to see them on HW.

None of them worked - shown a white screen. it took us 2 weeks to solve that problem and realize all 3 emulators share the same (bogus) information about the HW and we started re-RE the device with the limited knowledge we had.

Quite an adventure...

That WS demo might show itself in one demo party or another though...

I did this in impressive style while I was coding my video player for Spectrum + DivIDE interface.

It relied on a particular undocumented feature of IDE devices (namely, that incrementing the 'sector count' register repeatedly without issuing a new READ SECTOR command would cause it to read sectors indefinitely). This worked brilliantly on the Fuse emulator, but it turns out that on real IDE devices, this undocumented behaviour... doesn't actually exist.

So why did I think that this behaviour existed, and why did it work on the emulator?

Because that bit of emulation code was written by me. And at the time, I knew perfectly well that I'd completely made that behaviour up, without ever testing it. Turns out that coding something doesn't actually make it happen in the real world.

Ouch gasman, not only falling into the emulator trap, but a trap set by yourself! :)

i wouldn't know, i never tried my gba demos on real hardware.

ah let's just add each emulator to pouet as a platform and the problem is solved :-)

gasman: you should've just called it "pimp my spectrum+divide interface" and happily accept the award :)

F.U.

I can identify with that. When I first started working on my DS emulator - back in 2005 or whenever it was - I didn't have a DS (I still don't), and there wasn't much documentation available that went into details about the hardware. So the development process at the beginning pretty much consisted of me going through the Nitro SDK library source code files, and then implementing features in my emulator according to my understanding of how they worked. Sometimes I'd write a small demo to test the feature and send it to someone to run it on their DS and they'd say "yeah it works" or "no, just a blank screen"..

C64: I coded a quite nice twister over a bitmap screen with badlines, tested it in VICE and Hoxs64 and both showed it working, so I thought I was safe, especially since the author of Hoxs64 often brags about how good the emulation is... Big mistake, turns out sprite stretching is in fact impossible to pull off during a badline on a real C64, something which a more careful reading of the VIC article would've revealed.

Lesson learned: Even an old document such as the VIC article is more accurate than today's emulators. :-) Now I always try out some simple raster code on the real deal to see if it actually works as I intended, before I start coding properly. I still find it a mystery why both VICE and Hoxs64 allowed me to do something which quite clearly should be impossible though.

radiantx: That's rather odd, I thought C64 emulators today where pretty damn accurate as long as you don't go for the strange experimental 50-pixels wide sprites and stuff like Crossbow does.
C64 must be one of the machines where most effort has gone into making the emulators, but also it is also one of the machines with the most quirks, so I guess it all evens out in the end!

It took me a lot of trial and error to find which NES emulator is actually the most accurate what comes to PAL emulation... still, I recall debugging Quantum Disco Brothers was a total hell, everything worked perfectly on emu but constantly crashed in unpredictable ways on the NES :) Good times.

Same with Atari 2600 emulators, which don't seem to emulate the way the 2600 starts in a random bank each time... boy was my face red when I finally found that out.