Altirra 2.20 released

[miker]

Hi there.

 

Can you test the following xex file in Altirra (preferably in PAL-mode), and make sure it is more similar to the picture on the left than the one on the right?

 

And here the file itself (yes, that one from my april fool joke): ingame.xex

 

It contains both TIP and gr.15 modes on one screen, and Altirra seems to display it in wrong way.

[+Stephen]

I think you need to turn on frame blending. I was able to view this in Altirra PAL, and it looked like the image on the left.

[morelenmir]

I have a feature suggestion which I think has not been made before.

 

I do a lot of typing in of BASIC programs. I tend to use a text editor for this in windows for sheer ease of use and laterly have been using the H: host device 'Enter h6:..." or so on to get them into Altira. One complication I have come accross are the atari special graphic Esc+ or Esc+Ctrl codes. To use these I have to type those specific lines of code in, inside the emulated machine and then "List H6:..." them out of Altirra before copying and pasting them into to the source file.

 

I wonder if some kind of markup or formatting code could be used for these during the H6:'ing line break process - perhaps something as straighforward and simple to use as <esc+ctrl+backspace>, for instance.

[miker]

I think you need to turn on frame blending. I was able to view this in Altirra PAL, and it looked like the image on the left.

 

Doesn't help... But maybe my system is somewhat bad.

[morelenmir]

I have found an interesting feature of the axlon ramdisk.

 

I set Altirra up as an '65xe/130xe' in Hardware, 'default' in firmware, '64k' in memory size and finally Axlon RAMDisk of 1024kb. Next I run SDX from a cartridge image and try "chkdsk o:" and 'mem /x' I find a disk of ~1024kb and "Use: BANKED, Axlon $3F" respectively. Therefore SDX has found and is using the Axlon 'hardware'.

 

However, if I make only one change - '128k' (or higher) in memory size - and do the same checks I find SDX has NOT found the Axlon.

 

Similarly with '600xl/800xl' in hardware but the rest of the first configuration in place, Axlon is detected by SDX. Also similarly if you bump memory size to '128kb' the ramdisk vanishes.

 

Is this supposed to happen? Is there a conflict between 128kb of system memory (or greater as the same happens with 320kb+) and the Axlon system?

[+Stephen]

Hi there.

 

Can you test the following xex file in Altirra (preferably in PAL-mode), and make sure it is more similar to the picture on the left than the one on the right?

 

And here the file itself (yes, that one from my april fool joke): ingame.xex

 

It contains both TIP and gr.15 modes on one screen, and Altirra seems to display it in wrong way.

Apologies Miker - this file does in fact display the way you showed (screen on the right). The file from Fandal's site displays properly.

[flashjazzcat]

Is this supposed to happen? Is there a conflict between 128kb of system memory (or greater as the same happens with 320kb+) and the Axlon system?

 

Two things: First, (AFAIK), the Axlon RAM uses a different banking register (i.e. not PORTB), so if both a standard 64KB of extra RAM and an Axlon upgrade are emulated simultaneously, the RAMdisk driver will only choose one and not the other (there's no provision in RAMDISK.SYS to specify the banking register, so it presumably works with whatever it found first, which is likely PORTB).

 

Secondly, RAMDISK.SYS won't set up a RAMdisk by default if the computer only has 128KB unless you force it to by using a custom CONFIG.SYS. So - this is my speculative explanation of why there's no RAMdisk when you select both extended RAM types at once.

 

In any case - I doubt both upgrades could logically co-exist on real hardware (they both use the $4000-$7FFF banking region, I believe), so the emulator behaviour you're seeing strikes me as quite right and proper.

[morelenmir]

I did a bit more reading about the technique of 'banking' and I think you are quite right. From what I have learned it is a bit like the old EMS memory in DOS days prior to XMS. It actually sounds like to do banking you use an array-like system of memory - bank 01/byte 01, bank 01/byte 02 and so on? So perhaps a better similie would be the 'Near' and 'far' pointers in 16-bit C/C++?

 

Something I also didn't realize is - somehow, at least to my feeble understanding - the xl/xe's and so on actually used the old joystick ports 3&4 which you would have had on a 400/800 to somehow do the 'banking'. Which I find quite amusing. I always wondered why they got rid of them. I guess that's why.

[phaeron]

Hi there.

 

Can you test the following xex file in Altirra (preferably in PAL-mode), and make sure it is more similar to the picture on the left than the one on the right?

 

And here the file itself (yes, that one from my april fool joke): ingame.xex

 

It contains both TIP and gr.15 modes on one screen, and Altirra seems to display it in wrong way.

 

Initialization bug in program -- it is overwriting the OS display list on load and enabling DLIs before the VBI handler has a chance to swap the display lists. Depending on the EXE load timing, this can cause ANTIC to hit a JVB instruction with the DLI flag, which then causes the DLI to recurse repeatedly and get its even/odd flag out of sync. Amazingly, the program manages to recover from this without crashing, but with the flip state inverted.

[miker]

Oh, my...

 

In fact this required to put the value $7e (or lower) into $6a (there was: POKE 106,128) and the re-initialize screen in any mode.

 

OK, so please disregard this example.

[phaeron]

Odd, that's the exact issues to expect when it fails the timing checks..

 

Have you got anything on that isn't a stock Atari, ie 320 ram, VBXE etc etc.

 

Some of the old games checked for wrongs OS's ie Omnimon, odd ram sizes and any addons for creating freeze states.

 

Yup... if what is showing up is like this:

 

 

...then it is due to a failed copy protection check. The original loader for Mr. Do! checks if a certain section of the disk load completes within half a second (28 VBLANKs), by hooking the immediate VBI vector and counting frames. This count is supposed to be about 60 on an original copy and standard drive in NTSC. If the game loads too fast, it's assumed to be running a patched version on a Happy drive or similar and the game deliberately bombs when you drop an apple. Usually the versions on traditional disk formats are already patched; you would need a disk image format like VAPI (.ATX) that can hold the original format for this issue to be possible. Of course, if you just try to image an original to .ATR it will fail. It's also possible even for a patched version to fail on real hardware if loaded with an image loader that tries to reuse memory at the bottom of the stack page.

 

It looks like the help file needs to be updated, though, because in order to pass this check you usually also need the Accurate Disk Timing option enabled -- the disk still loads a wee bit too fast without it.

 

(Location $113 holds the VBI count, if anyone's curious. I have a slowly growing list of "interesting" things that various Atari programs do....)

[phaeron]

Whosoever who wrote this amazing emulator for PC. I did tried to boot up in Prototype Atari 1450XLD and 1400XL ROM and all I see is green output display. Anyone who can tempering to fix this issue ?

 

Altirra doesn't claim to emulate the 1400XL or 1450XLD and has no mode for doing so, so there really isn't an issue to fix....

 

Also, those computers just use a plain XL/XE OS; the magic happens in parallel bus interface (PBI) hardware handlers. Therefore, if you have the right OS, it'll just boot as usual but the parallel disk, direct connect integral modem, and voice functionality will be missing. In theory, you could build yourself one as a PBI add-on for an existing XL/XE computer, but there's little point considering that these computers don't seem to have ever existed in fully functional form, just somewhat working prototypes. Sorry, but I likely won't be adding emulation support for this; a speech synthesizer chip, a modem + ACIA, and a parallel disk drive is a lot of hardware to emulate for a computer that arguably never really existed and won't ever have any new software written for it.

 

From what I can tell, Atari800 has partially working emulation based on the prototype specs, so you can try that.

[phaeron]

I have a feature suggestion which I think has not been made before.

 

I do a lot of typing in of BASIC programs. I tend to use a text editor for this in windows for sheer ease of use and laterly have been using the H: host device 'Enter h6:..." or so on to get them into Altira. One complication I have come accross are the atari special graphic Esc+ or Esc+Ctrl codes. To use these I have to type those specific lines of code in, inside the emulated machine and then "List H6:..." them out of Altirra before copying and pasting them into to the source file.

 

I wonder if some kind of markup or formatting code could be used for these during the H6:'ing line break process - perhaps something as straighforward and simple to use as <esc+ctrl+backspace>, for instance.

 

I've thought about this before, but it involves creating a viable escape format. <esc+ctrl+backspace> won't work, for instance, because it's a valid string that you can type from the Atari keyboard. That kind of format also starts getting weird with some of the symbol keys on the keyboard that are not as straightforward to name. Making this fully round-trip safe would also involve stealing a printable character for the escape which then must be escaped itself, hopefully in not too ugly form.

[morelenmir]

Would it be possible to maybe use the alt-numberpad codes to represent the atari characters? Just a page in the help file which mapped those to the atari equivalents might tie this up pretty nicely. I guess there would need to be an 'understanding' with the programmer to use a unicode text file on the 'windows side', but if that were accepted you could ensure the alt+numpad 'markups' are beyond any ascii number the atari might legitimately use in itself. 'alt+numpad700' for atari 'escape+control+backspace' say. To be really snazzy then you could use one of the atari ttf fonts like atari classic smooth from here http://members.bitstream.net/marksim/atarimac/fonts.html inside your windows text editor!

 

I may well be missing something in the niceties of the process though.

Edited April 3, 2013 by morelenmir

[Kr0tki]

Making this fully round-trip safe would also involve stealing a printable character for the escape which then must be escaped itself, hopefully in not too ugly form.

We could use non-ATASCII characters such as {} for markup.

[ilaskey]

Yup... if what is showing up is like this...then it is due to a failed copy protection check.

Brilliant, hit the nail on the head, thanks Phaeron.

[morelenmir]

I am getting back into exploring the many and various DOS'es. I seem to have encoutered a problem using SmartDOS v8.2D.

 

With Altirra set up as 130xe, 128kb and xf551 I can create a single density disk and have SmartDOS format it sucesssfully. However, if I 'insert' a doube density disk, choose reconfigure from the dos menu so it discovers the new density floppy and then format... SmartDOS seems to crash, or at least hang. Interestingly, if I cold reboot altirra with a double density floppy in the drive it will format successfully. Once again though, if I eject and create a new - now single-density disk - reconfigure and attempt to format I get an error 138, not a hang. All in all it seems to prefer actual disk images that have been saved as files rather than 'VirtRW' but the behaviour seems inconsistent and varies between what disks are in on startup, whether they are saved as files and if you are switching to new images/'reconfiguring' without rebooting. It is highly possible this is SmartDOS's problem, not Altirra. Still, I would be interested to see if anyone else has a similar experience.

[phaeron]

This is a bug in Altirra. Specifically, the disk emulator is returning the physical disk status in bit 5 of the first status byte instead of the last state set by the Write PERCOM Block command. Unusually, this DOS does a Write PERCOM Block to change the density setting and then retrieves it with Read Status, triggering the problem. Disk format commands have an extremely long timeout of four minutes, thus the apparent hang.

 

Try this version:

 

http://www.virtualdub.org/beta/Altirra-2.30-test14.zip

http://www.virtualdub.org/beta/Altirra-2.30-test14-src.zip

[morelenmir]

Many thanks Avery! I'll give that one a test drive.

 

My apologies, I think I've harrased you quite a bit over the months with my various DOS adventures!

 

And... Still not entirely there it seems. If I: -

 

Altirra set up as 130 xe, 128kb, xf551. Start up with SmartDOS in D1, nothing in D2. Boot and enter dos. 'Insert' a single density disk into d2. 'Reconfigure' SmartDOS - which correctly sees and formats a single density disk in d2. Next, 'insert' double density disk into d2. 'Reconfigure' SmartDOS - and here the error appears. It still sees only a single density floppy - which WILL format with no hang, but only to SD capacity. It does not appear to be recognizing the changed disk. To be clear, all of these disk images are not saved as actual ATR's, just running as memory images with 'VirtRW' set. HOWEVER, on further testing the same thing happens even if I do save the D2: DD disk image as an ATR before attempting to 'reconfigure'/'format'.

Edited April 11, 2013 by morelenmir

[w1k]

[flashjazzcat]

Many thanks Avery! I'll give that one a test drive.

 

Can you post the SmartDOS ATR here? I'd like to test it with U1MB/SIDE, out of interest.

[morelenmir]

Sure thing fjc, or at least I will when I learn how to make attachments!!! Could you point me in the right direction please?

 

Ahhh!!! Found it!!!

 

Here we go - I think that should be attached now,

SmartDOS v8.2D DISK - # - #.atr

Edited April 11, 2013 by morelenmir

[+Allan]

I found this in my pile of 'stuff to scan'. It's a copy of a copy but it's still readable. I don't know what version it's for but here it is.

 

Allan

Rana_Smart_Dos.zip

[morelenmir]

Many thanks allan! That is an interesting read. I actually looked over an article from analog I think which quotes sections of this manual. It is good to see the source material itself!

[phaeron]

Altirra set up as 130 xe, 128kb, xf551. Start up with SmartDOS in D1, nothing in D2. Boot and enter dos. 'Insert' a single density disk into d2. 'Reconfigure' SmartDOS - which correctly sees and formats a single density disk in d2. Next, 'insert' double density disk into d2. 'Reconfigure' SmartDOS - and here the error appears. It still sees only a single density floppy - which WILL format with no hang, but only to SD capacity. It does not appear to be recognizing the changed disk. To be clear, all of these disk images are not saved as actual ATR's, just running as memory images with 'VirtRW' set. HOWEVER, on further testing the same thing happens even if I do save the D2: DD disk image as an ATR before attempting to 'reconfigure'/'format'.

 

This usage pattern is a bit odd. What's happening here is that when you insert the new disk, the drive switches over to the density of that disk. The reconfigure command, according to the docs that were just posted, switches DOS between single density and double density mode for that drive -- so this then switches the drive from DD to SD, which it then dutifully formats with. There is no physical difference between an SD and DD disk -- the difference is just in the encoding, so it can be freely reformatted from one to the other. The PERCOM block setting in a disk drive is weird in that it is both used to detect the format of the inserted disk and to set the intent for the next format command. The strange behavior here is due to that overlap and this means that the reconfigure command necessarily has to allow the single/double setting to be different than what's currently on the disk.

 

Now, one thing that does come to mind is when the drive decides to update its settings based on the disk you stick into it. This has to happen at some point, and I think for the XF551 it happens on the next sector read. However, I don't know if this is common across all drives. Also, there's nothing preventing a drive from being powered off and back on, which would also reset the density setting behind DOS's back.