Altirra 4.10 released

[Faicuai]

10 hours ago, phaeron said:

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.

 

Ok, trying my best here to conduct a coherent and repetitive test (even for everyone). In short, the setup is:

 

1. Actual HW (a reference 800 and an 800 / Incognito in Colleen mode), both running AltOS 3.34,  RAM config set for SDX, both at 52K and AXLON enabled).
2. SIO devices can be SDrive (NUXX in my case) or PC-based (RespeQt, etc.) set at DIVISOR 3, to be consistent. Direct SIO cable, or via SIO active-hub (for optimal SIO speeds).
3. Target media is a BLANK 16MB .ATR image, attached as D2: (could be any D1-D4 drive, though).
4. SDX can be booted WITH or WITHOUT pressing OPTION console-key. Does not matter. NO other drivers loaded other than those shown in my previous screen captures.
5. Target SW is SYSTEM INFORMATION 2.26, set to DMA=OFF and disk access to DOS (not OS). Actual test in SI 2.26 is "HD speed / benchmark", on drive "B" once polling ends.
6. SYMPTOMS and mitigation:

• systems hangs at a RANDOM stage of HD benchmark test, as shown in progress bars.
• BREAK key is IRRESPONSIVE, and lock-up is IRRECOVERABLE on reference-800, as even console RESET key is non-responsive there.
• OTHER operations will fail in a similar fashion, such as multiple files copying, CLX operation, etc.
• problem disappears when switching to Atari-base OS load or using PCLink drivers.

 

Here's how crash looks. first on Reference 800:

 

 

And here is with Incognito:

 

 

Have not yet tested SIOSET with NMI parameter, but this is a start for trying to reproduce this very strange problem that seems more of a timing issue lurking deeper, somewhere.

[drac030]

1 hour ago, phaeron said:

the SIOSET NMI command still works

I think it has been gone as of 4.49e, the SIOSET command assembled 28 November 2020 already does not support it.

1 hour ago, phaeron said:

is the transfer routine faster or has the range of supported SIO divisors on stock hardware changed?

Yes and yes. The lowest supported divisor is now 1. Theoretically, because in practice I get stable transfers at 2.

 

Such stuff is written in the release notes each time (whatsnew.txt).

 

1 hour ago, phaeron said:

It takes around 170 cycles for the the VBI in OSRAM mode

Yes, therefore the SIO driver installs own NMI handler for the transfer time.

[Teapot]

ATOS 3.37

 

I can't type an inverted vertical bar ($7C). It prints uninverted.

 

[phaeron]

So, I was on the right track with regard to the high-speed disk I/O hang, but the conclusion was unexpected.

 

The issue is actually a bug in the AltirraOS SETVBV routine regarding specific timing around the VBI. The reason it manifests here because the new SDX toggles the VBI immediate vector with SETVBV instead of toggling NMIEN, and this only happens for divisors that are low enough. With just the right timing, this results in the VBI being invoked with a corrupt VVBLKI vector and thus a crash. So it is definitely triggered by the changes in the new SDX and the high-speed divisor, but ultimately the SETVBV routine needs a fix.

 

I have ideas about fixing this but will have to wait until I can set up a framework to re-test exact cycle timings. The original idea was to have SETVBV be robust against weird combinations of DLIs and high-DMA modes on scan line 247, but it's not clear whether this is possible and I need to do some exhaustive testing to see how close it can get. The classic "STA NMIEN and wait some delay" is not an approach I feel comfortable with, at least not without some justification for the specific delay.

 

[Faicuai]

1 hour ago, phaeron said:

With just the right timing, this results in the VBI being invoked with a corrupt VVBLKI vector and thus a crash. So it is definitely triggered by the changes in the new SDX and the high-speed divisor, but ultimately the SETVBV routine needs a fix.

Sick !!! ...as soon as I saw how it happened (now-you-see-me-now-you-don't) I knew it was a tough one... especially since the Atari OS-load somehow handles it well...

 

Amazing forensics... like picking up a Boson in the middle of the ocean... 😵‍👍👍💪💪

 

Your effort is very valuable, because I have permanently installed and use AltOS on my Incognito / Colleen and CTIA-800, and plan to do so for the foreseeable future, since it is LOADED with plenty of optimizations under-the-hood (the interrupt-latencies reported on Acid-OS suite are impressive!! 😉💪)

 

Hope you can find some time to fix its SETVBV code. Cheers!!

Edited June 8 by Faicuai

[+Larry]

I'm trying to test some XF551 roms in Altirra, but so far, I can't get anything but 1X SIO.  I'm probably missing something.  I started with the standard XF551 rom supplied under Altirra Full Emulation with a (Hias) patched OS.  IIRC, it should produce 2X SIO ~39Kbs in DSDD mode, but I only get 1X.  Is it possible to change roms on the XF551 in Altirra?

 

BTW, The track/sector counter seems incorrect on the B side while doing a DSDD 360K format.

[phaeron]

3 hours ago, Larry said:

I'm trying to test some XF551 roms in Altirra, but so far, I can't get anything but 1X SIO.  I'm probably missing something.  I started with the standard XF551 rom supplied under Altirra Full Emulation with a (Hias) patched OS.  IIRC, it should produce 2X SIO ~39Kbs in DSDD mode, but I only get 1X.  Is it possible to change roms on the XF551 in Altirra?

 

BTW, The track/sector counter seems incorrect on the B side while doing a DSDD 360K format.

I'm a little confused about which mode you're running in. The standard drive emulator, which has an XF551 mode, doesn't use ROM images as it's high-level emulation. The full drive emulation mode added to the device tree does use ROM images, but there is no stock one supplied; if you don't attach one in the Firmware Manager, the drive will fail to start and be flagged as missing firmware in the device tree.

 

I'm not seeing issues booting either in high speed with the OS patch, but there is one thing to be aware of. Like the US Doubler, the XF551 doesn't have track buffering and is reliant on a high-speed interleave. If you mount a disk that has been formatted with standard interleave, it won't load any faster even though you will be able to hear the high speed transfer. You will see this in Altirra if you have accurate sector timing enabled. The only high-speed interleave that the XF551 can format with is 9:1 double density, it can't format single or enhanced density with high-speed skew. You can reinterleave a disk via the more options button in the drives menu though to try interleaves that the XF551 can't create, though.

 

[+Larry]

  I'll work with it some more.  I added full emulation, then tried a few roms (hyperxf, XFturbo, and the stock rom).  Used Hias' high speed patch for the OS.  Clearly I'm doing something wrong.  I'll find my error.

[+Larry]

I solved my issue, and it was the interleve.  But it leaves me with some new questions:

 

Will Altirra accept custom formats with interleves not found in the "Change Interleve" table or is it locked to the table values?  And I presume that I can change the interleve on an existing image at any time using the alternate table values? 

 

I've been testing XF551 firmware using the HyperXF (5.25") rom.  I believe it should use a the same interleve as the US Doubler, but so far, I cannot get UltraSpeed with this combination. 

[phaeron]

6 hours ago, Larry said:

Will Altirra accept custom formats with interleves not found in the "Change Interleve" table or is it locked to the table values?  And I presume that I can change the interleve on an existing image at any time using the alternate table values? 

Altirra will handle arbitrary interleaves, the Change Interleave table limitation is just to keep UI complexity under control. Under the hood, what's actually tracked are the angular positions of each sector on the track, which is more detailed than just interleave factor. The UI commands for changing the interleave just recompute angular positions for the new interleave factor and then apply them to the existing tracks.

 

The other limitation is persistence. The majority of Atari disk image formats only track decoded data and not sector position. This includes, ATR, XFD, and DCM. This means that interleave patterns cannot be saved with disk images in those formats and the interleave will be reset on load to the default. For a double-density disk, this is 15:1. The only disk format that does store sector positions is ATX.

 

6 hours ago, Larry said:

I've been testing XF551 firmware using the HyperXF (5.25") rom?  I believe it should use a the same interleve as the US Doubler, but so far, I cannot get UltraSpeed with this combination. 

Afraid I don't have experience with HyperXF. Double check against the sound of the disk load and whether SpartaDOS X activates high speed (SIOSET).

[woj]

Hi Avery,

 

You have a bug in the VBXE blitter collision detection code. I was nice enough to locate the bug in your source code, instead of sending you my contrived WIP XEX file. This is the part of the mode 6 overlay collision detection:

if (d) {
    if (c & 0x0f) {
        if ((1 << ((d >> 1) & 7)) & mBlitCollisionMask)
            mBlitCollisionCode = d;
    }

    if (c & 0xf0) {
        if ((1 << ((d >> 5) & 7)) & mBlitCollisionMask)
            mBlitCollisionCode = d;
        }
}

 

Now, the test vector from my application is source c = $EE (or $E0, what matters is the first nibble), the destination d = $0D, and the blit collision mask $03. This returns collision code $0D, while it should be 0. In the second if statement rightfully entered, (d>>5)&7 is 0, so you mask a singleton 1 against the collision mask, that returns 1 and the collision code is set. However, while the destination nibble of $0D is 0, the whole thing should be 0 too.

 

Not sure what to best fix for this is, my initial untested guess is to add "d & 0x??" correspondingly to the if conditions.

 

A small rant I was hunting a bug in my code that was not there for good part of yesterday until I ran the program on my actual VBXE and to my amazement it worked.

 

EDIT: Forgot to say, I wouldn't mind to have it fixed soon, I do not have a Windows build environment (Windows in fact) to compile my own version and this bug is rather blocking  

Edited June 13 by woj

[woj]

Update: after many hurdles setting up VS2022 and Altirra sources on my space lacking Virtual Win10 I did manage to compile it with the fix proposed above and it seems to work. A note to whoever may want to attempt to build Altirra from sources, with the most recent VS it is necessary to change:

 

<LanguageStandard>stdcpplatest</LanguageStandard>

 

to 

 

<LanguageStandard>stdcpp20</LanguageStandard>

 

in Altirra.props for the build not to shit itself badly  Fix courtesy of StackOverflow here (was not an immediate find either): https://stackoverflow.com/questions/76296911/precompiled-header-errors-in-visual-studio-2022-version-17-6   

[ggn]

1 hour ago, woj said:

Update: after many hurdles setting up VS2022 and Altirra sources on my space lacking Virtual Win10 I did manage to compile it with the fix proposed above and it seems to work. A note to whoever may want to attempt to build Altirra from sources, with the most recent VS it is necessary to change:

 

<LanguageStandard>stdcpplatest</LanguageStandard>

 

to 

 

<LanguageStandard>stdcpp20</LanguageStandard>

 

in Altirra.props for the build not to shit itself badly  Fix courtesy of StackOverflow here (was not an immediate find either): https://stackoverflow.com/questions/76296911/precompiled-header-errors-in-visual-studio-2022-version-17-6   

Definitely not the case on a Native Win10 setup: Just download the source archive, put mads.exe somewhere in your PATH (I used c:\windows because why not), build "release x86" and after 57 seconds I had a binary. EZ.

Props to @phaeron of course, building Altirra used to be a tad more involved because of the external dependencies required, now it's much more streamlined for everyone. (especially since I was looking at the output window and saw what was being built - which is pretty much everything including the kitchen sink).

[phaeron]

It does occur on native Windows 10, you just need the latest version of VS2022. For some reason, they decided to release 17.6 and 17.7 preview with a major bug, which is that std modules are (a) enabled by default in /std:c++latest and (b) broken with precompiled headers. Precompiled headers are used almost everywhere when building for Windows, they're essential to keeping builds fast.

 

I have a workaround in my tree to force modules off in the main Altirra.props file, I just haven't published a build with it yet.

 

[woj]

4 hours ago, ggn said:

Definitely not the case on a Native Win10 setup: Just download the source archive, put mads.exe somewhere in your PATH (I used c:\windows because why not), build "release x86" and after 57 seconds I had a binary. EZ.

Trust me, it's not the first time that I am doing this, and there is no difference here between native / virtual whatsoever. My only handicap here is that this Win10 installation of mine is an unwanted necessity (needed it bad for something else), unmaintained, and with very little disk space (and the amount of it eaten by VS just smashed me down). 

 

Anyhow, I suspect there is one more blitter mode 6 related bug, but need to confirm first. 

 

EDIT: Yes, there is another bug, in the same piece of code, when writing the c byte to the destination address. This write should also be done on nibble basis, to maintain correct half byte VBXE highres pixel transparency handling. In Altirra, the visual effect is that there is a black shadow around overwritten objects (when source data is $0X or $X0), see the picture, while on the actual hardware there is a monolithic color in this case. I don't have a direct fix for this (the c byte has to be transformed correctly), and I also wonder about the handling of the color 15 transparency when the VBXE configuration is set up for that, have not looked into that at all (probably applies both to data copying and collision detection). So sorry Avery for putting things onto your to-do list  For me the collision fix solves all my problems for now.

 

EDIT2: Putting aside color 15 transparency issue, my temporary fix, first after masking 😄

 

c &= mBlitAndMask;
c ^= mBlitXorMask;
uint8 c1 = c & 0x0f;
uint8 c2 = c & 0xf0;

 

Then inside the loop:

 

uint8 d1 = d & 0x0f;
uint8 d2 = d & 0xf0;

if (d1 && c1) {
	if ((1 << ((d >> 1) & 7)) & mBlitCollisionMask)
		mBlitCollisionCode = d;
}

if (d2 && c2) {
	if ((1 << ((d >> 5) & 7)) & mBlitCollisionMask)
		mBlitCollisionCode = d;
}

VBXE_WRITE(dstRowAddr, (c1 ? c1 : d1) | (c2 ? c2 : d2));

 

Visually seems to be doing the right thing  

 

Edited June 14 by woj

[phaeron]

10 hours ago, woj said:

Anyhow, I suspect there is one more blitter mode 6 related bug, but need to confirm first. 

 

EDIT: Yes, there is another bug, in the same piece of code, when writing the c byte to the destination address. This write should also be done on nibble basis, to maintain correct half byte VBXE highres pixel transparency handling. In Altirra, the visual effect is that there is a black shadow around overwritten objects (when source data is $0X or $X0), see the picture, while on the actual hardware there is a monolithic color in this case. I don't have a direct fix for this (the c byte has to be transformed correctly), and I also wonder about the handling of the color 15 transparency when the VBXE configuration is set up for that, have not looked into that at all (probably applies both to data copying and collision detection). So sorry Avery for putting things onto your to-do list  For me the collision fix solves all my problems for now.

 

EDIT2: Putting aside color 15 transparency issue, my temporary fix, first after masking 😄

 

Hey, sorry for late response on this, I hadn't had time to check this in detail and you beat me to it. It looks like there may also be a issue with the multiple collisions being handled in the wrong order, so I'll work on revising this code (think it needs to flag only the first collision and not the last). Hires graphics modes are underutilized in VBXE, so your experiences here are welcome.

 

Do you have any details on the ovtrans15 issue? The docs don't say whether the trans15 bit affects the blitter, though they do confirm that the transparency disable bit (no_trans) doesn't affect the blitter.

[woj]

36 minutes ago, phaeron said:

Do you have any details on the ovtrans15 issue? The docs don't say whether the trans15 bit affects the blitter, though they do confirm that the transparency disable bit (no_trans) doesn't affect the blitter.

 

I will have to check the docs too, what I meant is that I have not seen any code that takes into consideration possible color 15 transparency in blitter mode 6, but then, in all honesty, so far I only know there is an option for color 15 transparency that maintains collision. But you might be right (sure you are in fact), it is possible that color 15 transparency applies only to PF underlay, not the blitter. 

 

Yes, highres and mode 6 are a bit of a freak. What I miss, for example, in the VBXE design, is per-nibble treatment of zoom, pattern, or horizontal mirror with negative x step. Especially the last bit, I had to soft-code this into my game.

 

While we are having this conversation, a feature request, I do know this is probably very difficult - it would be really cool if there was some support for Rybag's interlace hack in Altirra. You could meet us half way, rather than implementing this deep in the ANTIC depths of the emulator, just have a video out option to turn on interlace mode where each scanline is split vertically and you over-paint odd/even lines alternatively. The order / init of this could be irrelevant, as they are actually displays that flip the order too and programs need to have a key-shortcut to pre-flip the odd/even fields. If you need a binary to experiment with I can be of service. 

[Teapot]

4.20-test14

 

1. Atari code is misbehaving.
2. break into the Altirra debugger to see why.
3. Select System->Cold Start menu item.
4. Atari restarts immediately.
5. debugger command line is still enabled.
6. Entering commands has no effect and it stays enabled.
7. Breaking into the debugger (F8) get's things back to normal.

 

Other times I reset broken code via File->Boot Image after correcting and rebuilding it (not in this case because I'm booting into DOS). The image load doesn't happen until I exit the debugger (F8 or 'g').

 

[wildstar87]

I must be missing something here, how do I go about creating a Virtual Hard Disk in Altirra?  According to one thread, that I can't seem to find any longer, there is a menu command under System, Create VHD, which doesn't seem to be there.  I've scoured the help file, and done searches in the forum, mentions of VHD, but I didn't see how to create one.  Trying to setup SIDE3, and can select a directory, but I don't see how to specify size, and I sort of got it working, but it doesn't save anything to the drive.  I'm sure I'm missing something.

 

The other problem that I'm running into, is when I try to format a floppy in Spartados X, as soon as I try to specify Unit#, I was getting an Altirra Error dialog, but now it just hangs, with a graphic line corruption, either way trying to format a floppy didn't seem to work for me.  Any ideas?

       

Edited June 16 by wildstar87

[+CharlieChaplin]

On 6/12/2023 at 2:40 PM, Larry said:

I solved my issue, and it was the interleve.  But it leaves me with some new questions:

 

Will Altirra accept custom formats with interleves not found in the "Change Interleve" table or is it locked to the table values?  And I presume that I can change the interleve on an existing image at any time using the alternate table values? 

 

I've been testing XF551 firmware using the HyperXF (5.25") rom.  I believe it should use a the same interleve as the US Doubler, but so far, I cannot get UltraSpeed with this combination. 

 

Well,

Hyper-XF reacts on most Happy ultraspeed drivers, allthough it does not have a track buffer, but uses sector interleave instead. The Hyper-XF interleave is NOT the same as the one used by US-Doubler or Turbo 1050 however (alas, I do not know what kind of interleave is used, the manual of the Hyper-XF only lists the interleave for normal/slow mode, not for ultraspeed or hyper-xf mode).

 

Example: Using Mycopier! or Mycopier 2.0 with "Ultraspeed skew" set to "on" will give you an Error with Hyper-XF-OS, since it does not use US-Doubler sector skew, pardon, interleave. Set "Ultraspeed skew" to "off" and it will read without problems and then format + use the Hyper-XF interleave when formatting/writing (meaning it writes with ultraspeed or 3x SIO then). Maybe someone can copy such a 5,25" disk with Hyper-XF interleave (90k, 130k, 180k) into an ATR so someone else can examine what interleave is used there...?!?

 

For a good laugh, here is a translation of the german manual of the Hyper-XF OS done with Babelfish around 1999 or 2000 (the translation is really bad and many german words had not been translated at all).

 

EDIT: Attached also the original german manual, one can create a much better translation nowadays with DeepL  (alas, the free use is limited to 3000 words and the manual has more than 31,000 words, so you have to split the text several times)...

 

HYPERDOC.TXT

HYPER_XF_Anleitung.TXT

[scotty]

6 hours ago, wildstar87 said:

I must be missing something here, how do I go about creating a Virtual Hard Disk in Altirra?  According to one thread, that I can't seem to find any longer, there is a menu command under System, Create VHD, which doesn't seem to be there.  I've scoured the help file, and done searches in the forum, mentions of VHD, but I didn't see how to create one.  Trying to setup SIDE3, and can select a directory, but I don't see how to specify size, and I sort of got it working, but it doesn't save anything to the drive.  I'm sure I'm missing something.

 

The other problem that I'm running into, is when I try to format a floppy in Spartados X, as soon as I try to specify Unit#, I was getting an Altirra Error dialog, but now it just hangs, with a graphic line corruption, either way trying to format a floppy didn't seem to work for me.  Any ideas?

       

 

In Altirra, Go into System, then down to Configure System.  Go down to Devices (under Peripherals) and select a device like the MyIDE, MyIDE2, any of the SIDE devices or similar, and then add it.  Then click where it says "no attached device" and click 'add...' from there hard drive, and it should be pretty straight forward from there.

 

Edited June 17 by scotty
added picture

[wildstar87]

2 hours ago, scotty said:

 

In Altirra, Go into System, then down to Configure System.  Go down to Devices (under Peripherals) and select a device like the MyIDE, MyIDE2, any of the SIDE devices or similar, and then add it.  Then click where it says "no attached device" and click 'add...' from there hard drive, and it should be pretty straight forward from there.

 

Thanks, I was trying to use the Virtual hard disks, it doesn't list any of those options.  Probably because I was having issues formatting floppies, so was just using the pre-created SDFS floppies, and those seemed to work (w/o formatting), so I think I had the same mindset on this, and didn't try that option (seems stupid of me now).  I seem to have gotten past the floppy formatting issue, by changing the Default write mode to Read/write, the default is Virtual Read/Write (prohibit format), though I did change that specifically when in Disk Drives, mapping the drive images. 

 

On another note, I've run into a REALLY strange problem, and I know I have done this in the past. I'm trying to setup a 1088XEL system to match the one I physically have, to test stuff out.  I've checked the Enable Ultimate 1MB under memory, and put the XELNOGOS.ROM in as a U1MB Firmware, under the Firmware Manager.  When it boots, I have no keyboard, so I can't change any settings in the "bios".  If I try loading the ULTNOGOS.ROM instead, and reboot the system, the keyboard works in the "bios" settings. 

 

Any ideas why the keyboard would fail using the 1088XEL firmware, and not the U1MB firmware?  It's using the exact same keyboard settings, so it can't be that.

[flashjazzcat]

2 hours ago, wildstar87 said:

Any ideas why the keyboard would fail using the 1088XEL firmware, and not the U1MB firmware?

Enable stereo. Full answer in the firmware thread.

[Teapot]

4.20-test14

 

I'm writing some library functions and just doing simple testing with ##TRACE output.

 

Build a XEX with MADS 2.1.5 generating LST and LAB files.

Load with File->Boot Image

 

When the debugger is not enabled everything is fine. But I can't see the output.

 

When the debugger is enabled the first load/run works. Trying a second load, with or without changing the XEX in between (even removing the trace), will cause a crash.

 

Likewise, if I try to disable the debugger after the first run there is a crash.

 

Exception code: C0000005 PC: 004808FE (ExeBase +000808FE)

 

It all works OK in 3.20 (the only other version I have set up).

[phaeron]

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

• Added build workaround for modules/PCH bug in VS2022 16.6/7preview.
• Added a configvar for the directory length limit in virtual SDFS disks, which is no longer hardcoded at 256 entries.
• Emulation network DHCP server no longer advertises a gateway if the networking mode is set to Host Only.
• Emulation network gateway now responds to ICMP pings.
• Emulation network gateway now has a different local MAC address to reduce the chances of conflicts when bridging to a LAN.
• Fixed VXLAN code sending two extra bytes in Ethernet frames.
• Fixed problem with emulation network HTTP server not shutting down connections properly.
• Emulation network tracing now decodes IPv6 frames.
• Improved emulation TCP stack handling of RST packets.
• AltirraOS 3.38: Fixed vertical bar not being invertible, Ctrl+3 can now be remapped through XL/XE KEYDEF, caught the 65C816 version up on Display Handler fixes, and fixed SETVBV timing issue.
• Accuracy fix for CPU execution timing around writes to WSYNC that cross an NMI, specifically whether the next instruction is executed or not prior to the NMI sequence starting.
• Fixed crash in debugger when clearing directive breakpoints loaded from symbols.
• VBXE: Fixed blitter handling of mode 6 (HR stencil); collision detection now returns the first collision instead of the last; fixed a bug where cycle timing was based on the raw source value instead of the post-AND/XOR value.

On 6/14/2023 at 11:50 PM, woj said:

Yes, highres and mode 6 are a bit of a freak. What I miss, for example, in the VBXE design, is per-nibble treatment of zoom, pattern, or horizontal mirror with negative x step. Especially the last bit, I had to soft-code this into my game.

Yes, the VBXE blitter is missing quite a few features. In this case, you would probably be best off pre-shifting the image Apple II style, selecting between even and odd offsets when blitting. You can generate these on load with the blitter, but it requires emulating a nibble swap with the blitter, which is not that fast (you have to construct a blit list with the blitter to do a table lookup blit per byte). This takes about 3 machine cycles per byte. It can also be done by shifting a bit at a time through masked stencil blits, but I think this takes too many blits to be any faster.

 

On 6/14/2023 at 11:50 PM, woj said:

While we are having this conversation, a feature request, I do know this is probably very difficult - it would be really cool if there was some support for Rybag's interlace hack in Altirra. You could meet us half way, rather than implementing this deep in the ANTIC depths of the emulator, just have a video out option to turn on interlace mode where each scanline is split vertically and you over-paint odd/even lines alternatively. The order / init of this could be irrelevant, as they are actually displays that flip the order too and programs need to have a key-shortcut to pre-flip the odd/even fields. If you need a binary to experiment with I can be of service.

So, Altirra does implement this through the Interlace option in Video, but the latest WIP that you haven't doesn't seem to trigger it. The case that Altirra implements is when hires mode is left on in the display list, which screws up the ANx bus logic such that DMACTL bits 0-1 can perturb AN2 in vertical blank and modify the vertical sync. Your program doesn't seem to do this, it's ending the display list with a JVB instruction which is classified as a lores mode. If you have a version that does trigger hires mode at scan line 247 to do this then I can take a look at why it isn't triggering the even/odd field detection.

 

The specific conditions that Altirra checks for to detect an even field is:

• IR register left in a hires mode when vertical blank begins
• Playfield DMA is toggled on and then off by DMACTL[1:0] during vertical sync.

It's worth noting that some modern TVs will display any video as interlaced including the Atari's non-interlaced output, and in that case you can get interlaced video regardless. Contemporary CRTs don't do this as they actually scan progressive 240p60 or 288p50. However, you can't set or detect the field polarity in that case, which makes it difficult to actually use the increased resolution. Altirra doesn't really support this right now, the logic for it needs a revision.

 

On 6/15/2023 at 4:05 PM, Teapot said:

1. Atari code is misbehaving.
2. break into the Altirra debugger to see why.
3. Select System->Cold Start menu item.
4. Atari restarts immediately.
5. debugger command line is still enabled.
6. Entering commands has no effect and it stays enabled.
7. Breaking into the debugger (F8) get's things back to normal.

This is another long-standing UI issue that I haven't gotten around to correcting -- the simulation core doesn't have a concept of ownership or notifications for suspend/resume, so restarting the emulation outside of the debugger confuses the debugger UI state.

 

On 6/15/2023 at 4:05 PM, Teapot said:

Other times I reset broken code via File->Boot Image after correcting and rebuilding it (not in this case because I'm booting into DOS). The image load doesn't happen until I exit the debugger (F8 or 'g').

It should get picked up on the next cold reset, which is when the program load is set up.

 

You can hot-load code via the .loadobj debugger command, but it's only useful in limited cases when no code has been moved or relocated on load. It simply reloads segments without running the init or run segments, so it works if you just changed a few values inline, but won't work if you've added or removed instructions.