Altirra 2.60 released

[flashjazzcat]

I think I've found a strange discrepancy between the behaviour of the Ultimate 1MB main BIOS mappings on real hardware and in the emulator...

Er, no I haven't. I found a strange discrepancy in my own code. Problem solved.

[Heaven/TQA]

actually both files are loaded regarding BPs. I am still on 2.6 test29

Edited May 7, 2015 by Heaven/TQA

[morelenmir]

I thought I would mention this officially here as a likely bug.

 

Old FJC has been helping me out getting to grips with the "Ultimate 1MB"/"SIDEII"/"VBXE" boards in preparation for buying the hardware in the physical world. Accordingly I attempted to create a 4GB *.VHD drive image to match the 4GB CF card that comes with the real "SIDE 2". However, if I try to make a 4096MB *.VHD image of 'dynamic disk image' Type with 'auto' Geometry I just get a warning chime and nothing else; no error dialogue appears and no new 4GB *.VXD is generated. In contrast if I use the native windows *.VHD creator within 'Computers->Manage->Storage->Disk Management' to make the 4GB drive image then not only does it succeed there but Altirra happily recognizes and uses it without any further problems.

Edited May 8, 2015 by morelenmir

[fujidude]

I assume you mean .vhd files right? I get the same thing within Altirra.

 

Update: I just made one with VirtualBox. Dynamically allocated. I'll attach it. Bear in mind it is not formatted at all. Just a raw image.

 

Great. Just got this when trying to attach it:

 

Error You aren't permitted to upload this kind of file

 

 

Edited May 8, 2015 by fujidude

[morelenmir]

I assume you mean .vhd files right? I get the same thing within Altirra.

Damnit!!! ..fixed.

 

Thanks for pointing that out fujidude. I think I must have decided it was time for a new xPanded virtual hard drive format... Now just to get Microsoft to buy out my intellectual rights and its easy-street here I come!!!

[flashjazzcat]

Try running Altirra with the administrative privileges it needs to create a VHD (i.e. "Run as administrator").

[morelenmir]

Try running Altirra with the administrative privileges it needs to create a VHD (i.e. "Run as administrator").

Will do...

 

You think its the old 'UAC' strikes again then? I did switch that off about four minutes after first installing windows 7 (it might have been three and a half!), but I agree sometimes it can still creep up and get you.

[fujidude]

Odd you need admin to create what is essentially a data file.

[phaeron]

You don't. Altirra has its own routines for reading and writing VHD files and administrator access is not needed to use them.

 

You do need administrator access if you are creating or mounting VHD files in Windows, however, because this is done through Virtual Disk Services, the same subsystem that manages physical disks.

 

The dialog doesn't let you create a VHD file bigger than 4GB because of a 1-4095 range check on the size (MB) field in the UI code. I'll raise it to 2097151 (2TB). Beyond that, you can't use it with Altirra because the emulated IDE interface doesn't support 48-bit LBA, and that's kind of overkill for an Atari.

[morelenmir]

You don't. Altirra has its own routines for reading and writing VHD files and administrator access is not needed to use them.

 

You do need administrator access if you are creating or mounting VHD files in Windows, however, because this is done through Virtual Disk Services, the same subsystem that manages physical disks.

 

The dialog doesn't let you create a VHD file bigger than 4GB because of a 1-4095 range check on the size (MB) field in the UI code. I'll raise it to 2097151 (2TB). Beyond that, you can't use it with Altirra because the emulated IDE interface doesn't support 48-bit LBA, and that's kind of overkill for an Atari.

4GB is large, but in keeping with the CF card that comes with SIDE2.

[bugbiter]

Maybe I'm blind but where did the 'Host device (H:)...' Menu option go? I can't find it!

[Roydea6]

Maybe I'm blind but where did the 'Host device (H:)...' Menu option go? I can't find it!

SYSTEM>DEVICES>ADD

 

and look to the bottom of options..

[fujidude]

You don't. Altirra has its own routines for reading and writing VHD files and administrator access is not needed to use them.

 

You do need administrator access if you are creating or mounting VHD files in Windows, however, because this is done through Virtual Disk Services, the same subsystem that manages physical disks.

 

The dialog doesn't let you create a VHD file bigger than 4GB because of a 1-4095 range check on the size (MB) field in the UI code. I'll raise it to 2097151 (2TB). Beyond that, you can't use it with Altirra because the emulated IDE interface doesn't support 48-bit LBA, and that's kind of overkill for an Atari.

 

Yes I knew Windows needs admin for the virtual disk services. I just thought I read that Altirra needed admin to make the image too and that's what I was wondering about. I suppose it doesn't hurt to raise the size limit for Altirra though 4GB is already ample.

[flashjazzcat]

Altirra has its own routines for reading and writing VHD files and administrator access is not needed to use them.

It must depend on Windows 7's file permissions, then. I tested VHD creation last night on a laptop using an admin level account and it failed until I explicitly started Altirra as admin. On this PC, meanwhile, VHD creation just works as-is.

[morelenmir]

Here's an interesting fault. It is a little tricky to get it to occur so I have given as precise details as I can.

 

I have the system set up to simulate an "Ultimate1MB", "SIDE2" and "VBXE" in PAL region. The machine type is an 130XE. The "Ultimate1MB" is flashed to the newest version of flashjazzcat's "PBI BIOS", "SIDELoader" and "SDX" custom distros. I myself have further customized the BIOS with adding 'Pilot' and 'Atari Assembler Editor' as alternatives 2 and 3 of the 'BASIC slot' respectively. I have also flashed in 'PAC-MAN', 'Asteroids' and Star Raiders' as the other three entries for the 'XEGS GAME slot'.

 

Now, starting with 'BASIC' chosen for the 'BASIC Slot' within the "Ultimate1MB" BIOS, I can type 'BASIC' from within SDX, enter "Atari BASIC" and then 'DOS' back. Next, I hold in F6 and press F5 to enter the "Ultimate1MB" BIOS screen and shuttle the 'BASIC slot' entry around to 'Atari Assembler Editor'. I then select 'S' to make this configuration active and 'Q' to return to normal operation. After a moment of black screen SDX returns and I again enter 'BASIC'. This time I am usually given the 'Edit' prompt as is appropriate from the "Atari Assembler Editor' cartridge, sometimes however I am also given 'Edit' followed by a number '3' on the line below. Either way, this is where the error occurs. If I now type 'DOS' to return to SDX the simulation crashes; I either get the 'Altirra has crashed' dialogue box or sometimes the emulator just freezes without any indication at all. The only way to resolve it is to shut Altirra down and reopen or Shift-F5 for a cold reboot. Once that is done I can then 'BASIC'/'DOS' in and out of 'ASM Editor' as often as I want with no further crashes. So clearly the error is something to do with changing the 'BASIC Slot' entry and NOT cold rebooting the simulation before entering BASIC.

 

I have included a copy of my current "Ultimate1MB" ROM file with the custom flashes as described.

Ultimate1MB v2 (SDX447&APT, PBI BIOS v1.0, SIDELoader, custom).rom

[Roydea6]

If you "S" you should then "C" for the saved changes to be permanent..

[morelenmir]

Even using 'C' after 'S' instead of 'Q' still causes the crash to happen, at least it does on my copy of Altirra.

[Keatah]

I don't know what half all this means, but it is good to see this kind of debugging and testing going on.

[fujidude]

It might have to do with the BASIC.SAV file. Try your experiment by deleteing the BASIC.SAV file before going into "BASIC" the 2nd time. By default it is created on the RAM drive. That RAMdrive and thus the file, would probably be preserved after making the switch to a "different" "BASIC" in the U1MB BIOS, and it might interfere.

[phaeron]

Dammit, you posted this right after I finished debugging it. Yes, this is due to BASIC.SAV. The problem is that the BASIC command in SDX is trying to load the Editor/Assembler program back into the BASIC interpreter, causing the crash.

[drac030]

Hmm, this means that the SAV files should probably contain some form of checksum to identify if the "internal BASIC" has not changed since the last time. Will enter this as an issue for a subsequent SDX version, it should not be hard to fix.

[morelenmir]

Dammit, you posted this right after I finished debugging it. Yes, this is due to BASIC.SAV. The problem is that the BASIC command in SDX is trying to load the Editor/Assembler program back into the BASIC interpreter, causing the crash.

Yep - I see the logic of that. It is even hinted at by the message you get on screen 'Restoring RAM disk' or words to that effect. Excellent problem solving guys, as always!!!

 

This sounds like it is a intrinsic error though and not really a 'fault' on the part of any of the system's involved - an emergent behaviour of the amazing functionality of 'Ultimate1MB'. I don't think you could really correct it in any way, at least not without some modification to SDX internally where the DOS is made aware of the "Ultimate1MB" and 'knows' when returning from its BIOS screen to flush the RAM disk ahead of time. This would sacrifice the encapsulation of the both systems though. Alternately perhaps 'Ultimate1MB' should always cause a cold reboot on exiting its BIOS, if that is possible. I know you could do that on the PC.

 

You must admit though - this was a pretty convoluted error to encounter!

 

What would you say was causing that number '2' to appear on the screen Avery? Things like that fascinate me.

Edited May 9, 2015 by morelenmir

[flashjazzcat]

I would have considered a cold boot mandatory after a cart change or BASIC swap. Why is it a problem to do so?

[phaeron]

The U1MB BIOS does clear enough of low memory to erase the boot signature and force the XL/XE OS to do a cold start. However, the OS doesn't clear extended memory, which is why the ramdisk persists. If you flip the power off and back on quickly enough on a non-U1MB system, you can also get this effect because the contents of extended memory won't have decayed enough. (Please don't actually try this.) However, this shouldn't happen with U1MB, which has a hardware bit to tell the BIOS whether a reset is from a cold or warm reset. Also, having BASIC.SAV in persistent storage -- disk, flash, or battery-backed extended memory -- would have had the same effect, even with a stone-cold boot.

 

Now, the U1MB BIOS could clear extended memory on exit after changing a setting like the BASIC interpreter. A recoverable ramdisk is a useful feature, though, so this would need to be optional. Also, clearing up to 1MB of extended memory can take a bit.

[flashjazzcat]

Good idea - thanks Avery.