Altirra 3.20 released

[+Philsan]

12 minutes ago, flashjazzcat said:

I guess the reason VRWSafe is the default is explained by the excerpt from the manual.

Yes, but I don't think that the average user loads protected disks that format themselves.

 

On the other hand, the average user doesn't format disks too...

 

Therefore, I don't know which option should be the default option.

[flashjazzcat]

Only Avery knows, but I suppose one cannot please everyone no matter which setting is the default. Is it better to accidentally destroy the contents of an ATR, or have to change a setting with a mouse click?

[+MrFish]

1 hour ago, Philsan said:

Therefore, I don't know which option should be the default option.

 

1 hour ago, flashjazzcat said:

Only Avery knows, but I suppose one cannot please everyone no matter which setting is the default. Is it better to accidentally destroy the contents of an ATR, or have to change a setting with a mouse click?

 

Maybe the solution would be for Altirra to allow the user to decide what default "disk mode" is used for newly inserted disks.

 

[flashjazzcat]

7 minutes ago, MrFish said:

 

Maybe the solution would be for Altirra to allow the user to decide what default "disk mode" is used for newly inserted disks.

An excellent solution. If only such a setting already existed in the tools menu.

Edited May 6, 2020 by flashjazzcat

[+MrFish]

8 minutes ago, flashjazzcat said:

An excellent solution. If only such a setting already existed in the tools menu.

Haha... in that case, I'm not sure why Philsan is even taking issue (shakes head). I thought there was no such option. Phaeron's already done his part...

 

 

Edited May 6, 2020 by MrFish

[tjcbs]

On 5/3/2020 at 7:24 PM, phaeron said:

The custom shader compiler uses vs2.0/ps2.0 by default for best compatibility when using precompiled shaders. Use this line to force SM3:

shader_profile_d3d9 = 3_0

 

Works, thanks!

 

Another question: Shader scaling works differently than Retroarch. Retroarch, by default, does this: 

 

Source -> Shade and Scale -> Display

 

This is what I want, but I can't figure out how to do it in Altirra. 

 

In Altirra, by default it does: 

 

Source -> Shade -> Scale -> Display

 

Playing with the .cgp scale_ options, I can get: 

 

Source -> Scale -> Shade -> Display

 

But neither of these works for me. How do I shade and scale in the same operation?

[phaeron]

2 hours ago, tjcbs said:

Works, thanks!

 

Another question: Shader scaling works differently than Retroarch. Retroarch, by default, does this: 

 

Source -> Shade and Scale -> Display

 

This is what I want, but I can't figure out how to do it in Altirra. 

 

In Altirra, by default it does: 

 

Source -> Shade -> Scale -> Display

 

Playing with the .cgp scale_ options, I can get: 

 

Source -> Scale -> Shade -> Display

 

But neither of these works for me. How do I shade and scale in the same operation?

 

This is determined by whether scaling types are set on the last pass. If the last pass has no scaling modes set, the custom pipeline is run as a pre-process at source size before the default scaler. This allows the built-in scaling options to work for shaders that only want to do image processing and not scaling. If the last pass does have scaling modes set, the custom shader is assumed to also be the scaler and the default scaler is bypassed, writing the shader output directly to the backbuffer 1:1 at the output size determined by the scaling parameters. In the latter case, the scaling properties should almost always be viewport 1.0x. The viewport size, however, is determined by the window framing options and will almost always be smaller than the display due to aspect ratio locking unless the UI scaling mode is set to Fit to Window.

 

Altirra never runs the scaler before the custom shading pipeline. The only processing that runs before the custom shaders is input decoding, particularly converting 8-bit indexed color to RGB. Setting a pass to any scaling mode other than source will cause it to run the pixel/fragment shader at a different rate than the source, which will implicitly scale through texture sampling. There are some video modes that will cause the CPU-side pipeline to generate different-sized sources, however -- high artifacting, for instance, doubles the horizontal pixel rate and thus the horizontal width of the source.

 

[+Philsan]

 

 

Maybe the solution would be for Altirra to allow the user to decide what default "disk mode" is used for newly inserted disks.

 

 

An excellent solution. If only such a setting already existed in the tools menu. [emoji3]

 

Haha... in that case, I'm not sure why Philsan is even taking issue (shakes head). I thought there was no such option. Phaeron's already done his part...

 

 

 

 

Obviously I know you can choose default write mode in Tools/options/media.

I changed that option to fix my format issue...

 

I meant Altirra's initial default setting.

I already asked Avery to change some default settings and he changed them, whenever he found it was a good idea.

 

 

 

[phaeron]

51 minutes ago, Philsan said:

Obviously I know you can choose default write mode in Tools/options/media.

I changed that option to fix my format issue...

 

I meant Altirra's initial default setting.

I already asked Avery to change some default settings and he changed them, whenever he found it was a good idea.

No, the default setting intentionally blocks formatting because some programs attempt to format the disk as part of copy protection and this is not very obvious when done on the sly on boot with immediate format operations. I consider this more important than default convenience when reformatting an existing disk, where you at least get a visible write protect error on a manually requested format operation. This default only applies to manually mounted disks; newly created disks are mounted VRW instead of VRWSafe.

 

[+Philsan]

No, the default setting intentionally blocks formatting because some programs attempt to format the disk as part of copy protection and this is not very obvious when done on the sly on boot with immediate format operations. I consider this more important than default convenience when reformatting an existing disk, where you at least get a visible write protect error on a manually requested format operation. This default only applies to manually mounted disks; newly created disks are mounted VRW instead of VRWSafe.
 

If someone formats a disk, he only gets an error.
If someone runs a protected disk, it may be deleted.

Therefore the default setting is the safer setting.
Thanks!

[Marius]

@Philsan

 

In my humble opinion it stays important that people who use an emulator are aware it is not a real atari. As you say yourself casual users might not use those disks that format themself or format disks at all, but that is exactly the reason why it is better to keep a default setting the safest. Many people might not have an idea what they are doing or what is going on.

 

Personally I am a huge Read Only fan. One of the most important and most used features on my blackbox back in the day (I really miss using it) was the centrally mounted large write protect switch. It was on read only by default. Ever! Only in the rare situation I had to write some data to my hard disk I put it in R/W setting. This story does only "proof" that there are more kind of users and the fact that there are also read only lovers here.

 

I know though those situations where you run into an issue with a program and you would like to change it that it works the best like you think it should work. Sometimes it is easier to accept the way things work... that helps too

 

[+Philsan]

I am a fan of VRW too.

I was talking about VRWSafe.

 

If you read my previous post, you'll see I already agreed with Avery's decision.

 

Previously I agreed with him when he accepted another proposal of mine and I agreed when he didn't accept another one as well.

 

It is clear that I "accept the way thing works".

 

I only politely and humbly asked a question.

 

 

[flashjazzcat]

2 hours ago, Marius said:

One of the most important and most used features on my blackbox back in the day (I really miss using it) was the centrally mounted large write protect switch.

You must surely enjoy the dual-level write-protect feature on the U1MB PBI HDD.

 

[_The Doctor__]

black box has individual partition/id protection as well as machine configurable wholesale write protect topped off with a hardware switch to write protect across the whole of connected devices. Don't worry we still forget and have some over writing and deletion fun..

 

Not to forget that most of the DOS offering have their own form of protections... and we manage to forget/not use it or even use functions that don't care about those protection flags... do I hear a format taking place? did the program really decide to drop data into sectors it shouldn't... what you mean the hard drive isn't a floppy?   I sometime wish the first 720k (or max# of sectors a floppy has used on Atari historically) of a hard drive were just a scratch pad for disks and programs to mangle with the rest of it for normal use.

 

Yeah that could really cut down that sort thing happening with newbies killing partitions.... repair would simply be milf for the hard disk partition possibly... details could be worked out...

Edited May 7, 2020 by _The Doctor__

[flashjazzcat]

1 hour ago, _The Doctor__ said:

black box has individual partition/id protection as well as machine configurable wholesale write protect topped off with a hardware switch to write protect across the whole of connected devices. Don't worry we still forget and have some over writing and deletion fun..

Indeed. APT has write-only flags on a per-partition basis as well, on top of the dynamic global configuration (write lock partitions or write lock physical disk) provided by the U1MB firmware. I assume next to no-one uses these facilities or are even aware they exist.

 

At the end of the day, such are the inherent problems of trying to guess the best fit defaults for every user. I leave all locking turned off by default; it is up to the user to set write-lock flags on partitions if they wish, but right out of the box, nothing is write-protected. I am sure that if the physical disk (i.e. the partition table) were read-only by default, every user would immediately complain that writing a new partition table to the disk generated an IO error.

[Alfred]

Why doesn't the debugger disassembly match actual memory ? Is there something I need to do to make it display the correct data ?

[Jacques]

Hi @phaeron,

 

is there a way to load external colour-palette in Altirra, e.g. from well-known act files, please?

Somehow I couldn't find such option myself ?

[Mclaneinc]

Fraid not, all files are internal..

[Jacques]

Oh, that's a bit of shame, as unfortunately PAL colours don't really match any of my real PAL Atari, the basic backround simply isn't that greenish, hmmm...

And there are built-in Olivier and Jakub palettes, so possibility to load one myself, would be great (I'd like to use great PAL palette done by Rocky).

Edited May 8, 2020 by Jacques

[Mclaneinc]

Well you can adjust the colours and it saves the adjustments per machine profile. I'm not sure if Phaeron will add random profiles to the build, you could ask.

[phaeron]

14 hours ago, Alfred said:

Why doesn't the debugger disassembly match actual memory ? Is there something I need to do to make it display the correct data ?

It does match actual memory, it's the BlackBox's debugger that is showing you different contents. The BlackBox firmware swaps out $3000-33FF in main memory to its own memory to use as a temporary display. Altirra is showing you the actual contents of that memory, while the BlackBox debugger is showing you a virtualized view with the contents of that memory when you entered the menu. What you are seeing in Altirra's debugger is the BlackBox debugger's display list and top of screen.

 

2 hours ago, Jacques said:

Oh, that's a bit of shame, as unfortunately PAL colours don't really match any of my real PAL Atari, the basic backround simply isn't that greenish, hmmm...

And there are built-in Olivier and Jakub palettes, so possibility to load one myself, would be great (I'd like to use great PAL palette done by Rocky).

Those are parameter-matched. Altirra can't use .PAL files directly because it needs the generation parameters for the palette and not just the final colors. You can get the main screen to be more blue by adjusting the Hue Start and Hue Step parameters -- I have tried to match some pictures that I have seen from PAL systems but it is a bit difficult. If you can post a picture from your PAL Atari of the COLORMAP utility from Altirra's Additions disk, I can see if I can come up with parameters to better match it.

 

[Jacques]

Thank you @phaeron

Just to make sure: so isn't there a way to somehow use attached .act palette? 

It's something that beside other emulators, can be used by VBXE to override default palette from its core, as well. 

rocky_real_atari2.act

Edited May 8, 2020 by Jacques

[+MrFish]

19 minutes ago, phaeron said:

Those are parameter-matched. Altirra can't use .PAL files directly...

 

4 minutes ago, Jacques said:

Just to make sure: so isn't there a way to somehow use attached .act palette? 

 

I'm pretty sure .PAL and .ACT are just different extensions for the same file type.

 

[kenames99]

17 hours ago, Alfred said:

Why doesn't the debugger disassembly match actual memory ? Is there something I need to do to make it display the correct data ?

I have that problem also, I have to go to the memory display window and refresh by hitting enter. That shows me current contents of memory.

[Alfred]

9 hours ago, phaeron said:

It does match actual memory, it's the BlackBox's debugger that is showing you different contents. The BlackBox firmware swaps out $3000-33FF in main memory to its own memory to use as a temporary display. Altirra is showing you the actual contents of that memory, while the BlackBox debugger is showing you a virtualized view with the contents of that memory when you entered the menu. What you are seeing in Altirra's debugger is the BlackBox debugger's display list and top of screen.

 

 

Ok, that explains it, thanks. There's also a bug in 3.90 that's been around since 3.20 but I can't tell you how to reproduce it. It's much reduced in 3.90 and I've only seen it once so far. I'm waiting for it to occur again so I can get a screenshot. The first symptom is the sector counters shown when reading/writing stop displaying. Once that happens, if you select a drop down menu, say File, with the View Printer pane already being displayed, the drop down menu doesn't disappear after you select an item and click. It remains there on the left over the black border. At that point different things happen. Altirra will not redraw it's window if something is brought into focus in front of it and then minimized, you're left with the just the window outline. The printer view pane becomes non-functional, as in output from a program ceases to be added to it. At some point in the process, emulation itself eventually stops. It used to happen a lot in 3.20, much less so as I said in this last build but I have seen it at least once. If I can get a screenshot of it, I'll pass it along. I am always in 65816 mode running Dataque's Turbo-816 OS, so perhaps it's related to the 816 emulation. There really doesn't seem to be anything common that I do to cause it, other than loads of using the Action! editor and running the Six Forks assembler and linker.