Altirra 2.30 released

[Vaughan]

 

I tried to reproduce this locally but couldn't do so -- the only possibility I can think of so far is that maybe my old 360 wireless controller acts differently (it is an early version I got at a conference). When this happens, does the input map still editor still see the button presses? Also, if you keep up the Game Controller control panel while playing, does it still see the inputs when the controller stops working in the emulator?

 

 

Huh, interesting experiment.... by the way, my 360 controller is a USB model (not wireless).

 

Okay, so into Donkey Kong we go - full screen. After four screens the joystick stops working. Go out to CP, and it still detects the controller. Go into Altirra mapper, and IT still see's the controller. Go back to the game - the controller works again. I'm not sure if this helps at all. Altirra is a great emulator, but since this happens on two completely different computers - but with the same controller - I thought it worth bringing up again.

 

360 Controller driver date: 13/08/2009. Version: 2.1.0.1349

 

ps: I reinstalled the controller driver to confirm the version I have is the latest - it was.

 

And I tested again with the same result. Donkey Kong lasted 6 levels this time, but the controller stopped working. Went into the mapper, and the mapper see's it fine. Cancelled out of the mapper, and the joystick works again inside the game.....

 

pps: I am experimenting a little more. Found something interesting..... the entire controller does not die. It seems to be hats that go (which I use to move Mario about), I start the game, and select two player etc, I use the A and B button. When Mario stops moving around, the A and B buttons still work (so I can reset the game) although this doesn't fix the hat. Right button (the one above the right trigger) also stops working.... I don't suppose that helps.......

 

Also, I assigned TURBO to the left button. I start Donkey Kong, give it a spurt of Turbo, and BAM.... the hats don't work...... Happens every time. Again, not sure if that helps.

Edited August 28, 2013 by Vaughan

[danwinslow]

support for the ethernet cartridge in next version of Altira would be cool...

Indeed. Phaeron, Mark and I would be glad to assist with this in any way we can.

[TXG/MNX]

Indeed. Phaeron, Mark and I would be glad to assist with this in any way we can.

Yes this would speed up the development for the real hardware aswell....

[phaeron]

pps: I am experimenting a little more. Found something interesting..... the entire controller does not die. It seems to be hats that go (which I use to move Mario about), I start the game, and select two player etc, I use the A and B button. When Mario stops moving around, the A and B buttons still work (so I can reset the game) although this doesn't fix the hat. Right button (the one above the right trigger) also stops working.... I don't suppose that helps.......

 

Also, I assigned TURBO to the left button. I start Donkey Kong, give it a spurt of Turbo, and BAM.... the hats don't work...... Happens every time. Again, not sure if that helps.

 

Think I know what this is now -- are you using an input map based on the default Xbox 360 controller map? That map has the left and right analog stick buttons bound to toggling between player 1/2 and joystick/paddle mode. This is done via bindings from Joy Button 9/10 to an Input State controller and flag conditions on the Joystick and Paddle controllers within the input map.

 

 

support for the ethernet cartridge in next version of Altira would be cool...

 

Sorry, not going to happen for the next version, too big. Haven't decided whether I'll go for this since it's a lot of work to implement.

[morelenmir]

That is a shame Avery, as it sounds a very cool toy to play with. However I do appreciate your point about how long it would take to implement. Maybe in the future when other things are fully nailed down?

 

I have come up with quite a few feature suggestions over the last few months that I have been away from the scene. However I don't want to bury you in them all at once!

 

My first is something that came up just today and I think should be easy to include. I suggest the data from the "Cartridge Images" page of "Atari800Win+"'s help file be incorporated in the Altirra docs. It is absolutely FASCINATNG and contains information on cartridge formats and banking schemes that I have not found elsewhere. I am going to make a PDF document from it just for my own uses. To have it quickly on-hand whenever Altirra is open would be more convenient still.

 

Also, is the overhaul of the custom shortcut system you referenced a while back still on the go? It can get a bit frustrating with the 'source debugger' not using the same shortcuts as the main application if you have customized them. Also, the source dubuger window remembering the size you last shrunk it down to between Altirra session would be a MAJOR, major boon!

[MaPa]

Just a question.. why there are only 224 scanlines visible in NTSC mode? Shoul I set something to display whole picture?

[MaPa]

DELETED.

Edited August 29, 2013 by MaPa

[bfollett]

Just a question.. why there are only 224 scanlines visible in NTSC mode? Shoul I set something to display whole picture?

Under the View menu, there is an Overscan option. Try Full.

 

Bob

[MaPa]

I don't want full overscan, i want nromal overscan and have same size as in PAL (the screen size is the same IMHO in both systems).

 

Secondly, why Altirra returns from PAL/NTSC check register values 1 and 15 instead of 0 and 14?

[Vaughan]

 

Think I know what this is now -- are you using an input map based on the default Xbox 360 controller map? That map has the left and right analog stick buttons bound to toggling between player 1/2 and joystick/paddle mode. This is done via bindings from Joy Button 9/10 to an Input State controller and flag conditions on the Joystick and Paddle controllers within the input map.

 

 

 

 

Holy toledo! Answer, yes, I used the default profile. I have now created my own custom profile, and have added everything I need to it. After a short test of ten minutes or so - - - - - - - sure enough, no problems! This deserves more extensive testing, so I'm going to enjoy some Atari over the next couple days and will most definitely post my findings back here - good or bad.

 

Thanks a lot for your attention to this, it has been driving me mad. I know you have more pressing things to worry about than users with ridiculous problems like this, especially nasty intermittent ones that whine like I do. Seems like it's user error.

[phaeron]

My first is something that came up just today and I think should be easy to include. I suggest the data from the "Cartridge Images" page of "Atari800Win+"'s help file be incorporated in the Altirra docs. It is absolutely FASCINATNG and contains information on cartridge formats and banking schemes that I have not found elsewhere. I am going to make a PDF document from it just for my own uses. To have it quickly on-hand whenever Altirra is open would be more convenient still.

 

Also, is the overhaul of the custom shortcut system you referenced a while back still on the go? It can get a bit frustrating with the 'source debugger' not using the same shortcuts as the main application if you have customized them. Also, the source dubuger window remembering the size you last shrunk it down to between Altirra session would be a MAJOR, major boon!

 

The cartridge info section of the A8WP help is indeed useful but I can't just copy it into Altirra. BTW, you want the updated version, which is CART.TXT from Atari800 -- it now contains some information on new .CAR formats that only Atari800 and Altirra support.

 

Haven't gotten around to redoing the shortcut system yet.

 

I don't want full overscan, i want nromal overscan and have same size as in PAL (the screen size is the same IMHO in both systems).

 

Secondly, why Altirra returns from PAL/NTSC check register values 1 and 15 instead of 0 and 14?

 

The amount of display put out by the Atari is the same between NTSC and PAL is the same, but the amount displayed by the TV isn't. The TV doesn't know or care that its signal is coming from an Atari, only that it's in NTSC or PAL format. In both cases a certain amount of the image display is cut off by overscan and in the case of NTSC that hides part of the active region from the Atari. One spec I have seen says an action spec border of 3.5% on each side vertically, which comes very close to 224 scanlines vertically. That's what Altirra displays in Normal overscan mode. My monitor's display is also pretty close to this.

 

Altirra returns $01/$0F from the PAL register because all of my NTSC machines return $0F stably and I haven't heard anything contradicting $01 for PAL, or seen anything in the schematics that would indicate instability in bit 0. Officially, only bits 1-3 matter.

[morelenmir]

Is the cartridge stuff not public domain? I assumed it was just a case that A8W+ had gathered it in to one place. Maybe it would be better for some public spirited individual to collate together the same data from multiple sources and then upload it here as a public resource? Maybe an Excel table or PDF? That way there might not be any problems with copyright or whatever.

Edited August 31, 2013 by morelenmir

[MaPa]

Altirra returns $01/$0F from the PAL register because all of my NTSC machines return $0F stably and I haven't heard anything contradicting $01 for PAL, or seen anything in the schematics that would indicate instability in bit 0. Officially, only bits 1-3 matter.

 

 

Then you should update your HW Reference Manual and I noticed, that in current version of manual you have shifted the bits to the right by one too.

[Vaughan]

Well, I've been playing Donkey Kong a lot - for hours - and it's got to be one of the most frustrating games going.... so damn random.

 

But the good news is - I can confirm my 360 controller now gives zero problems. In other words, everything now works well, and I can stop bothering you with my issue.

 

Thanks again for the emulator, and for your help in this forum.

[phaeron]

I'll fix the PAL register values in the Hardware Manual.

 

Another update:

 

http://www.virtualdub.org/beta/Altirra-2.40-test16.zip

http://www.virtualdub.org/beta/Altirra-2.40-test16-src.zip

 

Fixes some pretty nasty IRQ issues in 3.58MHz/7.14MHz 65C816 mode, and adds proper tracking of chip/fast bus accesses for more accurate timing. Currently RAM and shadowed ROM are on the fast bus, while hardware registers and cartridges are on the chip bus. An access to the chip bus forces alignment to the next machine cycle and takes the full machine cycle.

 

It appears that custom SIO routines are a common source of compatibility issues with accelerators. The main problem is improper handling of the serial output complete interrupt. The seroc IRQ is unusual in two ways, one being that it isn't latched, and the other being that it is the only IRQ that spontaneously deasserts. Both the Lucasfilm loader and the Joyride loader have bugs where they write to SEROUT and assume that the seroc IRQ deasserts before the CPU can respond to it. Unfortunately, there is a delay before POKEY starts shifting, and with an accelerator the CPU is fast enough that it can dispatch the IRQ before it goes away, trashing the load. This is avoided by properly written SIO routines that first wait for serial output ready before enabling the serial output complete IRQ.

[danielcg]

Atirra 2.40-test 16 will not allow Star Raiders to smooth out explosion and cause slowdowns when explosions are present because Star Raiders are stored on a cartridge which is not shadowed and cannot be accelerated. Can you add "Accelerate ROM cartridge" option so ROM cartridges can be accelerated. I know some cartridges are special rather than ROM cartridge and should not be accelerated. However, the user can turn on or off accelerate ROM cartridge. Hardware registers will remain at 1.79Mhz speed only.

[Keatah]

I love accelerated 65C816 processor. Star Raiders uses 6502C processor but works fine with accelerated 65C816 processor. Star Raiders run much more smoothly with 2X or 4X accelerated mode, especially when enemy ship or asteroid "explode". All other games did not benefit anything I know so I did not test other games other than Star Raiders.

 

Atari Basic works fine on 65C816 processor and even accelerated, too.

I bet that is because it uses genuine x,y,z 3D graphics. All on the main CPU. As far as the custom chips are concerned they're just plotting a few dots here and there. But it takes time to get the x,y positions from the CPU.

[Mclaneinc]

Atirra 2.40-test 16 will not allow Star Raiders to smooth out explosion and cause slowdowns when explosions are present because Star Raiders are stored on a cartridge which is not shadowed and cannot be accelerated. Can you add "Accelerate ROM cartridge" option so ROM cartridges can be accelerated. I know some cartridges are special rather than ROM cartridge and should not be accelerated. However, the user can turn on or off accelerate ROM cartridge. Hardware registers will remain at 1.79Mhz speed only.

 

Its a nice idea but surely it goes against the idea of an emulator, ie to emulate how the the real Atari would have done it as closely as possible, and then becomes a cheap hack?

 

Just my 1p

[phaeron]

Well, at this point we're no longer in the territory of anything Atari specced or built... but yes, I would like to ground the emulator in reality somehow. That means doing what real accelerators do or are likely to do.

 

Running the cartridge port at >1.79MHz isn't possible. However, having a BIOS copy an unbanked cartridge to a write-protected shadow in fast RAM definitely would be, as well as simply having the accelerator itself emulate the banked cartridge. As such, I would be interested if anyone knows of an '816 accelerator that does this or if one is planned. An MMU that allowed write protection of 8K banks would be a cool addition as it would also allow for proper soft OSes... there isn't much I miss about the Apple II but the language card is one thing I miss.

[danielcg]

Well, at this point we're no longer in the territory of anything Atari specced or built... but yes, I would like to ground the emulator in reality somehow. That means doing what real accelerators do or are likely to do.

 

Running the cartridge port at >1.79MHz isn't possible. However, having a BIOS copy an unbanked cartridge to a write-protected shadow in fast RAM definitely would be, as well as simply having the accelerator itself emulate the banked cartridge. As such, I would be interested if anyone knows of an '816 accelerator that does this or if one is planned. An MMU that allowed write protection of 8K banks would be a cool addition as it would also allow for proper soft OSes... there isn't much I miss about the Apple II but the language card is one thing I miss.

 

You responded very quickly! Wow!

 

In Atirra 2.40-test 15, cartridge port was accelerated at 2X or 4X speed. That greatly smooth Star Raiders' performance as well as Atari BASIC performance, especially when explosions are displayed. In Atirra 2.40-test 16, cartridge port is always running at 1.79Mhz and not accelerated. I understand that cartridge port should not be accelerated as you specified.

[morelenmir]

This was again mentioned over on the programming board - perhaps you could emulate the battery-backed RAM expansion. THAT would be AWESOME!!!

[xxl]

This was again mentioned over on the programming board - perhaps you could emulate the battery-backed RAM expansion. THAT would be AWESOME!!!

 

Yes, RAM-CART would be nice :-)

 

youtube.com/watch?v=56vfPopkcKo

[morelenmir]

Also a HEAVILY belated congratulation for a subtle but extremely pleasing feature.

 

I now notice you can attach or turn on a joypad/joystick after Altirra has been launched and it will still be recognized... This is hugely annoying in just about every other emulator I use. If you forget to plug the batteries in BEFORE you open the application you must shut it down, switch on the joystick and THEN restart before no doubt going through the tedious rigmarole of reloading the game/programme you wanted to play.

 

Not so in Altirra.

 

EXCELLENT and well done Phaeron I say!!!

[phaeron]

Yeah, Altirra handles device change notifications and rescans for joysticks when one occurs. It tries to preserve the assignments so that existing joysticks don't hop to different controller numbers.

 

Fixed a couple of crashes and a bad 65C816 mode switching performance problem, added 10MHz/14MHz modes and shadowing options, and added 65C816 support to the profiler:

 

http://www.virtualdub.org/beta/Altirra-2.40-test18.zip

http://www.virtualdub.org/beta/Altirra-2.40-test18-src.zip

 

[+bob1200xl]

Storing the OS, PBI code and 8K carts up in high memory works pretty well. You only allow writing if the access is from a long address instruction, not just from re-directed lower memory. You won't find many existing programs that make such writes.

 

So, the OS sits in $FFC000-$FFFFFF, the cart sits in $FFA000-$FFBFFF, and like that. If RAMOS is asserted, then access to what used to be the OS ROM gets switched to high memory - A16, A17, A18 all set to '1', with writing disabled.

 

Bob

 

 

 

 

Well, at this point we're no longer in the territory of anything Atari specced or built... but yes, I would like to ground the emulator in reality somehow. That means doing what real accelerators do or are likely to do.

 

Running the cartridge port at >1.79MHz isn't possible. However, having a BIOS copy an unbanked cartridge to a write-protected shadow in fast RAM definitely would be, as well as simply having the accelerator itself emulate the banked cartridge. As such, I would be interested if anyone knows of an '816 accelerator that does this or if one is planned. An MMU that allowed write protection of 8K banks would be a cool addition as it would also allow for proper soft OSes... there isn't much I miss about the Apple II but the language card is one thing I miss.