Altirra 4.20 released

[reifsnyderb]

9 hours ago, Tim Stone said:

NEVER SHOOT FOR MEDIOCRE IN LIFE.  GO AS FAR AS YOU CAN.

I am going to have to make a statement here.  Altirra is probably the best emulator ever made.  @phaeron has done an amazing job on it.  The emulator even emulates the hardware bugs.  In addition to the emulator, @phaeron wrote an Atari compatible OS and Altirra BASIC to go along with the emulator.  Both the Altirra OS and Altirra BASIC run on real hardware, are fast, and well written.  Altirra takes emulation as far as it can go and @phaeron is still making improvements to it.  The debugging support, within the Altirra emulator, is also top-notch.  Using Altirra's debugging support also greatly simplifies finding some of the more miserable issues when developing Atari software or firmware.  @phaeron has also gone to a great length to document Atari hardware in the hardware manual he wrote and provides it free of charge.  @phaeron has also been very helpful when I have asked him niche questions related to emulating portions of 1090XL hardware for development. 

 

Where Altirra is concerned, "mediocre" is at the distant opposite end of the spectrum.

 

Edited August 26 by reifsnyderb

[patjomki]

New user. 9 postings since saturday, five of them more or less aggressive.

 

I think he is either a troll or an agent provocateur from the c64 community 🧐🤓

Edited August 26 by patjomki

[darwinmac]

As soon as I saw the quote that reminded me of the garbage I find on LinkedIn (“Never shoot for mediocre in life …”), I knew the comments weren’t worth much. I can’t speak for the H: functionality, but I’m well aware of the quality software that @phaeron produces. 
 

I’ve always been happy with the help for those of us who use his software on non-Windows platform (using Wine 🍷). 
 

Whenever I have a problem on real hardware, the first thing I do is see if Altirra shows the same problem. 
 

Bob C

[phaeron]

15 hours ago, dmsc said:

That is easy: you need to implement XIO $28 in Altirra/source/hostdevice.cpp, line 1327

If only it were that simple. MyDOS 4.53 actually uses XIO 39 for this, which overlaps with SpartaDOS X's XIO 39 Get File Length. Apparently there was some effort to align on XIO 40 for this, but it's not clear which versions of MyDOS support or use XIO 40. The ambiguous XIOs are one of the reason that the H: device doesn't support most extended commands, although some of them are tough to implement externally (IIRC, SDX 4.48+ XIO 40 requires access to private data structures for some of the new segment alignment features).

 

Some DOSes also specifically check whether load segments overlap DUP.SYS <$3400 and use that to determine whether it needs to be reloaded -- though it looks like DOS 2's DUP doesn't use an XIO for its load command, the MyDOS might not have bothered with this check. And that's before getting to the weird divergences in DOS behavior in loading executables (the worst of which is thankfully quarantined to OS/A+).

 

It may be possible to make some of this work by adding an explicit setting to determine which DOS command set to use, but some behaviors like the COPY wildcard bug are possibly beyond what a regular CIO handler can deal with. There is not much that the H: handler can do when the COPY command has a hardcoded check to only enable some behaviors with the D device.

 

[Irgendwer]

22 minutes ago, phaeron said:

It may be possible to make some of this work by adding an explicit setting to determine which DOS command set to use

Wouldn't a hash over a memory range where (parts of) the DOS is settled typically help? (Knowing the restrictions applied to such a mechanism.)

[+yetanothertroll]

17 hours ago, Tim Stone said:

I love the type blah.txt like on MSDOS that is cool, but when I run supunarc.com it gives me an error 146.

 

This H: stuff is just horrible. Even under BW-DOS, I can't run executables like Super Unarc on an H: drive.   

 

So don't use it. So far I've been doing just fine without H: entirely, though now I'll probably have to play with it and see if I can achieve anything close to your level of butthurt. If you demand 64-bit Windows or POSIX level convenience, flexibility, and futureproofing from a 64KB architecture, that's on you.

[+yetanothertroll]

18 hours ago, Tim Stone said:

 

   Okay, so what about flipping this on it's head and expand on the virtual folder to the D drive? 

I tried to check the box for mounting the D drive and I can't get that to work. I don't know what number it mounts to on Atari Dos 2.5.  Can we get a dropdown instead of just checking a box to go to whatever D drive we want?

 

If H: is too limited why can I just load them on a higher D drive than D1: through D4:?

The version of Atari DOS II 2.5 included with Action! at https://sourceforge.net/projects/atari-action/ only likes D:, D1:, D2:, and D3:. Others I've tried only seem to like up to D2:. 8 bit Atari DOS isn't 16 bit MS-DOS. Have you considered writing your own DOS that can do everything you desire the way you desire and maybe even spare a few bytes left over for application programs or perhaps even load a game?

[ryswoj2]

23 hours ago, phaeron said:

System > Configure System > Devices > Add > Super Archiver w/ BitWriter, and then run the Super Archiver software. You'll need to Super Archiver firmware to run this configuration.

 

Thank you, but trying to copy any diskette results in a write error: Cannot save disk image: disk contains phantom or missing sectors. Copying to a physical diskette with a Super Archiver floppy drive works without a problem. Best regards, Richard.
 

[Tim Stone]

10 hours ago, reifsnyderb said:

I am going to have to make a statement here.  Altirra is probably the best emulator ever made.  @phaeron has done an amazing job on it.  The emulator even emulates the hardware bugs.  In addition to the emulator, @phaeron wrote an Atari compatible OS and Altirra BASIC to go along with the emulator.  Both the Altirra OS and Altirra BASIC run on real hardware, are fast, and well written.  Altirra takes emulation as far as it can go and @phaeron is still making improvements to it.  The debugging support, within the Altirra emulator, is also top-notch.  Using Altirra's debugging support also greatly simplifies finding some of the more miserable issues when developing Atari software or firmware.  @phaeron has also gone to a great length to document Atari hardware in the hardware manual he wrote and provides it free of charge.  @phaeron has also been very helpful when I have asked him niche questions related to emulating portions of 1090XL hardware for development. 

 

Where Altirra is concerned, "mediocre" is at the distant opposite end of the spectrum.

 

I don't disagree with anything you have said. My point only was that the file support could use a little help.  That's all.  Otherwise I agree 100 percent.  He is amazing and the Atari-8-bit emulator is amazing.

[Tim Stone]

6 hours ago, yetanothertroll said:

The version of Atari DOS II 2.5 included with Action! at https://sourceforge.net/projects/atari-action/ only likes D:, D1:, D2:, and D3:. Others I've tried only seem to like up to D2:. 8 bit Atari DOS isn't 16 bit MS-DOS. Have you considered writing your own DOS that can do everything you desire the way you desire and maybe even spare a few bytes left over for application programs or perhaps even load a game?

 

If I had this skillset I would have probably already done this.  I just don't find it too hard to go from D5: - D8:  It makes a lot of sense.  I mean when had a real Atari 800xl and 130XE, I didn't need more than 4 floppy drives, all I needed was 2, that was it.

[phaeron]

7 hours ago, Irgendwer said:

Wouldn't a hash over a memory range where (parts of) the DOS is settled typically help? (Knowing the restrictions applied to such a mechanism.)

Not really, because there are a surprising number of internal variables and buffers scattered within the DOS memory range -- this is also the reason that DOS.SYS is slightly different practically every time it's written to a new disk.

 

There are some quasi-standards involving checking memory around (DOSVEC) or the BPB, but I'm not sure how reliable they are. It'd likely be at least more reliable than trying to hash parts of DOS, at least.

 

6 hours ago, ryswoj2 said:

Thank you, but trying to copy any diskette results in a write error: Cannot save disk image: disk contains phantom or missing sectors. Copying to a physical diskette with a Super Archiver floppy drive works without a problem. Best regards, Richard.
 

This error message means that the emulator couldn't save the in-memory disk back to a disk image file, which probably means ATR. You'll need to re-save the disk image as ATX, since that format can actually hold sectors other than plain standard sectors.

[+yetanothertroll]

20 hours ago, Tim Stone said:

 

If I had this skillset I would have probably already done this.  I just don't find it too hard to go from D5: - D8:  It makes a lot of sense.  I mean when had a real Atari 800xl and 130XE, I didn't need more than 4 floppy drives, all I needed was 2, that was it.

Was there actual hardware that supported being D5 to D8? Which DOS could correctly identify any hardware that could be set to D5 to D8? Atari SIO wasn't ultra/wide SCSI you know

 

http://www.faqs.org/faqs/atari-8-bit/faq/section-23.html

 

EDIT: Or maybe it was lol

 

https://www.atarimax.com/jindroush.atari.org/asio.html

 

Edited August 27 by yetanothertroll
D15:???

[_The Doctor__]

1050's and other drives had mods done to allow the higher ID's, you might even find those in these and other forums

Not to mention hard drives, MIO/Black BOX, and ram disks

Today many a number of storage devices provide all the ID's and a way to swap others in as well for floppy and HD, not unlike BB and MIO

 

Edited August 27 by _The Doctor__

[+yetanothertroll]

8 minutes ago, _The Doctor__ said:

1050's and other drives had mods done to allow the higher ID's, you might even find those in these and other forums

Not to mention hard drives, MIO/Black BOX, and ram disks

Today many a number of storage devices provide all the ID's and a way to swap others in as well for floppy and HD, not unlike BB and MIO

 

Yup, something in the back of my brain told me I'd better go look up the SIO protocol to be sure I could back up my own BS 😁

[phaeron]

2 hours ago, yetanothertroll said:

Was there actual hardware that supported being D5 to D8? Which DOS could correctly identify any hardware that could be set to D5 to D8? Atari SIO wasn't ultra/wide SCSI you know

 

http://www.faqs.org/faqs/atari-8-bit/faq/section-23.html

 

EDIT: Or maybe it was lol

 

https://www.atarimax.com/jindroush.atari.org/asio.html

 

The SIO bus and SIO routines in the OS will support up to 15 drives. The only actual limitation is just conflicting with other device IDs, as there's only actually a single device ID in the command frame -- the SIO routines add DDEVIC and DUNIT together, and there's no separate unit byte in the command frame. Disk drive IDs start at $31 and are limited by printers starting at $40.

 

CIO supports up to unit 9 for any device when parsing filenames. It doesn't support two digit units, which is why the highest drives are often DJ: through DO: instead of D10: through D15:.

 

Older DOSes like DOS 2 are limited by the number of sector buffers they're configured for. Even then, 2.5 used D8: for the ramdisk, as the limitation pertains to physical disk drives supported and not other devices like H:. Newer DOSes have more flexible buffer support and don't need to directly tie MEMLO to drive count.

 

The most common stock drives like the 810 and 1050 have ID switches to select from D1 to D4, while some other drives like the PERCOM AT-88 or the 815 could use up to D8, as well as BlackBox drive emulation. Support above D8 seems uncommon aside from drives that allowed soft-changing the ID (Happy) or SIO2PC style devices.

 

[Tim Stone]

6 hours ago, yetanothertroll said:

Was there actual hardware that supported being D5 to D8? Which DOS could correctly identify any hardware that could be set to D5 to D8? Atari SIO wasn't ultra/wide SCSI you know

 

http://www.faqs.org/faqs/atari-8-bit/faq/section-23.html

 

EDIT: Or maybe it was lol

 

https://www.atarimax.com/jindroush.atari.org/asio.html

 

 

Also guys... I am not trying to be hostile here.  Just want to be clear.  I love Avery and his Altirra Emulator okay?  All I want is for better support for all of us.  That is it.  I am not trying to say I am smarter than anyone or that I don't love the work that he has done.

 

Because I find this emulator to be one of the best out there for any machine.  

 

I don't have the compiler nor the skills to be able to do what he does.  Yes, I have ChatGPT 4o, but that alone isn't a miracle.

 

I used Dosbox-X to run MSDOS Unarc because windows no longer runs 16-bit applications even when they are command-line based.  

 

Anyway.  I hope you understand...

[Tim Stone]

FEATURE REQUEST: 

 

          More robust support for H: redirected under D5: through D8: device support.

 

 

[phaeron]

31 minutes ago, Tim Stone said:

FEATURE REQUEST: 

 

          More robust support for H: redirected under D5: through D8: device support.

 

 

I'm not sure what this means -- you want D1-D4: to still access DOS drives while D5-D8: access H: devices?

 

That might be tricky, I'm not sure how doable this is. The way that CIO devices like D and H are registered is that there is a table of handlers by device letter, and then each handler handles all of the devices with that letter. Normally DOS registers D and the host device registers H. In order for this to work the host device would have to shadow the existing D device and try to forward D1-D4 through to DOS. That might work for DOS 2, it's likely to fail for SpartaDOS or whenever a program explicitly checks for the D letter when processing a path.

 

[+DjayBee]

Perhaps a stupid question because I do not use SDX:

 

Isn't PC Link exactly what @Tim Stone wants?

 

Transparent access from an emulated Atari to a directory on the PC using SpartDOS X ...

... through a device which can be added to the emulated Atari:

 

[Tim Stone]

20 hours ago, phaeron said:

I'm not sure what this means -- you want D1-D4: to still access DOS drives while D5-D8: access H: devices?

 

That might be tricky, I'm not sure how doable this is. The way that CIO devices like D and H are registered is that there is a table of handlers by device letter, and then each handler handles all of the devices with that letter. Normally DOS registers D and the host device registers H. In order for this to work the host device would have to shadow the existing D device and try to forward D1-D4 through to DOS. That might work for DOS 2, it's likely to fail for SpartaDOS or whenever a program explicitly checks for the D letter when processing a path.

 

Yes, exactly it.  Why should D5: through D8: only be for floppy drives only?  Why can't we use the lower-end for floppies and the other end for our local folders on our Windows based PC's?  I remember having Hard Drives hooked up from an ICD P: R: device back in the day to run my Bulletin Board System with Carina 2.  Instead of that, why can't we designate higher floppies to be folders?

[phaeron]

3 minutes ago, Tim Stone said:

Yes, exactly it.  Why should D5: through D8: only be for floppy drives only?  Why can't we use the lower-end for floppies and the other end for our local folders on our Windows based PC's?  I remember having Hard Drives hooked up from an ICD P: R: device back in the day to run my Bulletin Board System with Carina 2.  Instead of that, why can't we designate higher floppies to be folders?

There's no facility in the OS for assigning individual device units. The Central I/O subsystem (CIO) uses a handler table (HATABS) that only registers whole devices, like Dn: or Hn: and there's no direct way to "designate" only D5-D8:. In order to do this, it would be necessary to try to shim DOS's Dn: handler to split accesses between DOS and the host device. It also doesn't work whenever there's a command in DOS that specifically looks for the D drive letter on paths and assumes that it's dealing with a DOS device -- which would no longer be guaranteed.

 

Devices like the ICD MIO (which I assume you meant instead of P:R: Connection) simulate disk drives and not CIO devices. They can operate under DOS as a parallel bus interface (PBI) device, but that's a lower level than the H: device. Altirra does support that mode of operation by mounting folders as a virtual disk instead of a CIO device, but there are major limitations -- it's slower, doesn't support write access, has file size/count and update timing limitations, and can't do text EOL translation.

 

[Tim Stone]

6 hours ago, phaeron said:

There's no facility in the OS for assigning individual device units. The Central I/O subsystem (CIO) uses a handler table (HATABS) that only registers whole devices, like Dn: or Hn: and there's no direct way to "designate" only D5-D8:. In order to do this, it would be necessary to try to shim DOS's Dn: handler to split accesses between DOS and the host device. It also doesn't work whenever there's a command in DOS that specifically looks for the D drive letter on paths and assumes that it's dealing with a DOS device -- which would no longer be guaranteed.

 

Devices like the ICD MIO (which I assume you meant instead of P:R: Connection) simulate disk drives and not CIO devices. They can operate under DOS as a parallel bus interface (PBI) device, but that's a lower level than the H: device. Altirra does support that mode of operation by mounting folders as a virtual disk instead of a CIO device, but there are major limitations -- it's slower, doesn't support write access, has file size/count and update timing limitations, and can't do text EOL translation.

 

Yes, sorry.  It's been awhile.  Okay... So what method do you think would work the best?  What you have now?  Is there any way you can improve on it that makes sense?

[Tim Stone]

PRINTER FEATURE REQUESTS: 

 

  1) Printing of ATASCII CHARACTERS.  Right now it doesn't offer this as far as the printers that I tried. I have all four that you had implemented.

  2) Paper size support when printing.  Right now its just one paper and it keeps printing and doesn't allow me to do pages like on a PDF.  I have to sort this out manually for 8.5 x 11 paper, it would be nice to have different sizes of paper emulated.

  3) More support than just PNG, maybe multipage PDF support would be possible with a library added in.

  4) EPSON Dot matrix printer support so I can just run Printshop without having to load in a driver first.

  5) When you start printing the Printer Output box can pop-up automatically so you don't miss your printing.  I forgot to do this and I lost half of my print this way.

 

       THANK YOU AVERY FOR YOUR HARD WORK!

 

[_The Doctor__]

unless the printer supports font download / replacement you won't see Atascii chars. If it does then your driver needs to upload the set to the printer, There were a number of devices that would translate Atascii chars to printers graphics images on the fly and transparently for you. Maybe that would be the angle your looking for.

Some printers had native Atascii support either built in or in the form of a rom pack/interface card

[phaeron]

(sorry, editing problems... please bear)

Edited August 30 by phaeron