Hi, >> P.S.: It's really a pitty that the Apple II seems to be the only >> machine where one can presume that the typical user stepped up from >> the "original" DOS (here DOS 3.2/3.3) to THE "more useful" DOS (here >> ProDOS 8) - and not to "lots of" different incompatible DOSes like it >> seems on the C64. > You want to start a flame, don't you? ;-) Actually not ;-) > [...] DOS is ROM-stoned on the drive side [...] Beautifully put. > From my experience the most fragmented was Atari on this matter but there it paradoxically helped a lot that the DOS was booted from disk rather than kept in ROM. Wouldn't call this paradox but rather logically... > Problems happened with data disks, when there was no appropriate DOS disk at hand.. something that doesn't really happen on a 64 nor (as I understand from your words) on Apple ][ Sorry for being ambiguous. On the Apple ][ you have DOS 3.2, DOS 3.3, Pascal, CP/M and ProDOS 8 disks and they are all incompatible in one way or the other. But (at least as far as I understand in contrast to the Atari) this is not that much of a problem because not only the disk layout is incompatible but the API too. So a certain program is tied to one of mentioned DOSes. And the data files it uses are kept on compatible disks. So you only have issues when moving data between different programs (running on different DOSes) which wasn't that common to do according to my experience... So the point I wanted to make was: If I as an Apple ][ programmer choose that my programs (or in the case of cc65 my C library) works with ProDOS 8 then I can presume my Apple ][ users to understand this and handle it without getting into trouble. So from that perspective the Apple ][ is the only target I as programmer can easily take advantage of improvements made in DOS development. Regards, Oliver ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Thu Sep 20 14:16:51 2012
This archive was generated by hypermail 2.1.8 : 2012-09-20 14:16:55 CEST