Altirra 2.70 released

[fujidude]

Integer math is simply math that deals only in whole numbers and no fractional parts.

[Keatah]

The reason we have integer math is that it is faster than floating point math.

Edited August 16, 2016 by Keatah

[Mclaneinc]

Speed vs accuracy...My presumption being that I was a maths failure is that FP cores limit the number of trailing places to speed up the computation but are there situation where the more trailing numbers are better and actually used in real world work?

 

ie what needs a huge long trail for accuracy in the real world...Sorry, I know its a bit OT but does apply to Altirra a bit....ish..

[flashjazzcat]

Regarding VBXE, the point is that the blit lists are comprised of 19, 16 and 8-bit signed and unsigned integers. These can't be stored as numeric arrays in BASIC, so you'd have to have a bunch of data statements and POKE/DPOKE statements, or put the blit lists inside strings... but that's still not ideal since the blit lists need to be precisely aligned inside the MEMAC window. In an assembler like MADS, one can declare a blit record struct and lay things out in an extremely readable format. In BASIC, not only will it not look pretty, but it'll be slow and fiddly to set up.

 

As for FP in general: when I was coding in BASIC, I rarely needed floating point, and now that I'm coding in assembly language, I seem to need FP 0.01 per cent of the time... or rather 001 per cent of the time with a cosmetic decimal point added.

Edited August 16, 2016 by flashjazzcat

[Mclaneinc]

LOL Jon, I know FP has much more present day uses than the Atari but its nice to know its available for whatever needs there are...

 

And that is my last 0.1 word / byte etc on it

Edited August 16, 2016 by Mclaneinc

[flashjazzcat]

Any chance we could get a PBI device ID setting on the old KMK/JZ IDE v1 as well? The device's ID was controlled by a jumper on real hardware.

[phaeron]

Any chance we could get a PBI device ID setting on the old KMK/JZ IDE v1 as well? The device's ID was controlled by a jumper on real hardware.

 

Yeah, I can do that. Gonna shunt it to the 2.90 branch, though.

[StefanD]

With enabled SIO patch, Altirra 2.8 can't read sectors with $303 = 0 (error 143). With an original ATARI and Altirra 2.6 this works: The received data frame and $304/5 and $308/9 are ignored, if bit 6 of $303 is not set.

 

Examples: Boot a 180 KB DD image with QMEG+OS 4.04. Or boot XDOS 2.4 and enter the command "TES" (in both cases a sector is read with $303 = 0 to check the density - some older drives and the XF551 needs this).

 

Thanks for the new options "Pause when menus are open" and "Default write mode" in the Tools menu!

[Atari_Ace]

Avery, one feature I wish the Altirra debugger had was .logopen/.logclose. I could then bulk disassemble to a file rather than through the clipboard (I've been exploring the internals of PILOT and LOGO with the help of the Altirra debugger). Maybe I missed something in the documentation.

 

Another peculiarity is the use of 'o' for step over. Altirra seems to mostly follow WinDbg/Cdb debugger design, where 'p' has been the choice for step over for ages. I have done much single stepping in Altirra as of yet, but I have long experience switching between 'p' and 't' in cdb.exe. Perhaps an alias, since 'p' isn't bound as of yet.

[phaeron]

With enabled SIO patch, Altirra 2.8 can't read sectors with $303 = 0 (error 143). With an original ATARI and Altirra 2.6 this works: The received data frame and $304/5 and $308/9 are ignored, if bit 6 of $303 is not set.

 

Examples: Boot a 180 KB DD image with QMEG+OS 4.04. Or boot XDOS 2.4 and enter the command "TES" (in both cases a sector is read with $303 = 0 to check the density - some older drives and the XF551 needs this).

 

Ugh, gonna have to reopen the dev line for this:

http://www.virtualdub.org/beta/Altirra-2.80-test51.zip

http://www.virtualdub.org/beta/Altirra-2.80-test51-src.zip

 

Personally I find sending an SIO command and letting the reply data frame dribble on the wire to be a poor practice, but I'm about three decades late to do anything about it.

 

Avery, one feature I wish the Altirra debugger had was .logopen/.logclose. I could then bulk disassemble to a file rather than through the clipboard (I've been exploring the internals of PILOT and LOGO with the help of the Altirra debugger). Maybe I missed something in the documentation.

 

Another peculiarity is the use of 'o' for step over. Altirra seems to mostly follow WinDbg/Cdb debugger design, where 'p' has been the choice for step over for ages. I have done much single stepping in Altirra as of yet, but I have long experience switching between 'p' and 't' in cdb.exe. Perhaps an alias, since 'p' isn't bound as of yet.

 

You can use .dumpdsm to do bulk disassemblies. It also has disassembly options you can't normally get with the 'u' command.

 

As for the step over command, yeah, I realized at some point that it didn't match the WinDbg command; it matches Atari800's command instead. Never noticed it because I always use F10/F11/Shift+F11 to step instead. Not sure if I'll change it at this point, but you can remap it with an alias as follows:

as p o

Stick the command in startup.atdbg to run it at startup.

[Atari_Ace]

You can use .dumpdsm to do bulk disassemblies. It also has disassembly options you can't normally get with the 'u' command.

 

Interesting. That's clearly more flexible than 'u', but I'd still like to make an argument for .logopen/.logclose. The advantage of .logopen/.logclose is you can capture your entire session. PILOT and LOGO embed a fair amount of data into the cartridge more or less randomly, so I found myself disassembling in bits and pieces, doing a fair amount of byte dumping using 'db', et cetera. I'd cut and paste this into a large file and eventually edit it into a coherent disassembly. Having to generate lots of files and then merge them isn't quite as flexible. I can imagine other scenarios where being able to capture the debugger session would be useful.

[ilmenit]

Phaeron, is there some external API in Altirra that could be used to create something similar to ICU64? I have some project in mind and ability to pause, read and then write to memory would be very useful. Another option is just to compile the emulator myself with such changes but having an API would open it for other projects.

[flashjazzcat]

I recall talk of the CHS addressing limit in the past with regard to HDD images, but are the images hard limited to 7.5GB? I've been trying to test a 16GB VHD here attached to SIDE2 (basically to ensure the partition editor can encounter the values without overflow) and not only are the CHS fields empty but the "Resulting size (MB)" field reads "--". The ATA Identify device command appears to return 0x00EC3C4F as the total number of sectors (which equates to around 7.5GB), although the device model name is reported with the correct size ("GENERIC 16384MB SSD").

[fujidude]

Phaeron, is there some external API in Altirra that could be used to create something similar to ICU64? I have some project in mind and ability to pause, read and then write to memory would be very useful. Another option is just to compile the emulator myself with such changes but having an API would open it for other projects.

 

If I understand you correctly, you can simply engage the debugger. It has the ability to display memory or to write to memory. Then just unpause.

[StefanD]

Thanks, the $303 = 0 problem is now fixed.

 

One problem is left: Booting a 180K image with QMEG-OS still results in a repeated "Boot Error" with activated SIO patch. Reason is, that JSR DSKINV=$e453 is caught by the SIO patch, and QMEG's DSKINV differs from ATARI-OS: Normally DSCTLN=$2d5/6 is moved to DBYTLO/HI=$308/9, but QMEG moves $0080 to DBYTLO/HI if sector 1-3 is accessed. Unfortunately, DSCTLN is $100 when QMEG reads sector 1 with DSKINV, which results in error 138 with Altirra 2.8. This means also, that QMEG's RAM disk reader/writer doesn't work with the SIO patch. With Altirra 2.6 it works, since here DSKINV is not caught by the SIO patch (only SIOV is caught).

 

I solved this by turning temporarily the SIO path off with a keyboard shortcut, when booting a 180K image with QMEG-OS.

[Keatah]

Whoaa..

[ilmenit]

 

If I understand you correctly, you can simply engage the debugger. It has the ability to display memory or to write to memory. Then just unpause.

Yeah, but not a perfect solution to do it e.g. 25 times per second...

[phaeron]

Phaeron, is there some external API in Altirra that could be used to create something similar to ICU64? I have some project in mind and ability to pause, read and then write to memory would be very useful. Another option is just to compile the emulator myself with such changes but having an API would open it for other projects.

 

No, I've deliberately avoided creating such an API for maintenance reasons. Sorry.

 

I recall talk of the CHS addressing limit in the past with regard to HDD images, but are the images hard limited to 7.5GB? I've been trying to test a 16GB VHD here attached to SIDE2 (basically to ensure the partition editor can encounter the values without overflow) and not only are the CHS fields empty but the "Resulting size (MB)" field reads "--". The ATA Identify device command appears to return 0x00EC3C4F as the total number of sectors (which equates to around 7.5GB), although the device model name is reported with the correct size ("GENERIC 16384MB SSD").

 

The built-in VHD creation tool is limited to 4GB, but the VHD mounter and IDE emulator are not. Which words are you reading from the Identify Device output? 0xEC3C4F implies that you are reading the CHS limit; the 28-bit LBA limit in words 60-61 and the 48-bit LBA limit in words 100-103 should not be limited. Altirra does not currently support 48-bit LBA; I trust this is not an issue at the moment.

 

Thanks, the $303 = 0 problem is now fixed.

 

One problem is left: Booting a 180K image with QMEG-OS still results in a repeated "Boot Error" with activated SIO patch. Reason is, that JSR DSKINV=$e453 is caught by the SIO patch, and QMEG's DSKINV differs from ATARI-OS: Normally DSCTLN=$2d5/6 is moved to DBYTLO/HI=$308/9, but QMEG moves $0080 to DBYTLO/HI if sector 1-3 is accessed. Unfortunately, DSCTLN is $100 when QMEG reads sector 1 with DSKINV, which results in error 138 with Altirra 2.8. This means also, that QMEG's RAM disk reader/writer doesn't work with the SIO patch. With Altirra 2.6 it works, since here DSKINV is not caught by the SIO patch (only SIOV is caught).

 

I solved this by turning temporarily the SIO path off with a keyboard shortcut, when booting a 180K image with QMEG-OS.

 

Ugh. That's a breaking change, since the XL/XE OS and XL Addendum docs don't have that exemption. The DSKINV hook has actually been there for a while, but I fixed a bug in 2.70 that was preventing it from firing sometimes. I'm going to punt this to 2.90 since it's been this way for a while and it's too risky to change for 2.80, but I'll do something about this.

[flashjazzcat]

Which words are you reading from the Identify Device output? 0xEC3C4F implies that you are reading the CHS limit; the 28-bit LBA limit in words 60-61 and the 48-bit LBA limit in words 100-103 should not be limited.

Ack... I was reading words 57-58 (Current capacity in sectors), which is deprecated in later ATA revisions anyway. Ouch. Everything works now - thanks!

[StefanD]

Ugh. That's a breaking change, since the XL/XE OS and XL Addendum docs don't have that exemption. The DSKINV hook has actually been there for a while, but I fixed a bug in 2.70 that was preventing it from firing sometimes. I'm going to punt this to 2.90 since it's been this way for a while and it's too risky to change for 2.80, but I'll do something about this.

Thanks in advance! The easiest way would be not to catch DSKINV with activated SIO patch (or have an option to exclude DSKINV from SIO patch).

[Atari_Ace]

A minor nit with 'u' in the debugger, seen with Atari LOGO loaded:

 

Altirra> u 96A0 la
96A0: 9D 42 03 STA ICCMD,X [$0355]
96A3: A9 86 LDA #$86
96A5: 9D 44 03 STA ICBAL,X [$0357]
96A8: A9 37 LDA #$37
96AA: 9D 45 03 STA ICBAH,X [$0358]
96AD: A9 01 LDA #$01
96AF: 9D 48 03 STA ICBLL,X [$035B]
96B2: A9 00 LDA #$00
96B4: 9D 49 03 STA $0349,X [$035C]
96B7: 4C 56 E4 JMP CIOV [$E456] = $4C

 

Notice ICBLH is not recognized. I can add it with ya of course, but it's a curious omission.

[fujidude]

Yeah, but not a perfect solution to do it e.g. 25 times per second...

 

LOL. Obviously I did not understand you correctly. Not fully anyway.

[StefanD]

Suggestion to the SIO patch / DSKINV problem with QMEG-OS:

Since the DSKINV behaviour depends on the used OS, in my opinion the best way is to put a new option "No DSKINV hook with SIO patch" in the "Edit Firmware Settings" dialog - similar to the option "OPTION key inverted (hold to enable BASIC)".

Edited August 21, 2016 by StefanD

[Shannon]

Got a question.. I'm trying to create maxflash 1mbit and 8mbit (old format) carts using image disks. However they don't seem to work in any form of Atari800win or even the latest Atari800sdl..

 

Did the format of the maxflash carts change?

Edited August 21, 2016 by Shannon

[phaeron]

Got a question.. I'm trying to create maxflash 1mbit and 8mbit (old format) carts using image disks. However they don't seem to work in any form of Atari800win or even the latest Atari800sdl..

 

Did the format of the maxflash carts change?

 

If you are using the image disks to flash carts in Altirra and then saving out .car/.bin images to use with other emulators, it should work. If you are trying to boot the image disks in Atari800[Win], then it won't work; AFAIK the only Atari800-derived emulator that supports AtariMax cart flashing is a specially modified version of A8WP.