Altirra 4.20 released

[phaeron]

2 hours ago, drpeter said:

@phaeron

 

While messing about with wide playfields recently, I noticed something I didn't expect:

 

When horizontally scrolling a 48 byte wide playfield, the 4 bits of 'garbage' at the extreme right border that show up on extended overscan scroll out of view when HSCROL is 2,3,6,7,10,11,14, or 15.

 

This gives a usable playfield width without 'garbage' of 178 rather than 176 color clocks.

 

I've been unable to confirm this behaviour on real hardware because I have no monitor that will show extended overscan.

 

Is this correct?

 

I ask in particular because there's been discussion recently of making use of these 2 'garbage' color clocks in static images by ensuring predictable data on the bus at the critical moment, using DLI or screen kernel techniques. Just scrolling the relevant mode lines 10 color clocks (10 rather than 6 or 2 so as to to minimise 6502 cycles 'stolen' by DMA) would seem a very much simpler means to the same end...

 

Double-checked on hardware with a scope, this will work for bitmap mode (IR modes E and F) but not for character modes (IR 2 and 4). The character data fetch is one cycle later than the bitmap fetch for the same position on screen, so while you can get bitmap data fetched just in time to cover to the start of horizontal blank, it's short by one color clock at best for character modes.

 

[drpeter]

6 hours ago, phaeron said:

 

Double-checked on hardware with a scope, this will work for bitmap mode (IR modes E and F) but not for character modes (IR 2 and 4). The character data fetch is one cycle later than the bitmap fetch for the same position on screen, so while you can get bitmap data fetched just in time to cover to the start of horizontal blank, it's short by one color clock at best for character modes.

 

Ah yes, I hadn't tried character modes. I notice that on the 'bad lines' of IR mode 2, for example, when HSCROL is 2,3,6,7,10,11,14,15 the 'garbage' pixels don't represent 6502 use of the bus but are constant and seem to be something to do with ANTIC's  final fetches of character data for that line. What's going on there?

 

EDIT- ah- after some more experimentation I see that it's the screen code of the first character that is beyond the right margin of the display- presumably because ANTIC is continuing to load the internal buffer with these characters but not fetching display data for them

Edited April 5 by drpeter

[phaeron]

7 minutes ago, drpeter said:

Ah yes, I hadn't tried character modes. I notice that on the 'bad lines' of IR mode 2, for example, when HSCROL is 2,3,6,7,10,11,14,15 the 'garbage' pixels don't represent 6502 use of the bus but are constant and seem to be something to do with ANTIC's  final fetches of character data for that line. What's going on there?

The extraneous pixels are from ANTIC reading data from the data bus for a playfield fetch without actually having properly requested a DMA fetch. On a bad line, one of the refresh cycles is pushed all the way to end, where it executes on the first cycle of horizontal blank where there are no other DMA requests. However, refresh cycles don't drive the data bus, so what you should be seeing fetched is open bus data -- $FF on systems that have data bus pullups and last cycle read on ones that don't.

 

[drpeter]

23 minutes ago, phaeron said:

The extraneous pixels are from ANTIC reading data from the data bus for a playfield fetch without actually having properly requested a DMA fetch. On a bad line, one of the refresh cycles is pushed all the way to end, where it executes on the first cycle of horizontal blank where there are no other DMA requests. However, refresh cycles don't drive the data bus, so what you should be seeing fetched is open bus data -- $FF on systems that have data bus pullups and last cycle read on ones that don't.

 

Hmm... in emulation the behaviour on bad lines is the same in both the 800 (floating undriven data bus) and 800XL (pulled up undriven data bus)? In both it reflects the screen code data of the first character beyond the extreme right display border- i.e. in horizontal blank

[drpeter]

This is my test code:

 

5 SCRBAS=PEEK(88)+PEEK(89)*256
10 DLBAS=PEEK(560)+PEEK(561)*256
20 POKE DLBAS+3,82
30 FOR F=DLBAS+6 TO DLBAS+28:POKE F,18:NEXT F
40 POKE 559,35
50 FOR F=0 TO 3999:POKE SCRBAS+3,(F/250)+16:POKE 54276,F/250:NEXT F

[drpeter]

It seems to reflect the result of these character map DMA cycles:

 

[drpeter]

So it seems to me that for both the emulated 800 and 800XL, the virtual DMA cycle for playfield character data coinciding with a refresh cycle and therefore an undriven data bus results in fetching persistent data on the bus from the preceding character map DMA cycle- i.e. emulating a floating data bus

[phaeron]

16 hours ago, drpeter said:

Hmm... in emulation the behaviour on bad lines is the same in both the 800 (floating undriven data bus) and 800XL (pulled up undriven data bus)? In both it reflects the screen code data of the first character beyond the extreme right display border- i.e. in horizontal blank

Yes, this is a bug. I checked with a capture device and that cycle is a solid $FF on the 800XL while it's floating bus data on the 130XE, same as for other undriven bus cycles. The ANTIC emulation needs to force $FF into the virtual DMA path when they overlap refresh cycles.

[serj]

Avery, what happened?

have you decided to abandon the emulator?

two months no updates.

[pseudografx]

Serj, give the man some rest!

[davor]

18 hours ago, serj said:

Avery, what happened?

have you decided to abandon the emulator?

two months no updates.

version 4.21 was released mid-march.

[phaeron]

On 4/12/2024 at 12:19 AM, serj said:

Avery, what happened?

have you decided to abandon the emulator?

two months no updates.

No, I've just been working on some stuff that just isn't ready to release yet.

[drac030]

4.30-test6, the generic disk emulation seems to work as XF-551, i.e. under SDX it automatically syncs as one (at 38400) or can be set manually:

 

 

Is this intended?

[phaeron]

3 hours ago, drac030 said:

4.30-test6, the generic disk emulation seems to work as XF-551, i.e. under SDX it automatically syncs as one (at 38400) or can be set manually:

 

Is this intended?

Yes, the Generic mode supports XF551 high speed mode operation but is not limited to XF551 specs, as it supports additional disk formats and a couple of additional commands (e.g. format skewed).

[Yautja]

Excuse my ignorance... is it possible to configure a USB joystick with the emulator?

[phaeron]

3 hours ago, Yautja said:

Excuse my ignorance... is it possible to configure a USB joystick with the emulator?

As long as the joystick is exposed to the regular Windows APIs for a controller, sure. Altirra supports the DirectInput and XInput APIs. If it appears in the Game Controllers control panel in the OS, then it should work.

 

The easiest way to set up a new controller is to either create a new input map in Input > Input Maps with the Preset button, or Edit an existing one. Then click Rebind, which will step through each input binding waiting for you to press the controller button to assign to it.

[ascrnet]

Hi all,

 

I wanted to ask how to turn off the illegal opcode from debug mode or not?

 

Since I have disabled on the CPU

Greetings

[phaeron]

1 hour ago, ascrnet said:

Hi all,

 

I wanted to ask how to turn off the illegal opcode from debug mode or not?

 

Since I have disabled on the CPU

Greetings

The option you have showing will prevent the CPU from executing such instructions, and break into the debugger when one is encountered. There isn't currently an option to disable illegal instructions in the disassembly.

[ascrnet]

16 minutes ago, phaeron said:

The option you have showing will prevent the CPU from executing such instructions, and break into the debugger when one is encountered. There isn't currently an option to disable illegal instructions in the disassembly.

thank you for answering my question, I thought they were related. 😅

[phaeron]

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

• Debugger: Added SIOREPLY logging channel.
• Devices: Added support for external audio test in the SuperSALT test assembly.
• ANTIC: Fixed virtual DMA cycle data when overlapping refresh on a system with data bus pull-ups.
• UI: Window caption is less spastic in turbo.
• Display: Added color correction modes for targeting displays that use pure 2.2/2.4 gamma instead of sRGB.
• Display: Fixed incorrect gamma in some cases with HDR or Adobe RGB.
• Disk: The "Show disk image file" option now works with images mounted from within .zip files.
• PerfAnalyzer: Can now import monitor traces from Atari800 5.2.0.

 

[+Torq]

Hi @phaeron

 

Not sure how relevant this is, since it's a macOS issue (via Wine), but 4.21 seems to have an issue with image files specified on the command line.  If the path to the file to be run includes, or resolves to, starting with a "/" it seems to get treated as an option or switch (and is in error).  Works fine for folders within/below the Altirra folder ... (e.g. myfiles/test.xex ...), but if that folder is outside Altirra's folder (e.g. /myfiles/test.xex) "it go boom" ("file not found" or "invalid path" or "/myfiles is not a valid option").  Being clever with backwardly specifying relative (../../) folders doesn't help (still resolves to something beginning with "/").

 

Seems like a command-line parsing issue with POSIX paths, since the same files can be accessed via the menus, and it seems to work fine under Windows.

 

You can safely ignore this ...

 

Turns out this is an issue with Wine's handling of POSIX paths vs. the Windows pure paths it is providing.

 

 

Love the emulator ... amazing job!

[ldelsarte]

If I may, I'd like to submit a list of suggestions for new features to consider for a future release:
 

[1] Rewind

Altirra already offers ‘Saved states’, but I'm thinking of a feature like the one in ‘The400’, which lets you easily go back 30 seconds. It's obviously really interesting in games, when you do something stupid. For it to be convenient to use, you'd need a combination of keys to quickly go back in time. Not necessarily any time between now and 30 seconds back. Maybe just 15s and another 15s (i.e. 30s) back?
 

[2] Colour plot

This suggestion serves no practical purpose, but it's just to make the emulation as comprehensive as possible. All Atari machines have an easily (*) accessible ‘colour plot’ which allows you to finely adjust the colour of the output video display. Naturally, it is set correctly at the factory. In BASIC, for example, the screen background is blue (NTSC) or blue-green (PAL/SECAM). If the colour plot is completely off, the colour may be significantly different.

In the Altirra UI, this could be a slider, for example, with a ‘reset to factory setting’ button.

(*) There are a few exceptions. On the Atari 400, it's at the back of the computer, well hidden in the ventilation grille. On the Atari 800, it's behind the RAM cartridge compartment (you have to get access to the rear of this compartment). On the XEgs, it's on the motherboard PCB (you have to open the console).
 

[3] CRT Afterglow emulation

When using a monochrome mode in particular, to make the experience as close as possible to what you could do with a CRT screen back in the day, I think it would be interesting to be able to artificially add an afterglow. I don't even know if this effect can be implemented easily or not. I think it's harder to implement than just ‘overlay the last 20 generated images...’.

The idea would be to have a radio button to adjust the intensity of this afterglow effect from 0 (off) to 5 or something like that.
 

[4] Mechanical sounds

I know I've already mentioned this suggestion in a previous discussion. The idea would be to add, in addition to the usual sounds generated by the system, to add to Altirra sounds that are simply produced by the user interacting with the real hardware: the sound of a key being pressed on the computer or cassette player, the sound of the door/lid/latch of a floppy disk drive being closed, the sound of a dot matrix printer printing or feeding paper...

Naturally, I'm available to record samples.
 

[5] Additional character sets

This is one of the interesting features of Atari computers, among many others: the possibility for the user to add one or more additional character sets, in addition to the one supplied with the standard OS.

The idea would be to propose in Altirra to replace the standard character set (‘domestic’) by a character set supplied in a separate file. This would make it possible, without any programming of any kind, to use, in BASIC and DOS for example, a character set other than the one usually supplied with the machine. Since many 8-bit computers of the time also used an 8x8 pixel character set, it would be fun to be able to use them on an Atari.
 

[6] How can we help?

Thank you for reminding all of us, on a regular basis, of what we can do in practice to help. With my suggestions above, I can provide sound files, character set files, etc, etc. All you have to do is ask.

Everyone reading these posts about Altirra is certainly happy to use it - if not, develop your own emulator. A "Thank you" message is the absolute minimum, but we, grateful users of Altirra, can certainly do more.

[Kr0tki]

3 hours ago, ldelsarte said:

[2] Colour plot

It's called "colour pot", as in "potentiometer". And it is already implemented, see View->Adjust Colors->Hue step.

 

On a related note, I've noticed a peculiar issue in the "Adjust Colors" dialog. Among the various reference colours listed in the bottom-right, there are these two entries:

$AA: Pole Position sky

$D8: Pole Position grass

The problem is, "Pole Position" is among the handful of games that use different colours for NTSC and for PAL. So using these two colours as reference points may be somewhat confusing for PAL users 🙂

Edited May 7 by Kr0tki

[phaeron]

20 hours ago, ldelsarte said:

[1] Rewind

Altirra already offers ‘Saved states’, but I'm thinking of a feature like the one in ‘The400’, which lets you easily go back 30 seconds. It's obviously really interesting in games, when you do something stupid. For it to be convenient to use, you'd need a combination of keys to quickly go back in time. Not necessarily any time between now and 30 seconds back. Maybe just 15s and another 15s (i.e. 30s) back?

I've been working toward this incrementally. One of the issues has been reliability of save states, as Altirra has a lot of internal state for accuracy reasons, and it's only recently that save states have been somewhat reliable. Things get pretty sticky in situations like saving in the middle of an instruction, or during a disk load. It's a bit better now that there's support for trying to save at a nice point (first instruction in vblank) and flagging "unsafe" times like disk operations. But there are still cases that are not handled, like some devices that don't support save states, or rolling back across a disk write.

 

If you spot an issue with save states, do let me know as a rewind mechanism would be built on top of it. You can key-bind the save/load quick state commands, which will give you one level of manual rewind.

20 hours ago, ldelsarte said:

[2] Colour plot

This suggestion serves no practical purpose, but it's just to make the emulation as comprehensive as possible. All Atari machines have an easily (*) accessible ‘colour plot’ which allows you to finely adjust the colour of the output video display. Naturally, it is set correctly at the factory. In BASIC, for example, the screen background is blue (NTSC) or blue-green (PAL/SECAM). If the colour plot is completely off, the colour may be significantly different.

In the Altirra UI, this could be a slider, for example, with a ‘reset to factory setting’ button.

(*) There are a few exceptions. On the Atari 400, it's at the back of the computer, well hidden in the ventilation grille. On the Atari 800, it's behind the RAM cartridge compartment (you have to get access to the rear of this compartment). On the XEgs, it's on the motherboard PCB (you have to open the console).

As Kr0tki notes, the Hue Step slider is equivalent to the color pot. This includes the wonky behavior of the PAL GTIA encoder.

 

Of course, Altirra won't be able to emulate the awkwardness of trying to live trim a pot that's exposed on the bottom of the computer, particularly if you are bold enough to use a metal screwdriver on a powered computer.

 

20 hours ago, ldelsarte said:

[3] CRT Afterglow emulation

When using a monochrome mode in particular, to make the experience as close as possible to what you could do with a CRT screen back in the day, I think it would be interesting to be able to artificially add an afterglow. I don't even know if this effect can be implemented easily or not. I think it's harder to implement than just ‘overlay the last 20 generated images...’.

The idea would be to have a radio button to adjust the intensity of this afterglow effect from 0 (off) to 5 or something like that.

This would be possible, though it'd be emulating a pretty poor monitor. The only visibly long persistence monitor I've ever used was the Apple Monitor ///, and even that wasn't that visible.

 

20 hours ago, ldelsarte said:

[4] Mechanical sounds

I know I've already mentioned this suggestion in a previous discussion. The idea would be to add, in addition to the usual sounds generated by the system, to add to Altirra sounds that are simply produced by the user interacting with the real hardware: the sound of a key being pressed on the computer or cassette player, the sound of the door/lid/latch of a floppy disk drive being closed, the sound of a dot matrix printer printing or feeding paper...

Naturally, I'm available to record samples.

Yeah, I know you've asked about this before. I'm not opposed to it, but it needs some work. Altirra's internal sound effect system is limited to a small preset sound bank of samples pre-resampled to the internal mixing rate (63.9KHz), that would need to be made for flexible.

 

Printing is definitely one I've thought about, though some work would be needed just to emulate better print timing and output. The 820 is a particularly interesting case because its timing isn't entirely firmware driven, it's also determined by a timing roller driven by a motor, so I don't actually know how fast it prints. The 1020 and 1025 are a little better defined and I've partially disassembled the firmware for the latter (8051... bleh).

 

I'm a little surprised that no one has commented on the phone network sound emulation only supporting US dialing sounds, but perhaps there aren't enough people who used modems....

 

This also reminds me that I need to check the sound of the Atari 400 internal speaker, to see if it's appreciably different than the 800 and needs a different impulse. I have a 400, just can't be bothered to hook it up half the time because it only has a fricking RF output.

20 hours ago, ldelsarte said:

[5] Additional character sets

This is one of the interesting features of Atari computers, among many others: the possibility for the user to add one or more additional character sets, in addition to the one supplied with the standard OS.

The idea would be to propose in Altirra to replace the standard character set (‘domestic’) by a character set supplied in a separate file. This would make it possible, without any programming of any kind, to use, in BASIC and DOS for example, a character set other than the one usually supplied with the machine. Since many 8-bit computers of the time also used an 8x8 pixel character set, it would be fun to be able to use them on an Atari.

This one I'm not sure about, as it effectively would just be patching the OS ROM. Probably would be better to have a ROM patching tool to create customized ROM images than to add a feature specifically for the character set.

 

20 hours ago, ldelsarte said:

[6] How can we help?

Thank you for reminding all of us, on a regular basis, of what we can do in practice to help. With my suggestions above, I can provide sound files, character set files, etc, etc. All you have to do is ask.

Everyone reading these posts about Altirra is certainly happy to use it - if not, develop your own emulator. A "Thank you" message is the absolute minimum, but we, grateful users of Altirra, can certainly do more.

Feedback and testing are awesome, as always.

 

16 hours ago, Kr0tki said:

It's called "colour pot", as in "potentiometer". And it is already implemented, see View->Adjust Colors->Hue step.

 

On a related note, I've noticed a peculiar issue in the "Adjust Colors" dialog. Among the various reference colours listed in the bottom-right, there are these two entries:

$AA: Pole Position sky

$D8: Pole Position grass

The problem is, "Pole Position" is among the handful of games that use different colours for NTSC and for PAL. So using these two colours as reference points may be somewhat confusing for PAL users 🙂

Ooh, interesting, I didn't know that Pole Position did this. Easy enough to add the separate NTSC/PAL colors to the reference table, but this is quite an interesting reference since the PAL colors are relatively constrained. This is a much better reference for what contemporary colors were seen at the time than hand-wavy anecdotes about "green", "blue", and "gold" colors.

[+MrFish]

2 hours ago, phaeron said:

...hand-wavy anecdotes about "green", "blue", and "gold" colors.