Altirra 2.60 released

[danielcg]

I have Altirra x64 2.70-test 39. Rescue on Fractalus game do not work anymore as it loaded and run properly but did not respond to keyboard inputs. This game only respond to gamepad or joystick. Keyboard input is REQUIRED for game to work as it use keyboard input for spacecraft commands. Issues exist even with Atari 800 mode (OS 800-B) or Atari 65/130XE mode (OS XL/XE 2.0).

 

ALL other games worked PERFECTLY, even in accelerated 65016 modes.

[morelenmir]

 

What, you want this thread to be longer than it already is?

 

The dumps you see above are literally just copy-and-pasted out of the debugger, so I don't have more details. Also, not sure how others feel, but IMO having such explanations here would probably muddy up the thread more than it already is.. given how much that Altirra attempts to emulate, and therefore attracts discussion on. We do seem to have a lack "learn 6502 assembly" threads in the programming forum, though. I'd be happy to explain the above fragments in such a place, but I'd need to dissect them myself first.

Yep, if that is muddying the thread then I do

 

Seriously though, as I say I do not expect copious documentation. However just a couple of words next to a critical or slightly oblique assembler command; 'Load Accumulator with label ICAX1Z contents.' would really help. I don't think that would take up very much extra space alongside the code itself.

 

The danger is that a chunk of ASM flies completely over the head of a reader and then he misses out on the chance to contribute or learn from the discussion. In my experience there is so much perceived mystery and even elitism around - in particular - assembly language. It has always been that way right back to the 'Page6' days and other magazines I am sure. Anything we can do to lift that misconception is really valuable.

[flashjazzcat]

This was basically two advanced coders exchanging bits of disassembly to identify an issue. I wouldn't expect them to comment disassembly on the off chance a third party wants to study it. If a point of interest is questioned after the event, then someone might have time to explain it retrospectively. There's a lot of well commented source code on this forum which is ripe for study. An OS source listing might be a good starting point, and we could (in a different topic) gloss those parts up for discussion.

[serj]

Avery, in many games soured fonts.
Pay attention to the numbers.

 

see video:

[StefanD]

I testet the Error 15 problem with Altirra-BASIC 1.47: It's still there - and I found a way to reproduce it:

 

Enter line 1 in the following screenshot, RUN it and press BREAK immediately. Delete line 1. Now LIST produces Error 15 four times - see screenshot.

 

By the way: Is there a way to pause emulation, when a menu is opend (like in Altirra 2.60)?

[morelenmir]

This was basically two advanced coders exchanging bits of disassembly to identify an issue. I wouldn't expect them to comment disassembly on the off chance a third party wants to study it. If a point of interest is questioned after the event, then someone might have time to explain it retrospectively. There's a lot of well commented source code on this forum which is ripe for study. An OS source listing might be a good starting point, and we could (in a different topic) gloss those parts up for discussion.

Okay FJC. Clearly we disagree - no worries! Through the free exchange of ideas and knowledge we will all be advanced coders one day!!!

[Mclaneinc]

Good find Sergey...I can't reproduce it though...

 

I did notice one little oddity which MAY be on the original (sadly I can't find my Star Raiders cart, found the manual but no cart (sob)

 

As you start the game and you are 'launching' there's 3 or 4 dots on the right hand top edge of the crafts 'window', they are there until you get to the planet and then they go. They seem to be taking their colour from what is going on in the main window.

 

Normal or bug?

Edited November 30, 2015 by Mclaneinc

[serj]

I'm sorry, my mistake.

Version 2.7 test 39 has changed in the settings of the operating system on the Arabic version of the emulator.

answer №854 can be ignored.

[phaeron]

Update:
http://www.virtualdub.org/beta/Altirra-2.70-test40.zip

http://www.virtualdub.org/beta/Altirra-2.70-test40-src.zip

 

Another attempted fix for runtime stack issue in ATBasic, and fix for one color clock glitch with mid-screen GTIA mode 10 switch that affected Fractalus.

I have Altirra x64 2.70-test 39. Rescue on Fractalus game do not work anymore as it loaded and run properly but did not respond to keyboard inputs. This game only respond to gamepad or joystick. Keyboard input is REQUIRED for game to work as it use keyboard input for spacecraft commands. Issues exist even with Atari 800 mode (OS 800-B) or Atari 65/130XE mode (OS XL/XE 2.0).

ALL other games worked PERFECTLY, even in accelerated 65016 modes.

I can't reproduce this. With both OS-B and XL/XE hardware was able to land with the L key, with both the VAPI and ATR versions that I have. Try creating another copy of the emulator and running it with /portable to start with a fresh, localized configuration -- this will help rule out configuration issues, like the Arabic ROM issue serj ran into.

BTW folks, when reporting regressions... please indicate what version previously worked. I need to know whether "anymore" means relative to an earlier test release, 2.60, etc. There's months in between. Don't expect you go to searching for the exact bracket, but it helps track down issues on my side if you already know the bracket.

And, uh, what's with the weird highlighting...?

However just a couple of words next to a critical or slightly oblique assembler command; 'Load Accumulator with label ICAX1Z contents.' would really help.

That's literally what LDA ICAX1Z means. Sorry, but I can't document ASM at that level in the middle of a discussion about a complex interrupt timing problem.

I testet the Error 15 problem with Altirra-BASIC 1.47: It's still there - and I found a way to reproduce it:

Enter line 1 in the following screenshot, RUN it and press BREAK immediately. Delete line 1. Now LIST produces Error 15 four times - see screenshot.

By the way: Is there a way to pause emulation, when a menu is opend (like in Altirra 2.60)?

Rats, missed another place that the runtime stack was being pinned. On the bright side, removing it freed up seven bytes. 1.48 attached with another tack -- give it a shot. If this doesn't work, I'll probably revert back to 1.46 to ship 2.70 and try again after that release.

As you start the game and you are 'launching' there's 3 or 4 dots on the right hand top edge of the crafts 'window', they are there until you get to the planet and then they go. They seem to be taking their colour from what is going on in the main window.

Normal or bug?

Bug in the emulator, good catch. Specifically, Fractalus is doing a hot switch from lores to GTIA mode 10. There is a small glitch in this type of transition that the emulator simulates, but it was missing one cycle of data. Should be fixed now.

atbasic.bin

atbasicx.xex

[danielcg]

I changed some settings and Fractalus worked perfectly! However, Fractalus CANNOT work on accelerated 65016 modes as it was not respond to my keyboard inputs. It MUST run on slowest 6502 mode. Yes, Fractalus drawing is much smoother with accelerated 65016 modes but did not respond to keyboard input!

[Keatah]

I don't like the "keep the emulation running while menus are displayed" hack that was introduced in test 34.

 

Kinda conflicts with the System -> Pause When Inactive option. Feels kinda weird and unpolished somehow. And it's inconsistent anyway. The emulation stops if you open a dialog box.

 

Maybe this warrants an option to turn that hack on or off? And if so, it should be consistent with all levels of all menus.

[flashjazzcat]

I hadn't noticed that the menus don't pause emulation, but now I have noticed it, I like it. "Pause when inactive" refers to when the application loses focus, not when the display window loses focus, so I don't really see any conflicts there.

[Keatah]

Is this a minor user interface bug?

 

When holding down the "F1" speedup key, and then clicking on a main menu category like File, or View or System, then releasing the mouse, the "F1" key stays stuck in warp speed. Going to System -> Warp Speed and checking or unchecking does nothing. Nor does it indicate warp speed is active and locked in the on position. Pressing "F1" releases it (provided the warp speed is unchecked), and it works normally again.

[StefanD]

Thanks Avery, the Error 15 has now gone. No problem found with Alt-BASIC 1.48 when running several BASIC pgms.

 

I don't like the "keep the emulation running while menus are displayed" hack that was introduced in test 34.

 

Kinda conflicts with the System -> Pause When Inactive option. Feels kinda weird and unpolished somehow. And it's inconsistent anyway. The emulation stops if you open a dialog box.

 

Maybe this warrants an option to turn that hack on or off? And if so, it should be consistent with all levels of all menus.

I second that! There should be a menu option to pause the emulation, when menus are displayed (or simply revert this to Altirra 2.60) - since the menus overlay part of the screen - and the emulation stops anyway when a dialog window opens. The new behaviour irritates me.

[morelenmir]

Thanks Avery, the Error 15 has now gone. No problem found with Alt-BASIC 1.48 when running several BASIC pgms.

 

I second that! There should be a menu option to pause the emulation, when menus are displayed (or simply revert this to Altirra 2.60) - since the menus overlay part of the screen - and the emulation stops anyway when a dialog window opens. The new behaviour irritates me.

 

Yep; opening a menu should pause emulation. It should at least be an option that it does - that way everyone wins.

 

In regards comments on ASM; I am sorry we disagree Avery but at least we have discussed it amicably, which is worth a great deal... Obviously I cannot demand you or anyone does so, nor would I wish to. All I can say is my own code snippets - should I ever produce any!!! - will always be commented. I am sure the entire coding scene is breathing a sigh of relief at that news !!!

 

Finally it is cool to have a new version of Altirra Basic to put on the U1MB!

[fujidude]

 

Yep; opening a menu should pause emulation. It should at least be an option that it does - that way everyone wins.

 

In regards comments on ASM; I am sorry we disagree Avery but at least we have discussed it amicably, which is worth a great deal... Obviously I cannot demand you or anyone does so, nor would I wish to. All I can say is my own code snippets - should I ever produce any!!! - will always be commented. I am sure the entire coding scene is breathing a sigh of relief at that news !!!

 

Finally it is cool to have a new version of Altirra Basic to put on the U1MB!

 

Hey morelenmir, I understand your wish for informative comments in code. I applaud your motivation to learn and agree that such commenting is valuable to those who are less advanced to achieve that learning. But I also understand where Avery is coming from too. Let me attempt to persuade you a little, if you will permit, by asking you to ponder a question. Would it be better to have all postings of code be commented to the level you describe, but to then have some things never posted, or would it be better if some code was commented and some not, but more gets posted? In other words, what if someone just would rather not even put things out there rather than have to deal with the job of commenting for tutorial value? That's a situation that is worse is it not?

 

If Bill Wilkinson were alive today, and he was posting to help us learn, have no doubt there would have been excellent explanations of what code he put forth. But then, Bill wrote tutorial columns and he was very good at it. Avery, like lots of others, want to put their time and effort into functionality of the software, and not spare so much of it for teaching. While it would be great if we could have it all, sometimes we just have to be grateful for what we do get.

 

I see someone has just recently started a new topic about disassembly (or similar) for the purpose of examining assembly code to learn from it. Why don't you post up some stuff that you are working on and ask questions there? Then you can not only get code comments, but ones that are specific to areas of inquiry that you may have. Hopefully others participate too and you can sponge up some of what you see going on with that too.

[serj]

no need to make a stoped emulation during the opening of the options, so much better.

I also wonder why the emulation stops when I open the menu "Tape control".

[fujidude]

I have found an issue I want to put forth for consideration. I was just recently running BallBlazer and noticed some strange video malformation take place. This happened on test 39 and still does on test 40. I'm sorry I don't know how far the issue might go back, but I only just had an opportunity to notice it. The program starts fine, but before long (usually within 30 seconds) the video gets off. The checkerboard pattern gets very jagged looking and the scoreboard circles get a blocky scanlines look. Hard to describe. I am uploading all the pertinent files. BallBlazer is one of the programs on the GAMES044.ZIp disk image (included in the zip with everything else).

 

What I noticed though, was that if I swapped the CPU for a 65816 running at least close to 4MHz, the problem does not happen. It does happen with the standard 6502 or even a 65816 if running at 1.79MHz.

bb_issue.zip

Edited December 1, 2015 by fujidude

[Keatah]

Seems to be working fine. Maybe more information about what roms and hardware and settings are used would be helpful.

[flashjazzcat]

All the ROMs are in the archive which contains (as far as I can tell) a portable, ready-to-run version of Fujidude's exact setup.

[Keatah]

 

Just play the game, I got it to happen almost right away at 2:41.0

Edited December 2, 2015 by Keatah

[fujidude]

bb1messed.pngbb2messed.png

 

Just play the game, I got it to happen almost right away at 2:41.0

 

Yeah, I just set bot against bot and before long it gets ugly.

[Keatah]

Is there really a problem with the emulator¹? Maybe not. Because I have several other images/dumps² of BallBlaster and BallBlazer that seem to work 100% ok. You can play a 9-minute game to completion without any corruption. Not only that, but Atari 800 Emulator Version 3.1.0 fails or works in the exact same way, on the exact same images.

 

So I invite you to take some time and test the following images and see if you can make any of the ones I categorized as "working" fail. Or try to find Altirra settings that make the ones I marked as "fail" work. I regressed it v2.30 and behavior is still the same, the same images work or fail..

 

1- Maybe this has something to do with copy-protection, or how the images were dumped? Dunno.

2- I believe "Ballblazer (v1).atr" is the latest and greatest version.

_BallBlaster_BallBlazer.zip

Edited December 2, 2015 by Keatah

[fujidude]

I didn't have any real hardware to try it on, but I will try this version of bb with the Altirra setup I was using and report back.

[phaeron]

Tracked down the issue with Ballblazer -- it is a bug in the Homesoft version of the game. Ballblazer runs four display list interrupts in a cycle, where each DLI handler is responsible for hooking the next one up. There's nothing that resets this, so if any DLIs are missed, it throws the loop off and the DLIs all execute in the wrong places on screen. It turns out that this version of the game temporarily disables DLIs with NMIEN when switching screens, and this causes a chance for the screen to glitch out when the screens are switched (scoring). The other versions of the game that I have don't do this. The glitchy field is because the field rendering relies on HSCROL being stepped in sync with the per-line LMS offsets in the display list, and the desynced DLIs cause the LMS offsets from one player's field to be combined with the HSCROL offsets of the other. When it occurs, you can fix it by restoring the correct DLI handler at the beginning of vertical blank ($599B):

gv
e vdslst 9b 59
g

Obviously, it's preferred to run a fixed version of the game instead....

 

Tracked down the Rescue at Fractalus issue with 65C816 -- it's probably a bug in the emulators 65C816 core, namely that IRQs can't occur after a CLI/SEI pair. Yes, on the 6502 you can actually land in the IRQ handler with the I flag set on the stack. I'll have to do some research on this one though because I don't know whether this behavior actually occurs with a 65C816. The only way I currently have to test 65C816 behavior is the Veronica cartridge, and Veronica doesn't have interrupts. So if anyone of you out there have a 65816-equipped Atari or an Apple IIgs lying around and can test whether the IRQ occurs between CLI/SEI or after SEI, I'd appreciate it.

 

Menus weren't intended to pause the simulation, but that just happened to be a side effect of the way that menus are implemented in Windows using a modal loop. For that reason, the simulation isn't cleanly paused and one of the effects is that sound buffering temporarily gets out of whack. Dialogs are also modal but do disable the main window temporarily, so they're cleaner in that respect. Modeless dialogs, ones that don't disable the parent window, are harder to write and also have reentrancy issues since things can happen in the background while the dialog's up, i.e. a disk gets unmounted while the disk dialog is up. For this reason, only a few special dialogs in Altirra are modeless. I'll think about making the menu behavior an option.