Faicuai Posted February 5, 2021 Share Posted February 5, 2021 Altirra OS 3.28 / 3.29 / 3.30 BUG (on both Colleen and XL/XE loads): 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. Problem disappears entirely by simply switching to an Atari XL/XE OS-load, for instance, on wither Colleen or XL/XE modes. 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): When launching SI (v2.24) and running HD speed test via DOS (and DMA=OFF), system hangs shortly after test begins. 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. Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 6, 2021 Author Share Posted February 6, 2021 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): 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. Problem disappears entirely by simply switching to an Atari XL/XE OS-load, for instance, on wither Colleen or XL/XE modes. 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): When launching SI (v2.24) and running HD speed test via DOS (and DMA=OFF), system hangs shortly after test begins. 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. Quote Link to comment Share on other sites More sharing options...
emkay Posted February 7, 2021 Share Posted February 7, 2021 (edited) @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 Quote Link to comment Share on other sites More sharing options...
R.Cade Posted February 7, 2021 Share Posted February 7, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Faicuai Posted February 7, 2021 Share Posted February 7, 2021 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... Quote Link to comment Share on other sites More sharing options...
+Stephen Posted February 7, 2021 Share Posted February 7, 2021 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. Quote Link to comment Share on other sites More sharing options...
R.Cade Posted February 7, 2021 Share Posted February 7, 2021 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. Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 7, 2021 Author Share Posted February 7, 2021 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. Quote Link to comment Share on other sites More sharing options...
emkay Posted February 7, 2021 Share Posted February 7, 2021 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. Quote Link to comment Share on other sites More sharing options...
+gnusto Posted February 7, 2021 Share Posted February 7, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted February 7, 2021 Share Posted February 7, 2021 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.. Quote Link to comment Share on other sites More sharing options...
Faicuai Posted February 8, 2021 Share Posted February 8, 2021 (edited) 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): Set Altirra for XL/XE and Ultimate1MB, and set above ROM as main U!MB rom. (NO NEED to have SIDE 1/2 attached !) Mount above .ATR as D1. 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. Force-boot with "B", then "D" and "1", to make sure SDX checks .ATR at boot-time, yes or yes. 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. 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. 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 Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 9, 2021 Author Share Posted February 9, 2021 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. 3 Quote Link to comment Share on other sites More sharing options...
Faicuai Posted February 9, 2021 Share Posted February 9, 2021 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... Quote Link to comment Share on other sites More sharing options...
xxl Posted February 10, 2021 Share Posted February 10, 2021 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) Quote Link to comment Share on other sites More sharing options...
Faicuai Posted February 10, 2021 Share Posted February 10, 2021 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. Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 10, 2021 Author Share Posted February 10, 2021 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. Quote Link to comment Share on other sites More sharing options...
Atari Nut Posted February 10, 2021 Share Posted February 10, 2021 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. Quote Link to comment Share on other sites More sharing options...
xxl Posted February 11, 2021 Share Posted February 11, 2021 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 Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 11, 2021 Author Share Posted February 11, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 11, 2021 Author Share Posted February 11, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
xxl Posted February 11, 2021 Share Posted February 11, 2021 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 ? Quote Link to comment Share on other sites More sharing options...
Keatah Posted February 11, 2021 Share Posted February 11, 2021 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. Quote Link to comment Share on other sites More sharing options...
dualcam Posted February 11, 2021 Share Posted February 11, 2021 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/ Quote Link to comment Share on other sites More sharing options...
Atari Nut Posted February 11, 2021 Share Posted February 11, 2021 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.