Emulator performance on GNU/Linux

[pragma]

Yes, this is a known issue. Most of the bad memory access are in fact generated by LPM instructions used as 3xNOPs. Problem is the Z pointer could point to invalid locations at that time but we don't care. Pragma is working on the emulator and has fixed this. Just don't know when he wants to publish his work.

-uze

I'm currently tracking down an EEPROM handling bug. That said, if you feel comfortable releasing a Beta version to the community, let me know and we'll get that imported into your SVN tree. As it stands, there are some features that could benefit from a wider testing base.

[uze6666]

Please do so. As long as it's released in the beta4 branch we should be fine (it's beta stuff after all). And as you said, it could help find more bugs.

-uze

[lightfoot256]

Looking at the main loop no wonder it's choppy :-p

const int cycles = 100000000;
int left = cycles;
int now = SDL_GetTicks();
while (left > 0)
left -= uzebox.exec(disasmOnly,false);
now = SDL_GetTicks() - now;

You might be able to get away with that under windows but it's still the wrong way to do it; You should be sleeping during the time between execution cycles and giving up processing power where it's needed (probably to the sound thread?); A quick fix would be to just add:

SDL_Delay(0);

just after the last line in the quote above, it gets rid of the choppy sound and runs at full speed - It'd make sense to re-write the loop though to use events and the sdl timer; that way we're not wasting lots of CPU waiting for the next cycle; If I get chance I'll try it out and post a patch but until then the SDL_Delay works nicely.

The SDL_Delay delays the thread nicely (puts it to sleep rather than burning cycles) and even using a delay of 0, you give up enough time for the scheduler to do it's magic however using it to sleep for longer durations seems to be a bit inaccurate so the timer always seemed to work better.

I just switched to Ubuntu and finally got a setup I can deal with; Having trouble getting a full DVD to play through and AVR Studio won't boot under Wine (just hangs on the splash screen), but I've nearly got everything else working. I can't believe how fast 9.04 boots!! :-p

[lightfoot256]

Actually I'm not sure... it seems to help but doesn't fix it entirely.

How is the avr being clocked? I can see it tries to do 100,000,000 cycles but I don't get how it clocks to 28.xxx - I'm guessing there's somthing in the exec routine that's doing somthing else...

[pragma]

Thanks, for taking a look at this. I'm not even ready to tackle Linux/Mac porting just yet, but at least I have the hardware lined up for the job!

Actually I'm not sure... it seems to help but doesn't fix it entirely.

How is the avr being clocked? I can see it tries to do 100,000,000 cycles but I don't get how it clocks to 28.xxx - I'm guessing there's somthing in the exec routine that's doing somthing else...

I wish I could say. I've concentrated elsewhere in the bowels of avr8.cpp to get SPI/MMC/SD card emulation running, and dismissed the main loop as so much voodoo. There probably are better ways to handle this.

I brought all this up with a Linux wizard I know, and he suggested that it's possible that SDL might not be using hardware acceleration at all, despite the SDL calls being used. This may be due to how SDL may be compiled and the windowing environment it's running in. That may account for the poor framerate. But again, I have yet to verify this.

[uze6666]

How is the avr being clocked? I can see it tries to do 100,000,000 cycles but I don't get how it clocks to 28.xxx - I'm guessing there's somthing in the exec routine that's doing somthing else...

Dave had a hard time keeping the sound in sync (and detecting the beginning of a new frame?), so he took a simpler approach. Line rendering is synchronized on the sound output, since it's steadily output at 15.7Khz. There's an obvious problem to this, sound needs to be output for the emulator to work correctly. For the bootloader it's a bit annoying since I couldn't remove the whole sound system to save space. I had to keep the ring buffer running.

-Uze

[DavidEtherton]

That loop is a little misleading -- all it's used for is to generate the "emulated frame rate" display you see updated once every several seconds.

I pretty much count on the underlying SDL implementation to magically sleep on a flip or a full audio queue.

I'm not an SDL expert -- I added support in an hour or two and this was my first time using that API. Normally I hit the metal directly (I'm an engine programmer by trade) but on Linux, SDL pretty much IS the metal these days. (I did some linux work over ten years ago that hit the vga libs directly, I assume that's what SDL itself is layered on top of when it's not using X11)

-Dave

[paul]

I'm an engine programmer by trade

Rockstar's David Etherton?

[DavidEtherton]

I'm an engine programmer by trade

Rockstar's David Etherton?

Yeah.

-Dave

[paul]

Yeah.

I think I've had most of your games at some point. Sorry for the thread hijack; I'll just be over here trying not to dilute the community's obvious talent any further