Altirra 3.20 released

[xxl]

where can I find Altirra Basic 1.56 (newest?) as a ROM file

[Roydea6]

TOOLS -->EXPORT ROM FILES

9 minutes ago, xxl said:

where can I find Altirra Basic 1.56 (newest?) as a ROM file

TOOLS-->EXPORT ROM FILES

[Mclaneinc]

Here are the 3 flavours of the OS to save doing the dump 3 times...400/800    65C816  XL

 

I can read but don't seem to be always able to do it...Wanted BASIC so I read that as OS!!!   idiot

 

 

 

atbasic.rom

Edited November 13, 2019 by Mclaneinc

[Kyle22]

Sorry to be a pain in the ass. But, can there be a PINNED reference to the latest version of Altirra that runs under Windows XP?

 

[phaeron]

11 hours ago, tane said:

I've been testing in different TVs, and there are light differences, the hue and strength depends of the brand in their defaults (Sony, LG, Samsung). And it also differs from a CRT.

Yeah, there's quite a lot of settings that can affect this, and some TVs ship with really whacked settings. Typically I start by turning off all dynamic color/contrast enhancements, set normal black level, turn off skin-tone enhancement and any "digital vibrance" settings (a.k.a. overblown saturation), and turn down edge enhancement. Then I boot the colormap utility from the Altirra Additions disk and use that to check the color palette. I can get NTSC to match pretty closely between emulator and TV or CRT at this point; PAL I have less authority on since I don't have a PAL setup to compare against.

 

There's an entire procedure now in the help file for calibrating colors, but the key is hue 1. That's the colorburst, so it depends only on the TV's color decoder and tint settings. Standard NTSC says that it is always lime green, but some displays like the C1702 show it as more reddish because the decoder has the (R-Y) axis beyond 90 degrees in U-V space. From there, the later hues get spaced according to the color pot, which is set slightly differently on every computer. So the basic procedure is to match hue 1 by tint and then hue 15 by color pot (emulated or real). Limited saturation is a problem as in some cases you cannot get correct colors at the high end if you have the grayscale band scaled all the way to white, as there isn't enough room then in the RGB gamut for the saturated colors.

 

PAL's trickier, as the way that the PAL GTIA generates colors is more hardcoded and so the color pot's effects are more constrained. Altirra currently ships with a default PAL palette that has somewhat evenly spaced steps, but I've noticed some screenshots that show the color pot tuned farther than that to make the GR.0 screen more bluish (~15d) and am considering changing the default to that. This also causes some noticeable divisions to appear between some specific hues.

 

SECAM is basically unemulated right now but is something I've been working on sporadically, with the rare couple of screenshots that are floating around. Currently in released versions the only visual change from going to SECAM is the dropping of the lowest luminance bit. I have the YDbDr constellation from the FGTIA docs plugged in but the colors don't really match, they're not nearly as saturated as they should be. There should also be vertical artifacting due to the way that SECAM color encoding works but there are no screenshots of that.

 

[gozar]

5 hours ago, Kyle22 said:

Sorry to be a pain in the ass. But, can there be a PINNED reference to the latest version of Altirra that runs under Windows XP?

 

It's already pinned, 3.20 will be the last version to support WinXP. Even though there will be newer versions of Altirra, it doesn't diminish the fact that 3.20 is awesome emulator.

[oo7]

First off thanks for this great emulator!

 

 

Second just a report not a complaint. Rampage (Activision 1987) screen is full of garbage in Altirra, tested 2.9 and 3.20.

 

 

 

WOrks flawless real hardware and Atari 800 WinPlus.

 

 

Thought I would report it.

 

 

Thanks again.

[Mclaneinc]

You have it set to NTSC but its a PAL game and timings make a difference, I also set ram to 64K, it should not matter but it keeps it close to the real hardware...

[oo7]

12 minutes ago, Mclaneinc said:

You have it set to NTSC but its a PAL game and timings make a difference, I also set ram to 64K, it should not matter but it keeps it close to the real hardware...

WOW! You are correct. set it to pal and works.

 

 

What is strange is my real hardware is NTSC.

 

 

Atari 800win also needs to be in PAL.

 

 

 

 

Thanks for telling me.

 

 

So no bug oops.

 

[Mclaneinc]

Strange it works on real NTSC hardware?

 

One for Avery to answer as to why? (if he wants to)

 

Awful conversion tho....

Edited November 18, 2019 by Mclaneinc

[oo7]

1 hour ago, Mclaneinc said:

Strange it works on real NTSC hardware?

 

One for Avery to answer as to why? (if he wants to)

 

Awful conversion tho....

yes, works flawless on my NTSC 130 xe bought in Canada. Used in canada. However I now noticed it breaks on all emulators in NTSC mode.

 

Strange I guess.

[phaeron]

From my 130XE:

 

 

It's pretty clearly overrunning the VBI in the debugger on NTSC, so the only possibility I could think of to explain the difference is a dodgy NTSC/PAL detection routine, since I assume the machine that does work has an NTSC ANTIC in it.

 

[Mclaneinc]

That is strange, Phaerons machine is NTSC and like the emulators it breaks because of the timing VBI issue but it works on your machine so unless your machine has been PAL modded then it should be doing the same as the emulators and Avery's machine.

 

My real machines are PAL so the only way I can test NTSC is via Altirra which is extremely accurate..

[oo7]

ok this is weird. on my 130XE and XEGS in canada NTSC warranty stickers still intact its working.

 

Maybe its a patched version.

 

 

The version I ran on Altirra I obtained online the version IM running on my real hardware I got back in my bbs days and am running off a 1050 drive.

 

 

I will find a way to rip the floppy and see that versions behavior. Maybe it was patched for the BBS I downloaded it from. I believe I had downloaded it from the Echo or the Jail BBS in toronto.

 

 

Going to have to somehow inteface my old atari hardware to access that copy.

 

 

To be honest I only have hardware for old times sake and use Altirra for a long time now when I want atari 8 bit.

 

 

 

 

Edited November 19, 2019 by oo7

[Mclaneinc]

Tis a bit odd, I would not let it worry you, just get on with having fun with both the hardware and the emulator.

 

Any questions then fire them off here and the rather badly named newbies sticky thread is an excellent place to look for answers, I'd love it  they renamed it to 'Returners thread' or the like..

 

There's always someone on here who can answer a question and we love doing it..

 

Have loads of fun

 

Paul..

[Faicuai]

18 hours ago, oo7 said:

yes, works flawless on my NTSC 130 xe bought in Canada. Used in canada. However I now noticed it breaks on all emulators in NTSC mode.

 

Strange I guess.

FYI, this title WILL NOT boot (in any form or shape) on a 800/Incognito (NTSC), in any HW/RAM configuration, with the exception of [XL/XE-mode + Qmeg4.04], in which case joystick-ports do not seem active, unless I missed something else (that is, it does not work fully, either). Most likely, it will not work on my 800XLs (Ultimate1MB), either. I would have to check for full certainty.

 

So it seems to be a really interesting case, especially if you manage to boot it on your 130XE...

 

Did you post your file / .ATR, already? (sorry if I missed it...)

[Faicuai]

On 11/14/2019 at 12:24 AM, phaeron said:

(...)

 

There's an entire procedure now in the help file for calibrating colors, but the key is hue 1. That's the colorburst, so it depends only on the TV's color decoder and tint settings. Standard NTSC says that it is always lime green, but some displays like the C1702 show it as more reddish because the decoder has the (R-Y) axis beyond 90 degrees in U-V space. From there, the later hues get spaced according to the color pot, which is set slightly differently on every computer. So the basic procedure is to match hue 1 by tint and then hue 15 by color pot (emulated or real). (...)

 

 

VERY interesting...

 

All I can say is that, after analyzing hundreds of print-outs, actual live-screens, and titles (where intended color reproduction is a rather fixed, timeless and/or universal "known"), is that this long-and-curvy road invariably ends up in a 2-way split (one or the other, have not been able to get both):

 

1. Calibrate and tune for most-approximate "colorimetric" reproduction of modern NTSC color-decode, or...
2. Calibrate and tune for most-approximate "perceptual" reproduction of past / original NTSC color-retendering's (which will NOT be error-free, unfortunately, but can be error-minimized).

 

After testing and re-testing, I came to the conclusion that road #2 above minimized most "perceptual" errors (past and present):

1. Hue 1 must be GOLD, when looking at luma 11-15 values (lots of titles sourcing brown / skin-tones from this hue)
2. Hue A must be grayish-BLUE, when looking at luma 0-2 values. (ONLY wat to get Star Raiders shields, for which we known its production color). But this hue will progress quickly out of greyish-blue into Turquoise, when approaching luma 11-15 values.
3. Hue F must be as yellow as possible when looking at 11-15 values, and a reasonably behind Hue-1, which is ONLY way to get 256 distinguishable luma/hues out of the machine. However, there will be a perceptual "penalty" error on lumas 0-A of this band, which will come out as "moss / greenish" instead of soil / brownish / maroon  that some titles expect from this band (even some modern production, today). 
4. I would only add that all colors on highest luma-value (F) should NOT be pale / grayish. Their tint should be all visible and distinguishable from each other,  when scanned vertically, which will help yield in a more "compressed" and creamy gamma (e.g. midtones will appear rich, in all hue-bands, but not electrical, fake-looking).

And yes, you are 1000% correct regarding adjustment-actuation (e.g. #1 requires Phase / Hue on Monitor / CRT or video-processor) and #2 and #3 require machine's color-pot, but it will require to be warmed-up to at least three (3) hours, because there is quite a bit of drift, especially visible on hue A). This is truly annoying, I would have to say...

[flashjazzcat]

Was it ever possible to drag and drop files into folders in SDX volumes using the Disk Explorer, or did I completely imagine this? I don't mean dragging files from the host OS into the explorer window: I just mean dragging a file or group of files which already exist in a folder into one of its child folders. I found that a really handy way of restructuring disks... either in a prior version of Altirra, or in a parallel universe in which this was once possible.

 

[phaeron]

6 hours ago, flashjazzcat said:

Was it ever possible to drag and drop files into folders in SDX volumes using the Disk Explorer, or did I completely imagine this? I don't mean dragging files from the host OS into the explorer window: I just mean dragging a file or group of files which already exist in a folder into one of its child folders. I found that a really handy way of restructuring disks... either in a prior version of Altirra, or in a parallel universe in which this was once possible.

Nope, the whole window has always targeted the current directory, it doesn't look at the item at the drag point. I'm not terribly fond of that behavior anyway because it can be annoying to find a place in the window where you can drop files without them going into a subdirectory. Cut-and-paste might be an alternate solution for this case, as I could put the diskfs path into the clipboard to do the move in the emulator, and that would also help for moving files and folders upward as well as downward.

 

[oo7]

On 11/10/2019 at 4:16 PM, CrazyChris said:

I am noticing a strange lag in Altirra 3.20, when pushing the fire button,

to start this game. It does not matter if I am using a joystick or the keyboard.

 

In Altirra 3.10 pressing the fire button to start the game does not work at all.

 

In version 3.00 it seems fine.

 

I am running Windows 7 64-bit.

 

Can anyone else confirm this?

 

rescueEx.xex 33.37 kB · 11 downloads

Just tested this. Am running Beta 3.90 Test 18. No delay starting game with fire button, no problem using fire button.

 

 

[flashjazzcat]

9 hours ago, phaeron said:

Nope, the whole window has always targeted the current directory, it doesn't look at the item at the drag point.

Thanks for clearing that up. This is obviously an example of the Mandela Effect.

 

Edited November 20, 2019 by flashjazzcat
spelling

[Mclaneinc]

What, this?

 

 

[oo7]

On 6/24/2019 at 9:38 PM, Stephen said:

Not trying to be an asshole, but come on man - it's 2019, not 1995.  Things change.  These old OSes are utter SHIT at protection, etc.  There's plenty of ways to keep the spyware from 3rd parties and OS people turned off.

it is 2019, but a comment like this when someone is emulating an is from 1979 is kind of an oxymoron.

[+DrVenkman]

18 minutes ago, oo7 said:

it is 2019, but a comment like this when someone is emulating an is from 1979 is kind of an oxymoron.

He wasn't referring to the Atari OS, but rather the OS the emulator itself is running upon (specifically, WinXP in that specific discussion).

[oo7]

5 hours ago, DrVenkman said:

He wasn't referring to the Atari OS, but rather the OS the emulator itself is running upon (specifically, WinXP in that specific discussion).

right, but telling someone that it's not 1995 it's 2019 when the goal is to run 1979 is very how do I say it? foolish. maybe trolling.