Altirra 2.60 released

[phaeron]

So you already installed Window 10 for free that offer from Microsoft ? Like Window 10 better than Window 7 ? That I am using currently 7. It does offer free. I have not been installed it yet.

 

Don't want to get too much into Windows 10 in this thread, but... I ran the Preview builds in a VM, and my HTPC is now running 10 RTM through the free upgrade offer, upgraded from 8.1. I have not yet updated my main computer although I will eventually.

 

For Altirra, you will not really notice a difference in operation between 7/8.1/10. In general, Windows 10 is neither the spawn of the devil nor the savior of computing; ignore the raging fanboys on both sides and get your advice from level-headed sources (i.e. not Reddit). Few things to be aware of: make sure your desktop/laptop vendor has Windows 10 drivers available, as a few don't and have explicitly warned to hold off upgrading; don't upgrade if you have Windows Media Center and can't lose it; be aware of the Windows Update and Defender changes for Home Edition; performance is generally slightly better but not groundbreaking; application compatibility is generally very good compared with Windows 7. In any case, an OS upgrade is always a major undertaking, so don't upgrade before you're ready, back up your data and be prepared to reinstall if things go south, and keep in mind that you have about a year to upgrade free if you want to wait a few months for initial issues to be ironed out.

[fujidude]

Hi Avery, can you confirm that the PCLINK server, as provided by Altirra does not support SDX's XIO 39 (get file size) function? I'm not really concerned about if it does or doesn't, I just want to know if an issue I have seen is because of that or with a program I wrote. I have already gotten it from draco030 that it is supported in the PCLINK.SYS driver included for use with SDX 4.47.

 

I get error 146 when attempting to use XIO 39 on any file which resides on the PCL: device, but get normal expected results from files that reside anywhere else.

Edited August 13, 2015 by fujidude

[Roydea6]

Hi Avery, can you confirm that the PCLINK server, as provided by Altirra does not support SDX's XIO 39 (get file size) function? I'm not really concerned about if it does or doesn't, I just want to know if an issue I have seen is because of that or with a program I wrote. I have already gotten it from draco030 that it is supported in the PCLINK.SYS driver included for use with SDX 4.47.

 

I get error 146 when attempting to use XIO 39 on any file which resides on the PCL: device, but get normal expected results from files that reside anywhere else.

Would it work if you made the command 'DPCL:' instead of just PCL:

[fujidude]

No. The filename is produced by the ZCRNAME routine, so it already is. Observe:

I:\
#AAC PCL:TELIX.ASC H:TELIX.TXT /T

AAC 1.2 (C) 2015 FujiDude
Free software licensed under the GPL3

Translating to ATASCII.
Infile = DPCL1:TELIX.ASC
Outfile = D8:TELIX.TXT

Processed: 211KB

Conversion complete.

I:\

[phaeron]

Fixed:

http://www.virtualdub.org/beta/Altirra-2.70-test21.zip

http://www.virtualdub.org/beta/Altirra-2.70-test21-src.zip

 

Also:

• POKEY: Fix regression where having the serial port in external clocking mode with no external clock blocked the serial polling bit.
• AltirraOS: Tweaked line drawing to be closer to XLOS for ambiguous cases.
• AltirraOS: Fixed Mad Pascal plot incompatibility due to undocumented PUT RECORD with len=0.
• Debugger: Fixed .readmem command.
• U1MB: Force BASIC enable in 1200XL mode.
• UI: MInor reorgs to settings window.
• UI: Fixed PRT: acceleration option not saving.
• Additions: High-speed XEP80 handler is now officially added to the Additions disk.
• Display: NTSC artifacting engine optimized in x64 build.
• Cartridge: Raise size limit to allow drag-drop of 128MB cart images.
• VideoRecording: Fixed black screen when recording with scanlines enabled but not VBXE or artifacting.

[serj]

Avery, if it is not difficult, can I ask for you a slight improvement for the emulator.

whether it is possible to make an option "Recently booted" - edited?

for example I choose any of the running game early, press on the right mouse button and choose Delete.

so you can edit the list of running early games (programs) and keep in the list only the necessary.

and still would like to list was more, such as 15 - 20 programs, 10 short.

[phaeron]

Might be able to do that, but I'm not sure it'd be a good idea... the MRU list isn't really meant to act as favorites. It's kind of like the equivalent of keeping your valuables in the Recycle Bin or undo buffer. I'm thinking it would be better to have a separate list for stuff you really use often.

[flashjazzcat]

On the display turning white -- this typically means that the display code has hit a display API error that it wasn't able to recover from. Try switching to the Direct3D 11 display driver in Options and see if you get any different behavior.

Switched to Direct3D 11 and haven't had a problem since: thanks again.

[Keatah]

Feature Request:

 

I got playing around with the DiskEditor showcased in this thread:

http://atariage.com/forums/topic/241865-disk-explorer/?do=findComment&comment=3304404

 

..and it was the first time I set up the ST mouse on port 2 in Altirra. It worked, but I found myself picking up the mouse several times and repositioning it before I could scroll from one side of the emulated screen to the next.

 

I think there needs to be a sensitivity adjustment for the emulated mouse.

[flashjazzcat]

There already is sensitivity adjustment for the emulated mouse.

 

 

Input->Input Mappings->Select input device->Edit.

 

How does the mouse speed compare to real hardware with this particular piece of software? If the software doesn't implement any kind of pointer acceleration or doesn't poll the mouse especially quickly, it'll be slow there too.

Edited August 21, 2015 by flashjazzcat

[Keatah]

Got it..

 

Not having an ST mouse, I couldn't compare. But setting the setting to Relative 10 helps enough to make it usable. And the pointer now traverses the screen entirely without the need to pick-up and reposition.

 

If I could make Avery extend the sensitivity to something like 12 or 14 it would be even better! Or maybe the Disk Explorer program needs tweaking?

[Keatah]

I must be burned out to have missed drilling down through the menus. Too much M.A.M.E. tweaking on the wife's arcade cabinet these past 3 weeks. Gotta get back into the Altirra mindset.

 

I'll cross-post some of this over in the Disk Explorer thread and see what I can see over there.

[flashjazzcat]

I see no issue with Altirra's acceleration, having performed numerous experiments with mouse sampling rates using real hardware. I like to nudge Altirra up to eight, but any further seems unrealistic. Sample rates of 800-1,000 Hz can be required for reliable interpretation of the grey code, and even then I found that performing software acceleration helped prevent "roll back", whereby the mouse is moved fast enough that the grey code is missampled and the direction of movement becomes ambiguous. This was at 320px horizontal resolution, however, so the problem should be abated somewhat by software which employs a PMG at 160px horizontal resolution.

[Keatah]

Are you saying that the numbers in altirra are per-100 Hz? ..with 8 being 800?

 

In windows (up to 7) I'm only aware of 4 possible sampling rates of the mouse. That would be 125Hz, 250Hz, 500Hz, and 1000Hz. And sampling rates don't increase or decrease movement sensitivity. Sample rates effect smoothness and continuity. Appearance..

[phaeron]

Different polling rates.

 

PS/2 and USB mice can be configured to send updates at varying rates, but each "poll" can return varying deltas, such as -100 or +50 in a particular direction. When the polling rate is lower, the mouse sends bigger deltas less often, and when the polling rate is higher, the mouse sends smaller deltas more often. A higher polling rate gives lower latency (faster response) and smoother motion, at the cost of using more of the USB bus and a bit more CPU. The default rate for USB mice is 125Hz, which is typically high enough for most uses (besides FPS games). The Amiga works similarly, in that the hardware counts the steps from the mouse and is polled by a routine in VBLANK.

 

In contrast, the Atari has no such hardware to accumulate delta counts. Instead, it has to poll the raw mouse output directly, watching for whether the quadrature output for each axis changes 00 -> 01 -> 11 -> 10 -> 00 or 00 -> 10 -> 11 -> 01 -> 00, and counting off the changes in the right direction. The catch here is that the 6502 has to catch every single change or else it misreads the motion. If it misses one and the counter changes 00 -> 11, it knows the mouse changed two steps, but not which direction. If it misses two counts, it'll mistake the three steps for one step in the wrong direction. This means that the mouse must be polled much more often on the Atari to work. For comparison, the Amiga's hardware counters only overflow after ~127 counts, so its 60Hz polling is equal to 7620Hz on the Atari. Moreover, this polling has to be regular, not clumped. This takes a lot of CPU time, which is a reason that mouse support isn't very popular.

 

Now, when it comes to Altirra, there is an additional consideration. Altirra receives mouse events from the OS, and those can be noisy -- timing a bit erratic, some events merged or delayed, and sometimes the emulator is busy doing a bit of emulation before it can see the event. The result is that the emulator doesn't see mouse movement smooth enough to replay directly in the emulation -- if it tried to do so, you'd see cases where the mouse ran too slowly one frame and then overran the program the next. To work around this, the emulator internally buffers a few frames of the mouse to smooth the motion a bit, and then pushes the steps out to the emulation at a throttled rate of about 490Hz max (32 scanlines/step). This largely avoids overruns but means that you can see some different behavior in the emulator from what you'd see on real hardware.

 

There's also the issue that modern mice have much higher resolution than Amiga or Atari ST mice, and modern OSes often apply acceleration curves that don't match the linear behavior you'd see from reading an old mouse straight. I found my Amiga mouse a while ago and have been meaning to do some comparisons, but haven't gotten around to it. The one thing that I have confirmed is that you can't actually read the right mouse button on an unmodified Amiga mouse on an Atari.

 

[flashjazzcat]

I have compared Altirra's behaviour to a range of original and aftermarket ST and Amiga mice and it seems to me very authentic given the considerations you've outlined.

 

Polling the mouse needn't be unmanageably CPU-intensive: it's the OS timer IRQ dispatch which really slows things down, although you can of course use a series of DLIs. Once you're actually in the interrupt code, if the port bits haven't changed since the last read, you just RTI. Before we honed the mouse driver in the GOS thread, it was reliant on behaviours seen elsewhere, including pointer bounds checking inside the interrupt, which wastes time (just accumulate signed directional changes and process in VBI, or - as Diamond GOS does - use a DLI to buffer raw port reads and process them in a group every frame). These approaches really don't have a catastrophic impact on mainline code.

 

Another approach is to simply block on mouse action: have a tight loop polling the mouse, drawing the pointer, waiting for cliks of keystrokes. This is the way the old Multi-mouse driver worked.

[phaeron]

Well, I sat down to play a bit of Kaboom!, and found that it was basically unplayable with an Xbox 360 controller... so some tweaks to the input code were required. After some work, I still suck at Kaboom!, but the controller input mappings are now straightened out and more tunable:

 

http://www.virtualdub.org/beta/Altirra-2.70-test22.zip

http://www.virtualdub.org/beta/Altirra-2.70-test22-src.zip

 

There is now a menu item Input > Input Setup that brings up a dialog where game controller input can be tuned. The dead zones for the 2D and 1D axes can be set, and more importantly, the dead zones can be set differently for analog input vs. digital input. This is useful because dead zones usually need to be bigger when mapping a stick to 4-way or 8-way D-pad input vs. using it for analog input. For analog mappings, there is now a "stiffness" option that allows a power curve to be applied, which can make fine control easier. For digital mappings, the conversion now uses an octant mapping, which allows a better hit zone for cardinal directions and directly going to diagonals.

 

There is no help for the dialog yet, so here's a cheat sheet:

• The four input windows displayed are: left stick (axes 1-2), left trigger (axis 3), right stick (axes 4-5), right trigger (axis 6).
• The black crosshair or line is the raw position.
• The small dot is the adjusted position used for analog mappings, e.g. paddles. The analog dead zone is displayed as a gray disc. Adjust this to a reasonably low level that doesn't cause the game control to drift annoyingly when the stick is in the center. You'll notice that the dot is a bit off from the crosshair when the dead zone is non-zero -- this is intentional so that input ramps up smoothly from zero at the edge of the dead zone.
• The red arrows are the directions triggered for digital mappings, e.g. joysticks. The digital dead zone (threshold) is the red circle. Adjust this up if the digital input is too sensitive or drifts at center; adjust it down if it is not responsive enough.

A few bugs in the mappings were also corrected -- IIRC, DirectInput had analog mappings upside down from digital mappings for analog sticks, and XInput had the triggers on different axis numbers for digital and analog mappings. This became pretty obvious with the visualization. You may need to adjust your input maps as a result. If you run into problems, let me know the mappings you're having problems with, i.e. Joystick, Up -> Left Stick Up, and whether you're using the XInput (Xbox 360) controller or not.

 

Other changes in this version:

• Debugger: Improved keyboard navigation in the History pane when browsing search results.
• DragonCart: Added support for a forwarded incoming UDP/TCP port pair from the host to the emulation network, fixed bugs in DHCP and ARP handling (Contiki IPCONFIG now works), fixed a number of bugs in the TCP stack, and added support for VXLAN tunneling. VXLAN tunneling allows the emulator to connect its internal emulation net to other systems that support the VXLAN protocol, which is essentially Ethernet over UDP. Linux and *BSD systems can connect to the emulation network this way if you futz with their firewall configurations, which allows the emulation to communicate with a real TCP/IP stack, and also allows the emulation network to be monitored with Wireshark.

 

[TheMontezuma]

Hi,

I tested today 2.70-test22 with new CONTIKI and got an Altirra crash.

 

 

A dump is attached (please rename to AltirraCrash.mdmp) AltirraCrash.mdmp.txt

[phaeron]

Fixed, try now:

http://www.virtualdub.org/beta/Altirra-2.70-test23.zip

http://www.virtualdub.org/beta/Altirra-2.70-test23-src.zip

[w1k]

lol..

 

any update xxxx new bugs

[+MrFish]

lol..

 

any update xxxx new bugs

 

There's only one "bug" that persists in this thread.

 

Maybe Albert needs to be alerted to your activities...

[Keatah]

lol.. any update xxxx new bugs

 

That's right, there are new bugs with these releases - which are typically resolved in the "official" release.

These Altirra-2.70-testXX.zip releases are just that. Tests. Expect things to get broken, fixed, added and removed.

[bfollett]

w1k doesn't really care if there are bugs, he just likes to stir things up in any thread I've ever seen him post in. On top of that, I believe I remember a while back that Phareon said w1k was the first and only member who's posts he's blocked... so it's not like the author of Altirra is even going to see his post.

 

Bob

[TheMontezuma]

Fixed, try now:

http://www.virtualdub.org/beta/Altirra-2.70-test23.zip

http://www.virtualdub.org/beta/Altirra-2.70-test23-src.zip

 

Thanks. 2.70-test23 works stable with CONTIKI

[phaeron]

A project that isn't getting any new bugs has either (a) discovered the holy grail of software development or (b) is a dead project.