659 replies to this topic

[phaeron]

http://www.virtualdu...-2.90-test3.zip
http://www.virtualdu...0-test3-src.zip
 
Adds an additional monitor change check in the display code, fixes rich text paste into the console command line, fixes Remove not being available for devices that don't have settings. Annoyingly, I've discovered that exclusive full-screen mode is now broken on my dev system with two monitors enabled, both in Altirra and in other programs. Yay. Fortunately it still works on my other laptop where I can still test.
 

Regarding the emulator itself Avery, you refuse monetary donation for reasons I fully understand but us lot tend to feel that there something we could do to help other than 1. using you work there fore proving its worthwhile and loved and 2. beta testing and reporting errors. Are there any other area's you could use a hand with or causes people could give to as a show of thanks?
 
Hardware lends / donations etc?

 
To be honest, the thing I'm shortest on when working on Altirra is time and motivation. That's not to say that I don't like working on the emulator, but there are other things I can spend my time on as well... like the PS4 that's calling me at the moment. Just the testing you folks do is already a big help.
 
Regarding hardware needs, there are a couple of pieces of hardware that would be nice to have for testing, namely an 800 and an 810 disk drive. I haven't gotten them mainly just because I haven't needed them enough to go look for one and don't have any tests ready to go for them anyway. Cost isn't really much of a problem, ridiculous eBay auctions being an exception of course (I'm not going to pay USD$150 for a "collector's item" 810 that looks like it's been through a wood chipper and then a landfill). If I go down that route, I'd probably cobble together a test program and try to invite someone here to run it on the hardware for me first.

 

The compatibility database would be a good thing to crowdsource, but I really don't want people to go to town on it until I get the format locked first. At this point I'm probably going to switch to the same CRC64 that xz uses, but I need to brush up on binary field arithmetic first. The main benefits of doing so are more robust hashing (decreased chance of collisions), and checksum consistency with another well-known tool for bare images like .bin carts.
 

Something I just noticed today (running 2.80 Test 48 prior to updating to 2.90 Test 1 and then Test 2) is that folders mounted as virtual SpartaDOS disks return directories with the archived bit set for every file. I didn't notice this before: I just happened to be fiddling with The Last Word's file manager which displays all the file attributes. Tried SDX's MENU.COM as well and the archive bit is set there too, so it's not a bug in the word processor. Perhaps the bit is set deliberately: if so, please ignore.
 
EDIT: Regarding the archive bit - just checked the obvious, and the archive bit is set on the host file system, so there's no problem. Clearing it clears it in the emulator.

 

Yeah, the archive bit is simply reflected because it was there. Let me know if this causes issues. As far as I know, the archive bit is about as used as it is on Windows, i.e. not really, but one weirdness is that Windows Explorer does use the archive bit on directories. The alternative would be to simply force-clear it.
 

Does BASIC interfere with Mr Do!
 
It does not seem to and the game appears to play fine but its sort of an unwritten law that says to remove BASIC when booting a machine code game, just noticed that when playing with the Compatibility settings that it did not mind BASIC being on..

 

"Disable BASIC" is going to be an interesting tag, as the majority of games require it. Might have to special case it since otherwise it'd have to be spammed throughout the DB. "Requires 48K" is an even worse case that I'm not sure I'd want to have at all in the DB.

 

[Mclaneinc]

I guess most people will be aware when they get a "Remove Cartridge" message

 

Just not all software checks available ram and tells you, then you get the screen corruption normally leading to a crash

 

Like I say, unless it specifically requires BASIC I tend to turn it off just in case..The issue should not be Altirra you to second guess the original programmer..

[rdemming]

The compatibility database would be a good thing to crowdsource, but I really don't want people to go to town on it until I get the format locked first. At this point I'm probably going to switch to the same CRC64 that xz uses, but I need to brush up on binary field arithmetic first. The main benefits of doing so are more robust hashing (decreased chance of collisions), and checksum consistency with another well-known tool for bare images like .bin carts.

 

Why not use SHA(256) for unique identification of files as CRC is more intended as error detection code and not, in the first place, as a signature like SHA? Is is because you want to be compatible with xz (what is that?) and other tools?

[flashjazzcat]

http://www.virtualdu...-2.90-test3.zip
http://www.virtualdu...0-test3-src.zip
 
Adds an additional monitor change check in the display code, fixes rich text paste into the console command line, fixes Remove not being available for devices that don't have settings. Annoyingly, I've discovered that exclusive full-screen mode is now broken on my dev system with two monitors enabled, both in Altirra and in other programs. Yay. Fortunately it still works on my other laptop where I can still test.

Thanks for the update. Display still vanishes on the secondary monitor in the aforementioned circumstances, but leaving DirectX 11 checked fixes it anyway.

Yeah, the archive bit is simply reflected because it was there. Let me know if this causes issues. As far as I know, the archive bit is about as used as it is on Windows, i.e. not really, but one weirdness is that Windows Explorer does use the archive bit on directories. The alternative would be to simply force-clear it.

I don't see it causing a problem, and the current behaviour is proper anyway. I think the only issue was my failure to appreciate after all these years that the archive bit is set every time the file is written or modified.

Edited by flashjazzcat, Tue Sep 6, 2016 6:19 AM.

[morelenmir]

Again - my apologies for repeating this, but for the sake of clarity; there is no way to run Altirra in source debugging mode, honouring the breakpoints set in WUDSN IDE if you are starting a cartridge image?  I'm currently a bit hung up trying to get it to work, but so far no luck.  Maybe a future version of Altirra could have specific command-line switches specifying which *.ATDBG, *.LST and *.LAB files to load - this would work well with the custom command line option WUDSN allows to specify when launching the chosen debugger.

 

If it is the case then I guess JAC's approach is the best one - compile and debug the programme as a normal *.XEX and then make the small changes required to transform this in to a *.ROM or *.,CAR image.

[Farb]

 

The compatibility database would be a good thing to crowdsource, but I really don't want people to go to town on it until I get the format locked first. At this point I'm probably going to switch to the same CRC64 that xz uses, but I need to brush up on binary field arithmetic first. The main benefits of doing so are more robust hashing (decreased chance of collisions), and checksum consistency with another well-known tool for bare images like .bin carts.

 

 

I can give you access to the preservation database if you think that would be a helpful starting point for seed data. It currently has CRC16, MD5 and SHA256 for every file as well as whether the title needs BASIC, a specific OS version, etc.

[serj]

on this place the emulator stops.
earlier this test was taken completely.

 

 

Attached Thumbnails

• 

[+Adam+]

Firstly, I would like to thank you, Phaeron, for all your work for Atari 8-bit, including Altirra (great tool!)

 

Secondly, I got a question. In the earlier Altirra versions (up to 2.60 I think) when I clicked with mouse on the upper panel, it caused the program to pause automatically. In the later versions it doesn't cause such effect. How can I change the settings to bring back the earlier behaviour?

[fujidude]

Firstly, I would like to thank you, Phaeron, for all your work for Atari 8-bit, including Altirra (great tool!)

 

Secondly, I got a question. In the earlier Altirra versions (up to 2.60 I think) when I clicked with mouse on the upper panel, it caused the program to pause automatically. In the later versions it doesn't cause such effect. How can I change the settings to bring back the earlier behaviour?

 

I'm not sure about how you can make mouse clicking work to pause, but the F9 key works a treat.

[rdea6]

WOW! Three test build changes in 3 Days.

[phaeron]

Why not use SHA(256) for unique identification of files as CRC is more intended as error detection code and not, in the first place, as a signature like SHA? Is is because you want to be compatible with xz (what is that?) and other tools?

 
SHA256, like other cryptographic hash algorithms, is designed with a significant computational cost to thwart brute-force attempts and to be impractical to incrementally update (because that would allow forging of hashes). This would mean that any case where the emulator had to deal with a write back to the image or a scatter load of the image, it would be obliged to recompute the hash from scratch using the entire image. This is undesirable in the case of a large image like a 32MB disk or a 128MB cartridge. This can be mitigated somewhat by means of per-block hashing, but it's still nowhere near as fast or as simple as a CRC, which is linear and has known algorithms to allow incremental updates. These incremental update algorithms are fast enough to run in real time without disturbing emulation timing.
 
As an example of the scatter load problem, it's desirable for the hash to be the same for a disk regardless of whether it's encoded as ATR, ATX, or DCM. Only the first is a straightforward linear load, however.
 
CRC32 is often used for this kind of purpose, but 32 bits is too small for a full database without some other way to partition it: the chance of at least one collision rises to 90% by the time you hit 30K entries in the best case. A 64-bit hash greatly reduces this issue to the point that it is generally not an issue, in my experience.
 
That xz uses the same hash is just a bonus in that it provides a way to check the hashing algorithm, whereas right now I don't have any good way to verify that the existing goofy block FNV1 hash is correct. And I'd like to confirm that before we go and populate hundreds of entries.
 

on this place the emulator stops.
earlier this test was taken completely.

 

Turn off burst I/O -- it is not compatible with the timing test that this particular test is trying to do. The crash is an issue with the test, but it is correct to fail because the emulator is speeding up the serial timing.
 

Firstly, I would like to thank you, Phaeron, for all your work for Atari 8-bit, including Altirra (great tool!)
 
Secondly, I got a question. In the earlier Altirra versions (up to 2.60 I think) when I clicked with mouse on the upper panel, it caused the program to pause automatically. In the later versions it doesn't cause such effect. How can I change the settings to bring back the earlier behaviour?

 

Tools > Options > UI > Pause when menus are open.

 

[rdemming]

@Phaeron:

Thanks for the elaborate explanation. I originally thought about a static hash for images and didn't realise you need to update the hash dynamically whenever the image changes. I didn't know a CRC could be updated by only processing the changed parts of the data instead of recalculating it over the whole data, that is indeed a big advantage when working with large amounts of data.

 

Robert

[morelenmir]

I am not sure if this is a bug or a feature; when debugging is enabled Altirra does not 'remember' if the 'source code' window was open when the emulator was last closed, nor does it remember where it was docked.  Therefore after manually using 'Open Source File...' and choosing the *.LST file you want to work with the 'source code debugging' windows always reopens attached to the default 'Registers', 'Disassembly' and 'History' docked Tab Group at the far right.  Given source code is almost always going to be pretty wide I prefer to dock it at the bottom and form a Tab Group with the 'Console'.

 

For instance this is my current debugging layout of the emulator and its windows:

 

 

However it will not reappear in this pattern on next launch, although it will reuse the layout if I launch the debugger again from inside WUDSN and specify one instance of altirra be used on the command line.

Edited by morelenmir, Wed Sep 7, 2016 7:36 AM.

[+Adam+]

 Tools > Options > UI > Pause when menus are open.

 

Thanks, that's what I needed!

[phaeron]

Thanks for the elaborate explanation. I originally thought about a static hash for images and didn't realise you need to update the hash dynamically whenever the image changes. I didn't know a CRC could be updated by only processing the changed parts of the data instead of recalculating it over the whole data, that is indeed a big advantage when working with large amounts of data.

 

Yes, CRCs have some neat characteristics. They're closely related to the noise generators used in TIA and POKEY, by the way. The algorithms used to incrementally update CRCs can also be used to directly compute the state of the random generators at any arbitrary tick.

 

As for what xz is, it's essentially 7-Zip for Unix.

 

For instance this is my current debugging layout of the emulator and its windows:

 

Altirra debugging layout.jpg

 

However it will not reappear in this pattern on next launch, although it will reuse the layout if I launch the debugger again from inside WUDSN and specify one instance of altirra be used on the command line.

 

The reason this happens is that source windows are unique to a session and can't be restored, and the docking system can only remember the position of a pane that it can save or restore. In the absence of an existing source pane, the debugger defaults to docking a new source pane over the disassembly pane. I suppose it might be possible to try to remember the relative placement of the last source pane instead.

Edited by phaeron, Wed Sep 7, 2016 11:57 PM.

[mr-atari]

Hmmm, I can't load XEGS-cartridges (also in the 2.80 final version).

 

The attachment is NOT a zip, I just added the .zip extension.

Since I can not upload a .mdmp-file.

 

Later!

Edited by mr-atari, Fri Sep 9, 2016 12:46 AM.

[flashjazzcat]

Flashed SIDE firmware seems to be saving as a 0 byte file. Possibly been going on for a while, but I just noticed it. SIDE2 and everything else appear OK.

[Keatah]

1up!

[Shannon]

I just have to say.  I was testing a tape image from the Farb's ASPI set and it was really weird heard the good 'ol cassette sound SIO while the tape was loading (I had to disable the burst modes for it to work).

 

It brought back some memories of starting a tape load and then wandering off to get some food, or some other activity.    I used to turn up the volume just enough so I could hear it from the other room.

 

We need some more realism though.  Altirra needs to sense if I'm walking through the room too hard and cause a tape error to occur right near the end of the tape image...  Arrggh that used to drive me nuts!

[777ismyname]

Thank you for your hard work, phaeron!

[Madi]

phaeron :

 

Using AtariWriter 80 under Altirra (XEP80 View)

Pictures are self explanatory:

 

Normal:

 

Glitched: Filter Mode -> Sharp Bilinear

 

Also, "Copy Frame to Clipboard" doesn't work (empty clipboard) when XEP80 View is enabled.

 

Request: May you add more icons to Altirra?. This will allow the users (especially elderly and sight impaired) to choose the file type association based on categories.

Currently, I have difficulties to differentiate between ATR and ATX file extensions based on texts.

 

madi

Edited by Madi, Sun Sep 11, 2016 10:50 AM.

[phaeron]

http://www.virtualdu...-2.90-test4.zip
http://www.virtualdu...0-test4-src.zip

• Fixes XEGS cartridge crash.
• Fixes bug in SIO acceleration system that caused corruption of an accelerated command that interrupted a non-accelerated command.
• Fixed SIDE 1 cart saving.
• Debugger directives and startup scripts are now supported for cartridges.
• Added 'ib' command to issue non-debug memory reads from the debugger.
• Fixed XEP80 display using point sampling if the display mode was set to bicubic. (It still doesn't support bicubic because I don't care enough implement on that path, but bilinear is closer than point.)
• I could not reproduce the XEP80 sharp bicubic issue, but I did find another issue in the new fxc10 builder that might affect the display. If you're still seeing the problem, please indicate the model video card, OS (XP, Win10...) and whether you see this on 2.80.

We need some more realism though.  Altirra needs to sense if I'm walking through the room too hard and cause a tape error to occur right near the end of the tape image...  Arrggh that used to drive me nuts!

 
I could make you rewind the tape in real time... that would make it more representatively painful....
 

Also, "Copy Frame to Clipboard" doesn't work (empty clipboard) when XEP80 View is enabled.
 
Request: May you add more icons to Altirra?. This will allow the users (especially elderly and sight impaired) to choose the file type association based on categories.
Currently, I have difficulties to differentiate between ATR and ATX file extensions based on texts.

 
I couldn't reproduce the clipboard issue either....
 
As for more icons, that would depend on having said icons. I'm artistically challenged.

[rdea6]

Is anyone experiencing problems with the IDE +2.0 and not being able to use the Load executable function of the START+F5 menu.. with the latest 2.90 test4 build..

[Madi]

Test result Summery:

 

The XEP80 view - sharp bicubic issue is caused by Direct3D 11 option:

Tools -> Options -> Display -> Direct3D 11

Unchecked the Direct3D 11 option, reverts sharp bicubic display to normal

 

Another way to get rid of the glitch is to use "NVIDIA GeForce 710M" video card as the default display for Altirra:

XEP80 view + sharp bicubic + Direct3D 11, display is normal when NVIDIA GeForce 710M is selected.

 

The glitch will occur if:

- Intel® HD Graphics 4600 is selected "AND" Direct3D 11 is checked.

In other words:

Display will become normal under XEP80 view - sharp bicubic when Direct3D 11 unchecked, or NVIDIA GeForce 710M display card is selected.

 

System property:

 

Model Name               Satellite C50-A428

OS Version               Microsoft Windows 10 Home Single Language  10.0.10586

BIOS Version             1.40

CPU                       Intel® Core™ i5-4200M CPU @ 2.50GHz

Physical Memory           12288MB RAM

Video                     NVIDIA GeForce 710M  Version=10.18.13.5906

                          Intel® HD Graphics 4600  Version=20.19.15.4474

Screen Resolution         1366 x 768 Pixels

Color Quality             True Color (32 Bit)

 

XEP80 view + sharp bicubic + Direct3D 11, display is normal when NVIDIA GeForce 710M is selected.

However, the glitch persists if Intel® HD Graphics 4600 was selected.

------------------------------------------

Copy Frame to Clipboard" doesn't work (empty clipboard) when XEP80 View is enabled:

 

Tested several versions of Altirra from 2.9 down to 2.5 (result = empty clipboard)

Windows 10 (x64) - Windows XP (SP3) 2 different laptops (result = empty clipboard)

Altirra.exe/Altirra64 were tested in all testing setups.

 

As for more icons, that would depend on having said icons. I'm artistically challenged.

 

 

 

Sorry for misunderstanding. I did not think of designing new icons. I was referring to the free icon libraries available on the net.

I am currently, using "Types.exe" do customize/add new icons to Altirra. But it does harm more than good.

 

madi

[mr-atari]

Thank you very  much !

 

:-)

 

http://www.virtualdu...-2.90-test4.zip
http://www.virtualdu...0-test4-src.zip

• Fixes XEGS cartridge crash.