Altirra 4.10 released

[FaustXXX]

On 5/31/2023 at 9:07 AM, spicyjack said:

Short thread hijack...

 

@pmgraphics, the original file was posted to the libretro forums, and the mega.nz download link in that forum post is still working, in case anybody else wants to download a copy.

 

 

Reg.

T2E.pl

VintageTV-t2e.pl.zip

[drac030]

On 5/31/2023 at 10:08 AM, spicyjack said:

Please let me know if you need any more info, disk images, screenshots, or checksums, and I'll be happy to paste them here.  Thanks!

 

From my side I can confirm that flashing the emulated IDE+ BIOS ROM works here (PC, Win7 64-bit). I do it regularly to keep the emulation firmware/software setup as close to my real hardware setup as possible.

 

The symptoms you are describing seem to point to a problem with the flashing process. If the software (like KMKDIAG) does not recognize the ROM, this means that it is probably empty or filled with garbage. Therefore it could be useful to see what is saved in the ROM image file.

 

If this is confirmed, I am of course also interested in the diagnosis, because there may be something to fix on my side, too.

[spicyjack]

3 hours ago, drac030 said:

 

From my side I can confirm that flashing the emulated IDE+ BIOS ROM works here (PC, Win7 64-bit). I do it regularly to keep the emulation firmware/software setup as close to my real hardware setup as possible.

 

The symptoms you are describing seem to point to a problem with the flashing process. If the software (like KMKDIAG) does not recognize the ROM, this means that it is probably empty or filled with garbage. Therefore it could be useful to see what is saved in the ROM image file.

 

If this is confirmed, I am of course also interested in the diagnosis, because there may be something to fix on my side, too.

Here are the ROMs and checksums for the ROM files I saved from versions 1.6, 1.7, 1.8, and 1.9.  I have no way beyond the "Save Firmware" menu in Altirra to create the ROM files, unless you have a program somewhere that can "unpack" the ROM files from the BIOSXX.COM binaries.

 

$ crc32 ideplus-bios-1.*
eba5834c	ideplus-bios-1.6.2023-05-30.rom
249a97c2	ideplus-bios-1.7.2023-05-30.rom
aa0cfd5b	ideplus-bios-1.8.2023-05-30.rom
4cee2fdf	ideplus-bios-1.9.2023-05-29.rom

 

And the MD5 checksums:

 

$ md5 ideplus-bios-1.*
MD5 (ideplus-bios-1.6.2023-05-30.rom) = cf732ed6408e41b327e0730593062455
MD5 (ideplus-bios-1.7.2023-05-30.rom) = a49d8b5fae170ed928eccb382d144051
MD5 (ideplus-bios-1.8.2023-05-30.rom) = e470212ccbeaa00713516a093671bbd3
MD5 (ideplus-bios-1.9.2023-05-29.rom) = a63254ef4e1e9c9984252c96b28f0b65

 

And the ROM files themselves...

ideplus-bios-1.9.2023-05-29.romideplus-bios-1.8.2023-05-30.romideplus-bios-1.7.2023-05-30.romideplus-bios-1.6.2023-05-30.rom

 

The dates in the filenames are the dates I created the ROMs by using "Save Firmware" in Altirra, not the dates you released them (of course).

[spicyjack]

11 hours ago, drac030 said:

The symptoms you are describing seem to point to a problem with the flashing process. If the software (like KMKDIAG) does not recognize the ROM, this means that it is probably empty or filled with garbage. Therefore it could be useful to see what is saved in the ROM image file.

One other thing I didn't mention previously, if I loaded the firmware using BIOSXX.COM, then re-entered the BIOSXX.COM program right after the "flashing" process finished, the BIOSXX.COM program would just show me that the existing ROM was valid, and then exit.  Here's a screenshot from running BIOS19.COM a second time after flashing the first time showing what I mean.

 

 

[Teapot]

A few things I've found:

 

Help>Reference>Options>Hardware

"The XEGS is very similar to a 64K 800" - 800XL perhaps?

 

Has two entries for Memory Size = 52K (sections 2.3 and 2.11).

 

 

In ATOS HELPFG only ever gets set to $11 - masking out the shift and control keys.

Using XL OS v.3 I see shift-help ($51) and control-help ($91).

 

I also noticed in the ATOS source that you're using a BIT instruction to check bit 7 of NOCLIK while Atari OS uses BNE. I see the 1200XL ctrl-F3 behavior is to EOR the value. If it had been poked with 01-FE this wouldn't work in XL OS (it would never be zero) but would work in ATOS (possibly needing an extra ctrl-F3).

Mapping the Atari says any non-zero value will disable the click.

[This only caught my eye because BIT is so rarely used and I had recently read the MtA entry]

 

Edited June 2, 2023 by Teapot

[phaeron]

14 hours ago, drac030 said:

 

From my side I can confirm that flashing the emulated IDE+ BIOS ROM works here (PC, Win7 64-bit). I do it regularly to keep the emulation firmware/software setup as close to my real hardware setup as possible.

 

The symptoms you are describing seem to point to a problem with the flashing process. If the software (like KMKDIAG) does not recognize the ROM, this means that it is probably empty or filled with garbage. Therefore it could be useful to see what is saved in the ROM image file.

 

If this is confirmed, I am of course also interested in the diagnosis, because there may be something to fix on my side, too.

Tracked this down to revision -- rev. D works, rev. E doesn't. Looks like it's an unemulated register bit, firmware is expecting to $D1FA bit 5 to be clear when currently it is set. Any description of this bit?

 

2 hours ago, Teapot said:

In ATOS HELPFG only ever gets set to $11 - masking out the shift and control keys.

Using XL OS v.3 I see shift-help ($51) and control-help ($91).

Ah yeah, this is a bug in the keyboard IRQ handler. I'll fix this.

 

2 hours ago, Teapot said:

I also noticed in the ATOS source that you're using a BIT instruction to check bit 7 of NOCLIK while Atari OS uses...

If you don't mind, could you report these in terms of affected programs instead of what the Atari OS code does? I try to write AltirraOS in terms of what programs expect or the official documentation says, in order to avoid having code dependencies and to have known test cases.

[drac030]

4 hours ago, phaeron said:

Tracked this down to revision -- rev. D works, rev. E doesn't. Looks like it's an unemulated register bit, firmware is expecting to $D1FA bit 5 to be clear when currently it is set. Any description of this bit?

Ah yes, I am using the rev. D (therefore in emulation too). PCONFIG bit 5 = 1 - no CF card inserted (rev. E and up).

[Teapot]

49 minutes ago, phaeron said:

3 hours ago, Teapot said:

I also noticed in the ATOS source that you're using a BIT instruction to check bit 7 of NOCLIK while Atari OS uses...

If you don't mind, could you report these in terms of affected programs instead of what the Atari OS code does? I try to write AltirraOS in terms of what programs expect or the official documentation says, in order to avoid having code dependencies and to have known test cases.

Apologies. I know you're trying to keep a clean room.

 

Is there official documentation on the XL OS? An updated version of the Technical Reference Notes or an addendum? I have traditionally used Appendix 12 of Mapping the Atari.

 

The MtA entry says zero=click and non-zero=quiet. From that description I would just set it to 1. But seeing the 1200XL function key behavior (just by PEEKing) I'll be using FF.

 

Going through existing programs and figuring out which use NOCLIK and which just bypass E:/K: seems daunting.

 

[phaeron]

3 hours ago, Teapot said:

Apologies. I know you're trying to keep a clean room.

Thanks, really appreciated. I try to at least maintain a good-faith level of effort in this regard. Besides, I don't want to match Atari's code a lot of the time, they use JSR too much....

 

3 hours ago, Teapot said:

Is there official documentation on the XL OS? An updated version of the Technical Reference Notes or an addendum? I have traditionally used Appendix 12 of Mapping the Atari.

 

The MtA entry says zero=click and non-zero=quiet. From that description I would just set it to 1. But seeing the 1200XL function key behavior (just by PEEKing) I'll be using FF.

 

Going through existing programs and figuring out which use NOCLIK and which just bypass E:/K: seems daunting.

The two primary sources I use are the Atari 400/800 Operating System User's Manual and the XL Addendum supplement. There are other official sources that sometimes have info, like the Atari BASIC and DOS manuals, but those two by far have the most information about OS variable usage. Having an official source of course isn't necessary, but many times the manual has a clear and unambiguous statement about what's supposed to happen -- which is a more solid justification for odd behavior than "fixes program X."

 

That having been said, in this case, unfortunately, the behavior is underspecified:

Quote

You may control a key click enable/disable from your program. All that needs to be done is to change the same flag which the operating system uses to indicate whether a key click is required. This flag is called NOCLIK. It is one of the OS database variables, contained at location $02DB.

On power up and reset, the operating system initializes this variable to a value of 00, meaning that key click is enabled. This location, when it contains the value $FF, indicates that no key click is desired. The key combination Ctrl-F3 toggles it between the values 00 and FF.

So, the XL Addendum unfortunately doesn't say what happens for other values. The OS manual is actually quite good at usually specifying high bit or non-zero for such cases. Of course, it has other problems, like specifying the behavior of OS-A -- which in several cases is quite different from OS-B.

 

I do implement undocumented behavior, and hitting a program that does it is the best case as it's a clear motivator for doing it. Otherwise, I'm not opposed to matching behavior anyway, but I do ask that it be reported as black box results -- not just for cleanliness, but also because the internal details often differ and AltirraOS doesn't have the same code as the Atari OS, so it would have to be implemented differently. So the pertinent part here what NOCLIK triggers for other values, and not what instructions are used to test it.

 

I never use Mapping the Atari when working on AltirraOS. It's a useful book, but besides it including far too many internal details of the OS -- many of which are just plain not guaranteed, especially for the 1200XL that everyone forgets about -- it sometimes just has bad information. In this case, while MtA is technically correct that a non-zero value disables the key click, it neglects to mention the XL Addendum tells you to write specifically $FF and that any other non-zero value will break Ctrl+F3. This kind of problem is why my recommendation is always that programmers should start with the OS Manual and not Mapping the Atari.

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.20-test14.zip
https://www.virtualdub.org/beta/Altirra-4.20-test14-src.7z

• AltirraOS 3.37: Improved NOCLIK compatibility, fixed Ctrl/Shift flags in HELPFG, and fixed KEYREP/KEYDEL not being implemented in '816 version.
• Fixed IDE+2 1.9 BIOS not detecting CF card.
• Fixed keyboard shortcuts not working in history window in the performance analyzer.
• Ctrl+F in history view selects search field.
• Fixed emulated TCP not properly handling graceful shutdowns from the remote side.

[scotty]

Avery, Is there a way to clear the OS and Basic used if you temporarily change it during an experiment?  In other words....  How do I get rid of this:

  

and get it to go back to the default (like this)??

 

 

Edited June 3, 2023 by scotty

[Teapot]

20 hours ago, phaeron said:

The two primary sources I use are the Atari 400/800 Operating System User's Manual and the XL Addendum supplement.

I've had the OS Manual since 1980 when I was given a xerox copy by a neighbor that worked at JPL and knew some people. And this is the first I've heard of the addendum. It looks like it was published with the 1200XL and there aren't any further updates for the later machines. I really hope the ToC having an entry "3.13 Deleted Features" and there not being a section 3.13 was on purpose.

 

I keep the OS Manual PDF open all the time and have the Mapping the Atari book on the desk. It's much easier to look up a memory label spelling or address in MtA. And the OS Manual is a better source of functional understanding.

 

20 hours ago, phaeron said:

So the pertinent part here what NOCLIK triggers for other values, and not what instructions are used to test it.

I agree, I was just caught up in seeing a BIT instruction that wasn't just a 3 cycle NOP.

[+gnusto]

9 hours ago, scotty said:

Avery, Is there a way to clear the OS and Basic used if you temporarily change it during an experiment?

Use the /tempprofile command line switch.

  /tempprofile
              Enable temporary profile mode (do not save settings)

 

You can see all command line switches by starting Altirra with /? as the command line (they are extensive, which is great for batch files and front-ends, thank you Avery).

[Faicuai]

Bug-alert:

 

Not sure if already reported but AltirraOS (3.34) system-wide-crashes during SIO-access (reads) when used in combination of SDX's own SIO High-speed drivers (assumes /A option in SDX config.sys to such purpose). I tested this with NUXX SDrive. Trying other Divisor-based speeds seem of no effect.

 

This issue is fully mitigated by simply changing the OS to an Atari-based load, for instance, OR, resorting to PC-based SIO with SDX's PCLINK drivers.

 

There seems to be a deeper timing problem, of some sort.

[Teapot]

I'm writing a program that has a GR.8 display that toggles the text window on and off while keeping the bitmap.

 

In ATOS 3.37 (4.20-test14) the default colors flash before my code can set them again. This doesn't happen in several Atari OSes I tried.

 

The code I'm working on is assembler and is just sequentially calling CIO with Close and Open and then setting the shadow registers. So it's about as fast as it can be setting the color after the return.

 

Here's some basic code that demonstrates the difference:

10 OPEN #1,12,0,"K:"
20 GRAPHICS 8+32
30 SETCOLOR 2,0,0
40 ? "*"
50 GET #1,A
60 GRAPHICS 24+32
70 SETCOLOR 2,0,0
80 GET #1,A
90 GOTO 20

 

Unintentionally this also shows differing behavior in the text window.

 

As is there will be a column of forgotten cursors alongside the *s in ATOS.

 

If you add a semicolon to the print statement Atari OSes will print a growing horizontal chain where ATOS will only have a single asterisk with a toggling cursor next to it.

[+Larry]

I need help with the XEP-80 in Altirra (4.10). 

 

As I understand it, a real XEP-80 has two roms: the 2364 OS rom, and a 2764 character rom.  But Altirra evidently has the character rom fixed, so all that must be added for firmware is the OS rom.  When I try to add Mytek's OS rom, the Altirra firmware manager tells me that I need to set the type, but when I scroll through the available options, the XEP-80 isn't on the list.  What am I doing wrong? 

[phaeron]

22 minutes ago, Larry said:

I need help with the XEP-80 in Altirra (4.10). 

 

As I understand it, a real XEP-80 has two roms: the 2364 OS rom, and a 2764 character rom.  But Altirra evidently has the character rom fixed, so all that must be added for firmware is the OS rom.  When I try to add Mytek's OS rom, the Altirra firmware manager tells me that I need to set the type, but when I scroll through the available options, the XEP-80 isn't on the list.  What am I doing wrong? 

Altirra only supports high-level emulation of the XEP80 -- you can't run the actual NS405 firmware code on it.

[+Larry]

Thanks, got it working.  I missed the "View" setting toggle.  That XEP80 display is impressive!

[phaeron]

On 6/3/2023 at 2:40 PM, scotty said:

Avery, Is there a way to clear the OS and Basic used if you temporarily change it during an experiment?  In other words....  How do I get rid of this:

and get it to go back to the default (like this)??

No, this is kind of an awkward initial-only state that I haven't gotten around to resolving.

 

The blank entries appear when the OS or BASIC are set to invalid, which causes the emulator to auto-select a default. The heuristics for this aren't very sophisticated and currently this is just a bootstrap condition. Problem is, having an Auto or Default here becomes extra confusing with the Firmware Manager, where the Set as Default doesn't do anything for OS or BASIC firmware. I should probably just make the emulator default back to one of the existing firmwares.

 

On 6/4/2023 at 8:00 PM, Faicuai said:

Not sure if already reported but AltirraOS (3.34) system-wide-crashes during SIO-access (reads) when used in combination of SDX's own SIO High-speed drivers (assumes /A option in SDX config.sys to such purpose). I tested this with NUXX SDrive. Trying other Divisor-based speeds seem of no effect.

This issue is fully mitigated by simply changing the OS to an Atari-based load, for instance, OR, resorting to PC-based SIO with SDX's PCLINK drivers.

There seems to be a deeper timing problem, of some sort.

I'm confused about the configuration you're using here. DEVICE SIO.SYS /A or MAP /A causes SDX to fall back to SIOV through the OS, which will not give you high-speed operation because AltirraOS doesn't support high speed. It will only do standard 19200 baud. Can you clarify the details of this configuration?

 

20 hours ago, Teapot said:

I'm writing a program that has a GR.8 display that toggles the text window on and off while keeping the bitmap.

 

In ATOS 3.37 (4.20-test14) the default colors flash before my code can set them again. This doesn't happen in several Atari OSes I tried.

 

The code I'm working on is assembler and is just sequentially calling CIO with Close and Open and then setting the shadow registers. So it's about as fast as it can be setting the color after the return.

So, this is kind of a complicated one.

 

The reason that you're seeing this flash with AltirraOS is that I put in an explicit loop to ensure that a VBI passes before the OPEN exits, to ensure that the screen appears:

	;wait for screen to establish (necessary for Timewise splash screen to render)
	lda		rtclok+2
	cmp:req	rtclok+2

 

The issue with the referenced application Timewise is that it immediately begins loading from the disk after switching screens. SIO turns on CRITIC to suppress VBI stage 2 while it is on, which in turn prevents SDMCTL from being copied to DMACTL to activate the screen created through S:. Thus, Timewise has a dependency on the S: open finishing within the right time window for VBI stage 2 to execute at least once before the disk load occurs so the screen takes effect. However, your program is the opposite, you are assuming it's with different timing so that you can intercept and reset the playfield colors back before VBI stage 2 turns on playfield DMA to show the PF2 color. Even if the Timewise issue no longer recurs I'm not sure this is a battle I can win in all cases, since it depends on the specific timing of the S: open routine. That is never going to match exactly between the Atari OS and AltirraOS and setting up the larger displays can take longer than a frame.

 

I can't say what you're doing is wrong, really, because it's a timing dependency, but I can say that even with the Atari OS it's probably not 100% guaranteed that the timing you have will work depending on the specific OS version and hardware configuration, though with assembly language you can get the timing vulnerability window much smaller than with BASIC. Setting CRITIC around the open call might work to suppress stage 2 VBI until you're ready.

 

20 hours ago, Teapot said:

As is there will be a column of forgotten cursors alongside the *s in ATOS.

 

If you add a semicolon to the print statement Atari OSes will print a growing horizontal chain where ATOS will only have a single asterisk with a toggling cursor next to it.

I'll look at this separately, it's probably due to some cursor state (not) getting reset appropriately for the bit 5 mode case. The split screen window is weird in a lot of ways.

 

[Faicuai]

14 minutes ago, phaeron said:

I'm confused about the configuration you're using here. DEVICE SIO.SYS /A or MAP /A causes SDX to fall back to SIOV through the OS, which will not give you high-speed operation because AltirraOS doesn't support high speed. It will only do standard 19200 baud. Can you clarify the details of this configuration?

Sure, it is confusing because I mixed settings from a different test scenario.  Here is the config. and SDX files:

 

  

 

Above is from real HW (both A800/Incognito and A800 reference with Side-2, running Altirra OS 3.34)

 

Media is attached-SIO drive (can be SDrive or PC-based), on any divisor <=7 (what I tested), as long as PCLInk is not used, since that is inmune to the problem.

 

Operations like multiple file-copies, CLX or even a simple System Info. 2.24 or 2.26 HD test (assuming a 16MB .ATR SDX-formatted image on Sdrive) will fail and lock-up the host.

 

Let me know anything else you need for me to do here.

[phaeron]

1 hour ago, Faicuai said:

Sure, it is confusing because I mixed settings from a different test scenario.  Here is the config. and SDX files:

 

Above is from real HW (both A800/Incognito and A800 reference with Side-2, running Altirra OS 3.34)

 

Media is attached-SIO drive (can be SDrive or PC-based), on any divisor <=7 (what I tested), as long as PCLInk is not used, since that is inmune to the problem.

 

Operations like multiple file-copies, CLX or even a simple System Info. 2.24 or 2.26 HD test (assuming a 16MB .ATR SDX-formatted image on Sdrive) will fail and lock-up the host.

 

Let me know anything else you need for me to do here.

Hmm... this is a bit of a weird case because SpartaDOS X bypasses the OS ROM almost entirely for its high-speed I/O -- there's very little influence that the OS has on such transfers.

 

A couple of things stand out. First, you have a newer dated version of SDX 4.49g than I can find anywhere, though that could be that the timestamp came from when someone built the custom cartridge image and not when the kernel was compiled. Second, that divisor range just happens to be at the threshold under which SpartaDOS X disables the NMI because the transfer is too fast to allow for it. That's suspicious, as when the NMI is disabled it also isn't possible for the high-speed transfer to time out.

 

Can you try a couple of tests:

• Can you try booting with OPTION to force vanilla CONFIG.SYS and check if the SIO high-speed issue persists without the extra drivers loaded?
• Are you able to Break out of the hung transfer?
• Run the command SIOSET NMI 16 and see if that causes divisors 8-15 to fail as well.

 

Update: Still can't explain everything, but latest 4.49g betas seem to have the NMI disable code broken, they leave NMIs enabled by default regardless of divisor.

Edited June 6, 2023 by phaeron

[Teapot]

1 hour ago, phaeron said:

I can't say what you're doing is wrong, really, because it's a timing dependency, but I can say that even with the Atari OS it's probably not 100% guaranteed that the timing you have will work depending on the specific OS version and hardware configuration, though with assembly language you can get the timing vulnerability window much smaller than with BASIC. Setting CRITIC around the open call might work to suppress stage 2 VBI until you're ready.

 

I put a tracepoint where I set the colors after the open and had it print VCOUNT.

 

           GR.8  GR.8+32 GR.8+16+32
800XLv3     96      63      55
1200XL      95      63      55
OSB         103     65      57

 

These numbers were consistent across many (dozens) mode switches. It looks like they're doing some kind of syncing with VBlank.

[phaeron]

14 minutes ago, Teapot said:

I put a tracepoint where I set the colors after the open and had it print VCOUNT.

 

           GR.8  GR.8+32 GR.8+16+32
800XLv3     96      63      55
1200XL      95      63      55
OSB         103     65      57

 

These numbers were consistent across many (dozens) mode switches. It looks like they're doing some kind of syncing with VBlank.

Yes, the S: open does sync against the VBI, but there's quite a lot of code that runs after it -- so the exit timing will depend on what modes you pick, whether the immediate or deferred VBIs have been hooked, how fast the OS VBI and CIO routines are, whether S: has been hooked, etc.

 

[drac030]

2 hours ago, phaeron said:

latest 4.49g betas seem to have the NMI disable code broken, they leave NMIs enabled by default regardless of divisor

The NMI code is not "broken", it is simply disabled.

[phaeron]

8 hours ago, drac030 said:

The NMI code is not "broken", it is simply disabled.

Very well, it was hard to tell otherwise since this behavior was documented and the SIOSET NMI command still works. But if that's the case, then is the transfer routine faster or has the range of supported SIO divisors on stock hardware changed? It takes around 170 cycles for the the VBI in OSRAM mode, which is a large amount of the byte time for the cases that SDX originally disabled the NMI (<divisor 8).