Altirra 4.20 released

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.30-test4.zip
https://www.virtualdub.org/beta/Altirra-4.30-test4-src.7z

• Fix for BRK flags push in 65C816 native mode (attempt 2).
• Debugger register (r) command can now set full 16-bit S register in native mode.
• Fixed STA (zp) instruction being broken only in 65C02 mode.
• Added video deinterlacing option.
• Workaround for empty label in Windows 11 taskbar (which is broken AF).
• Fixed a crash when loading some raw audio tapes.
• Tweaked ATX density detection to prevent false 1050 Duplicator DD detection with ED disks that have only boot sectors on track 0.

The deinterlacer is just a very simple auto-switch between bob and weave for areas of the screen based on a motion mask, no fancy ELA or mocomp. The effect is similar to what you see from some TVs that don't have true support for noninterlaced video and force-interlace the Atari's output.

[Justin Payne]

Looks like I found a small bug. I increased the font size a little bit so I could see more stuff better 😁 and I noticed that none of the memory windows updated. When I clicked on them, that line increased in side. By using the slider, that seems to set it to the new font size but then I noticed this when I clicked on the byte. That's not right. 😆

Setting it back to the default 7.5 resolves that issue but my difficulty seeing the text has now increased. 😊

WISH LIST: When selecting a byte in memory, it would be cool to see the same byte get highlighted on the right pane and vice versa. 

Edited February 5 by Justin Payne

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.30-test5.zip
https://www.virtualdub.org/beta/Altirra-4.30-test5-src.7z

• Added a cvar to apply a one-line vertical offset to the VBXE XDL in NTSC: devices.vbxe.ntsc_vertical_offset. It delays the XDL start from line 8 to line 9. This is disabled by default for now until we get more confirmation in the other thread.
• Fixed LDA (zp) instruction in 65C02 mode only.
• VBXE no longer resets overlay and attribute map addressing on vertical blank.
• Debugger: Added .vbxe_xdlhistory command.
• Debugger: Expanded Ctrl+Alt+click information. It now shows exact byte address at point, current value of that address (best effort), and also shows XDL and attribute map information for VBXE.

 

On 2/4/2024 at 6:10 PM, Justin Payne said:

Looks like I found a small bug. I increased the font size a little bit so I could see more stuff better 😁 and I noticed that none of the memory windows updated. When I clicked on them, that line increased in side. By using the slider, that seems to set it to the new font size but then I noticed this when I clicked on the byte. That's not right. 😆

Setting it back to the default 7.5 resolves that issue but my difficulty seeing the text has now increased. 😊

WISH LIST: When selecting a byte in memory, it would be cool to see the same byte get highlighted on the right pane and vice versa. 

 

This is a bug when the window is undocked, it looks like it isn't getting the font update notification. I'll fix that, but as a workaround you can Ctrl+wheel zoom the window instead.

 

Selection suggestion seems good, I can make the opposite side show the inactive highlight.

 

[ggn]

On 1/24/2024 at 9:37 AM, phaeron said:

Rant about global hotkeys: It seems that almost any program these days feels entitled to commandeer random global keyboard shortcuts without warning, messing up other programs. The hall of shame includes: Macrium Reflect (Ctrl+Alt+M), Alienware Command Center (Ctrl+Shift+Y), and the winner, Intel Arc Control Panel with the ridiculous and unchangeable Alt+I and Alt+O keys. Some of these programs also fail to unregister global hotkeys even if you've disabled them in the UI, which leaves the corresponding key shortcuts simply inexplicably broken. There is also no way built into Windows to tell that this is happening. So now Altirra can tell you if another program is doing this.

While we're at it: shout outs to the Intel Graphics command center that, still to this day, registers ctrl-alt-up/down/left/right to rotate the screen in 90 degree steps. (Common question from people back in the 2000s: "Hey I was playing some games on MAME and now all the letters are sideways. Halp!")

[drac030]

It seems that in IDE+ emulation the emulated ATA controller does not react correctly to the ATA command $40 (READ-VERIFY). When fed with it, it just enters the BUSY state and that is it.

 

To reproduce, run CLX with /SV switches (scan for bad sectors / use Verify sector command).

 

 

When I poke a $40 to the COMMAND register, poking something else there seems to restore normal operation (or at least clears the busy bit). However, as it is on the pic, it hangs irrecoverably and only clicking "Cold reset" in the menu gets it back to normal.

Edited February 6 by drac030

[jenorton]

Hi:

 

I'm just curious about the XEGS experience.

 

I have seen a rom collection called "emuroms.zip" containing a few roms, but, the XEGS rom isn't in there.

 

However, the one that is in the MAME collection is called "c101687.rom".  Some searching reveals that it is all the roms together in 1 32-K file.  To get Altirra to run it, do I need to split it up some way for Altirra to detect and use it?  It doesn't seem to like the full 32-K image.

 

Thanks!

[_The Doctor__]

Firmware manager doesn't accept the XEGS C1011687 as single plugin? Seems odd. But I hadn't tried it yet.

[phaeron]

10 hours ago, drac030 said:

It seems that in IDE+ emulation the emulated ATA controller does not react correctly to the ATA command $40 (READ-VERIFY). When fed with it, it just enters the BUSY state and that is it.

 

To reproduce, run CLX with /SV switches (scan for bad sectors / use Verify sector command).

 

When I poke a $40 to the COMMAND register, poking something else there seems to restore normal operation (or at least clears the busy bit). However, as it is on the pic, it hangs irrecoverably and only clicking "Cold reset" in the menu gets it back to normal.

READ VERIFY is indeed busted, I'll get that fixed up.

 

8 hours ago, jenorton said:

I have seen a rom collection called "emuroms.zip" containing a few roms, but, the XEGS rom isn't in there.

 

However, the one that is in the MAME collection is called "c101687.rom".  Some searching reveals that it is all the roms together in 1 32-K file.  To get Altirra to run it, do I need to split it up some way for Altirra to detect and use it?  It doesn't seem to like the full 32-K image.

The XEGS ROM physically is a single 32K ROM containing the 16K OS + self test and 8K BASIC firmware that was traditionally split into two ROM chips on earlier computers, plus another 8K of ROM for Missile Command. Historically, the XEGS has not gotten a lot of attention for emulation, so it's often just been treated as a variant of an 800XL -- not all emulators support detaching the keyboard, for instance, which inverts the function of some console buttons. For this reason it's actually more common to run into 16K OS-only images of the XEGS v4 OS rather than the full 32K image.

 

The tricky part is that Altirra currently treats the OS and BASIC ROMs as separate, so it's kind of awkward to shovel in combined images into the existing setup. But what I could do is rig the firmware loader so that if a 32K XEGS is bound to the OS/BASIC/game firmware slots, it'll extract out that specific firmware from the pertinent area in the XEGS image.

 

Aside from keyboardless operation support and internal game support, the changes in the XEGS OS are minor and there is negligible difference in normal operation from v3, or even the very common v2 OS. You won't be missing much running with this. If you want to split the ROM image apart yourself -- or assemble a custom combined ROM image -- the order in the image is 8K Missile Command + 8K BASIC + 16K OS.

 

An important gotcha with the XEGS is that the Missile Command in the XEGS is not the same as the Missile Command cartridges. Keyboard input is broken on XL/XE machines with the regular Missile Command cartridge, but the built-in XEGS version is fixed to work with the XL/XE OS.

 

[jenorton]

Hi:

 

Ok, thanks to that explanation, I split it correctly--Altirra's firmware manager  recognizes the first 8K as Missile Command, the second block of 8K as BASIC REV C, and the last 16K as the XEGS kernel.

[jenorton]

Hi:

 

Think I got it now, thanks to the explanation.

 

Altirra's firmware manager now recognizes the first 8K block as Missile Command, the 2nd block of 8K as BASIC Rev C. and the last 16K as the XEGS firmware.

 

Just wanted this for completeness.  After all, as a blind user, I can't do much with any game really--I just wanted to see if I could get the thing to work.  I can get Pacman to a power pill (or whatever they're called) sometimes.

 

Anyway, gonna hit the sack now.

 

Thanks again.

[Yautja]

Hello, good gentlemen

I'm trying to record videos in MP4 with this version...

But, I get this error message:

 

Any idea on how to fix it will be welcomed.

 

- Y - 

[phaeron]

55 minutes ago, Yautja said:

Hello, good gentlemen

I'm trying to record videos in MP4 with this version...

 

But, I get this error message:

 

Any idea on how to fix it will be welcomed.

Why are you running 4.10? This is the 4.20 release thread....

 

The MP3 encoding filter only exists in Windows 8 and above, it's not available in Windows 7. You can try to use AAC, but it may have the same bug as in Windows 10 where it produces oinks in the output (supposedly this is finally fixed in 11). Otherwise you'll need to use another format.

 

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.30-test6.zip
https://www.virtualdub.org/beta/Altirra-4.30-test6-src.7z

• Debugger: Fixed font updates on undocked panes.
• Debugger: Memory window now highlights location in both sections.
• IDE: Fixed Read Verify command.
• Fixed incorrect 5200 floating bus and XEGS internal BASIC settings.

[mirao]

6 minutes ago, phaeron said:

Debugger: Memory window now highlights location in both sections.

That's great. However could you use a more prominent color (e.g. light blue instead of light gray)?

[flashjazzcat]

Yes - this isn't very readable in dark mode either:

[Rockymin]

I have an issue with Altirra 4.20.  I posted a topic in the emulation section but got no replies.  My issue is playing Atari 5200 Star Raiders.  When I push the = key to change to command mode the game just freezes.  Other keypad mapped keys work fine.  The = key also works fine in other games.  I am using the default mappings.  I still had Altirra 4.01 on my laptop, so I started it up and loaded the 5200 Star Raiders game and the = key worked fine on that version.  I was able to switch to command mode and turn on shields and go to the navigation map and all that.

 

Is this a bug in version 4.20?

[phaeron]

6 hours ago, Rockymin said:

I have an issue with Altirra 4.20.  I posted a topic in the emulation section but got no replies.  My issue is playing Atari 5200 Star Raiders.  When I push the = key to change to command mode the game just freezes.  Other keypad mapped keys work fine.  The = key also works fine in other games.  I am using the default mappings.  I still had Altirra 4.01 on my laptop, so I started it up and loaded the 5200 Star Raiders game and the = key worked fine on that version.  I was able to switch to command mode and turn on shields and go to the navigation map and all that.

 

Is this a bug in version 4.20?

This is literally just fixed in the test release I just posted. The issue is that 5200 Star Raiders reads from a nonexistent PIA chip.

[Rockymin]

55 minutes ago, phaeron said:

This is literally just fixed in the test release I just posted. The issue is that 5200 Star Raiders reads from a nonexistent PIA chip.

 

Sorry, I didn't realize.  Thanks.

[w1k]

Hi, Phaeron

I know Altirra know playing czechoslovakia TURBO 2000 tape system, i want ask if you plan add support Slovak rare TURBO D/DNM ? i have audio files, and technical infos (but only in slovak language)

[baktra]

On 2/13/2024 at 1:40 PM, w1k said:

Hi, Phaeron

I know Altirra know playing czechoslovakia TURBO 2000 tape system, i want ask if you plan add support Slovak rare TURBO D/DNM ? i have audio files, and technical infos (but only in slovak language)

Well, you will not expect Phaeron to go through the documentation in Slovak language (and mostly scans that are not so easy to translate) and come up with support for a rare system out of the blue, won't you? That would be naive.

 

I believe such request must come on a silver plate with the following information:

1. What is the modulation style (how the 0 and 1 are translated to the electric signal and back)
2. How the data recorder is switched to turbo mode (if it is applicable)
3. How the signal goes to the computer (SIO, Joystick Port, etc.)
4. Sample recording
5. Sample loader and instructions on how to use it.

This is the bare minimum. It still doesn't guarantee that a request would be granted.

It also very much depends on how much work it would require, how it would fit in the current code that supports turbo systems. And last, but not least, the business value of the enhancement must be taken into account.

 

Let me do some digging first. If I collect sufficient information, we can get back to this matter.

[jenorton]

Hi:

 

This question relates, not so much to Pacman itself, but, how Altirra handles it.

 

I am referring to the 5200 version vs. the 800 version of Pacman.

 

I figured one would be very similar to the other, since they run on similar hardware, but, the 5200 version appears harder by default.  For example, I have a particular move (moving up, then all the way left, then slightly down, to get a power pellet.  In the 800 version, I get there with no problem.  With the 5200 version, I'm eaten almost immediately after I go up.

 

Is there some kind of player difficulty setting? if so, how do I change it in 5200 mode?  Or, is the maze different or the ghost monster movement different?

 

Thanks!

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.30-test7.zip
https://www.virtualdub.org/beta/Altirra-4.30-test7-src.7z

• Fixed an crosstalk issue between input ports 1/2 and 3/4.
• Fixed registration of file types for the current user only and added support for more direct entry to the default settings page for the program (Windows 11 only).
• Tweaked the inactive selection colors in dark theme.
• Super Archiver full emulation now supports slow disk speed.
• Added initial BitWriter emulation.

The BitWriter emulation is currently a bit fragile, it relies on the emulator to render the track and this is difficult with some of the ways that protections interleave sectors. There are some problems with the way that the BitWriter software works that makes it a bit unreliable even for plain unprotected disks, and I haven't figured out how to improve it yet. The BitWriter itself is fairly simple, it consists of a 6520/6821 PIA, 8K static RAM, a shift register, an up/down address counter, and a 4us clock divider.

 

Writing is relatively simple. The BitWriter, when enabled, bypasses the FDC and shifts raw bits out from RAM to the drive. It can only do FM (single density) as its clock divider is hardcoded to a 4us bit cell and it doesn't have enough RAM to buffer a raw MFM track. The hardware automatically drives the shift register from the RAM, so all the firmware needs to do is upload to the RAM and trigger the write. The BitWriter RAM is not directly accessible, however, and can only be accessed through the PIA and by clearing, incrementing, or decrementing the counter. The way that the entire 8K RAM has to be accessed is goofy, it requires the firmware to manually toggle the counter clock 16 times, which is very slow. Software must also encode data into FM before writing, and this also requires a bit reversal since for some reason the hardware shifts LSB first. The BitWriter software does this on the computer, so about 6.5KB must be transferred over the SIO bus per track written, which is also not fast. But otherwise, the BitWriter can basically write any flux pattern with a fixed clock.

 

Reading is where it gets ugly. The BitWriter has no support at all for reading, so this is done through the FDC's Read Track command, with the BitWriter only being used for track buffer RAM. The Read Track command has a number of known problems due to the inability to identify address marks, which are simply returned in-band with other plain data bytes. This means that the software has to guess where the address marks are, and its heuristics for doing this are very weak. This means that it commonly identifies bogus address marks and writes tracks with bogus IDAMs in the middle of sectors. This is mostly harmless, but it's a mystery why it doesn't do basic validation like checking if the track and sector number are remotely valid. It also seems to have trouble with identify the wrap point for the track and will occasionally drop a sector -- from what I can tell it simply checks for about 140 bytes to match, which isn't enough with a blank sector in the vicinity.

 

As part of this work, the Read Track command is now implemented in the FDC for all full drive emulators. The track rendering routine is an improved version of the one that was originally put in for the 815 and can deal with some quirks, but can fail when sectors overlap. I've found that some ATX images also have coarse and inaccurate sector timings, so the track renderer will attempt to vary gap III and shift sectors to fix this.

 

1 hour ago, jenorton said:

I am referring to the 5200 version vs. the 800 version of Pacman.

 

I figured one would be very similar to the other, since they run on similar hardware, but, the 5200 version appears harder by default.  For example, I have a particular move (moving up, then all the way left, then slightly down, to get a power pellet.  In the 800 version, I get there with no problem.  With the 5200 version, I'm eaten almost immediately after I go up.

 

Is there some kind of player difficulty setting? if so, how do I change it in 5200 mode?  Or, is the maze different or the ghost monster movement different?

I'm not familiar with the specifics of either version of Pac-Man, but there are a couple of differences in the platform that could explain this. First, the 5200 OS is more lightweight than the 800 OS, which can change the program timing. POKEY provides a hardware random number generator that is often used, so changes in timing can result in changes in generated random numbers.

 

The second issue is that the 5200 uses analog joysticks instead of digital. This requires an additional frame to read, and on top of that, games often do averaging to reduce noise in the readings, which can in turn change move timing. A few 5200 games also have explicit support for analog movement instead of just converting the analog input to digital, Star Raiders being an example.

 

For 5200 games that do support options, these can usually be activated by pressing controller keypad buttons at the title screen.

 

[_The Doctor__]

Sounds like the BitWriter can be improved real world to handle quite a 'bit' more with those observations in hand, and be made quite a bit faster as well.

[+MrFish]

14 hours ago, jenorton said:

Is there some kind of player difficulty setting? if so, how do I change it in 5200 mode?  Or, is the maze different or the ghost monster movement different?

The ghosts are more aggressive in the 5200 version than in the 8-bit computer version of Atari Pac-Man. As far as I know, there is no way to change the difficulty.

 

[jenorton]

17 minutes ago, MrFish said:

The ghosts are more aggressive in the 5200 version than in the 8-bit computer version of Atari Pac-Man. As far as I know, there is no way to change the difficulty.

 

Thanks.