Jump to content
IGNORED

Altirra 2.00


phaeron

Recommended Posts

Well, this is nothing new to anyone who's been following the test releases, but here's version 2.00 final of my Altirra emulator. There are no significant changes from the last test release. Thanks to everyone who provided feedback!

 

(You need to copy and paste these links into your browser, since I have a referrer check on the download directory.)

http://www.virtualdub.org/downloads/Altirra-2.00.zip

http://www.virtualdub.org/downloads/Altirra-2.00-src.zip

 

And, now that 2.00 is released, I can release the changes that I've been keeping on the side into the main devline. :D New features include disk drive emulation levels, Slight-SID emulation, the debugger's alias support has been beefed up to emulate more Atari800 debugger commands, and WIP on 1030 modem support.

 

http://www.virtualdub.org/beta/Altirra-2.10-test2.zip

http://www.virtualdub.org/beta/Altirra-2.10-test2-src.zip

 

Happy holidays, everyone!

  • Like 7
Link to comment
Share on other sites

Unfortunately Altirra has still no option for unprocessed video-output. It is not possible to have 1:1 pixels without any stretching or filtering. That's strange because I do not know any emulator not being able to to do so.

 

I found a way with DirectDraw but then vsync suddenly does not work anymore, with DirectX vsync works but it's not possible to have unstretched video...

Link to comment
Share on other sites

Unfortunately Altirra has still no option for unprocessed video-output. It is not possible to have 1:1 pixels without any stretching or filtering.

 

Isn't that what the "View -> Stretch Mode -> Integral Square Pixels" option does?

 

I have two questions for Phaeron:

 

- Is it possible to have integral square pixels with a multiplicator, like x2 or x3? (I think this was discussed before, sorry to ask again :)).

 

- What represents the "speed" parameter in "Add/Edit Input Mapping" for a mouse controller?

 

Thanks.

Link to comment
Share on other sites

nice!

what about this carts? i cant load it on altirra.. (button must be push off)

 

Sorry, haven't gotten around to this yet.

 

Does Altirra buffer the keyboard itself? I have trouble speeding up the repeat rate too... it seems quite ponderous.

 

In general, no. Since the default is to use character messages, though, Windows will buffer the keys within the application's message queue. This is ordinarily only a problem if the emulator is dropping frames, which is bad (you need to tweak the display settings in that case).

 

As usual, though, the repeat problem is related to cooked key mode being enabled. Basically, the Atari OS does not accept keys fast enough to work with the native OS repeat rate. Therefore, you need to switch to raw keys so that the Atari OS key repeat can activate reliably.

 

Unfortunately Altirra has still no option for unprocessed video-output. It is not possible to have 1:1 pixels without any stretching or filtering. That's strange because I do not know any emulator not being able to to do so.

 

I found a way with DirectDraw but then vsync suddenly does not work anymore, with DirectX vsync works but it's not possible to have unstretched video...

 

DirectDraw mode is not recommended as I haven't done as much work on it, particularly with vsync. You should switch back to Direct3D mode and use integral square pixels + point sampling instead, which should get you what you want.

 

- Is it possible to have integral square pixels with a multiplicator, like x2 or x3? (I think this was discussed before, sorry to ask again :)).

 

Yes, it does this automatically if you make the window big enough. Reducing the view region to standard or OS region only helps if the borders are too big to allow this to happen. Currently you can't fix the ratio or force the emulator to crop besides through the view region settings.

 

- What represents the "speed" parameter in "Add/Edit Input Mapping" for a mouse controller?

 

This controls how fast the mapping is from the host controller to the emulated controller, i.e. how fast the emulated mouse moves when you push the host joystick or mouse. Higher values move the mouse faster. There is a hardcoded throttle in the emulator to prevent the mouse from moving too rapidly, though -- it buffers movement so that the control lines only change at most once every 32 scan lines.

Link to comment
Share on other sites

Unfortunately Altirra has still no option for unprocessed video-output. It is not possible to have 1:1 pixels without any stretching or filtering. That's strange because I do not know any emulator not being able to to do so. I found a way with DirectDraw but then vsync suddenly does not work anymore, with DirectX vsync works but it's not possible to have unstretched video...
DirectDraw mode is not recommended as I haven't done as much work on it, particularly with vsync. You should switch back to Direct3D mode and use integral square pixels + point sampling instead, which should get you what you want.

Unfortunately this does not work. I'm using special drivers for GroovyMAME with which I can use original screen resolutions of each system. When I'm using 320 x 240 with DirectDraw it works with integral square pixels + point sampling. But as soon as I'm using DirectX (because vsync is working there) it also switches to my custom resolution of 320 x 240 but I get a totally distorted picture in the lower right corner (about 200 x 150 Pixels or so). I tried other custom resolutions (336 x 256, 352 x 288, etc.) but even 640 x 480 does not show the picture right. Only DirectDraw shows the picture right - but without working vsync...

 

By the way: Picture in DirectX mode is totally ok but stretched if I use a e.g. Preserve Aspect Ratio or Square Pixels, the bug appears as soon as "Integral Square Pixels" is selected. I would recommend to fix vsync in DirectDraw mode or add a mode for totally unstretched and unfiltered video mode.

Edited by cwscws
Link to comment
Share on other sites

Does Altirra buffer the keyboard itself? I have trouble speeding up the repeat rate too... it seems quite ponderous.

 

In general, no. Since the default is to use character messages, though, Windows will buffer the keys within the application's message queue. This is ordinarily only a problem if the emulator is dropping frames, which is bad (you need to tweak the display settings in that case).

 

As usual, though, the repeat problem is related to cooked key mode being enabled. Basically, the Atari OS does not accept keys fast enough to work with the native OS repeat rate. Therefore, you need to switch to raw keys so that the Atari OS key repeat can activate reliably.

 

Thanks for the info. Switching to RAW keys would seem to solve the keyboard lag problem, but it also totally kills the auto-repeat on the cursor keys for some reason, so that solution is not really usable for me.

Edited by flashjazzcat
Link to comment
Share on other sites

How should I set-up SIDE emulation? I've got IMG file made out of whole CF card (SDX + FAT32), select this file in Altirra, hardware option is SIDE. And still I can't submit OK, the window doesn't close. Geometry needed (if so, where do I take this information from)? Sth else?

Link to comment
Share on other sites

- Is it possible to have integral square pixels with a multiplicator, like x2 or x3? (I think this was discussed before, sorry to ask again :)).

 

Yes, it does this automatically if you make the window big enough. Reducing the view region to standard or OS region only helps if the borders are too big to allow this to happen. Currently you can't fix the ratio or force the emulator to crop besides through the view region settings.

 

Doh, I was almost sure to have tested that :)

 

- What represents the "speed" parameter in "Add/Edit Input Mapping" for a mouse controller?

 

This controls how fast the mapping is from the host controller to the emulated controller, i.e. how fast the emulated mouse moves when you push the host joystick or mouse. Higher values move the mouse faster. There is a hardcoded throttle in the emulator to prevent the mouse from moving too rapidly, though -- it buffers movement so that the control lines only change at most once every 32 scan lines.

 

Then if I want a 1:1 relation between the mapping I set it at "1"? (or the default value "5"?). I would like to simulate the feeling of using an atari mouse in the real hardware.

 

Also, could this hard coded throttle be configurable at some point? Like setting it at 8 scan lines?

I suppose that reading a mouse every 8 scan lines right now is just a waste of code time then.

 

Regards.

Link to comment
Share on other sites

Thanks for the info. Switching to RAW keys would seem to solve the keyboard lag problem, but it also totally kills the auto-repeat on the cursor keys for some reason, so that solution is not really usable for me.

 

Figured it out -- turns out "repeat count" means something completely non-intuitive in the WM_KEYDOWN message, so Altirra wasn't detecting key repeat on the host side properly. This version should work better:

 

http://www.virtualdu...-2.10-test6.zip

http://www.virtualdu...0-test6-src.zip

 

How should I set-up SIDE emulation? I've got IMG file made out of whole CF card (SDX + FAT32), select this file in Altirra, hardware option is SIDE. And still I can't submit OK, the window doesn't close. Geometry needed (if so, where do I take this information from)? Sth else?

 

You're getting that error because you haven't set up the disk geometry, i.e. cylinder/head/sector counts. You can also enter in a size in MB, but in that case the emulator picks a default C/H/S translation and you should use the one from your physical device instead. Atari-based IDE code that uses linear block addressing (LBA) won't care about the exact translation, but some that still use CHS will.

 

I've been thinking about some ways to record the geometry in a side file so you don't have to enter it in each time. An alternative would be to add support for VHD/VHDX images, which contain geometry information inside.

 

Still on 2.0-test10 here... just wondering - wasn't there a "Randomize VBXE VRAM" option available before? Can't seem to find it now.

 

It's the main randomize option in Debug / Options. It will randomize VBXE memory as well as main memory.

 

One of the items on my TODO list has been to check the actual power-up DRAM pattern on a real Atari, as it is actually mostly deterministic if the system has been off long enough. When the randomize option is disabled the emulator clears memory to $00, which is not accurate. Extended memory on my 130XE powers up with alternating $00 and $FF bytes, but I don't know whether that system has 1-bit or 4-bit DRAMs.

 

- What represents the "speed" parameter in "Add/Edit Input Mapping" for a mouse controller?

 

This controls how fast the mapping is from the host controller to the emulated controller, i.e. how fast the emulated mouse moves when you push the host joystick or mouse. Higher values move the mouse faster. There is a hardcoded throttle in the emulator to prevent the mouse from moving too rapidly, though -- it buffers movement so that the control lines only change at most once every 32 scan lines.

 

Then if I want a 1:1 relation between the mapping I set it at "1"? (or the default value "5"?). I would like to simulate the feeling of using an atari mouse in the real hardware.

 

This is difficult due to interference from the host OS. On a real Atari, mouse movements result in the mouse lines counting faster or slower proportional to the movement speed. On a PC, these are internally aggregated by the mouse into a movement count, which is then sent as packets at regular intervals to the OS, which again aggregates them and optionally applies a rescaling and acceleration curve before passing it at irregular intervals to the application. On top of that, the resolution of a PC mouse is often quite different and higher than an Atari mouse. This makes the relationship between the physical mouse and the emulation ambiguous.

 

Right now, the default or speed 5 settings result in a mapping of 16 pixels on the host mouse cursor to one quadrature encoded tick on the joystick port. Speed 0 is about one third the speed and speed 10 is three times faster.

 

I think it might be possible to bypass the OS-level interference using raw input messages, but there's still the issue of trying to transform periodic packets back into continuous motion. Ideally the emulator should not post updates at regular intervals but instead vary the rate of update by the amount of accumulated motion. Problem is, I think latency would have to be added to make this work.

 

Also, could this hard coded throttle be configurable at some point? Like setting it at 8 scan lines?

I suppose that reading a mouse every 8 scan lines right now is just a waste of code time then.

 

Yeah, I need to rework this. The current code implements this by actually executing events every 32 scan lines, which is a waste when it should be inverted so that higher sampling rates don't eat more CPU.

 

Sampling every 8 lines is not necessarily a waste. On real hardware, the maximum rate at which the mouse can be moved is proportional to how fast you poll it, and unlike on the emulator, the hardware will easily overrun the software polling rate if you move it too quickly. You'd need to compare the resolution of an Amiga or Atari ST mouse to determine how fast to poll. For a 100 dpi mouse, I think polling every 8 scanlines gives you a maximum movement rate of 20 inches per second, which is not bad but could be overrun. Polling every 32 only gives you 5 inches per second which is less forgiving.

  • Like 1
Link to comment
Share on other sites

You're getting that error because you haven't set up the disk geometry, i.e. cylinder/head/sector counts. You can also enter in a size in MB, but in that case the emulator picks a default C/H/S translation and you should use the one from your physical device instead. Atari-based IDE code that uses linear block addressing (LBA) won't care about the exact translation, but some that still use CHS will.

 

I've been thinking about some ways to record the geometry in a side file so you don't have to enter it in each time. An alternative would be to add support for VHD/VHDX images, which contain geometry information inside.

 

Question is: where can I read the geometry from? It's a CF card used with SIDE on real ATARI. but FDISK, DEVINFO and other SDX tools I tried don't show the geometry for CF card in a way required by Altirra ;) Or have I missed sth?

Edited by Jacques
Link to comment
Share on other sites

Thanks for the info. Switching to RAW keys would seem to solve the keyboard lag problem, but it also totally kills the auto-repeat on the cursor keys for some reason, so that solution is not really usable for me.

 

Figured it out -- turns out "repeat count" means something completely non-intuitive in the WM_KEYDOWN message, so Altirra wasn't detecting key repeat on the host side properly. This version should work better:

 

http://www.virtualdu...-2.10-test6.zip

http://www.virtualdu...0-test6-src.zip

 

Brilliant - I'll test this when I get back later. :)

Link to comment
Share on other sites

I just tried 2.10-test7. Unfortunately video output is worse then before. In the new mode "(fixed multiples only)" the whole picture is a lot darker. In the regular mode "Square Pixels" it seems to be correct (unstretched) now but I see stripes on the screen (a stripe in regular color about 10 pixels in height and a stripe with darker color also about 10 pixel in height, repeating). But in this mode the picture is still on the lower side of the screen, it does not fill the full screen.

Link to comment
Share on other sites

That's interesting, considering that the only thing I did was add new modes. The "square pixels (fixed multiples only)" mode is just the "integral square pixels" mode renamed. I haven't made any changes at all to the DirectDraw code.

 

The stripe patterns you are seeing are likely the result of scaling down and forcing point sampling mode. The fixed multiple modes will fall back to fractional scaling if the zoom factor drops below 100%. If you are using 320x240 as the display resolution this will always happen for any overscan mode other than OS Screen Only as current versions of Altirra are not intended to run at that low of a resolution. The Normal overscan mode is 336x240/288, the Extended mode is 376x240/288, and the Full mode is 456x262/312.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...