Altirra 2.70 released

[Roydea6]

 

Make them R/W and then you don't need to save.... Autosave ineffect with R/W

 

[Fuji-Man]

This was under 2.71.

 

I had it set to R/W.

The filename box would change color.

I didn't notice that, maybe that is some indicator that the ATR needs saving.

I don't know. The emulator told me the files were saved. They were not.

I shouldn't have to save the image anywhere.

I load an image, it should be writable, readable, get status, eject, swap, etc. as any disk drive.

When the BASIC cartridge says it is saved, it should be. Not stored in a buffer, but on the disk.

 

I all I know is that I lost a full day typing, proofreading, testing an entire magazine and saving to a ATR that wasn't updating.

[flashjazzcat]

Here, if I make changes to an ATR in Virtual R/W mode and then attempt to close down the emulator without saving it, a message box pops up reminding me to do so. If, on the other hand, I have the ATR set to "R/W", changes are committed immediately. I'm using 2.80 Test 50, however.

 

I doubt anything can be done here to help you move on from the trauma of losing a day's typing, but I do notice that if one ignores the change in colour of the virtual R/W drive slot and ejects the image, changes are lost. Clearly the colour change signifies unsaved changes, but it's quite easy to blunder past that and hit the eject button. So I'm wondering what the pros and cons would be of replacing this visual cue with a blocking message box saying "Lose changes?".

Edited August 12, 2016 by flashjazzcat

[morelenmir]

I cannot recall if I mentioned it before, but some kind of - opt-in obviously - timed auto-save feature would be very useful. In the past I have lost if not a whole day then several hours of typing because the drivers for my video card crashed and forced a reboot to recover. If Altirra had the capability to save state files every so often if would be very handy for this type of situation.

[flashjazzcat]

I think the advice "save often" applies particularly well to 8-bit computers, and therefore equally well to the emulated machine (and I'm talking about the user's practices inside the emulated machine). This, coupled with R/W ATR mode should ensure that hours of typing are not sitting in volatile RAM with no persistent copy. Auto-save in Windows applications is all very well but you will not find me typing more than a few paragraphs in Microsoft Word without hitting Ctrl-S at least once.

[fujidude]

@Fuji-Man: what version of Windows were you running Altirra under (assuming you were not running it under WINE in Linux).

[Fuji-Man]

WinXP SP3 all updates nearly minty fresh install. <30 days.

 

Now paranoid that I have to check & backup the ATR every time I save something.

I'm not going to type a third time.

 

I have reason to believe it may have only been an issue with 2.71.

I updated to latest beta and no problems yet.

[phaeron]

I'm sorry for your loss, but the statement about needing to explicitly Save is incorrect.

 

Writes to disks in read/write (R/W) mode are flushed within two seconds or when the disk is ejected, whichever comes first. Pending writes are not lost when you eject the disk and an explicit save is not needed unless you are making a copy or switching to different file. The only case where an explicit Save is needed is if the emulator hits an error trying to write back to the .ATR file. In that case, the disk drive indicator flashes to indicate a problem and the disk is remounted virtual read/write (VRW) to try to keep the changes until they can be resaved.

 

If the disk is mounted as virtual read/write (VRW), then you do need to explicitly save the changes, since that's the point of VRW mode. However, in 2.71, disks are auto-mounted as virtual R/W only when new disks are created, and in that case there is no file associated with the disk to save back to yet.

[Mclaneinc]

I understand the nature where people wait for 'finals' of software but Altirra is one of those quality programs where beta's normally offer additions and higher quality emulation rather than just programming fixes so in my opinion are always worth updating to, by all means keep a latest final but use the last beta, I seriously have great faith in them BUT I'm not a programmer but I have to say apart from the last few comments I can't remember a person mentioning that Altirra lost their work for reasons of incorrect emulation or the like

 

Also, when I did program back in the dark ages I followed the old adage of saving often as mentioned by FJC, I was a Q&D programmer (quick and dirty) who banged the metal at time rather than using shadow locations but I'd had a ZX81 previously with the wobbly rampack and lost MANY a type in thanks to it so I became adept at doing what IT tells you to do in data protection and SAVE a lot, the point here is that I don't think the emulator should be responsible for backing up work, its deal is to be as accurate as possible, data protection is your problem. It does include 2 forms of save states which should be more than good enough for stuff that isn't trying to push the hardware above and beyond (but probably is fine for even those) and the age old practice of saving to disk is even better covered in later Altirra's to safeguard data as if it was on a real machine. Sure there are safety options to try and cover lots of uses but its all in there and simply needs a bit of RTM

 

Not having a pop, every one in here is a star in my book but just relaying my 2p's worth and hopefully offering a little info in between..

 

Paul..

 

Again, I recommend looking at the beta's rather than waiting for full releases, there's usually all sorts of goodness added by Avery..

Edited August 13, 2016 by Mclaneinc

[fujidude]

WinXP SP3 all updates nearly minty fresh install. <30 days.

 

Now paranoid that I have to check & backup the ATR every time I save something.

I'm not going to type a third time.

 

I have reason to believe it may have only been an issue with 2.71.

I updated to latest beta and no problems yet.

 

Oh drats. If you were using Win 8.x or greater and had the file history feature engaged, it is likely that much of your work could have been recovered.

[fujidude]

@Phaeron: How does Altirra deal with mutable objects like disk images when there are multiple instances of Altirra running, and the same mutable objects are configured for use by each one?

Edited August 13, 2016 by fujidude

[phaeron]

You will get inconsistent disk states between the emulator instances and intermittent flush errors if they attempt to concurrently write. Don't do that.

 

[fujidude]

You will get inconsistent disk states between the emulator instances and intermittent flush errors if they attempt to concurrently write. Don't do that.

 

 

I don't. But since Altirra can run multiple instances, and it automatically uses the registry for initialization (or the ALTIRRA.INI file), I can see where someone could easily and accidentally find themselves in just such a situation. In fact, I got the impression that may have happened to Fuji-Man. And, I have to admit, it has happened to me once or twice in the past by accident; when I didn't realized I had a minimized instance running already. Fortunately, I did not happen to suffer any great hardship as a result. I do feel Fuji-Man's pain though.

 

Anyway... If it is possible for you to modify Altirra to disallow it's use of data files that another instance, or even another program altogether (though that may already be covered), and throw an "already in use" type of error, would you be willing to consider doing that? Even if it was limited to just preventing more than one instance with write capability that would solve much I should think.

 

As always, thank you for your efforts. They are appreciated regardless of the outcome of this feature request.

[gozar]

I'm setting up a little Lenovo X120e as a dedicated Atari Emulation machine, but am running into performance issues. I have Windows 8 installed, but the little guy can't seem to hit 60 fps reliably. Are there any performance tweaks I can do? Maybe the 1.6GHz AMD Fusion E-350 dual-core processor isn't powerful enough?

[Mclaneinc]

The usual things like minimal theme not using that built in theme engine it uses (name escapes me), making sure its running on Direct3d 9..

 

Also depends what you are hoping to run it as, a basic machine or U1m etc?

 

The more its emulating the more the CPU loss.

 

That's just my bit, I'm sure there's more technical things to turn off etc...

 

Edit: make it an offline machine and lose the Virus checker in realtime etc..

Edited August 15, 2016 by Mclaneinc

[Keatah]

For reference, I tried it out on a Pentium M 1.73GHz with integrated intel Extreme Graphics², this is dot-com era Centrino laptop hardware from 2004 and just about the worst graphics you can imagine. Less than Voodoo. And I was able to achieve a full 60FPS. 500 if I hit F1.

 

I had artifacting on, scanlines on, 65C816 at 10MHz, bilinear filtering, preserve aspect ratio, and the full-screen display set to 800x600 with direct3d. There was power to spare.

 

The combination of artifacting, scanlines, and 1024x768 is tough and resulted in 55 FPS. That's why I ran it at 800x600 - and then got power to spare. And believe it or not, the OSD of FPS counter does suck up some graphics power when you're doing full-screen.

 

ADDED:

I don't believe that Altirra can make use of multi-cores. So half that AMD chip isn't being utilized.

Edited August 15, 2016 by Keatah

[Fuji-Man]

Okay, got the magazine typed in and blood pressure to normal.

 

Don't get me wrong, I **REALLY** like Altirra. It's incredible.

 

but the drive box drives me batty.

 

I work with a lot of disk images. Lots of swapping...

 

1) Its modal. I have to open and close it every time I need to change disks.

2) Its not sizable. I have to insert cursor and move it to see which image is in each drive.

3) swapping disks, have to click box, tell i want to move it. click destination box.

 

I'd have to admit, but maybe I've been spoiled with the Tucker's APE interface.

 

Printer emulation is also a topic that also gets pushed to the back burner too often.

Maybe print to .SVG or a standard graphic format. But that's another mountain.

 

~Fuji~

[Fuji-Man]

4) Drag and drop images into the drive slots.

[phaeron]

I'm setting up a little Lenovo X120e as a dedicated Atari Emulation machine, but am running into performance issues. I have Windows 8 installed, but the little guy can't seem to hit 60 fps reliably. Are there any performance tweaks I can do? Maybe the 1.6GHz AMD Fusion E-350 dual-core processor isn't powerful enough?

 

Turn off vsync and see if that helps. Also, check that the processor is able to run at full speed, i.e. not limited by power saving settings. On that CPU you will probably have problems if the CPU is limited by the power profile being set to Power Saver -- if so try Balanced (not High Performance, which can be a misnomer). Turn off artifacting too if it is on, since this CPU looks rather weak at SSE2 instructions, even weaker than an Atom.

 

Unfortunately, I don't have a Bobcat CPU based system to test against. What I'd really need to see to diagnose this problem is an instruction sampling profile from Intel VTune or AMD CodeXL... it's a pain to set up if you're not a developer. Looking at the instruction tables, though, there is an issue with the MASKMOVEDQU instruction being unnaturally slow, as in "instruction takes thousands of clocks instead of dozens." I might be able to do something about that.

 

For reference, I tried it out on a Pentium M 1.73GHz with integrated intel Extreme Graphics², this is dot-com era Centrino laptop hardware from 2004 and just about the worst graphics you can imagine. Less than Voodoo. And I was able to achieve a full 60FPS. 500 if I hit F1.

 

I had artifacting on, scanlines on, 65C816 at 10MHz, bilinear filtering, preserve aspect ratio, and the full-screen display set to 800x600 with direct3d. There was power to spare.

 

The combination of artifacting, scanlines, and 1024x768 is tough and resulted in 55 FPS. That's why I ran it at 800x600 - and then got power to spare. And believe it or not, the OSD of FPS counter does suck up some graphics power when you're doing full-screen.

 

ADDED:

I don't believe that Altirra can make use of multi-cores. So half that AMD chip isn't being utilized.

 

Intel Extreme Graphics has no pixel shaders, so yeah... the name is a bit of an overstatement. No pixel shaders means no acceleration for paletted textures, although if you have artifacting on, it'll have to upload 32-bit anyway. In that configuration, the display alone will probably take about 0.5GB/sec of bandwidth, which probably explains why you're having trouble running at 1024x768. On most systems resolution isn't an issue as the stretch is hardware accelerated and the 3D scene is very simple. That you're seeing a performance difference with the FPS meter up is especially disturbing, given how simple that thing is.

 

I might be able to add support for running in 16-bit, which would help the bandwidth situation. Currently Altirra always uses a 32-bit display, since for most systems there is basically no cost to doing so, but low end systems are an exception. In 2.90 I am planning on dropping some graphics support on the low end to simplify the graphics code, particularly bicubic on ps1.x... but that shouldn't be an issue as most cards at that level weren't fast enough for that anyway. Point/bilinear/sharp bilinear will continue to be hardware accelerated as in 2.80.

 

The 2.80 line is a bit too far along to work on this stuff, so I'll probably delay it until 2.90-test starts. I'm thinking of just promoting 2.80-test to release as-is, since it's been in the oven for a while and probably stable enough.

[morelenmir]

Is there any possibility than an 'extensions' or 'toolkit' disk for Altirra BASIC could add commands that allow the amazing graphics features of the VBXE to be used from BASIC?

[flashjazzcat]

Is there any possibility than an 'extensions' or 'toolkit' disk for Altirra BASIC could add commands that allow the amazing graphics features of the VBXE to be used from BASIC?

Drac030's S_VBXE driver already provides access to FX core graphics capabilities from any language which permits access to the "S2:" device. If you haven't looked into it yet, I recommend it. This driver based approach is generally much more flexible than attempting to hard-code extensions into the dialect.

[morelenmir]

Drac030's S_VBXE driver already provides access to FX core graphics capabilities from any language which permits access to the "S2:" device. If you haven't looked into it yet, I recommend it. This driver based approach is generally much more flexible than attempting to hard-code extensions into the dialect.

 

Okay - I agree it is certainly a flexible approach. Its probably a matter of personal preference anyway and also a question of what can be made available to the novice. I think a BASIC extension would make learning the new commands and techniques easier than using the S2: method. At least they would to me; I am no longer very comfortable with Atari programming so... Probably that - 'S2:' - is the middle-ground that most competent coders should follow on their way to being fluent in accessing the features from pure assembler.

 

Certainly the work you did to make P/MG graphics accessible from BASIC was exemplary and the kind of thing I was hoping for the VBXE.

Edited August 15, 2016 by morelenmir

[flashjazzcat]

It probably depends on what you want to do. S_VBXE comes with an archive of examples showing you how to access the new text modes from BASIC, etc, and for the moment, the driver's XIO statements are the commands, since there is no existing high-level syntax describing access to more advanced features such as the blitter. However, if you want to write the next Lamers Old-School demo, assembler will probably be required (or at least MAD Pascal, which offers a quite well-equipped VBXE library).

Edited August 15, 2016 by flashjazzcat

[phaeron]

BASIC isn't really appropriate for driving VBXE, both due to its slowness and lack of extensibility. To really take advantage of it you want to drive lots of bobs with the blitter, and BASIC is really ill equipped to set up blit lists. Just the lack of integer math alone is pretty painful.

[morelenmir]

Okay guys - interesting stuff and you both certainly make a lot of sense. It would be really nice if there were more programmes and stuff that used the VBXE. I thought if there were some way to access as least some of the features via something easy like BASIC then there might be more interest from te wider community. I guess the S2: device makes at some of the possible.

 

Maybe Pascal would be the way to go, then like FJC suggests - although I have no idea what integer math is!!!