Altirra 2.70 released

[Madi]

ATBasic-20160323.pdf

 

I tried to find in the forums but search didn't bring any thing up, so this is from my PDF collection.

 

Do you mean this:

Newest version of Altirra Basic and manual?

madi

Edited July 17, 2016 by Madi

[serj]

bfollett, no error in the emulator.

 

[bfollett]

bfollett, no error in the emulator.

 

 

Interesting. I was getting the corruption consistently so after a little experimenting I see the difference between your Altirra setup and mine. You had 128k ram selected and I only had 64k set. The thread I got the program from said near the beginning of the thread that it was for 64k machines , but maybe it's requirements changed as new revisions were made. For some reason when I installed v 2.71 on top of my 2.80 v47 install it defaulted to a 320k Rambo config with out me noticing. I'm surprised the 2 versions of Altirra maintained separate configs.

 

Bob

 

Bo

[+Stephen]

bfollett, no error in the emulator.

 

 

Also worked fine for me in PAL mode.

[Mclaneinc]

As Avery said on the previous page, on an NTSC machine setup it runs out of VBLANK time hence the corruption, with longer VBLANK time on the PAL setup it works.

 

Looks like it was designed on or for PAL.

[atx4us]

I have a quick question. If Altirra is used on a tablet/computer with a touch screen feature, is there any support for the touch screen such as virtual joysticks or paddles? Thanks.

[phaeron]

No virtual controller support. On-screen keyboard does support multitouch, and paddles you can sort of do -- Altirra knows how to disable the right-click gesture emulation that causes laggy input when right-click is not bound, so if you bind paddles to the mouse it should work reasonably OK. The only touch device I have is a Dell Venue 8 Pro that I don't use often, so I've mainly only done enough work to make the emulator usable on it for demos and not really worked on making games playable.

[phaeron]

Update:

http://www.virtualdub.org/beta/Altirra-2.80-test49.zip

http://www.virtualdub.org/beta/Altirra-2.80-test49-src.zip

 

• Fixes a couple of more emulation issues with IDE+2.0. SDX cold reset issue is fixed (thanks to drac030 for the tip), and the CCTL region is now also switched when the external cart setting is toggled.
• Fixed a bitmap handling bug in the SDFS resizing code that caused filesystem corruption when expanding .ARC files on certain disks.
• Fixed a bug in the enhanced text mode code that caused excessive CPU usage.

[Roydea6]

144 Write protected or bad sector Altirra 2.80-test49 after upgrading to SDX448_ideplus.rom and installing Bios15.com.

on trying to CHTD *.* , rename, or save an ED file. Trying to copy/install the reset of the toolkit ARC files to hard drive fails.

[phaeron]

Yeah, sorry... this was due to an attempt to emulate more of the IDEPlus 2 registers, which resulted in the BIOS having problems because the emulator was now presenting an unholy mix of registers that didn't correspond to any one real revision of the hardware. This should fix it:

 

http://www.virtualdub.org/beta/Altirra-2.80-test50.zip

http://www.virtualdub.org/beta/Altirra-2.80-test50-src.zip

 

The fix kinda started snowballing:

• IDEPlus 2.0 revision is now selectable. Current versions supported are rev. C, rev. D, and rev. E. Rev. D adds write protect and IRQ switches; rev. DS/S is rev. D with Covox at $D1FB. Rev. E has slightly different registers and isn't really complete yet.
• IDEPlus 2.0 PBI ID is now selectable.
• IDEPlus 2.0 rev D/E write protect switch and IRQ button (swap partitions) are implemented under System > Console.
• While implementing the above... I discovered that Covox volume was fubared. It's now renormalized and the Covox emulator has been overhauled. Addressing is now selectable between $D1xx, $D280-D2FF, $D5xx, $D6xx, and $D7xx, and it can now also be switched between mono and 4-channel (Amiga style). The volume is also adjustable in Audio Options.
• Fixed a bug with the flashing indicator (F) not appearing consistently when writing to The!Cart cartridges, and a potential issue in memory mapping that may have caused native mapping mode to sometimes malfunction.

[Mclaneinc]

Thanks Avery, I personally don't use the IDE stuff but others do and if I venture in to it I'll know its in tip top shape thanks to you.

 

Just a little question, what sort of emulation preciseness is the Pokey at these days, I listen to some songs from time to time and hear what I think a re 'bum' notes but yet I hear pretty much everything else sounding as I remember it. I suppose that sort of answers my own question but I thought I'd ask the man himself on how he judges the level of emulation on Pokey. Obviously if the tune is created with bum notes its going to sound wrong but its stuff from people I'd say were pretty good at the music side so I wondered if other variations could cause er inflections (right term?) on sounds based on emulation?

Edited July 29, 2016 by Mclaneinc

[Bikerbob]

Ok people tell me to get the latest version.. I have 2.71 and if I go to the git hub it says 2.70.. but people tell me that is old.

 

SO ... where do I go for the latest version???

 

James

[phaeron]

Thanks Avery, I personally don't use the IDE stuff but others do and if I venture in to it I'll know its in tip top shape thanks to you.

 

Just a little question, what sort of emulation preciseness is the Pokey at these days, I listen to some songs from time to time and hear what I think a re 'bum' notes but yet I hear pretty much everything else sounding as I remember it. I suppose that sort of answers my own question but I thought I'd ask the man himself on how he judges the level of emulation on Pokey. Obviously if the tune is created with bum notes its going to sound wrong but its stuff from people I'd say were pretty good at the music side so I wondered if other variations could cause er inflections (right term?) on sounds based on emulation?

 

It should be pretty accurate for most types of music. There are a few common causes for bum notes:

1. The pitch can legitimately be off. This happens because all of the voices have to be switched between the 15KHz or 64KHz clocks, and both have limited ranges for 8-bit pitches before notes start to sound "sour." If you hear plain square-wave tones that are just slightly off in pitch and particularly on the higher end, this is the reason. Altirra should be cycle-exact for pitches of standard tones.
2. The timbre may be variable. Using distortion 10 or 12 to do low notes incurs this problem since you can get a few "flavors" of notes depending on exactly when the note is played. Also, how the player is started can also make a difference, if the program doesn't reset all the clocks when it starts. This too is cycle exact, but the timing is likely to vary because the program probably isn't loaded in the emulator exactly as it would be on real hardware.
3. Channels fighting each other. If two channels are playing at the same pitch or harmonics of each other, they can partially or completely cancel and cause notes to sound thin. A funny example I once looked at involved a music player that happened to play the exact same note on two channels at opposite phases... which caused them to completely cancel. Dead silence.

The audio monitor (System > Audio > Audio Monitor) will show what POKEY's four audio channels are doing. This is a good way to tell whether the player is just using standard square waves with envelopes or trying to do tricky things like high-pass effects and digital drums. The trickier the playback technique, the more likely the possibility of variance between machines, emulated or not.

 

Analog effects are where things tend to break down a bit. The D2D player, for instance, has an option to do 6-bit audio, and that depends heavily on the response of the analog output circuitry. The current non-linear emulation is a bit weak with regard to the frequency-dependent part of such effects, and I suspect I would have to learn a lot more about op-amp based amplifier circuits to be able to fix that.

 

 

Ok people tell me to get the latest version.. I have 2.71 and if I go to the git hub it says 2.70.. but people tell me that is old.

 

SO ... where do I go for the latest version???

 

James

 

Uh, I never put Altirra on GitHub or any other code hosting site. If you see it on there, someone else stuck it on there, and that's not the official release line. This is:

 

http://virtualdub.org/altirra.html

 

That having been said, 2.71 is the same as 2.70 except for a startup fix for Windows XP SP2 systems. No difference with any other OS. 2.71 is the current official release, 2.80 test-50 in this thread is the current beta.

[Bikerbob]

yep.. found it in this thread.. and yes I ment your virtualdub.org site.. thanks

 

2.80 is doing what I need it to do.. but does not help with me issue unfortunatly.

 

James

[Mclaneinc]

Thanks for the breakdown Avery...

[Roydea6]

 

Ready to return to DOS from Atbasicx.xex v1.51 screen

 

 

And after pressing the return key screen.

 

The ROM version 1.51 does not have this effect.

 

Using the latest SDX448 build Emulator and real hardware.

 

[phaeron]

This looks like a bug in the SpartaDOS X.COM return logic. It is attempting to relocate the display down $BC20-BFFF to $9C20-9FFF to clear the SDX cartridge, but it doesn't check whether the display is actually at that address or if it is even in mode 0, so it corrupts the display instead. 4.47 seems OK with a GR.0 screen but still blows up with GR.7 -- run attached program with X for a test case. All it does is switch the display to mode 7 and then exit.

 

gr7.zip

[drac030]

That is true that the code relocating the display is not perfect, and it has always only been aimed at GR.0, so the screen corruption in GR.7 is no surprise.

 

It is also true that the X does not check if the display is not at the correct place already before an attempt to relocation, this should be fixed there.

 

At the other hand, however, if a program (like Altirra BASIC) relocates the display from $BCxx to $9Cxx, I would expect that it relocates it back upon exit, as the DOS is not obliged to switch to GR.0.

[phaeron]

I'll have to look at relocating the display, but on principle I disagree that programs should be expected to switch the display back to Gr.0 prior to returning to DOS. The requirement to relocate the display and the associated problems in the current implementation are specific to SpartaDOS X and its X.COM because of the need to temporarily clear its library window; other DOSes don't have this requirement or problem, and for a program that doesn't need X.COM, SDX is perfectly fine running the CP in a text window. There are also a few EXE-loadable device drivers that load high instead of low, and I would expect that if they could be convinced to load below $9FFF that X.COM should not have a problem preserving a display that is already below its required threshold to re-enable the library.

 

This also wouldn't be an issue if SDX wasn't trying to directly modify the display; the OS has a supported method of doing this, which is modifying RAMTOP and reopening E:. That's what the EXE version of ATBasic does on startup if needed. It's understandable that SDX is doing this as the official method doesn't allow for preserving the display without at least a couple of memory copies, but this is a little bit sketchy.

[FifthPlayer]

When I run Altirra Basic with SDX on real hardware, it doesn't seem to trap the System Reset key. I end up in SDX instead. To get back to Altirra Basic, I have to relaunch it - which kills any Basic program previously loaded.

 

Is there a reason why Altirra Basic doesn't trap the System Reset vector?

 

I'm using a 130XE with SpartaDos X on a Maxflash cart, Altirra Basic loaded from disk (SIO2SD).

[phaeron]

There is no system reset vector. There are vectors to reinitialize a disk or cassette loaded program (DOSINI/CASINI), but these are called after the display and the rest of CIO has already been reinitialized, which overwrites where ATBasic loads. For consistency the disk-based version loads at the same place as the cartridge version ($A000); it's provided as a convenience, but loading from disk isn't the primary intended use case.

 

It's unfortunate that Atari didn't provide more vectors in low memory, particularly for warm reset and for SIO loads.

[+MrFish]

How do you get Altirra to read the key sequence <ctrl><shft><ESC>?

 

EXDDT is supposed to use this for entry after being loaded, but Windows (7) intercepts the sequence and jumps into the Task Manager.

[flashjazzcat]

I'd map it under a different key in Altirra's keyboard editor since I think the Windows shortcuts are hard coded.

[+MrFish]

That worked, thanks!

[drac030]

The requirement to relocate the display and the associated problems in the current implementation are specific to SpartaDOS X and its X.COM because of the need to temporarily clear its library window.

That is true and it is also true that all of this is handled by somewhat kludgy code inside X.COM. The matter is also a bit more complicated than it may seem at first glance.

 

But the thing I am speaking about is in fact unrelated to SpartaDOS X at all. Under SpartaDOS 3.2 there is no visible problem with Altirra BASIC, but there is a problem anyway: running it and quitting to DOS leaves the display at $9C20-$9FFF, effectively shortening the available memory (for copying buffer, for example) by 8k.

 

This is so, because, as I wrote above, eventhough some DOS-es do a GR.0 after a program quits, in fact no DOS is really obliged to do that. And indeed some do not, like SpartaDOS 3.2 or probably DOS XL.

 

This is why, in my opinion, every program which changes the parameters of the default screen should restore the initial settings before quitting to DOS.

 

EDIT: I also see that even if the CP did a GR.0, it would not change anything, because the Altirra BASIC leaves RAMTOP=$a0...

Edited August 2, 2016 by drac030