Altirra 3.90 released

[Faicuai]

Altirra OS 3.28 / 3.29 / 3.30 BUG (on both Colleen and XL/XE loads):

1. After initializing Sparta Commander with RC_GR8.SYS driver (tested with >= v4.49 final), any command like "View" (CTRL-V), or simply "Quit" (CTRL-Q), the system hangs. Only additional drivers loaded are ENV.SYS and DOSKEY.SYS, but they seem unrelated.
2. Problem disappears entirely by simply switching to an Atari XL/XE OS-load, for instance, on wither Colleen or XL/XE modes.
3. Tested on 800 / Incognito (could not find anything Incognito-related to this problem, though).

In addition to the above, I also found this issue with latest v4.49E, in Colleen mode, with OS 3.30 (may be yet another bug, may also be present in prior loads):

1. When launching SI (v2.24) and running HD speed test via DOS (and DMA=OFF), system hangs shortly after test begins.
2. Problem disappears by switching to any Atari-derived OS load (OS/b, Newell OS/N, etc.).

I am not sure if these two problems are related, but I would definitely start with the first one.

[phaeron]

On 2/5/2021 at 8:51 AM, Faicuai said:

Altirra OS 3.28 / 3.29 / 3.30 BUG (on both Colleen and XL/XE loads):

1. After initializing Sparta Commander with RC_GR8.SYS driver (tested with >= v4.49 final), any command like "View" (CTRL-V), or simply "Quit" (CTRL-Q), the system hangs. Only additional drivers loaded are ENV.SYS and DOSKEY.SYS, but they seem unrelated.
2. Problem disappears entirely by simply switching to an Atari XL/XE OS-load, for instance, on wither Colleen or XL/XE modes.
3. Tested on 800 / Incognito (could not find anything Incognito-related to this problem, though).

Can't reproduce, not seeing an issue running AltirraOS 3.30 with SpartaDOS X 4.49E and the RC_GR8.SYS + SC105 from its Toolkit disk.

 

On 2/5/2021 at 8:51 AM, Faicuai said:

 

In addition to the above, I also found this issue with latest v4.49E, in Colleen mode, with OS 3.30 (may be yet another bug, may also be present in prior loads):

1. When launching SI (v2.24) and running HD speed test via DOS (and DMA=OFF), system hangs shortly after test begins.
2. Problem disappears by switching to any Atari-derived OS load (OS/b, Newell OS/N, etc.).

I am not sure if these two problems are related, but I would definitely start with the first one.

You didn't specify which hard disk interface was being used, but I also couldn't reproduce this with a emulated IDE+2 interface. It seems likely that this is related to the screen switch though, given the previous issue.

 

Can you try to reduce these repro cases by removing devices/drivers, and see if you can get it in an emulated setup? I don't have an Incognito, so I can't test on that device.

 

[emkay]

@phaeron

Is there a special issue, that keeps Altirra from running free in the Multitasking Environment?

 If any movement of the Windows is stopping the emulation, any other event could stop it as well. 

 

 

 

Edited February 7, 2021 by emkay

[R.Cade]

48 minutes ago, emkay said:

@phaeron

Is there a special issue, that keeps Altirra from running free in the Multitasking Environment?

 If any movement of the Windows is stopping the emulation, any other event could stop it as well. 

 

 

 

You can turn this off in the configuration...

 

System->Pause when Inactive

 

Edited February 7, 2021 by R.Cade

[Faicuai]

18 hours ago, phaeron said:

Can't reproduce, not seeing an issue running AltirraOS 3.30 with SpartaDOS X 4.49E and the RC_GR8.SYS + SC105 from its Toolkit disk.

 

You didn't specify which hard disk interface was being used, but I also couldn't reproduce this with a emulated IDE+2 interface. It seems likely that this is related to the screen switch though, given the previous issue.

 

Can you try to reduce these repro cases by removing devices/drivers, and see if you can get it in an emulated setup? I don't have an Incognito, so I can't test on that device.

 

I will work on this and get back here.

 

The first problem was tested (over-and-over) with SDX 4.49 final... 

[+Stephen]

6 minutes ago, R.Cade said:

51 minutes ago, emkay said:

@phaeron

Is there a special issue, that keeps Altirra from running free in the Multitasking Environment?

 If any movement of the Windows is stopping the emulation, any other event could stop it as well. 

 

 

 

You can turn this off in the configuration...

 

System->Pause when Inactive

No - that will let it continue to run when in the background.  When dragging the window to move or re-size it, it will still stop.  This is what emkay is asking about.

[R.Cade]

49 minutes ago, Stephen said:

No - that will let it continue to run when in the background.  When dragging the window to move or re-size it, it will still stop.  This is what emkay is asking about.

That is pretty normal for other emulators, and most Windows applications...

 

Just for kicks, I ran AppleWin, VICE C64... They paused when moving the window.

[phaeron]

2 hours ago, emkay said:

@phaeron

Is there a special issue, that keeps Altirra from running free in the Multitasking Environment?

 If any movement of the Windows is stopping the emulation, any other event could stop it as well.

Window dragging, as well as window open/close animations and some common control interactions, are modal operations that block the UI thread on Windows. I implemented a workaround for this for menus but it was a complicated and annoying fix. Multithreading is not a simple fix for this because input and drawing have to occur on the UI thread and the thread communication would have to be added to all the UI code that talks to the emulation.

 

[emkay]

30 minutes ago, phaeron said:

Window dragging, as well as window open/close animations and some common control interactions, are modal operations that block the UI thread on Windows. I implemented a workaround for this for menus but it was a complicated and annoying fix. Multithreading is not a simple fix for this because input and drawing have to occur on the UI thread and the thread communication would have to be added to all the UI code that talks to the emulation.

 

Odd. 

I 'm using several Programs, just like different Video Players or a DVB-Viewer. What do they different?

Possibly they use an RGB overlay that runs free on the UI?

And, well other emulators also stop. But the Atari800win keeps running without showing changes in the graphics. This means the music is not stopping when interactions on the window happen.   

[+gnusto]

5 minutes ago, emkay said:

And, well other emulators also stop. But the Atari800win keeps running without showing changes in the graphics. This means the music is not stopping when interactions on the window happen.

 

I actually wrote the first version of Atari800Win and maintained it for several years. Modern Atari800Win (plus?) is probably similar to how I did it back then - the emulation logic is in an independent thread. This was relatively easy based on the way I was starting the code base - Atari800 core code already existed, had no expectations other than a virtual framebuffer (which it rendered to first, then you had to copy that to the host machine representation). One of the side benefits was that it could render (but not draw to the host framebuffer) while the Windows GUI was occupied; but there are also drawbacks. For one if you aren't fast enough on the GUI side you can end up more than a frame behind in display or miss a frame update. But generally the danger is that you have a thread "doing things" - I/O, sound and the like - that is at best governed by the UI on a frame basis, and that difference can cause problems, like an emulation thread that goes too long or won't shut down in circumstances the UI wants it to.

 

It is much more traditional, and straightforward, to do it the way Phaeron has, and leave the part that draws ultimately the owner of advancing logic.

[Mclaneinc]

22 minutes ago, gnusto said:

I actually wrote the first version of Atari800Win and maintained it for several years.

 

Ha ha, you must have dealt with me many times then, I was always asking for things to be added and testing stuff, its how I got a place in the manual.

 

Small world..

[Faicuai]

On 2/6/2021 at 4:35 PM, phaeron said:

Can't reproduce, not seeing an issue running AltirraOS 3.30 with SpartaDOS X 4.49E and the RC_GR8.SYS + SC105 from its Toolkit disk.

 

You didn't specify which hard disk interface was being used, but I also couldn't reproduce this with a emulated IDE+2 interface. It seems likely that this is related to the screen switch though, given the previous issue.

 

Can you try to reduce these repro cases by removing devices/drivers, and see if you can get it in an emulated setup? I don't have an Incognito, so I can't test on that device.

 

Ok, so here's a package I prepared so you can reproduce the issue, as simply as possible on your end (with Altirra):

 

1. U1MB 512K rom image: Ultimate1MB-v10.rom

2. SDX-bootable target .ATR: Scratchpad-SDX-SDrive_BOOT-AA.ATR

 

And here's the step-by-step (trying to be as precise as I can):

1. Set Altirra for XL/XE and Ultimate1MB, and set above ROM as main U!MB rom. (NO NEED to have SIDE 1/2 attached !)
2. Mount above .ATR as D1.
3. Get to U1MB Bios and press "3" (not sure if it will land there automatically). Ignore profile's OS label, as AltOSv3.30 is already loaded and selected.
4. Force-boot with "B", then "D" and "1", to make sure SDX checks .ATR at boot-time, yes or yes.
5. A CONFIG list should pop-up. Select either "_BEST" or "_SDXCART" (latter will run SIO faster). Loaded drivers do not seem to matter at all.
6. Once in SDX prompt, just type "-SDX80COL -SDXCOMDR", and after a short while you should land on SDX Commander main screen. Pointing directly to sub-directories involved, and calling Sparta Commander manually, does not see to matter, either. You can try if you wish.
7. Once there, type "CTRL-Q" and watch lock-up.

Hopefully, you should be able to reproduce it. Problem is cured by simply selecting another XL/XE OS-load.

Edited February 8, 2021 by Faicuai

[phaeron]

7 hours ago, Faicuai said:

Ok, so here's a package I prepared so you can reproduce the issue, as simply as possible on your end (with Altirra):

Ah, thanks for all that. The profile gave me a little trouble as the profiles are stored in NVRAM and were not available, but there were only four ROM images to try.

 

It would have been difficult for you to tell, but the repro is just to set LMARGN=0 (POKE 82,0) and do a character delete. The screen editor is getting confused trying to detect when it has gone beyond the left margin. Shouldn't be hard to fix, just a little tricky doing so without adding more bytes since the screen editor is packed tighter than a can of sardines.

[Faicuai]

 

1 hour ago, phaeron said:

It would have been difficult for you to tell, but the repro is just to set LMARGN=0 (POKE 82,0) and do a character delete. The screen editor is getting confused trying to detect when it has gone beyond the

 

Very nice... It was already difficult finding it, per se... but it is good you nailed down, because it has the potential to compromise any other application that performs the exact same action with the screen editor.

 

Let's see how the walls of that can-of-sardines flex...

[xxl]

is it possible that Altirra does not allow bank switching for a 1MB AtariMax card if the image has no header but is in .bin form (I indicate the type of card correctly)

[Faicuai]

On 2/8/2021 at 10:57 PM, phaeron said:

Ah, thanks for all that. The profile gave me a little trouble as the profiles are stored in NVRAM and were not available, but there were only four ROM images to try.

 

It would have been difficult for you to tell, but the repro is just to set LMARGN=0 (POKE 82,0) and do a character delete. The screen editor is getting confused trying to detect when it has gone beyond the left margin. Shouldn't be hard to fix, just a little tricky doing so without adding more bytes since the screen editor is packed tighter than a can of sardines.

A couple more items that have been in the queue, but showing more frequently now that I am enjoying AltOS strengths in colleen-mode:

 

1. In SDX, with DOSKEY driver loaded, when re-calling a prior command from DOSKEY buffer that eventually takes more than one line to display (say, the "current path" takes a good chunk of the first line), trying to move back from second line to first line, char-by-char, with cursor-keys, will eventually halt in left margin of 2nd line, as cursor will not wrap around left and continue in upper-right corner of prior line. This does not happen with oem OS loads. Left Margin is set to 0, just in case.

 

2. Indus/GT Diagnostics (operation "Zero Adjust") seems to fail in Altirra OS, which is weird. Everything else works like a charm. Switch to another OS/b load and it does perform correctly). Noticed this while adjusting track-0 sensor in one of my Indus/GT units.

[phaeron]

9 hours ago, xxl said:

is it possible that Altirra does not allow bank switching for a 1MB AtariMax card if the image has no header but is in .bin form (I indicate the type of card correctly)

No, this shouldn't be the case. The only difference between CAR and BIN image file handling is how the image is processed, but both get unpacked to the same raw data and banking config.

 

Do make sure you are choosing the right size, though, as AtariMax carts are sometimes named in megabits instead of megabytes, and the 1Mbit (128KB) and 8Mbit (1MB) cartridges have incompatible banking. You can also use the .map debugger command to check if the cartridge banking layers are present and the .bank command to check the current banking offset.

 

[Atari Nut]

Does anyone know how to set up the mapping for a set of Atari Paddles plugged in to a 2600-daptor?  I can't get it to work.

[xxl]

6 hours ago, phaeron said:

Do make sure you are choosing the right size, though, as AtariMax carts are sometimes named in megabits instead of megabytes, and the 1Mbit (128KB) and 8Mbit (1MB) cartridges have incompatible banking. You can also use the .map debugger command to check if the cartridge banking layers are present and the .bank command to check the current banking offset.

 

 

thanks. I used to run this image and it worked fine - on another emulator it also works: / I don't know what I'm doing wrong.

 

 

 

Multi-Disk Cart.car

[phaeron]

32 minutes ago, xxl said:

thanks. I used to run this image and it worked fine - on another emulator it also works: / I don't know what I'm doing wrong.

You're also running quite a lot of add-on devices. The cartridge runs fine for me on a base 3.90 configuration. You can run the emulator with /portabletemp to start it on a clean configuration for testing without loading or saving anything from the Registry or INI files.

 

Looking at the .map output there is a suspicious unnamed second layer in the $D5 page at hardware overlay priority (57) that is likely causing the problems. Essentially, you have a hardware conflict. It is probably either SoundBoard or SlightSID, either of which will cause problems as an AtariMax 8Mbit cartridge needs the whole $D5 page free for banking.

 

[phaeron]

10 hours ago, Faicuai said:

2. Indus/GT Diagnostics (operation "Zero Adjust") seems to fail in Altirra OS, which is weird. Everything else works like a charm. Switch to another OS/b load and it does perform correctly). Noticed this while adjusting track-0 sensor in one of my Indus/GT units.

So it turns out this one is a funny bug in the Indus GT diagnostics. The Zero Adjust step uploads custom code to the drive that fumbles the SIO protocol and sends two ACKs instead of ACK + Complete. The stock OS SIO routine accepts this (arguably a bug), while AltirraOS rejects it under a strict interpretation of the protocol. Fortunately, it only takes an ORA instruction to allow this.

[xxl]

3 hours ago, phaeron said:

Looking at the .map output there is a suspicious unnamed second layer in the $D5 page at hardware overlay priority (57) that is likely causing the problems. Essentially, you have a hardware conflict. It is probably either SoundBoard or SlightSID, either of which will cause problems as an AtariMax 8Mbit cartridge needs the whole $D5 page free for banking.

that was it !!! now works ?

[Keatah]

Love the ongoing work with this emulator. Like I say I don't pretend to understand 50% of it. But all of the pieces seem to come together for a great user experience. Especially all the menu/customization options.

[dualcam]

18 hours ago, Atari Nut said:

Does anyone know how to set up the mapping for a set of Atari Paddles plugged in to a 2600-daptor?  I can't get it to work.

 

There is Altirra setup on the 5200-daptor page -

http://2600-daptor.com/5200-daptor.htm

 

Haven't looked at Altirra in some years, possible the controller setup has changed.

 

Tom

http://2600-daptor.com/

 

[Atari Nut]

6 minutes ago, dualcam said:

 

There is Altirra setup on the 5200-daptor page -

http://2600-daptor.com/5200-daptor.htm

 

Haven't looked at Altirra in some years, possible the controller setup has changed.

 

Tom

http://2600-daptor.com/

 

Thanks Tom.  The setup in Altirra has changed a bit.  I found this in another post here and this works.

 

Original post...

How to get paddles to work on Altirra 2.3 with 2600-daptor II - Atari 8-Bit Computers - AtariAge Forums