Altirra 2.00

[cwscws]

The command line option /f still does not switch to the custom resolution set in the options. It switches to full screen but not to the custom resolution. But when pressing Alt+Return in the emulator itself it does switch correctly.

[phaeron]

Unless there's some bug in Altirra.

 

There's 2 status bits - bit 1 blit in progress and bit 0 BCB being read.

 

Maybe set a breakpoint at that point and see if the status register reflects what should be happening.

 

I reviewed the blitter emulation code, and it looks like BLITTER_BUSY bit 0 is bugged. Problem is, it's bugged the wrong way -- BCB_LOAD is set during the entire processing of the blit list instead of only when the BCB is loaded. This would at most extend the time that the CPU waits and reduce the problem, not the other way around.

 

If I can get a build that reproduces this problem, I'd like to debug it to see if I can figure out what's wrong. Waiting for the blitter before starting the next blit doesn't necessarily work, because it's still possible for the CPU to overwrite data before the blitter gets to it, but waiting for the blitter after starting a blit should always work.

[flashjazzcat]

Waiting for the blitter before starting the next blit doesn't necessarily work, because it's still possible for the CPU to overwrite data before the blitter gets to it, but waiting for the blitter after starting a blit should always work.

 

That completely correlates with my findings.

[phaeron]

Okay, then it is what I thought. I'll have to think about ways to increase blitter granularity. It's hard to find a good way to do this other than to slice up the blits or to do them lazily on a conflicting access. The former has major performance concerns and is the main reason why Altirra runs at the speed that it does. The latter has annoying behavior when viewing state in the debugger -- if I had VBXE memory breakpoints, for instance, viewing a memory location would cause a deferred blit to run which could then fire the breakpoint off a debug access.

[carmel_andrews]

have'nt played with this version but I did notice that phaeron did a sneaky with the autofire option for joysticks etc (in previous versions), you have to go into the particular joystick option you want to edit and edit it, on the option for fire button, one of the options on the dropdown menu's should say autofire and you move the slider to how fast you want the autofire to be

[Rybags]

Related request - if not already there, could we have the option (like A800W+) to allow keys mapped to controllers to still function for keyboard.

 

It's just a bit of a pain losing the arrow keys due to having them mapped as a joystick.

[phaeron]

You can hold down ALT when using the arrow keys to bypass mapped controllers.

[retrobits]

I tried Altirra 2.00 for some 2 player action last night and noticed that the controllers were affecting each other. I had two LE Atari USB sticks running with Windows 7. The controllers were both active and working, but only if used one at a time. During simultaneous play some directions or trigger presses would affect the other player also. I'm still not sure if this is just an issue with the LE sticks and Windows 7. Need to experiment more.

Edited January 17, 2012 by retrobits

[phaeron]

Check that the input mappings are restricted to only one game controller. By default, they will react to input from any connected controller.

[retrobits]

Check that the input mappings are restricted to only one game controller. By default, they will react to input from any connected controller.

 

Thanks for the tip, that was the problem. I fixed up the input mappings and all is good now. Your emulator is just outstanding.

[cwscws]

I just tested version 2.1-test10 - command line /f is now working correctly! Thank you!

 

Now I only request an remapping option for the Atari keyboard...

[funkheld]

http://www.virtualdub.org/beta/Altirra-2.10-test10.zip%3Cbr%20/%3E

 

error : 2.1 test 10 not found .

[lemiel]

Link is without this %3Cbr%20/%3E what means <br /> , so:

http://www.virtualdub.org/beta/Altirra-2.10-test10.zip

[cwscws]

vsync is still not working correctly. As mentioned before a working sync to screen (besides a fixed vsync option) would be nice. I can go as low as 352x288 - but with 51 Hz. So only a sync to screen would remove tearing and result in a soft scrolling on my system...

[flashjazzcat]

Has anyone else found that palette changes don't "take" until you restart the emulator?

[phaeron]

That happens if you have VBXE enabled -- since the palette is configurable the emulator can't change it until you reset.

[flashjazzcat]

That happens if you have VBXE enabled -- since the palette is configurable the emulator can't change it until you reset.

 

Ah - thanks. I should have realized that.

[Roydea6]

Since SIDE is emulated in the EMU. is there a key press or combo to simulate the red button press to get back into the FAT32 area of the CF card.

 

TIA

[phaeron]

No, the menu button on the SIDE cart currently isn't supported. I need to dig up the hardware spec for that again.

[flashjazzcat]

Having some problems with the IDEa (KMK v1) emulation with regard to bank switching. KMKDIAG recognizes and tests two banks of ROM / RAM, but when running a beta BIOS which is 3KB long and bank switches (1.5KB of code residing in each bank of ROM), the system crashes at boot. I traced this down to the first bank-switching operation called by the INIT routine ($D819). $D819 contains a JMP to $D82A, where A and X are loaded with the destination address prior to the bank switch. A store to $D1A0 should swap in the other bank (I'm not sure if the two banks are reversed in the logic or the ROM - KMK told me that a write to $D1A0 selects bank #0, while a write to $D1C0 selects bank #1, but that this was reversed in early versions of the hardware). Anyway, the PBI vector table and complementary bank switching routine should be duplicated at $d800 in bank #1, but disassembly in Altirra shows this not to be the case. The $D800 region is filled with apparently random bytes. I've checked the beta ROM outside Altirra and $D800 in the second bank should contain the PBI vector table.

 

The whole point of this is to be certain that the banking is working under emulation before I start writing an APT BIOS for the IDEa (although that's not the end in itself, but the foundation for yet another project). KMK told me the beta BIOS was unstable, but I have no reason to suppose it won't at least boot up.

Edited March 7, 2012 by flashjazzcat

[José Pereira]

If I set up the % of CPU at ALTIRRA does it show exactly the CPU in use?

Strange that a simple tittle screen with just a GR.1 or GR.2, no DLIs, PMs or Music, just 4colour letters is 80% or 90% of CPU... Isn't this strange?

 

Thanks.

José Pereira.

[Rybags]

Not really. The CPU is "always in use".

 

If a block of code is using like 95% of the CPU then chances are it's just in a tight loop waiting for a keypress or a flag in memory to change value.

[José Pereira]

Not really. The CPU is "always in use".

 

If a block of code is using like 95% of the CPU then chances are it's just in a tight loop waiting for a keypress or a flag in memory to change value.

 

And when I am moving Joystick/Playing a game with sounds ALTIRRA %CPU is correct?

[flashjazzcat]

Right - I now have a rudimentary version of the old SDX MyIDE driver running as a PBI ROM, and testing the bank switching using my own routines still causes a crash in the emulator. As soon as the second ROM/RAM bank is switched in, unexpected code appears where the upper half of the BIOS should be.

Edited March 7, 2012 by flashjazzcat

[carmel_andrews]

Just a quick question phaeron....where did you come by the name 'altirra' for your atari emulator

 

And some more questions

 

the various parts of the emulator, i.e the cpu emulation, Antic/gtia/pokey etc is that your own emulation code or based on other peoples code of those parts of the emulator (i.e antic, gtia, pokey and 6502/c/65816 emulation)