Altirra 2.50 Final out

[Mclaneinc]

Not sure if its a bug or not, was just trying my ATR's of the Shadow of the beast demo and Altirra reports them as unsupported or corrupted but i was sure I'd ran them before and booted Atari800win 4.1 and they booted ok either in to the demo or you get a message "Rom Disabled" and you can then load via DOS.

[Mclaneinc]

Also, is it normal that when the input is set to gamepad that the arrow keys on the keyboard pause emulation until they are hit again?

[phaeron]

Alright, another update:

http://www.virtualdub.org/beta/Altirra-2.60-test28.zip

http://www.virtualdub.org/beta/Altirra-2.60-test28-src.zip

 

Main change are gamma correction support, brighter gaps between scanlines, and a retuned NTSC filter. The high NTSC filter should look sharper now and the artifacts should be more like what you'd see on a real TV set. I replaced the low-pass linear phase filters with IIR low-pass and notch filters that only ring forwards in time and are tuned sharper. Did I ever mention how much I hate pole-zero graphs and recursive filters? Also, in the Adjust Colors dialog, the artifact hue setting has also been flipped so that it now matches the hue start setting instead of being backwards, and it shows the standard text colors so you know immediately if you've turned the GR.0 screen purple. The default NTSC color settings have been redone and there are now separate XL and XE settings for the artifacting phase difference.

 

Copy Frame issues were due to a bug in some aspect ratio correction code I had put in. It worked for frames being rendered in 32-bit mode (VBXE, blend frames, artifacting, and scanlines), but not in 8-bit mode (interlace). Fixed, and extended to the Save Frame command.

 

The issue with the Shadow of the Beast file is that it's named ATR, but it's actually an XFD with no header. People love to choose random filename extensions. Modified the ATR code so it can redirect to XFD if it discovers this.

 

Haven't seen an issue with arrrow/gamepad keys myself. Some games will auto-pause whenever any key is pressed, though.

[serj]

Avery, the default palette - became very bright.

default palette should be darker.

 

[+Roydea6]

_{Flashing does not seem to be working for the Ultimate Rom as of the last couple of updates.. With UFLASH.COM by fjc.}

 

_{and I tried all three flash type options.}

[Wally1]

i'd like to report

 

when input is set to gamepad

 

the joystick/gamepad drags up when pulled to the left

 

sometimes not left direction at all, it seems to stick

 

I tested this quite a few times.

no biggie I hope

[phaeron]

Just tried uFlash 1.2 test 1 with U1MB/A29040, and didn't seem to have an issue reflashing BASIC...?

 

I'm not sure what you mean by the joystick/gamepad dragging.

[Wally1]

well I tried 2.40 and 2.50 with two different gamepads

 

same thing

 

sorry

[Keatah]

Thanks for the tuning of the NTSC filtering and lightening of the scanlines. I hope to try this out on my emulator rig and not a random laptop in good time.

[fujidude]

Anyone having trouble using Altirra's emulated printer? If I try to redirrect SDX output (like a DIR command for instance) to PRN: or P:, I just error 138 device does not respond, or 130 device non existant. However, if run a custom BASIC program that I made ages ago to print a cassette label on a 1020 plotter, that output more or less comes out okay in the printer output window.

[phaeron]

SpartaDOS X appears to be doing something a bit unusual here -- its PRN: device calls directly into the P: handler entry points, bypassing CIO and HATABS. Currently, Altirra only emulates the printer via CIO hooking, so it doesn't see the requests that are bypassed this way.

[Mclaneinc]

Just tried a game called Atomix and it crashes (gamewise) when you press start to play a game, now I set all the usual bits (r/w etcetc) and it still didin't work so I tested it on Atari800win and it plays perfectly so I went back to Altirra (current beta) and started messing about and pressed different F Keys to see if it made a difference, after pressing OPTION a couple of times and then start the game actually ran twice but it was random and when the game ended and you tried to play again it crashed after reading some sectors.

 

Not the end of the world but is it Altirra or bad programming?

Atomix.atr

Edited December 21, 2014 by Mclaneinc

[flashjazzcat]

Does it work on real hardware???

[w1k]

now testing......

on real HW working

[fujidude]

SpartaDOS X appears to be doing something a bit unusual here -- its PRN: device calls directly into the P: handler entry points, bypassing CIO and HATABS. Currently, Altirra only emulates the printer via CIO hooking, so it doesn't see the requests that are bypassed this way.

 

The Altirra emulated printer exists only through CIO then... that explains it perfectly. Thanks.

[Mclaneinc]

Due to space and hospital issues my real hardware is under a mountain of stuff...

 

Trust me, i would have tried it If I could..

[phaeron]

Reproduced on real hardware -- it is an intermittent bug in the game. The problem is that it attempts to shut off the display list via SDLCTL and DMACTL without turning off DLIs, and then overwrites the DLI handler. When the Start button is pressed on a mode line with the DLI flag set, the game crashes on the overwritten DLI handler.

[Keatah]

I had it working on my 2.50 install. I got it working 2 times out of 10 tries.

[wesmond]

Hi all,

 

This really isn't a feature request - just a curiosity really. I noticed Phaeron did some cassette-related updates for 2.50, so wondered if it was at all interesting! (Mclaneinc commented on the other thread about this - "Another emulated project for Avery perhaps? (I am joking)" - which I think is a very reasonable comment!!)

 

Turbo-tape - I put a Rambit kit into my 1010 years ago. (There were other similar kits I think). I expect there's hardly any Atari software that exists in a turbo-tape format, but not in another standard format. There's one exception I can think of, which is the actual software by Rambit that does the conversion - it's three blocks of normal speed, followed by some high speed stuff. (Two versions were supplied, maybe with different memory usage, on a tape that used to be States and Capitals...) Due to a question in another thread, I recently dug up the tape, and made a WAV of it, which I believe loads and runs ok on real (modified) hardware.

 

I don't believe it can be loaded into any emulator at present? And to emphasise again, what would you do with it if you could emulate it? But if there is any fun/interest in working out how the thing worked... (and I am slightly interested in that), then the link to 100Mb of zipped WAVs is below...

 

http://teapotrecords.co.uk/tmp/rambit.zip

 

Wes

[Mclaneinc]

Wesmond, the reason I did the smiley is that Phaeron has always voiced a negative opinion on Tape stuff hence the basic support for it, I personally would love to see all the strange little upgrades emulated but I'm not the person writing the emulator so I count for nil. I have to say there's part of me that agrees with Avery's viewpoint regarding the whole tape side, its an old antiquated system of loading that was left for dead when disk drives arrived so what's the point of doing massive emulator rewrites to try and accommodate it.

 

BUT, whatever gets added is down to the man himself...

[wesmond]

Yep, I knew that Paul - I smiled at your comment, and knew exactly why it was a joke! :-) I guess if "anyone" wanted to explore how turbo tape worked, the WAVs might be a good start point - and I've not seen them uploaded anywhere else, so this seemed as relevant a place to mention it as anywhere.

[Mclaneinc]

You will start Serj going on about the Polish tapes now

 

With Altirra you never know what will be added, its likea little Xmas present every release..

[matosimi]

Hi phaeron, I have one issue and I'm not quite sure if we discussed it like 2 years ago... but I think we have and I also believe it was fixed, yet I bumped to this bug again in altirra 2.50...

It is related to altirra state files. In case of Ridiculous Reality, there are like 120 data blocks in XEX file of game. Everytime player wins a level, 5-8 new blocks are loaded. When I create altirra state file and I load it, this further datablock reading is not possible and system crashes.

 

Haven't you fixed this issue of Altirra already when RR was out? Or I just made that up? ... I tried to find some discussion about it here at AA, but had no luck, so i don't know if I was daydreaming or something...

 

anyway, it would be nice to be able to load data blocks of opened executable further after statefile gets loaded. -this might be possible if statefile would contain whole xex binary, not only memory dump...

 

I also created one example... its level 1 of RR, just load statefile and go through the door: rr_level1.zip

 

regards,

Martin

[phaeron]

Nah, never addressed this particular issue -- not all state is in state files, including executable state.

[matosimi]

Nah, never addressed this particular issue -- not all state is in state files, including executable state.

Ok, maybe I was discussing this with someone else, not with the only guy who can make the change... How foolish 😆

As I feel from your reply, you don't seem to be concerned about this, so you don't plan such change, right?