Altirra 4.00 released

[LessNick]

2 hours ago, Mclaneinc said:

Update...The 8k I could get all the games working but only by trying some of the bigger cart sizes, I found but going up in cart sizes that more and more games worked. So far, not one title seems to run on the 16K cart (apart from the menu)

 

Update 2: The smallest driver that would play all 4 games on the 8 file was 64K...I think they are all 8K roms, need to check..Yes, all 8k roms, the file size is 40K so I presume that the menu part is allotted 8K as well. Sadly the same logic does not work for the 16k image.. ie 6 x 16K +8K menu. That matches the file size but using the 128k driver fails to play any.

I contacted the author of "xe-multicart" project and he said that things are not so simple with 16k cartridges:

 

Quote

If I remember correctly, the 16k games need to be aligned a certain way in order to load correctly (essentially, both 8k halves have to occupy the right memory locations). That alignment is supposed to be done by the packing scripts provided in this repository, but I've got to admit that I haven't tested them thoroughly - I made some carts with the games I like the most and that seems to be working on both of my machines.

 

In other words, most likely the problem is in the correct assembly of the cartridge image.

Need more information and testing.

[Mclaneinc]

Seems a bit unfriendly for a user.....I'll stick with my AVG

[LessNick]

14 minutes ago, Mclaneinc said:

Seems a bit unfriendly for a user.....I'll stick with my AVG

Well, unfortunately this is a feature of open source

At the moment, the author does not have the time and opportunity to deal with the project, but is not opposed to get help.

I do not mind taking up this issue in more detail and bringing the bring to happy end. 

 

I was able to find the pattern of the error. As the author wrote, the problem is with alignment.

 

If you arrange the blocks like this:

8k menu

8k first game

16k second game

 

For example, pac-man = 8k. zaxxon = 16k

 

 

Everything works perfectly.

 

 

cart_8_16.zip

Edited March 14, 2022 by LessNick

[Mclaneinc]

Ah, so if they are stacked in size order from smallest to last cart being biggest it works.

 

Sort of screws any chance of an alphabetic menu unless you are either very lucky or only want certain games.

 

Still, it's open source so there you have it..

[Mclaneinc]

I now feel such an idiot for not working out how the 8K cart worked from the start...It just shows, you can put all the information right in front of some people and still they go the wrong route...

 

In the words of the great Homer...DOH!

[LessNick]

18 minutes ago, Mclaneinc said:

I now feel such an idiot for not working out how the 8K cart worked from the start...It just shows, you can put all the information right in front of some people and still they go the wrong route...

 

In the words of the great Homer...DOH!

You shouldn't be so worried.

I can say that when adding a large number of images of cartridges, the loading also breaks. A byte-by-byte comparison shows that the files are shifted. So most likely the problem is in the builder script itself.

 

Now I'm trying to figure out how it all work together. The problem is that part is done in python, then C is built, and only then ASM is compiled. There are a lot of intermediate steps.

 

As soon as I reach enlightenment, I will definitely share the results

[phaeron]

To be specific, the hardware limitation is that 8K images can be aligned to an 8K boundary, but 16K images have to be aligned to a 16K boundary. This is not an uncommon limitation; some cartridges simply just don't let you use even banks in 8K mode, always aligning the two cartridge windows to 16K.

 

The builder script tries to deal with this, by sorting the 8K cartridges first and then adding a dummy 8K slot if needed. However, the logic for doing so looks busted:

    if len(cart8) // 2 == 1:
        # Extra padding for 16 KB carts alignment.
        output.write(bytes(8192))

This checks whether the number of 8K carts divided by 2 is 1, where it should use modulus instead -- and it needs to check for an even number of 8K carts since the menu itself occupies an 8K slot. build_menu() has the correct check.

 

The way the build process works is: buildcart.py generates the cart list for the menu, cl65 is invoked to compile and link a menu binary specifically for the cart, then buildcart.py is run again to assemble the final cart image. Probably could have been made easier if the menu just referenced entries from a fixed address instead of linking them into the source.

 

[Mclaneinc]

Good luck although Avery looks to have passed on the way to fix..

[LessNick]

43 minutes ago, phaeron said:

This checks whether the number of 8K carts divided by 2 is 1, where it should use modulus instead -- and it needs to check for an even number of 8K carts since the menu itself occupies an 8K slot. build_menu() has the correct check.

woow! the problem is really in this. I compile all 15 different games and everything worked.

However, this does not solve the problem with the first game, which should be 8k and complement the menu.

 

In any case, thanks for the info. But it's better to write your own builder

[+Stephen]

20 hours ago, phaeron said:

22 hours ago, Stephen said:

I have a question - I finally figured out how to enable VBXE blits (.vbxe_traceblits doesn't toggle, it requires an on or off parameter).  Can you please explain what the following info in the parenthesis (the 3 numbers) signifies:

(8367:169,  3) VBXE: Starting new blit at $00554:

(8367:258, 16) VBXE: Blit list completed

 

Hmm - noticed the console displays those same 3 numbers when pausing and entering the debugger console as well.  Browsed much of the help file, didn't see anything.

Frame number, Y counter, and X cycle counter.

Is it suitable for timing VBXE blits (as in reasonably accurate enough to determine just how much can fit in one frame)?  I'm just starting to mess with them, and it's amazing how damn fast this thing is.  Also - what are the ranges of the 2 counters?  I assume Y counter would be scanline so 0-239 and x-cycle is CPU clocks per scanline?  I'm trying to figure out how to take these starting and ending times, and see what that equates to in 6502 cycle counts.

[phaeron]

1 hour ago, Stephen said:

Is it suitable for timing VBXE blits (as in reasonably accurate enough to determine just how much can fit in one frame)?  I'm just starting to mess with them, and it's amazing how damn fast this thing is.  Also - what are the ranges of the 2 counters?  I assume Y counter would be scanline so 0-239 and x-cycle is CPU clocks per scanline?  I'm trying to figure out how to take these starting and ending times, and see what that equates to in 6502 cycle counts.

The beam position spans the entire scanned frame including overscan, so it's 262 scanlines for NTSC and 312 scanlines for PAL. x-cycle is 0-113 (114 cycles/line) for both.

 

You can approximately compute the blit time from the log output, although it's only approximate because of buffering in the emulator. The beam positions reported are the 6502/ANTIC timings when the blits occur, but those may be skewed from the VBXE timings because the emulator only runs the VBXE when necessary. The time skew can be up to a scanline (114 cycles). It's also easier to see the blitter activity in the Performance Analyzer, which will plot the blitter activity times.

 

You can also just crunch the numbers since the number of local cycles needed for the blit is a simple function of the size of the blit and a few of the parameters. A fill, for instance, will take 1 local cycle/byte, a 1:1 copy will take 2 local cycles/byte, and a 1:1 read-modify-write blend op will take 3 lc/byte. There are 8 local cycles for each Atari cycle. However, this is from available blitter cycles, which excludes any cycles used from DMA. Overlay DMA is the main contender and you can figure out how many local cycles it will take just by the size in bytes of the overlay data. For instance, for a 320x192, 256 color display, it'll take 61,440 cycles per frame out of the 238,944 available (NTSC), leaving 177,504 cycles, minus a few for XDL and CPU access. 177,504 / 61,440 = 2.9 framebuffer reads or writes, so there is only enough memory bandwidth to fill the screen twice or copy it once per frame.

 

And yes, the VBXE blitter is very fast, since it runs at 14MHz instead of 1.79MHz. Do keep in mind that VBXE screens also have much more data, which counters the speed of the blitter. Also keep in mind that Altirra does not currently emulate cycles stolen by MEMAC -- this is not ordinarily a problem unless you map ANTIC or run 6502 code out of a MEMAC window, but you can lose another ~10% of local memory bandwidth that way, which can turn into a much larger percentage of blitter time. Finally, the blitter can't make use of memory cycles when it's not running, so if you are structuring your rendering loop such that the blitter constantly waits for the 6502 instead of running in parallel with it, you are losing a lot of blitter speed.

 

[Pixelfetish]

Hello all.

When using a save state for a game, why do I have to Pause and Unpause via the menu only (F9 twice doesn't work) to get the game running again?
And why is a Quick Save only valid for the current running Altirra session? The Quick save is gone, when restart Altirra 4.00

Edited March 15, 2022 by Pixelfetish

[Mclaneinc]

Look at the quick save as something you use when you tinker with a game, it's a quick way to save a state with the actual saving side of it (well apart from to memory). I look at it like the rewind feature in some emulators, it's there for while you are playing, but for something longer lasting you do a proper save state. Quick saves are usually used when you may be at a tricky part of a game that you want to not have to track all the way back to if you die, so you might during play quick save a hell of a lot, imagine if those we saved states, you would have a huge list of save states, so the quick save is just for that session, when you want to end your session do a real save state if you need to.

 

As for the first question, not sure what you mean, if I save a state and then come back to the same game I just load that state and it auto resumes..No need for pausing etc

 

Maybe Avery / Phaeron knows what you mean.

 

Just trying to help.

Edited March 15, 2022 by Mclaneinc

[Pixelfetish]

2 hours ago, Mclaneinc said:

Look at the quick save as something you use when you tinker with a game, it's a quick way to save a state with the actual saving side of it (well apart from to memory). I look at it like the rewind feature in some emulators, it's there for while you are playing, but for something longer lasting you do a proper save state. Quick saves are usually used when you may be at a tricky part of a game that you want to not have to track all the way back to if you die, so you might during play quick save a hell of a lot, imagine if those we saved states, you would have a huge list of save states, so the quick save is just for that session, when you want to end your session do a real save state if you need to.

 

As for the first question, not sure what you mean, if I save a state and then come back to the same game I just load that state and it auto resumes..No need for pausing etc

 

Maybe Avery / Phaeron knows what you mean.

 

Just trying to help.

I found out, when I set "Pause when inactive", Altirra does NOT autoresume, I have to do it manually with the method described above

Altirra needs about 10 seconds to autoresume. Apologies.

 

Another apologies, if I press space after loading the save state, it resumes.

Edited March 15, 2022 by Pixelfetish

[Mclaneinc]

Glad it's working..

[phaeron]

On 3/15/2022 at 5:31 AM, Pixelfetish said:

Another apologies, if I press space after loading the save state, it resumes.

This is strange, you should not have to press space after loading the save state unless it was saved in a state where the running program needs that. If the emulation is running when the load state occurs, the new state should resume immediately.

 

As for the reason why the save states are as they are, it's to prevent people from relying too much on them. Save states have to save a lot of internal emulator state that is subject to change between versions, and there's also lots of state that isn't currently saved, such as in devices. Plus there are all sorts of weird cases, like loading a state where you don't have the disk images mounted. There's already been a couple of problems of people trying to use save states in lieu of saving to disk/tape, and then getting burnt when save state compatibility breaks in a new version because the emulation got improved. So I'm reluctant to make it easier to use save states without doing more work to reduce chances of data loss.

 

[Pixelfetish]

14 hours ago, phaeron said:

This is strange, you should not have to press space after loading the save state unless it was saved in a state where the running program needs that. If the emulation is running when the load state occurs, the new state should resume immediately.

 

As for the reason why the save states are as they are, it's to prevent people from relying too much on them. Save states have to save a lot of internal emulator state that is subject to change between versions, and there's also lots of state that isn't currently saved, such as in devices. Plus there are all sorts of weird cases, like loading a state where you don't have the disk images mounted. There's already been a couple of problems of people trying to use save states in lieu of saving to disk/tape, and then getting burnt when save state compatibility breaks in a new version because the emulation got improved. So I'm reluctant to make it easier to use save states without doing more work to reduce chances of data loss.

 

The game where this happened was Pitfall 2.
One improvement I am thinking of, could be to paste the loaded game file name into the Save State box as default name for the Save State.
I think Altirra already remembers the file name if saving recurrently, if the file has been saved once in the current session.
I dunno, if we are supposed to code this ourselves though...

Anyway, many thanks for answering this topic in depth?. 

Edited March 17, 2022 by Pixelfetish

[Pixelfetish]

My three favorite emulators: Altirra, Emu8086 and Turing complete.

Happy Easter (Egg hunting). ???

[Fuji-Man]

Hi,

Is there a configuration settings for printer width for custom width settings? 0<x<=132 or ???

FujiMan

[www.atarimania.com]

How difficult would it be to implement optional emulation of the Votrax Type-n-Talk or Alien Group Voice Box?

 

I remember there was some discussion on the subject recently but am unsure whether any progress was made. 

[phaeron]

On 4/16/2022 at 1:01 PM, Fuji-Man said:

Is there a configuration settings for printer width for custom width settings? 0<x<=132 or ???

No, the printer currently only supports base 820 functionality.

 

20 hours ago, www.atarimania.com said:

How difficult would it be to implement optional emulation of the Votrax Type-n-Talk or Alien Group Voice Box?

 

I remember there was some discussion on the subject recently but am unsure whether any progress was made. 

The Votrax chips are complicated to emulate and are unlikely to be supported, as I don't have emulation code for them and have a policy of not using external code in the emulator. It may be possible to reasonably map the accesses to the system speech synthesis engine, but I haven't looked into doing so.

 

[www.atarimania.com]

4 hours ago, phaeron said:

The Votrax chips are complicated to emulate and are unlikely to be supported, as I don't have emulation code for them and have a policy of not using external code in the emulator. It may be possible to reasonably map the accesses to the system speech synthesis engine, but I haven't looked into doing so.

 

Thanks for replying.

 

I understand the Voice Box directly hooks up to the Atari while the Votrax Type-n-Talk requires the 850 interface, making it "more external". If somebody comes up with Type-n-Talk emulation and the virtual ability to connect the device to the 850, would that be enough to make it work in Altirra? Just thinking out loud and trying to comprehend how things function...

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.10-test9.zip
https://www.virtualdub.org/beta/Altirra-4.10-test9-src.7z

• Adds support for DXGI 1.3 seamless custom refresh rates, which can be enabled in Tools > Options > Display. There are narrow circumstances in which this works: you need Windows 8.1 or newer and both a video driver and internal LCD panel that supports appropriate custom refresh rates, with no external displays connected, and running borderless full screen. When this works, the emulator can switch the LCD panel to 50Hz for smooth PAL operation even if the display doesn't normally report 50Hz as a supported refresh rate. Unfortunately, Windows doesn't provide usable ways to determine when a custom refresh rate actually takes effect, so this can only be verified visually.
• Fixed a possible crash when scaling up in the video recorder.
• Added a bunch of advanced debug config vars for the display code.
• The D3D11 driver now displays some vsync timing information and composition mode when debug info is enabled.
• Fixed light pen/gun vertical position being way off in PAL. As a result of this fix, the light pen/gun offset has been reset in 4.10-test9 to be separate from previous versions. (0,0) is now an average-ish position for some XEGS light gun games.
• Added a command to recalibrate the light pen/gun offset. Unlike the dialog settings, this is interactive where you can click on where the emulated program thinks the light pen/gun position is, and the emulator will auto-compute the offset adjustment based on that.
• The immediate paddle option now also enables immediate light pen/gun updates, which can also remove 1 frame of latency for light pen/guns.
• Some internal code reorganization to improve building of the RMT plugins, removing some more extraneous dependencies and formally relicensing the remaining ones. The RMT plugins and the libraries used in them are now GPLv2 with an explicit linking exception for noncommercial use. This additional exception is retroactive. See COPYING.RMT in the source archive for details. Note that there is no functional change in the RMT plugins in this version.
• YASM has been removed as a build dependency.

A few misc notes:

• This version contains some pre-work on trying to reduce latency, but the WIP was not stable enough to release yet. One thing I discovered is that some night light reduction programs, notably f.lux, can introduce an extra frame of latency in full-screen mode. This is because the default settings for that program force the DWM to composite. You can tell if this is happening if the D3D11 debug info says that the composition mode is [Composed: Flip] instead of [Hardware: Independent Flip].
• Multiple monitors can also cause additional latency in windowed mode. With two monitors, the Windows 10 DWM will sometimes lose track of the flip queue and queue more than one frame, raising the minimum latency to 2+ frames. Also, in some cases it cannot promote a window to hardware overlay if two monitors are active.
• The light pen calibration screen in the Atari Graphics cartridge is somewhat difficult to get past because it has a strict limit on the PENH values it will accept, and as a result it will not accept the calibration positioning unless you either aim left of it or set the offset negative. I suspect that this is because the Atari light pens have a different horizontal offset than light guns, but need to get data from an actual light pen to verify. If this is the case, I'll need to put in a separate offset for light pens.

 

On 4/24/2022 at 3:16 AM, www.atarimania.com said:

I understand the Voice Box directly hooks up to the Atari while the Votrax Type-n-Talk requires the 850 interface, making it "more external". If somebody comes up with Type-n-Talk emulation and the virtual ability to connect the device to the 850, would that be enough to make it work in Altirra? Just thinking out loud and trying to comprehend how things function...

This would work, though the audio wouldn't go through the emulator. There is an issue in that the 850 emulation doesn't provide a dumb connection, it only allows a full-blown modem emulation which would interfere with the serial protocol. I want to put in a raw TCP/IP socket device at some point for this. For now, the only other way is a custom device, which would work but would also have to emulate the rest of the 850 (or at least an R-Verter).

[Mclaneinc]

Hi Avery, only just noticed this, any reason a right click on a full screen takes it to a windowed display but without the menu bar visible, if you click above the now windowed display then you get the menu bar. Not saying it's a bug, just wondering why it does this.

 

I'm sure there's a simple answer...

 

As always, thanks for a new release!

 

Paul..

Edited April 26, 2022 by Mclaneinc
spelling as always!

[phaeron]

16 hours ago, Mclaneinc said:

Hi Avery, only just noticed this, any reason a right click on a full screen takes it to a windowed display but without the menu bar visible, if you click above the now windowed display then you get the menu bar. Not saying it's a bug, just wondering why it does this.

This is due to another annoying design decision in Windows.

 

In Direct3D 11, if a full-screen exclusive window is occluded in any way, even by a single pixel for a single frame, DXGI forces the swap chain out of full-screen mode. The result is that Altirra still thinks it is full-screen while it is actually presenting windowed. This behavior is great for a simple game with a plain window and nothing else, it's useless for any program that has anything else on its window that needs to change between windowed and full-screen mode. I need to try to figure out how to reliably detect this and force the application state out of full screen mode as well.

 

As for what triggers it, right-clicking brings up a context menu which occludes the main window. I should probably block that in exclusive full-screen mode.