Altirra 4.10 released

[Teapot]

2 hours ago, phaeron said:

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.

 

I don't have to do a manual reset. Just exiting the debugger causes a reset and image load.

 

I don't know if the immediate response or the delayed response seems more "correct." I only used Boot Image for a long time so the different behavior of Cold Reset surprised me. Doesn't matter though, as long as it's just a UI glitch and not doing something like spawning another debugger object.

 

2 hours ago, phaeron said:

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.

If I really need to adjust values while a program is running I'll just 'eb' them in. My current project has a couple of init segments that load into a reserved file data section of memory so they don't take up real space when they're done.  Reloading those would be bad. It's easy enough to start over from a fresh load.

[Teapot]

I found another crash:

 

Closing the Help->Change Log window. Via the [OK] button or the window close button or ESC.

 

Exception code: C0000005 PC: 7AC26EA0

 

[woj]

9 hours ago, phaeron said:

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.

I knew about the modern TVs, however, the rest opened a huge can of worms, I indeed "optimized out" too much of Rybags original code, so I sat down to fixing it. I now sort of got it back to where it is supposed to be, I get interlaced mode in Altirra and everything seems to be working again, but there is defo something wrong, because I lost keyboard auto-repeat in the meantime, so there is some IRQ interaction now that I need to dive into  Anyhow, may thanks!!!

[serj]

Hi Phaeron, can I ask for one small change to the emulator?

please add a combination of buttons for quick save and quick load.

for example Alt+W and Alt+X keys.

[+DjayBee]

7 minutes ago, serj said:

Hi Phaeron, can I ask for one small change to the emulator?

please add a combination of buttons for quick save and quick load.

for example Alt+W and Alt+X keys.

Tools -> Keyboard Shortcuts...

 

[kenp]

Gonna ask one of my silly questions in gathering info for a future attempt to get an emulator working (and the real hardware again as well.)

 

From what I've scanned, can't say properly read, just keeping afloat here, it looks like the Altirra emulator has an associated FujiNET emulator that would allow the Altirra to connect to FujiNET resources like software archives out on the net.  If that's not so then tell me and ignore the following question.  Can you run a TNFS server on the same machine as the Altirra and FujiNET emulations, keeping it all in one box, as it were?

 

 

[+DrVenkman]

21 hours ago, kenp said:

From what I've scanned, can't say properly read, just keeping afloat here, it looks like the Altirra emulator has an associated FujiNET emulator

It does? I don't see that in the supported serial device list. I think emulating FujiNet would require a full ESP32 emulator inside Altirra in order to run the FujiNet firmware, and I don't think that's something that's feasible. Happy to be wrong on this though. 

[+Stephen]

I think there is a FujinetPC - perhaps this is what kenp was referring to?  I can't say - while I do have a FujiNet, I have not attempted to emulate it or run anything on the PC.

[_The Doctor__]

FujiNetPC has a bridge to Altirra

[Faicuai]

On 6/19/2023 at 10:48 PM, phaeron said:

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.

Been silent here, on a deep-dive testing this.

 

Also tested thoroughly with Fujinet v1.7, set at divisor=1 (on my reference 800), reading from its on-board MicroSD storage (for maximum speed). This was (in fact) one of the key reasons for trying to have this resolved.

 

I threw at it every other wrench I had, so far. It works flawlessly.

 

A BIG thanks!! 🤙💪

Edited June 23, 2023 by Faicuai

[kenp]

On 6/21/2023 at 6:55 PM, _The Doctor__ said:

FujiNetPC has a bridge to Altirra

That may be what I was thinking of.  I'll look closer hoping that it gives the Altirra emulator the access to the net as the FujiNET does for the real Atari hardware..

[woj]

On 6/20/2023 at 4:48 AM, phaeron said:

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.

 

So my question is - should this be the even or the odd field? Asking, because, after getting my interlaced code fixed, my game with its odd/even sequencing adjusted to Altirra displays OK in the emulator, it consistently starts flipped on the real hardware connected to an LCD screen. At this point it could be "my" issue, but then Rybag's 480i Falcon Millenium VBXE demo consistently starts flipped on Altirra and consistently correct on my hardware.

 

If I look at my Altirra correctly behaving sequencing the frame displayed after the vblank interrupt routine when DMA is manipulated is the odd one. Confusingly, this seems to be conceptually correct, but then why on Earth I get problems with the swapped fields as described above...?  

[phaeron]

On 6/26/2023 at 8:29 AM, woj said:

 

So my question is - should this be the even or the odd field? Asking, because, after getting my interlaced code fixed, my game with its odd/even sequencing adjusted to Altirra displays OK in the emulator, it consistently starts flipped on the real hardware connected to an LCD screen. At this point it could be "my" issue, but then Rybag's 480i Falcon Millenium VBXE demo consistently starts flipped on Altirra and consistently correct on my hardware.

 

If I look at my Altirra correctly behaving sequencing the frame displayed after the vblank interrupt routine when DMA is manipulated is the odd one. Confusingly, this seems to be conceptually correct, but then why on Earth I get problems with the swapped fields as described above...?  

This is a complicated question to answer.

 

To start with, I can confirm that Altirra currently has the polarity detection inverted compared to previous versions. The catalyst for this issue was when I moved the frame boundary from line 0 to line 248 in 3.90 to improve input latency; this had the side effect of delaying the effect of the polarity detection by one frame as well. I'll get that fixed up... but what to fix it up to is a different question, and that requires some explanation of what's actually going on here.

 

The core of this trick is a bug in ANTIC when the frame ends with a hires mode line on line 247 -- specifically, when vertical blank is entered with the display list Instruction Register (IR) holding mode 2, 3, or F. These modes affect the encoding logic for the AN0-AN2 signals between GTIA and ANTIC because in hires modes, the AN2 signal is driven high for the entire playfield instead of only for a non-zero pixel. The bug is that ANTIC only suppresses this during horizontal blank and not vertical blank. When the playfield is enabled in DMACTL, this has two significant effects:

• It can suppress the vertical sync on lines 251-253 by forcing the ANx code in the visible region from %001 (vsync) to %101 (playfield 1/2). For this reason, if you try doing just a full 240 line hires screen with just the display list, you'll lose the display because vertical sync will disappear.
• It can break up the blanking intervals on the other lines in vertical blank, which has an interesting effect: it can reset the horizontal counter within GTIA, and thus force extra horizontal sync pulses.

As Rybags discovered, this can be used to trick some displays into rendering interlaced. However, to see why this doesn't always work, it's necessary to check the result under a scope:

 

The top and bottom signals are the two fields, and the three low pulses are the vertical sync on lines 251-253. Notice that Memopad 480i's effect is actually after the sync. What it does is toggle the playfield on and then back off several times during lines 255-257. The effect of this is to flip the ANx encoding from horizontal blank to playfield and back -- thus resetting GTIA's horizontal counter and forcing it to re-emit horizontal sync. There's also color burst after each sync, which I think is not supposed to be emitted in vertical blank, but just a minor transgression of GTIA.

 

The issue is what these pulses mean. They're meant to simulate some of the equalizing pulses that normally appear in an interlaced video signal. But those aren't really the core of how interlacing originally worked. The way it originally worked is that in an old CRT, the vertical sync being offset by half a line on every other field also caused the vertical scan to be offset by a half a line for that field, because of the shift between horizontal and vertical timing and the way the CRT beam scan worked. That doesn't happen here as the vsync is unchanged, and presumably this is the reason that on a Commodore 1702 it doesn't work. However, more modern displays, both CRT and LCD, have much more sophisticated scanning and video processing and need to actually detect whether the video is interlaced and the field polarity. They instead analyze the sync pattern in vertical blank, and that is what this trick is able to trick into triggering interlace with definitive polarity. But the rules for doing this aren't well defined, and I'm actually surprised that putting in post-equalizing pulses like this works given that some references suggest that good sync separators don't need the equalizing pulses at all.

 

Altirra's detection logic for this is very simple, it looks for any trickery with hires and DMACTL[0:1] within 6 lines of vsync and certain horizontal bounds, and detects that presence or absence as the two polarities. That's not really right, as such accesses could produce fields of either polarity. The right rules for this, though, are not well defined; they certainly wouldn't be defined in the NTSC standard due to the non-standard nature of the signal, and no doubt differ between displays.

 

The more interesting question is whether this trick can be evolved to produce an interlaced signal closer to broadcast standard. It isn't possible to extend or move vsync, since that's hardcoded in ANTIC on those three lines with no known bug to change it. But it is possible to shorten the vsync, and also to add pre-equalizing pulses as well. It would take a lot of CPU time, but could produce a more stable and reliable output.

[woj]

2 hours ago, phaeron said:

This is a complicated question to answer.

 

...

I would like to say "I see" with full confidence, but I have to admit I can only partly say that. For me as a programmer it has the following conclusions: (a) the reference behavior and field initialization for my code should be real hardware, (b) I should get a CRT screen that would work with this to be double sure and have proper test bed, (c) the program might not (and will not) work correct on all displays, some will not deal with it all, some will need to have the fields swapped anyhow.

 

This is definitely some shaky ground - I was testing the game inside-out over the last few days, I keep discovering some bugs. One of the things I saw (but this is more of a feature I have to accept I guess) - during score saving on the score list screen I temporarily bail out of the vblank interlace code upon checking critic==1 (otherwise SIO does not work due to too heavy VBI routine). This works fine (though not tested with all HSIO speeds), however, during this time, the display on my LCD first shakes a tiny bit, and then gets shifted (down IIRC) by one scan line, to revert back to "normal" when the interlace code in the VBI resumes. So clearly, the LCD display gets confused about those pulses being in the right places. On yet another hand, my display seems to have occasional syncing issues with my VBXE in some other situations too (predominantly right after power up), might be something on the side in my hardware too...

[+gnusto]

@phaeron interesting issue, may not be considered a bug:

On 4.20-test15, When booting the a8preservation society image of "Alptraum" ( Alptraum (1987)(R&E Software)(DE)[disk].zip is the file), even if I turn everything to safest timing mode via command line, if I hold down F1 to warp through the load, it fails. If I don't touch it and let it load at full original speed, it works. This is an ATX disk so may have its protection in place, and may be timing the load as a result, but I thought F1 would move everything forward consistently?
 

Here is my command line:

/tempprofile /pal /artifact:none /hardware:800xl /kernel:xl /memsize:64K /nobasic /noburstio /nosiopatch /accuratedisk

 

Granted you may not consider this a bug, but thought I would supply. It's 100% reproducible, hold down F1 and it freezes past the title screen, hands off it takes a long time but loads into the game proper. Interestingly if I turn convenience time savers on with /burstio /siopatch /noaccuratedisk, it then loads properly.

[phaeron]

3 hours ago, gnusto said:

@phaeron interesting issue, may not be considered a bug:

On 4.20-test15, When booting the a8preservation society image of "Alptraum" ( Alptraum (1987)(R&E Software)(DE)[disk].zip is the file), even if I turn everything to safest timing mode via command line, if I hold down F1 to warp through the load, it fails. If I don't touch it and let it load at full original speed, it works. This is an ATX disk so may have its protection in place, and may be timing the load as a result, but I thought F1 would move everything forward consistently?
 

Here is my command line:

/tempprofile /pal /artifact:none /hardware:800xl /kernel:xl /memsize:64K /nobasic /noburstio /nosiopatch /accuratedisk

 

Granted you may not consider this a bug, but thought I would supply. It's 100% reproducible, hold down F1 and it freezes past the title screen, hands off it takes a long time but loads into the game proper. Interestingly if I turn convenience time savers on with /burstio /siopatch /noaccuratedisk, it then loads properly.

Altirra is supposed to be deterministic regardless of warp, yes.

 

I'm not able to reproduce this. I can get it to fail, but independently of whether warp speed is used or not. The problem is that the game uses a pair of DLIs very close to each other that are too long, making the disk load sensitive to the disk drive timing. In particular, if this pair of DLIs hits shortly after the Complete byte, and the disk drive doesn't have a delay between C/E and the first data byte, it breaks the SIO load and the data frame receive later times out:

 

 

Due to a bug in the OS, this also corrupts the OS variables and prevents the device retry that would normally occur (the receive handler overruns the C/E buffer). SIOV returns Y=$01 despite the timeout, and the game load crashes.

 

The reason for the variation is that by default, Altirra randomizes the starting rotational position of each disk at startup. This is controlled by the randomization seed. Can you check whether you are seeing different seeds appear in System > Configure System > Computer > Boot > Randomization? It should be different every time you start the emulator and after each cold reset. Also, try fixing the seed to a specific value and see if you're still seeing the different behavior.

 

[+gnusto]

13 minutes ago, phaeron said:

Can you check whether you are seeing different seeds appear in System > Configure System > Computer > Boot > Randomization?

Interesting. Yes, I do get random seeds per-run in the above (by design obviously). It appears I may have just had an usual run of randoms here? I got the same result 5+ times in testing before, but I do see it's variable now with my runs. That means the state of siopatch etc is likely a red herring.

978712610 is a seed that will always lock on my set up, if that's helpful. Probably not though since this seems to be a case where it would occasionally lock up on real hardware. I lack the motivation for tonight to try it on real hardware 10 times in a row, but I'll get around to it!

It took me an embarrassing number of attempts until I realized the "Use Specific Seed" button was a toggle instead of an indicator to use the seed I had just entered (I kept pasting it in several times). Never underestimate user error!

[phaeron]

3 minutes ago, gnusto said:

Interesting. Yes, I do get random seeds per-run in the above (by design obviously). It appears I may have just had an usual run of randoms here? I got the same result 5+ times in testing before, but I do see it's variable now with my runs. That means the state of siopatch etc is likely a red herring.

978712610 is a seed that will always lock on my set up, if that's helpful. Probably not though since this seems to be a case where it would occasionally lock up on real hardware. I lack the motivation for tonight to try it on real hardware 10 times in a row, but I'll get around to it!

It took me an embarrassing number of attempts until I realized the "Use Specific Seed" button was a toggle instead of an indicator to use the seed I had just entered (I kept pasting it in several times). Never underestimate user error!

Yeah, that UI's a bit awkward, could use another pass. Maybe I'll rename that to "Apply".

 

It does depend on the disk drive, and it looks like the 1050 does have a little bit of delay in between that could influence chances of success. Altirra's default "Generic" profile is a bit of a mutt -- it's largely based on 810 timings, but that can be a bit odd when booting enhanced density disks. But in any case, to the extent that this game does reliably boot on real hardware, it's pretty close to the edge timing-wise.

 

[+gnusto]

Seed/Random Toggle maybe? Such an esoteric thing though, not much worry.

Also, I'd be remiss to not point out how awesome it is that Altirra can be used to debug the super close to the edge timing required to make this happen in the first place. It's really without parallel in the field of emulation on accuracy, thanks for all of your continued efforts in supplying it!

[phaeron]

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

• Revised recently added MDDOS and JRC cartridge types, and added reset button to JRC carts.
• Fixed all cartridges having a cartridge switch instead of just the COS32K type.
• Fixed inverted field polarity detection in interlace mode and improved auto-flipping behavior when no explicit interlacing is detected.
• AltirraOS 3.39: Fixed S: to ignore the no-clear bit in mode 0.
• Fixed virtual FAT32 device limiting the image to 64K clusters, which only applies to FAT16.
• Added compare memory (c) command to debugger.

[scotty]

7 minutes ago, phaeron said:

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

• Revised recently added MDDOS and JRC cartridge types, and added reset button to JRC carts.
• Fixed all cartridges having a cartridge switch instead of just the COS32K type.
• Fixed inverted field polarity detection in interlace mode and improved auto-flipping behavior when no explicit interlacing is detected.
• AltirraOS 3.39: Fixed S: to ignore the no-clear bit in mode 0.
• Fixed virtual FAT32 device limiting the image to 64K clusters, which only applies to FAT16.
• Added compare memory (c) command to debugger.

No idea how you keep improving perfection, but some how, you do!  Thanks!

 

[+DjayBee]

46 minutes ago, scotty said:

No idea how you keep improving perfection, but some how, you do!  Thanks!

 

Particularly in regularly finding imperfection in perfection.

[phaeron]

It's easy to find stuff to fix when you break stuff... need more tests.

[spicyjack]

On 6/3/2023 at 1:44 PM, phaeron said:

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

• Fixed IDE+2 1.9 BIOS not detecting CF card.

I finally got a chance to check if things are working for me now with newer versions of the IDE+2 ROM, version 1.8 worked with no issues with 4.20-test15, and version 1.9 worked after I upgraded version 1.8 in to IDE+2 from the ATR image and then re-dumping the ROM file using the File -> Save Firmware option in Altirra.

 

I'll upgrade to -test16 in a bit.

 

Thanks again!

 

$ crc32 ideplus-bios-1.9.2023-0*
4cee2fdf	ideplus-bios-1.9.2023-05-29.rom
77a9bcf1	ideplus-bios-1.9.2023-07-01.rom

$ md5 ideplus-bios-1.9.2023-0*
MD5 (ideplus-bios-1.9.2023-05-29.rom) = a63254ef4e1e9c9984252c96b28f0b65
MD5 (ideplus-bios-1.9.2023-07-01.rom) = 003af00241846b04b662529162c25d9b

 

[spicyjack]

3 minutes ago, spicyjack said:

I finally got a chance to check if things are working for me now with newer versions of the IDE+2 ROM, version 1.8 worked with no issues with 4.20-test15, and version 1.9 worked after I upgraded version 1.8 in to IDE+2 from the ATR image and then re-dumping the ROM file using the File -> Save Firmware option in Altirra.

It looks like this was PEBCAK, I'm looking at a diff of the hexdumps of both files, and it looks like I dumped the SIDE3 ROM instead of the IDE+2 ROM using "Save Firmware" in Altirra.