Altirra 3.20 released

[TheEditor]

Can someone shed some light on the altirra.ini file?  Specifically the line in bold below.  Is the Hex value at the end significant in some way or just random?

 

Thanks,

T.E

 

[User\Software\virtualdub.org\Altirra\Profiles\6AC4B1FF]
"_Name" = "400/800 Computer"
"_Visible" = 1
"_Category Mask" = "hardware,firmware"
"_Saved Category Mask" = "hardware,firmware"
"Hardware mode" = 0

[phaeron]

3 hours ago, TheEditor said:

Can someone shed some light on the altirra.ini file?  Specifically the line in bold below.  Is the Hex value at the end significant in some way or just random?

It is just a random GUID that needs to not be zero (global default) or FFFFFFFF (invalid).

 

[TheEditor]

Cool.  Thanks phaeron.  I noticed that there are matching sections that match the GUID for keymap, etc.  I am correct that if not specified the defaults are on play?

 

[phaeron]

23 hours ago, TheEditor said:

Cool.  Thanks phaeron.  I noticed that there are matching sections that match the GUID for keymap, etc.  I am correct that if not specified the defaults are on play?

 

The category mask for the profile determines whether each category of settings is inherited from the parent or isolated to the profile. In the latter case, any settings that aren't present are default.

 

[phaeron]

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

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

 

• Fixes screen update when stepping in debugger, which had been broken by the change to split frames at scanline 248.
• Alt+Shift+left-click on the display when stopped in the debugger jumps to the closest entry in History for that beam position on the most recent frame.
• Add 810 Turbo emulation support.
• Fix FDC to immediately start a write track operation if the index sensor was already active, instead of waiting for a new edge. This was blocking the 810 Turbo double-density diagnostic test as that test leaves the index signal active and expects a DRQ to arrive afterward.
• Fixed bug in Disk Explorer that allowed duplicate files to be written to a DOS 2 filesystem if the source name had the same 8.3 prefix with different characters after the extension. This now properly reports an error or renames the file.
• The Disk Explorer now has right-click menu items for importing and exporting files so that drag-and-drop is not required to do so.
• Added support for half float (min16float) precision in shaders in D3D11 mode on Windows 8+, for slightly better efficiency/performance.
• Added workaround for bug in WINE causing crash in D3D11 mode -- WINE's DXGI layer incorrectly returns different LUIDs for the same adapter on different DXGI factories.

 

[TheMontezuma]

On 7/24/2019 at 7:29 PM, TheMontezuma said:

Hi Phaeron,

I saw that you have implemented (on the CIO level) B: device emulation
and I wondered if you could also emulate the SIO layer corresponding to it?

 

As a bridge between Planetary Defence 2012 and the "URL Submit" SIO call (which is implemented in RespeQt and SIO2BT)

I have written a simple B: handler:
https://github.com/TheMontezuma/B-Handler

 

Here is an ATR which automatically loads that B-Handler and "Planetary Defence 2012":
https://github.com/TheMontezuma/B-Handler/releases/download/1.0/pd2012.atr

 

More info about "URL submit":
http://atariki.krap.pl/index.php/URL_Submit

and in the attached Sio2BT Smart.pdf.

 

To avoid introduction of a new SIO device, I decided to reuse device ID=$45,
reserved so far in combination with command ID=$93 by APE Time.
I called device $45 a smart device, providing "APE time" and "URL submit".

 

There are also games patched to directly support SIO "URL submit" (in addition to data matrix):
https://github.com/TheMontezuma/mahna-malysz/releases

https://github.com/TheMontezuma/1K-ATASCII-BLASTER/releases

 

I hope enough stuff for testing

 

Best Regards
TheMontezuma

Sio2BT Smart.pdf 110.91 kB · 10 downloads

In the meantime, I have patched the games mentioned above to use B: handler (instead of directly calling SIO):

https://github.com/TheMontezuma/mahna-malysz/releases

https://github.com/TheMontezuma/1K-ATASCII-BLASTER/releases

 

Also the B: handler implementation was improved (https://github.com/TheMontezuma/B-Handler). It checks now wether B: device is already installed in HATABS and quits if so.

 

In Altirra you can enable B: handler:

System -> Configure System -> Peripherals / Devices -> High-Level Emulation (HLE) Devices / Browser (B:)

 

load one of those games (mahna-malysz-cio.atr or 1KAtasciiBlasterHSCCIO.atr) and the Alrirra's B: handler will trigger High-Score submission in a Browser

The same games can be loaded on a real hardware with RespeQt (or SIO2BT) and the High-Score will be uploaded via SIO.

You need a HI SCORE CAFÉ account ( https://xxl.atari.pl/hsc/ ) for high-score submission.

 

Anyway it would be great to have a SIO level emulation, too.

[Kyle22]

Does this B: Handler INTERFERE with APETime or anything else?

 

[TheMontezuma]

11 hours ago, Kyle22 said:

Does this B: Handler INTERFERE with APETime or anything else?

Altirra and Colleen support high level "B: device" emulation - no 6502 code, no interference with anything.

 

The B: Handler written in 6502 Assembler on the other hand will be physically loaded into the 6502 address space and it uses SIO level "URL Submit".

"URL submit" is a SIO command belonging to a virtual SIO device DDEVIC=$45 (the same as APETime).

There is no interference as long as you don't connect SIO2PC with APE and another SIO2PC with RespeQt / SIO2BT at the same time to the ATARI.

APE knows only GET TIME command (ID=$93), so it would NACK anything else, also URL SUBMIT (ID=$55).

 

The B: device concept is generic and it could be implemented in various ways.

The B: handler mentioned above is just one possible implementation using underlying SIO to achieve the same on a real ATARI.

Edited August 7, 2019 by TheMontezuma

[ldelsarte]

I understand donations are impossible. So, practically speaking, what can we do to help? What can we do to express our gratitude? Do you have any "to do list" somewhere for which volunteers' help might be appreciated? Any document you're looking for? Any "cleaning, straightening and enhancing document required for OCR" task? Any "impossible to OCR" document to retype? Any repetitive but important task you need performed? Any translation? Any design to create? I'm so grateful for Altirra (mainly to play Boulder Dash), I play almost every day: I feel indebted for this.

[_The Doctor__]

10 hours ago, TheMontezuma said:

Altirra and Colleen support high level "B: device" emulation - no 6502 code, no interference with anything.

 

The B: Handler written in 6502 Assembler on the other hand will be physically loaded into the 6502 address space and it uses SIO level "URL Submit".

"URL submit" is a SIO command belonging to a virtual SIO device DDEVIC=$45 (the same as APETime).

There is no interference as long as you don't connect SIO2PC with APE and another SIO2PC with RespeQt / SIO2BT at the same time to the ATARI.

APE knows only GET TIME command (ID=$93), so it would NACK anything else, also URL SUBMIT (ID=$55).

 

The B: device concept is generic and it could be implemented in various ways.

The B: handler mentioned above is just one possible implementation using underlying SIO to achieve the same on a real ATARI.

I use one instance of APE to serve a sio2pc usb and sio2pc rs232 at the same time as well as respeqt for my pclink drives, generally that means 1-8 is served by APE out to 2 machines and 9 and up are the pclink drives.... this are my two everyday drivers...

 

are you saying APE will nack for sure, it would be better it ignored whatever your protocol does, perhaps you could contact Steve and share whatever you are doing so they can coexist?

[TheMontezuma]

9 hours ago, _The Doctor__ said:

I use one instance of APE to serve a sio2pc usb and sio2pc rs232 at the same time as well as respeqt for my pclink drives, generally that means 1-8 is served by APE out to 2 machines and 9 and up are the pclink drives.... this are my two everyday drivers...

 

are you saying APE will nack for sure, it would be better it ignored whatever your protocol does, perhaps you could contact Steve and share whatever you are doing so they can coexist?

 

Sending NACK to unknown commands is a proper behaviour (defined in the SIO spec).

But you have anyway a potencial problem, since both APE and RespeQt implement APE Time.

This means a clash on the SIO bus, when ATARI asks "what time is it?"

 

 

 

[flashjazzcat]

There may be an issue with extremely large VHDs attached as IDE hard disks (with SIDE2, for example). I created a 32GB VHD in the Disk Management console and attached it to the Compact Flash bus, but the geometry is blank (perhaps because it's outside the bounds of CHS addressing), and the device will not respond to the Identify Device command, and thus not respond to software. Ironically the purpose of such a large image is to troubleshoot issues FDISK has creating a large FAT MBR entry on a 32GB card using real hardware.

 

I think we should be good up to 128GB or so?

 

Oh well: scratch that. Every size of VHD was rejected until I decided to restart the emulator, at which point they suddenly worked again. I have no idea why.

Edited August 8, 2019 by flashjazzcat

[_The Doctor__]

hmmm, I haven't run into that, probably because my real time clocks are either R-TIME-8's, clones, or built in to my SDX carts.

It would be a good Idea to make that a switchable option on both of the peripheral emulators then.

 

 

Edited August 8, 2019 by _The Doctor__

[RobS]

Can anyone tell me why this takes 1-2 minutes to start up?? I moved the previous version I had from an external to an internal drive, installed this new version (3.2) reset all settings, and made it portable. All I get is "not responding" for almost 2 minutes before it boots into anything. Thank you.

[phaeron]

On 8/7/2019 at 8:11 AM, ldelsarte said:

I understand donations are impossible. So, practically speaking, what can we do to help? What can we do to express our gratitude? Do you have any "to do list" somewhere for which volunteers' help might be appreciated? Any document you're looking for? Any "cleaning, straightening and enhancing document required for OCR" task? Any "impossible to OCR" document to retype? Any repetitive but important task you need performed? Any translation? Any design to create? I'm so grateful for Altirra (mainly to play Boulder Dash), I play almost every day: I feel indebted for this.

Hmm, I haven't really thought much about this.

 

Testing is, of course, always appreciated, especially with some of the more unusual configurations. Designs, I don't really need, I have far more designs in mind than I can actually implement.

 

Hardware reverse engineering is something that is always helpful, but I don't have specific suggestions off-hand. The work that Nezgar's been doing to dump previously unknown or rare disk drive ROMs is excellent. I've recently been given an Atari 400 and a Happy 1050 for testing which are going to come in real handy, but unfortunately they're not something I can get help with over the Internet unless you're skillful at writing custom drive code to exercise the floppy drive controller.

 

20 hours ago, TheMontezuma said:

Sending NACK to unknown commands is a proper behaviour (defined in the SIO spec).

But you have anyway a potencial problem, since both APE and RespeQt implement APE Time.

This means a clash on the SIO bus, when ATARI asks "what time is it?"

So... it wouldn't be hard to implement SIO-level support for the B: device since the emulator's device intrastructure makes this easy to do, but I'm a little uneasy about the reuse of the APE device ID. The SIO specification does say that devices should NAK commands that aren't valid, but this interpretation is up to the device. I'm not sure it's a good idea to co-opt command IDs on another device's ID, especially for a multi-function device implemented in various versions on a PC. I would suggest switching to another device ID for adding a new function like this.

13 hours ago, flashjazzcat said:

There may be an issue with extremely large VHDs attached as IDE hard disks (with SIDE2, for example). I created a 32GB VHD in the Disk Management console and attached it to the Compact Flash bus, but the geometry is blank (perhaps because it's outside the bounds of CHS addressing), and the device will not respond to the Identify Device command, and thus not respond to software. Ironically the purpose of such a large image is to troubleshoot issues FDISK has creating a large FAT MBR entry on a 32GB card using real hardware.

 

I think we should be good up to 128GB or so?

 

Oh well: scratch that. Every size of VHD was rejected until I decided to restart the emulator, at which point they suddenly worked again. I have no idea why.

There is a known issue in Altirra where browsing to an existing hard drive image may not reflect values in the UI if the hard drive image is already mounted, because the UI tries to open another file handle to the image and fails. When this happens, you need to remove the existing image from the device tree first.

 

There is also a note for IOCTL_DISK_GET_PARTITION_INFO that it may not work with GPT disks. This should only affect the UI, but I haven't tested that case because ordinarily removable drives are not formatted as such.

 

In any case, the next time you see this, please run the .ide command in the debugger and check its output -- it should indicate if something is amiss with the physical disk image geometry.

5 hours ago, RobS said:

Can anyone tell me why this takes 1-2 minutes to start up?? I moved the previous version I had from an external to an internal drive, installed this new version (3.2) reset all settings, and made it portable. All I get is "not responding" for almost 2 minutes before it boots into anything. Thank you.

Needless to say, this is not expected or normal. Were you seeing this long startup on 3.20 even before doing reset all settings + make portable?

[flashjazzcat]

5 hours ago, phaeron said:

In any case, the next time you see this, please run the .ide command in the debugger and check its output -- it should indicate if something is amiss with the physical disk image geometry.

Will do. There were no duplicate images here, but I suppose Windows may have GPT'd the new VHD without my knowing it.

 

[RobS]

5 hours ago, phaeron said:

Needless to say, this is not expected or normal. Were you seeing this long startup on 3.20 even before doing reset all settings + make portable?

Yes it is very odd. It resided on an external drive for a long time (v 2.9) and never did this.  I moved it to an internal drive and nothing changed, then when I set up 3.2 now both versions exhibit this behavior. I tried to a full settings reset then made it portable, hoping to "fix" this (thinking something with the settings being stored in the reg might be doing something weird or retaining some previous settings or something). The other odd thing is it also hard-locks (goes non-responding) if you plug or unplug any USB device - anything, even a charging cable. Maybe my windows is just screwed up (windows 7). Works a treat otherwise!

[FULS]

Hi Phaeron,

When I load an ATR disk file, I would love a feature where I could click on "TOOLS" and then have an option to view that specific disk (Directory).

I know about "DISK EXPLORER" under "TOOLS" (Great Feature), but then you have to find that ATR file which possibly is in another directory.

It would just be a convenience for me. Thanks!

Edited August 9, 2019 by FULS

[Roydea6]

 

click the icon left of the RW and select explore disk..

 

Edited August 9, 2019 by rdea6

[phaeron]

Additional warning: If you have a disk mounted on a disk drive, do not also mount it in Tools > Disk Explorer by browsing to the ATR and modify it there. This will not work as the disk drive and Disk Explorer will independently access the disk image. If it's mounted as read-only, the disk drive will not notice the changes to the disk image, and if it's mounted as read/write, this can corrupt the disk. I need to add checking for this. Always run Disk Explorer through the entry in the disk drives dialog. This works on the same mounted image as the disk drive, ensuring that they stay in sync -- any modifications to the disk will be seen by the disk drive and if the disk drive is in virtual read/write mode the Disk Explorer will also see the unsaved changes.

 

[ijor]

On 8/4/2019 at 8:29 PM, phaeron said:

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

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

• Fix FDC to immediately start a write track operation if the index sensor was already active, instead of waiting for a new edge. This was blocking the 810 Turbo double-density diagnostic test as that test leaves the index signal active and expects a DRQ to arrive afterward.

 

If I understand correctly that sentence and your implementation, that is not correct. The FDC waits for an IP edge before actually starting writing the track. The index signal being already active is not enough. The FDC must detect an active edge, and the edge must happen when the FDC is actually waiting for it after all the previous phases of the command (such as waiting for the E delay if it was enabled). A previous edge, even if it happened after the command started, is ignored.

 

What happens is that the FDC does assert DRQ, once, beforehand and unconditionally to the state of the index. But I understand you knew this already and you implemented that long ago? So not sure what was the issue.

Edited August 11, 2019 by ijor

[phaeron]

2 hours ago, ijor said:

 

If I understand correctly that sentence and your implementation, that is not correct. The FDC waits for an IP edge before actually starting writing the track. The index signal being already active is not enough. The FDC must detect an active edge, and the edge must happen when the FDC is actually waiting for it after all the previous phases of the command (such as waiting for the E delay if it was enabled). A previous edge, even if it happened after the command started, is ignored.

 

What happens is that the FDC does assert DRQ, once, beforehand and unconditionally to the state of the index. But I understand you knew this already and you implemented that long ago? So not sure what was the issue.

You're probably right, as this matches some tests I've been doing all afternoon on a Happy 1050. It's the leading edge that the FDC waits for, right?

 

I have the Write Track command updated with some more accurate timings and also implementing the 3-byte initial DRQ timeout, but it doesn't allow the 810 Turbo to pass the format tests. I'm now leaning toward a possible issue with RIOT emulation setting the index pulse too early, since I'm seeing indications that the behavior past initial timer underflow is more weird than anticipated. Force Interrupt is also giving me problems in tests, it's taking 3-4x the number of clock cycles for the second FI to be recognized after the first when interrupting a Write Track command, compared to what's specced in the datasheet.

 

Should also note, there is another issue with the 810 Turbo diagnostics specific to emulation. It polls the write protect sensor to detect disk changes, but it does so from the computer, so it's too slow to detect the pulse injected by the emulator. Currently you need to manually flip the write protect mode for it to see a disk change.

 

[ldelsarte]

On 8/9/2019 at 6:17 AM, phaeron said:

On 8/7/2019 at 5:11 PM, ldelsarte said:

I understand donations are impossible. So, practically speaking, what can we do to help? What can we do to express our gratitude? Do you have any "to do list" somewhere for which volunteers' help might be appreciated? Any document you're looking for? Any "cleaning, straightening and enhancing document required for OCR" task? Any "impossible to OCR" document to retype? Any repetitive but important task you need performed? Any translation? Any design to create? I'm so grateful for Altirra (mainly to play Boulder Dash), I play almost every day: I feel indebted for this.

Hmm, I haven't really thought much about this.

 

Testing is, of course, always appreciated, especially with some of the more unusual configurations. Designs, I don't really need, I have far more designs in mind than I can actually implement.

 

Hardware reverse engineering is something that is always helpful, but I don't have specific suggestions off-hand. The work that Nezgar's been doing to dump previously unknown or rare disk drive ROMs is excellent. I've recently been given an Atari 400 and a Happy 1050 for testing which are going to come in real handy, but unfortunately they're not something I can get help with over the Internet unless you're skillful at writing custom drive code to exercise the floppy drive controller.

 

Well, I have an Arabic 65XE (http://www.atari800xl.eu/hardware/computers/star-arabic-atari-65xe.html). I had dumped the ROMs for a friend. I've got two disks with these ROMs, and cannot remember the difference. Maybe I've just done it twice, for safety. Please find enclosed the ROMs of the Arabic 65XE, if you want to add it to Computer > Firmware > Operating System.

 

I also have the PERITEL 400 (http://www.atari800xl.eu/hardware/computers/peritel-atari-400.html) and PERITEL 800 (http://www.atari800xl.eu/hardware/computers/peritel-atari-800.html).

They are modified PAL machines, with added video circuitry. They are Atari-made modifications, as you can see from the Atari reference inside the chassis or on the additional video PCB.

I don't know if you have an interest in adding their support in Altirra, but I believe it could have an historical interest, at least for preservation. If you need anything, just let me know.

 

I believe we already had this conversation before but I hope one day Altirra will emulate the 1450XLD, with V: & M:. Unfortunately, I don't own this jewel, so I cannot help.

65XE_V2.ATR 65XE_V1.ATR

[ijor]

6 hours ago, phaeron said:

You're probably right, as this matches some tests I've been doing all afternoon on a Happy 1050. It's the leading edge that the FDC waits for, right?

 

I have the Write Track command updated with some more accurate timings and also implementing the 3-byte initial DRQ timeout, but it doesn't allow the 810 Turbo to pass the format tests. I'm now leaning toward a possible issue with RIOT emulation setting the index pulse too early, since I'm seeing indications that the behavior past initial timer underflow is more weird than anticipated.

 

Yes, the active edge is the leading one. Or more precisely, from the point of view of the FDC, it's the falling edge at the FDC input pin. This in turn usually corresponds to the leading edge as issued by the drive.

 

So the problem is that the edge is triggered too early? It seems that the diagnostic code just calls the firmware format routine at $FA2A, or it uses its own format routine? Because, if my math is correct, the firmware routine seems to be ok. The DD format routine waits for the initial DRQ, then fires the RIOT timer with a 1024 usecs timeout. Even when the value is rather low in comparison, it still should be more than enough for the 3 bytes delay that take less than 100us. That is, the FDC asserts the initial DRQ, delays 3 bytes, then it is ready to detect an IP edge. There are some small additional delays involved, but they shouldn't be too significant.

 

Quote

Force Interrupt is also giving me problems in tests, it's taking 3-4x the number of clock cycles for the second FI to be recognized after the first when interrupting a Write Track command, compared to what's specced in the datasheet.

 

I admit I never checked those values in the datasheets, but the Force Interrupt takes a variable amount of cycles that depends on exactly what the FDC is doing at the time

 

[Colleton]

I just want to say thank you for this, I had no idea Altirra existed.  I was using a different emulator and the results weren't that great.  I have it set up with Launchbox right now and full screen Atari gaming goodness is available with a few mouse clicks.  Using an xbox360 controller for input.

 

This is awesome!