Jump to content
IGNORED

Altirra 3.20 released


phaeron

Recommended Posts

Version 3.20 of my emulator Altirra is out:

 

http://www.virtualdub.org/altirra.html

 

As usual, thanks for everyone who helped with testing, suggestions, criticism, analysis, and witty banter during 3.10's development. 3.20 is almost the same as the last 3.20-test release, except for a small bug fix (broken BASIC profiling option).

 

Highlights since 3.10 (https://atariage.com/forums/topic/281825-altirra-310-released ) :

 

  • Accuracy: Fixes to several cartridge types, VBXE, Black Box, raw Shift key handling.
  • Disk: Fixes to address and data CRC error handling, non-standard sector size encoding support, ATX physical sector size chunk support, rotate disk now works with full disk drives.
  • Debugger: Additional disk debugging features, bank-sensitive breakpoints and symbol lookup for AtariMax carts, deferred auto-loading of symbols, more Turbo-Basic XL debugging support, minor fixes to various commands.
  • Devices: APE Warp+ OS 32-in-1 is now emulated, Ultimate1MB can soft-control stereo and Covox, fixes to some broken modem and CIO acceleration options.
  • Display: Hardware accelerated effects support including distortion and bloom, new color preset for the NTSC 800 model, new overscan preset to match modern widescreen displays.
  • Firmware: Updated to Altirra BASIC 1.56 with minor startup fix, AltirraOS 3.17 with fixes to the math pack, SIO, boot screen, and keyboard handler.
  • Software: The ColorMap tool on the Additions disk now supports CTIA systems.
  • UI: Easier enabling/disabling of portable mode, enhanced drag-and-drop support, system overview/recommendations, escaped text paste, Alt+click to decode BASIC PEEK/POKE addresses, mounted tapes and non-internal BASIC carts now persist, fixes to input state and console controllers in 5200 mode, bogus DOS/Windows executable detection, automatic BASIC/binary switching for tape boot.

 

And per tradition, now that there's been a release, new test release:


http://www.virtualdub.org/beta/Altirra-3.90-test1.zip
http://www.virtualdub.org/beta/Altirra-3.90-test1-src.zip

 

  • Experimental support for dark theme. This is hidden behind a /dark command line switch because it is incomplete due to a ton of really annoying restrictions in the OS (basically a total lack of actual dark support in the Win32 API), so I'm not sure if it's feasible to get it to a polished state, but it works well enough that I've left it on for my own development. Some UI elements like buttons and menus are not reskinned due to insufficient OS support (short of going ham on owner draw).

    image.png.e32f9e7ae193a98baa93b2cc95f3a1fc.png
     
  • Improvements to the debugger's Disassembly window. As seen above, it now has an option to infer and visually separate procedures, as well as hyperlinking and previewing JSR/JMP targets. This makes it possible to peek at the called procedure without losing your place. There are also go back/forward buttons.
  • The history loop detector has been updated to more tightly identify loops, reducing the number of loose instructions in the trace.
  • Disassembly options in the disassembly and history windows are now saved.
  • Several debugger commands that take paths now accept "?" as the path, which causes the debugger to open a file dialog to browse to the desired file: .loadsym ?
  • Accuracy improvements based on research into power-up state on actual hardware. Several registers have been tweaked to have more representative values, and the reset NMI on 400/800 models is now properly synchronized to vertical blank.
  • WIP on new save state system. The format has been changed to a zip file with mixed JSON and named memory block files, which makes it much easier to pull out data with tools. The internals have been rewritten as well to better support in-memory saves and extensibility, the CPU save code can now save in the middle of an instruction, and standard disk drives can now save and restore a pending disk read operation. The plan is to gradually increase the amount of state saved, including device state that previously hasn't been saved. Note that saving to the v1 *.altstate format is no longer supported, although loading it still is, and this is still very new so I really don't recommend keeping your valuables in save states.
  • Tape decoding and emulation code has been partially rewritten. The emulation-side of the tape decoder has been rewritten to be edge-based with much less host CPU load during tape operations, especially with acceleration on. There is also a prefilter option now to reduce phase shifts from high-frequency attenuation, which improves the reliability of turbo decoding of tapes archived using non-Atari tape recorders.
  • The Add Firmware UI now has heuristics to detect 10K and 16K OS ROMs other than the specific Atari ROMs in the signature list, including custom OS ROMs. This helps detect when a ROM image appears to be another 16K ROM type is actually an OS ROM.
  • AltirraOS updated to 3.20: XL/XE mode boot screen now continues boot instead of restarting when a disk is inserted for faster boot and preserving Option suppress-BASIC state, POKEY configuration changed to give more familiar sound during tape loads, QUICKED.SYS and SIDE Loader compatibility fixes, fixed background color in GR.11, fixed combined disk+rightcart and disk+tape boots. This ROM export package is attached for people testing this outside of the emulator.

 

Also, deprecation notice: 3.20 will be the last major version of the emulator to support Windows XP/Vista. The plan is to release the next version as 4.00 with Windows 7 as the minimum OS. 3.90-test1 still currently builds with XP targeting but I will be changing over to the newer non-XP toolchain in the future.

 

AltirraOS-3.20.zip

  • Like 20
  • Thanks 25
Link to comment
Share on other sites

Love the dark theme already. This is going to be easier on the eyes during late-night debugging sessions.

 

Still hoping to see NVRAM and firmware (U1MB, etc) registry entries housed inside of profiles one day, although I guess I could accomplish the same thing with multiple portable configurations.

  • Like 1
Link to comment
Share on other sites

So much better on my failing eyesight.. thank you for the experiment into dark mode!

 

I was cheering with all I was reading, and was looking for Einstein to give his paw print of approval. Each sentence was spelling out every joyful needed fix and improvement. The culmination of Avery's hard work both impressive and monumental. Then Einstein walked away... no paw print.. seems he was not at all joyful to hear XP/Vista planning to be dropped, seems retro folks (and pups) love to use the XP and Vista flavors of that OS and some despise the abomination of 10 et al.

 

What can I say.. He's clearly correct as I am using a Vista machine to make this post, and the machine that rules all of the hardware programmers and emulation is an XP box. Many of the gizmos that handle making the hardware updates, flashing, programming will only ever work via XP. Many being end of line drivers and devices with no path to newer OS monstrosities.

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

These are the droids you are looking for...

http://www.virtualdub.org/beta/Altirra-3.90-test1.zip

http://www.virtualdub.org/beta/Altirra-3.90-test1-src.zip

 

To edit a posted link, click edit to go back into your post, highlight the link, hold control and right click... it will give you a choice to edit the link or do otherwise...

 

Edited by _The Doctor__
  • Like 2
Link to comment
Share on other sites

Hmmm,

 

with Altirra 3.20 test 18 there was a new version of Altirra Basic released, V1.56. The update comment read as follows: ATBasic 1.56: Fix for crash that occurred when hitting Break prior to startup banner.

 

Now the official release of Altirra 3.20 also includes Altirra Basic V1.56 but with that update comment:  Updated to Altirra BASIC 1.56 with minor startup fix.

 

So both versions are V1.56 ?!? Do they have different updates - or are the updates one and the same ?!? (minor startup fix = fix for crash that occured...? -or- minor startup fix <> fix for crash that occured...?)

 

Edited by CharlieChaplin
Link to comment
Share on other sites

a Rose by any other Name?  While you might consider a crash major, someone who see's lot's of crashing in their day to day work might classify it as minor... I would hope and think they are indeed the same version with a different comment attached is all

Link to comment
Share on other sites

Thanks for catching the link issue, I like the new editor less now. At least Edit worked this time so I could fix the random emoji.

 

6 hours ago, _The Doctor__ said:

So much better on my failing eyesight.. thank you for the experiment into dark mode!

 

I was cheering with all I was reading, and was looking for Einstein to give his paw print of approval. Each sentence was spelling out every joyful needed fix and improvement. The culmination of Avery's hard work both impressive and monumental. Then Einstein walked away... no paw print.. seems he was not at all joyful to hear XP/Vista planning to be dropped, seems retro folks (and pups) love to use the XP and Vista flavors of that OS and some despise the abomination of 10 et al.

 

What can I say.. He's clearly correct as I am using a Vista machine to make this post, and the machine that rules all of the hardware programmers and emulation is an XP box. Many of the gizmos that handle making the hardware updates, flashing, programming will only ever work via XP. Many being end of line drivers and devices with no path to newer OS monstrosities.

Let me explain my thinking here in more detail. This was a deliberate shot across the bow to force the issue, in a way. 3.90 test-1 still actually runs on XP/Vista as the build configuration hasn't changed yet. Switching over to SSE2-required went over well, but I expected this one to be more contentious.

 

I'm not in the camp of "XP is bad because it's old." It is old, but the argument that XP is almost 20 years old clearly wouldn't be a sound argument with the users of an emulator of a 40 year old computer. Nor do I subscribe to the idea that everyone in the world should instantly drop XP because it no longer receives updates, because as you note there are still reasons to need to use it in a more isolated environment. But one thing that is clear is that XP becomes harder to use each year. Besides the security issues with using it on the Internet, it's simply being left behind because you can no longer run an up to date web browser on it, even Firefox ESR having dropped support. Many other popular programs have finally dropped XP support as well, so increasingly software simply won't run on the platform.

 

It's also getting harder to continue to build programs for XP. Visual Studio dropped full support for XP a long time ago, and for several years it has been impossible to run Visual Studio on an XP machine to debug or profile directly on it. Building programs for XP requires switching to a older SDK setup that has been on life support, and I've had to do increasing hacks in the source to continue to both support XP and the newest Windows 10 features like DPI scaling. Recently I've run into a number of problems with the Rich Edit UI control having different bugs features on XP vs. 7/10, and the only XP machine I can test on is a sad little HP Mini in the corner that is even having trouble connecting to network shares due to SMB1 protocol deprecation. XP also has unique Direct3D issues and doesn't support some newer technologies that would be nice to use like Direct2D. Visual Studio 2019 has also finally dropped XP targeting support entirely, and the upcoming 16.2 release is going to have some major compiler improvements that I'll be interested in. This all means that supporting XP in Altirra is has some visible costs that are slowly increasing over time.

 

Vista is an interesting case. It's not quite as bad as XP since it's newer and a lot of techs were introduced in Vista, but Vista has been on life support for a long time and kept viable only because of XP since anything that can run on XP also runs on Vista. Vista's market share dropped even faster than XP and the majority of software companies dropped Vista as soon as they could drop XP. Continuing to support Vista longer is viable but not great, I literally have no computers running Vista to test against and still minimal debugging tools and no profiler. At best this would only extend Vista for perhaps one release. Windows 7, on the other hand, is not really going anywhere for a long time as it is quickly becoming the "new XP" but in a far better state than XP SP3, aside from the end of official Microsoft support.

 

The conclusion is all of this is that while the deadline for dropping XP/Vista support can be negotiated, it is going to have to happen at some point. The question is how long to delay ripping off the band-aid.

 

  • Like 8
Link to comment
Share on other sites

6 hours ago, _The Doctor__ said:

... seems he was not at all joyful to hear XP/Vista planning to be dropped, seems retro folks (and pups) love to use the XP and Vista flavors of that OS and some despise the abomination of 10 et al.

 

What can I say.. He's clearly correct as I am using a Vista machine to make this post, and the machine that rules all of the hardware programmers and emulation is an XP box. Many of the gizmos that handle making the hardware updates, flashing, programming will only ever work via XP. Many being end of line drivers and devices with no path to newer OS monstrosities.

ALL of my Windows computers run XP. I don't own a W7/8/x/10 computer.

This is sad news.

 

  • Like 1
Link to comment
Share on other sites

1 hour ago, CharlieChaplin said:

with Altirra 3.20 test 18 there was a new version of Altirra Basic released, V1.56. The update comment read as follows: ATBasic 1.56: Fix for crash that occurred when hitting Break prior to startup banner.

 

Now the official release of Altirra 3.20 also includes Altirra Basic V1.56 but with that update comment:  Updated to Altirra BASIC 1.56 with minor startup fix.

 

So both versions are V1.56 ?!? Do they have different updates - or are the updates one and the same ?!? (minor startup fix = fix for crash that occured...? -or- minor startup fix <> fix for crash that occured...?)

They are the same. It's minor because while you can trigger it just by hitting Break, I only found it because of a weird corner case: switching to enhanced text mode in the emulator causes it to inject a Break key press to break out of the K: loop so the enhanced text engine can take over for input. The enhanced text view is rarely used, but I use it sometimes when working in BASIC and a 40x24 screen is too small.

 

The release process for Altirra BASIC a bit weird since it is versioned independently from the emulator. Those who have followed the emulator threads on here for a long time may have noticed that I don't always use the same wording for the changelogs here as in the official changelog. This is for two reasons, one being that on these threads I bias the descriptions toward what to watch out for with regard to possible breakage, and also because official changelogs are PR in a way -- they're how you "market" a new release by giving a reason for users to want to upgrade to it. (This is a bit more reasonable than the "because you have no choice" attitude that many software companies have nowadays.)

 

Because the Altirra firmware set is being increasingly used outside of Altirra itself, the HTML readme that gets spit out by Altirra's "Export ROM Set" feature is now the authoritative list of changes for each release. Even if AltirraOS or Altirra BASIC gets updated more than once during an emulator release, the ROM images themselves contain a version number that can be cross-referenced against the README. The only reason I don't separate them entirely is just that it's more convenient to build them as part of the emulator.

 

Link to comment
Share on other sites

1 hour ago, rdea6 said:

AltirraCrash.zip 16.9 kB · 3 downloads

A small crash while using emulator as an IDE +20 with VHD file and a MyDos  ATR attached to D1:  trying to copy file to D1: from VHD partition.  NOT able to replicate error.  Also PCLINK is not being registered as a Device.

 

Derp. I tested disk reads, I didn't test disk writes. Tells you how weird my usage patterns are.

 

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

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

  • Fixes non-command SIO writes. This was a regression from some surgery I did for save states.
  • Fix for the color matching setting not being set properly on initial start. (Candidate fix for a 3.21 release, if I do one.)
54 minutes ago, Kyle22 said:

ALL of my Windows computers run XP. I don't own a W7/8/x/10 computer.

This is sad news.

Yeah, I'm sorry, I was thinking of you when mulling this over. I've held out with continuing to support XP for this far, but that can only go on so long if Altirra is to continue moving forward.

 

  • Like 3
Link to comment
Share on other sites

3 hours ago, phaeron said:

But one thing that is clear is that XP becomes harder to use each year. Besides the security issues with using it on the Internet, it's simply being left behind because you can no longer run an up to date web browser on it, even Firefox ESR having dropped support.

 

Web browser development isn't quite dead yet... see here:

 

https://msfn.org/board/topic/177125-my-build-of-new-moon-temp-name-aka-pale-moon-fork-targetting-xp/

  • Like 2
Link to comment
Share on other sites

4 hours ago, Kyle22 said:

ALL of my Windows computers run XP. I don't own a W7/8/x/10 computer.

This is sad news.

 

Not trying to be an asshole, but come on man - it's 2019, not 1995.  Things change.  These old OSes are utter SHIT at protection, etc.  There's plenty of ways to keep the spyware from 3rd parties and OS people turned off.

  • Like 3
Link to comment
Share on other sites

I have a feature request.

 

Story of what I'd like to achieve:

I would like to be able to rip out graphics from games without needing to process the images later.

 

* I guess I could do some memory dumping, however it is not very user friendly though.

* I would like screens with 40 byte width graphics (I guess it would need to be only those using 40byte width throughout the whole screen) to be saved as a screenshot which gives a 40 byte output (160 pixels, bit-packed), saved in a raw format, no headers.

- I have noticed that screenshots save as 336 pixel wide images, I'd like no border and to save as 40 byte width.

 

Therefore I'd like the file content to be precisely that of the screen (presuming the same width all the way down the screen)

 

Could this be possible?

Link to comment
Share on other sites

2 hours ago, Stephen said:

Not trying to be an asshole, but come on man - it's 2019, not 1995.  Things change.  These old OSes are utter SHIT at protection, etc.  There's plenty of ways to keep the spyware from 3rd parties and OS people turned off.

LOL, the new operating systems ARE spyware, and you can't turn it off. If anything, it is less secure because you have no control over the data they collect on you.

Edited by firebottle
additional info
  • Like 2
Link to comment
Share on other sites

1 hour ago, snicklin said:

I would like to be able to rip out graphics from games without needing to process the images later.

 

* I guess I could do some memory dumping, however it is not very user friendly though.

* I would like screens with 40 byte width graphics (I guess it would need to be only those using 40byte width throughout the whole screen) to be saved as a screenshot which gives a 40 byte output (160 pixels, bit-packed), saved in a raw format, no headers.

- I have noticed that screenshots save as 336 pixel wide images, I'd like no border and to save as 40 byte width.

 

Therefore I'd like the file content to be precisely that of the screen (presuming the same width all the way down the screen)

 

Could this be possible?

Depends on how complex the screen is.

 

First, note that the screenshots saved aren't always 336 pixels wide, this depends on your view overscan settings. The OS Screen setting will target 160 color clocks, so it will be closer to what you want. Games are mostly well behaved for the horizontal axis because ANTIC only allows for a few specific widths. The height is controlled by the display list, however, and games aren't very consistent about where they position the screen. For that case it's possible that there is no built in overscan setting that will fit precisely. The emulator does know the precise bounds of the playfield or P/M graphics, but it doesn't know what constitutes the "screen" that you may want if it's different than those.

 

I could see some more refined save options, such as a debugger command that lets you save a specific region by beam positions, and an auto-incrementing fire and forget command. That having been said, it would be a good idea to learn a Python image library or how to script ImageMagick, because it would make it easier to do further transformations on the images. With such a script you could just take images with the existing version on max overscan and then just batch-crop them to what you want.

 

As for the format... what would you use to process the images? There's indexed color or 24-bit RGB/BGR, but many languages nowadays can easily consume PNG, and there's also interesting data that the emulator has internally such as which parts of display list go along with each image. If the game's display is a simple screen like an OS graphics mode, you could even process the raw memory from the new save state v2 format -- it's designed so that in Python you can pop open the zip file and have relatively easy access to main memory and the hardware register states.

 

  • Like 1
Link to comment
Share on other sites

6 minutes ago, phaeron said:

Depends on how complex the screen is.

 

First, note that the screenshots saved aren't always 336 pixels wide, this depends on your view overscan settings. The OS Screen setting will target 160 color clocks, so it will be closer to what you want. Games are mostly well behaved for the horizontal axis because ANTIC only allows for a few specific widths. The height is controlled by the display list, however, and games aren't very consistent about where they position the screen. For that case it's possible that there is no built in overscan setting that will fit precisely. The emulator does know the precise bounds of the playfield or P/M graphics, but it doesn't know what constitutes the "screen" that you may want if it's different than those.

 

I could see some more refined save options, such as a debugger command that lets you save a specific region by beam positions, and an auto-incrementing fire and forget command. That having been said, it would be a good idea to learn a Python image library or how to script ImageMagick, because it would make it easier to do further transformations on the images. With such a script you could just take images with the existing version on max overscan and then just batch-crop them to what you want.

 

As for the format... what would you use to process the images? There's indexed color or 24-bit RGB/BGR, but many languages nowadays can easily consume PNG, and there's also interesting data that the emulator has internally such as which parts of display list go along with each image. If the game's display is a simple screen like an OS graphics mode, you could even process the raw memory from the new save state v2 format -- it's designed so that in Python you can pop open the zip file and have relatively easy access to main memory and the hardware register states.

 

 

Thank you for your reply. I am of the belief that I should be able to do what I am looking to do either by manipulating the bytes dumped from memory as you mention. I could use ImageMagick etc, yet I was looking for a way so that I could avoid all of this extra work. Yes, laziness prevails....! :)

 

You've mentioned the screen starting at different points, I was hoping that a routine in Altirra could work out where the start is from all the different settings that are in place and then present it to the user in a simpler way. I almost imagined a menu entry being a 'hook' to a routine which processes the screen.

 

You've asked which program I would use to manipulate the image, essentially I wouldn't (at least not in a normal program). I'd just have a dump of the whole screen (yes, different modes in use could make this complicated) and I'd identify the parts that I want and would remove them with a hex editor.

 

Yes, potentially a debugging command to dump a section of the screen would be fine.

 

Or a way to draw a rectangle on a paused screen and then have that dump out packed binary (4 pixels=1 byte for gr.12) for what is inside it. A routine would need to be able to work out what mode is being used underneath it. Perhaps if multiple modes are detected, a data dump is refused? A text mode would need to be represented as a graphics mode, i.e. 0->8, 12->15

 

I appreciate the difficulty in achieving what I am asking for, as I can see that no solution would be perfect. If it's a massive bit of work, I'd say leave it, but if you can think of a relatively quick way of achieving this, I'd really appreciate it.

 

Link to comment
Share on other sites

2 hours ago, snicklin said:

 

You've mentioned the screen starting at different points, I was hoping that a routine in Altirra could work out where the start is from all the different settings that are in place and then present it to the user in a simpler way. I almost imagined a menu entry being a 'hook' to a routine which processes the screen.

 

You've asked which program I would use to manipulate the image, essentially I wouldn't (at least not in a normal program). I'd just have a dump of the whole screen (yes, different modes in use could make this complicated) and I'd identify the parts that I want and would remove them with a hex editor.

 

Yes, potentially a debugging command to dump a section of the screen would be fine.

 

Or a way to draw a rectangle on a paused screen and then have that dump out packed binary (4 pixels=1 byte for gr.12) for what is inside it. A routine would need to be able to work out what mode is being used underneath it. Perhaps if multiple modes are detected, a data dump is refused? A text mode would need to be represented as a graphics mode, i.e. 0->8, 12->15

 

I'm having some difficulty figuring out what you're actually looking for. Laziness is fine, but a hex editor is the farthest from lazy you could get for this.

 

If what you want is a raw memory dump of screen memory, the debugger can be scripted to do this without too much effort if the program is still using the OS to set up the screen, just need to dump bytes from SAVMSC to TXTMSC for the main screen:

Altirra> ap "savescreen %1" ".writemem %1 dw(savmsc) L>dw(txtmsc)-1"
Defined alias: savescreen %1.
Altirra> savescreen e:\x.bin
Wrote 9C40-9F5F to e:\x.bin

Ditto for dumping the character set from CHBAS, if desired.

 

There are a couple of other pieces of useful info, such as the display list (.dumpdlist), or the display list history:

 

Ycoord DLIP PFAD H V DMACTL MODE
--------------------------------
    8: 9c20 a000 0 0   22   70
   16: 9c21 a000 0 0   22   70
   24: 9c22 a000 0 0   22   70
   32: 9c23 9c40 0 0   22   42
   40: 9c26 9c68 0 0   22   02
...
  208: 9c3b 9fb0 0 0   22   02
  216: 9c3c 9fd8 0 0   22   02
  224: 9c3d a000 0 0   22   41

If these are useful, it would probably be easiest right now to just dump it to text form with the .logopen command and then parse that. Right now you can't specify multiple commands with aliases, so it would be necessary to run a batch file instead.

 

Debugger commands are easier for me to write, just because I can then avoid creating UI for them and finding a place to put it. But that still leaves a lot of questions as to the best format, and there are quite a number of formats I can write equally easily but which may be more or less difficult for you to consume. For instance, if you're planning on consuming this from BASIC, I can make the debugger dump to DATA statements -- I've had a couple of times where that could be useful. Or, alternatively, suggest some Python fragments to transform. Python is the new BASIC, it's really easy to do things like extract a range of bytes from a binary file and then repeat it 40 times (data[1000:1016]*40).

  • Like 1
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...