Altirra 4.00 released

[Mclaneinc]

21 minutes ago, drpeter said:

contemporaneous physical electron beam position?  If this is taken as the immutable baseline timeframe

 

Typical Doctor, can't understand their writing

[glurk]

I think I understood him.  But regardless of whatever flaws this view may have, it's INCREDIBLY useful, and one of the features I use the most often when building display lists.  So please do not remove, or I'll have to keep using older Altirra versions!  ?

[+KlasO]

I just experienced VBXE not being detected in 4.10-test7 and could not understand why, but when removing and adding the VBXE in Devices it works just fine again. Possibly a bug. 

 

Kind regards

Klas

 

EDIT: I am running Altirra in CrossOver on macOS, so this may work just fine if you run it in the intended setup on Windows. 

EDIT: Mr 'Train-wreck' just found the reason - VBXE disabled in U1MB. I'll see myself out.  

[andyhants]

On 2/6/2022 at 11:37 AM, drpeter said:

That may be true, but this view remains a very useful educational insight into where in the raster cycle 6502 cycles are being 'stolen' by DMA.

 

I assume that at present the view is synchronised to show when DMA is occurring precisely in relation to the contemporaneous physical electron beam position?  If this is taken as the immutable baseline timeframe, known register write pipelining delays in relation to that timeframe can be counted forward from it to determine where the graphical effects of register writes will appear on screen...

'the contemporaneous physical electron beam position?  If this is taken as the immutable baseline timeframe'

 

Reverse the polarity of the Neutron flow !

Edited February 17, 2022 by andyhants

[rsh]

Confirmed Altirra is not behaving correctly to Real hardware.  In version v3.2 of Altirra works just like the real hardware.  (I did not test with any

versions after v3.2 and before v4.0 so it could have creeped in anytime after v3.2).

 

Tested against real hardware 130XE using Basic XE, however with minor mods it will run in normal Atari Basic and with NO mods in Altirra Basic.    

 

You can also Test Altirra v3.2 vs v4.0 and you will see you need to press the arrow keys like 100 times in v4.0 before you get a kp value change.  Timing seems to

be off on keyboard/key register updates.  On the real hardware & v3.2 you will get a non 255 immediately on key press.

 

Test Code:

10 Gosub 200:If Kp<>255:? Kp,Peek(753):Endif
20 Goto 10
200 If Peek(753)=3:Kp=Peek(764):Poke 764,255:Else :Kp=255:Endif :Return

 

 

Edited February 18, 2022 by rsh

[+Stephen]

1 hour ago, rsh said:

Confirmed Altirra is not behaving correctly to Real hardware.  In version v3.2 of Altirra works just like the real hardware.  (I did not test with any

versions after v3.2 and before v4.0 so it could have creeped in anytime after v3.2).

 

Tested against real hardware 130XE using Basic XE, however with minor mods it will run in normal Atari Basic and with NO mods in Altirra Basic.    

 

You can also Test Altirra v3.2 vs v4.0 and you will see you need to press the arrow keys like 100 times in v4.0 before you get a kp value change.  Timing seems to

be off on keyboard/key register updates.  On the real hardware & v3.2 you will get a non 255 immediately on key press.

 

Test Code:

10 Gosub 200:If Kp<>255:? Kp,Peek(753):Endif
20 Goto 10
200 If Peek(753)=3:Kp=Peek(764):Poke 764,255:Else :Kp=255:Endif :Return

 

 

There are 3 different modes of reading the keyboard in Altirra - Raw, Cooked, and Full Keyboard Scan.  What is this set to?  To find it, go to Configure System, Peripherals, Keyboard and check the "Key Press Mode".

[rsh]

13 hours ago, Stephen said:

There are 3 different modes of reading the keyboard in Altirra - Raw, Cooked, and Full Keyboard Scan.  What is this set to?  To find it, go to Configure System, Peripherals, Keyboard and check the "Key Press Mode".

I did try and go through all the configuration settings in the past to see if there was some config setting to fix this... but, I will look at this tonight and get back to you, thx! 

[Mclaneinc]

I'm betting you are set to cooked.. I use raw

[+Stephen]

Well, I went through and tried every option, and no matter what I did, I could not get the arrow keys to respond the same as the rest of the keys.  Interesting.

[Mclaneinc]

5 minutes ago, Stephen said:

Well, I went through and tried every option, and no matter what I did, I could not get the arrow keys to respond the same as the rest of the keys.  Interesting.

Not sure what you were expecting, here with RAW all keys give a 3, including the arrow keys..

Edited February 18, 2022 by Mclaneinc

[StickJock]

13 minutes ago, Mclaneinc said:

Not sure what you were expecting, here with RAW all keys give a 3, including the arrow keys..

[+Stephen]

1 hour ago, Mclaneinc said:

Not sure what you were expecting, here with RAW all keys give a 3, including the arrow keys..

That's the problem.  The arrow keys don't give anything.  They will move the cursor like they should, but with the BASIC code snippet posted, the arrow keys do not register.

[+Stephen]

54 minutes ago, StickJock said:

 

[StickJock]

[phaeron]

20 hours ago, rsh said:

Confirmed Altirra is not behaving correctly to Real hardware.  In version v3.2 of Altirra works just like the real hardware.  (I did not test with any

versions after v3.2 and before v4.0 so it could have creeped in anytime after v3.2).

 

Tested against real hardware 130XE using Basic XE, however with minor mods it will run in normal Atari Basic and with NO mods in Altirra Basic.    

 

You can also Test Altirra v3.2 vs v4.0 and you will see you need to press the arrow keys like 100 times in v4.0 before you get a kp value change.  Timing seems to

be off on keyboard/key register updates.  On the real hardware & v3.2 you will get a non 255 immediately on key press.

 

Test Code:

10 Gosub 200:If Kp<>255:? Kp,Peek(753):Endif
20 Goto 10
200 If Peek(753)=3:Kp=Peek(764):Poke 764,255:Else :Kp=255:Endif :Return

This is just a compatibility issue with the built-in AltirraOS and the way it handles the KEYDEL variable. It works with the Atari OS on 4.00 and the issue with AltirraOS is already fixed in 4.10-test7.

[Phlod]

I hope this is the right place for this question.  Is there any way to set the speed of the Warp Speed pulse when hitting F1?  Running at max speed is rarely what I want to do, but running at like 1.5x for a few seconds would be nice when playing certain games which are a bit taxing on the A8 hardware.

 

[Keatah]

That feature becomes more and more relevant as processors get faster and faster. Unrestricted warp plays at 3,000 fps on recent hardware.

[rsh]

7 hours ago, Mclaneinc said:

I'm betting you are set to cooked.. I use raw

It was set to Raw but that did not work, nor did Cooked,  but after I set it to Full Raw keyboard scan.. It appears to work like the real hardware.  So Raw default is different from 3.2 vs 4.0... thanks!!!! And someone posted that something was addressed in 4.10 as well.  Thanks everyone!

[Mclaneinc]

I'll set mine to the same, so thank you..

 

 

Edited February 19, 2022 by Mclaneinc

[phaeron]

20 hours ago, rsh said:

It was set to Raw but that did not work, nor did Cooked,  but after I set it to Full Raw keyboard scan.. It appears to work like the real hardware.  So Raw default is different from 3.2 vs 4.0... thanks!!!! And someone posted that something was addressed in 4.10 as well.  Thanks everyone!

What? No, you don't need full keyboard scan for this, just raw scan will do fine.

 

Note that the default was changed a while back from Cooked to Raw. If you started on an old version you may still have had the old setting.

 

8 hours ago, Mclaneinc said:

I'll set mine to the same, so thank you..

Don't. All this is going to do for the vast majority of programs is randomly add one frame of latency to keystrokes. The main reason that full keyboard scan exists is for 5200 emulation.

 

[Mclaneinc]

Thanks for the heads up Avery..Appreciated..

[Mclaneinc]

22 hours ago, Phlod said:

I hope this is the right place for this question.  Is there any way to set the speed of the Warp Speed pulse when hitting F1?  Running at max speed is rarely what I want to do, but running at like 1.5x for a few seconds would be nice when playing certain games which are a bit taxing on the A8 hardware.

 

Technically you can adjust the speed (not the warp though) by going in to the system configure and speed, and manually set speed to 110% or whatever suits, BUT its not really a fun way to do it, easier just to tap warp briefly. Maybe if Avery added a rewind feature, you could mix the two in case you skip too far ahead.

 

I doubt that Avery would even consider a rewind feature, as it's just cosmetic rather than emulation correctness. Personally, I like a rewind ability, but it is just a toy.

[Mclaneinc]

 

Just for info, 4.01 Final is up on Avery's site, as there's been no post here it's leads me to believe that there is no difference from the last beta (7)

 

Just for people who like to have a final..

[phaeron]

On 2/18/2022 at 1:22 PM, Phlod said:

I hope this is the right place for this question.  Is there any way to set the speed of the Warp Speed pulse when hitting F1?  Running at max speed is rarely what I want to do, but running at like 1.5x for a few seconds would be nice when playing certain games which are a bit taxing on the A8 hardware.

Afraid not, warp speed always runs without the speed limiter.

 

A kind of janky thing you can do is set speed to 200% and then enable slow-mo (bind System.ToggleSlowMotion in Keyboard Shortcuts) -- slow-mo applies a 50% factor which gets you back to 100%.

 

1 hour ago, Mclaneinc said:

 

Just for info, 4.01 Final is up on Avery's site, as there's been no post here it's leads me to believe that there is no difference from the last beta (7)

 

Just for people who like to have a final..

It only contains a selection of bug fixes from 4.10-test, so you don't need 4.01 if you are on the test line -- but I wanted to get out an updated release version due to the #&*$( Intel D3D11 graphics driver bug. Took a bit longer than I expected since I hit a tape audio regression in one of the fixes that I had to back out.

• Additions: Fixed LOADEXE.XEX using old $FD device SIO code for the program loader instead of $7D.
• AltirraOS: Fixed math pack compatibility issue with FDIV modifying FLPTR (fixes B-Graph pie chart routine).
• AltirraOS: Fixed a cursor position checking bug with split screen Gr.0 (fixes the BASIC game House of Usher).
• AltirraOS: Fixed compatibility issue with KEYDEL handling (fixes cursor movement in BrushupV40).
• ATBasic: IOCB#7 is now automatically closed on I/O errors to avoid SAVE files being kept open for write.
• Cassette: Fixed FLAC decoder crash with some block sizes.
• Cassette: Fixed regression with FSK blocks in CAS files being read as turbo pulses instead of FSK pulses.
• Disk: Retuned XF551 high-speed C/E to data frame delay.
• Display: Workaround for D3D11 minimum precision crash on Intel Iris Xe 30.0.101.1069 driver.
• Serial: Pad out 850 relocator to match length of original firmware relocator (fixes compatibility with loaders that hardcode the relocator length).
• VFS: Fixed wrong file being accessed when using atfs:// paths to access files inside a DOS 2 disk image.

 

[vitoco]

Sometimes I use the File View utility from the Disk Explorer popup to get an idea of what kind of file it is.

 

Today I did it with an AUTORUN.SYS file just to check which version it was and noticed that some of the ATASCII characters do not match the right ones:

 

 

 

Up arrows are displayed as down ones in the File View, and inverse-down are displayed as inverse-left. There are few more differences.

 

Why is there a difference?

 

Also, could the File View window use the standard ATASCII font?

 

Thanks...