drac030

Just as some form of side notes to the discussion: 1) CAR: since SDX 4.49f has not been limited to 8k (8176 bytes to be exact) per file anymore. We were repeatedly receiving complaints about that, so now it is finally 7*8176 = 57232 bytes per file. I can see in the changelog that it was done in May 2021 - more than two years ago. 2) This per se means that a file residing on CAR: is not necessarily contained in one cartridge bank anymore. 3) The files on CAR: are not (and have never been) executed in-place. They are copied to RAM. The system sees them as normal file streams, thus a "read" means copying data from the media (cartridge banks) to the operating memory (per usual rules). 4) The limit of files open simultaneously on CAR: has nothing to do with the internal organization of the media. This limitation just saves memory. An open file requires a descriptor, which in case of the CAR: device takes up 23 bytes of the main RAM. If CAR: handled more files open simultaneously, it would probably be files_open*23+23, plus a lot more complicated handler code. There is no point to do that, if the only operation, which cannot be done because of that, is COPY. 5) MAN files stored on the CAR: are probably compressed, this is why one cannot display them directly. MAN COPY opens the COPY.MAN file and, when it detects that it was compressed, it hands it to ARC, which uncompresses it to a temporary directory ($TEMP$ - by default it points to the ramdisk). When done, it hands the uncompressed file to the program defined as $PAGER$.

Hum. A printer is of little use for a game, probably, but for a HDD I would say the opposite: it is a data storage and it can load games very efficiently (even by ATR emulation). Considering that I do not think that anyone really uses floppy disks nowadays, yes, parallel floppy drives are now a rarity. But HDDs not so.

I understand this. Just from my point of view, I do not have enough time to be fully involved in every software project related to SDX. I wrote the documentation, I offered assistance, if anything is not clear enough. But I do not have enough time to do more. Oh no. What you can say for sure is that PBI was never really properly *documented* by Atari, but it is pretty well developed, as far as I know. There are several devices which use it successfully, so... Yes, and the XE solution is better just by providing more signals. This also means that XE is not just a repacked XL, there was some value added between these two series, although I agree that it was not much. As far as I know, that is nothing good. It is better when external devices are powered independently. This is true, but the reasons are clear: a PBI expansion box is needed (1090-like), but it must come with extension boards, documentation etc. so that people could develop own extension boards. This means costs, effort, time etc. Do different devices connected to the SIO bus simultaneously really cooperate better than e.g. two IDE+ units connected to the computer at the same time? Especially SIO devices with different transmission speeds...? I have completely no idea what the FujiNet N: device does, but I guess that at least some of these functions may be emulated. Besides, it certainly opens files (via sockets?), so at least this part should not be hard. On PCL: there is no access to file metadata either, it is emulated by the server.

If the user base is so great, then I do not see why it has to be me to write the handler, who even do not have the device. I just wrote the documentation and made it available. I took my spare time to do that, because you asked for that, eventhough I really might have used that time for something else. And, instead of some sort of "thank you", what I get here? Sheesh.

Also many 65XE and all 130XE. These are the majority of Atari machines in Europe. As you write, the SIO is the least common denominator for all the systems, nevertheless, there is also a reason why Atari went for the PBI: namely, SIO is *slow*. Even at divisor 0, ~12 KB/s is slow in comparison with a basic PBI solution. Yes, the Fujinet has the undisputable advantage that it exists. It however does not seem to work very well, as said above.

The regular OS clrear screen routine clears the GR.0 display at about 15 cycles per byte, if I count correctly. Yours - at about 12. So, it is indeed a great speed improvement at the expense of basic compatibility - because it does nothing on XEP80, on VBXE, on a load of software-driven 80-column screens, still taking the time. Not to mention the fact that on VBXE (and on XEP probably too) the system-invoked CLRSCR is probably still much faster than this (on VBXE it is 1 6502 cycle per 4 characters). Plus, we obviously have here again the home cursor position being set at 0,0 "because Commodore"; plus some code mindlessly transcribed from OS, which justs hogs memory, instead of just using the regular E: functions. No wonder why even OP wants to get rid of that. Indeed, fortunately.

What is the sense of this? Why are you detecting drives, which are a legion, instead of protocols, which are about 5? And, what about parallel drives?

clrscr() optimized for speed. Like to make it execute once per frame, 50 times per second. At the expense of compatibility, portability and everything else. Yes, that makes perfect sense. Especially in a C library.

Some PC utilities that claim to be able to create SpartaDOS disks do weird things to the bootloader. E.g. they do not create any at all. Therefore indeed it is better to use a native formatting program or, under SpartaDOS X, CLX /B, which checks the bootloader and offers to replace it, if it detects that it is "non-standard" (which may mean "non-existing").

@Faicuai Thanks for the offer, normally I probably could hardly resist, but my spare time is so tight this year, that I probably will have to spend all my vacation sitting home at the computer. And that computer, unfortunately, will not be Atari with an assembler, but a PC with a wordprocessor. Of course, I will do some programming, but I just do not have time for new projects. That said, I also must say that I saw Fuijnet in action once and, how to put it gently, I was not impressed. IMHO its worst handicap is SIO (a parallel PBI version would be most welcome), and it is by design; but apart from that there were visible problems with stability, error handling (every problem was acknowledged by the software with a very informative message: "SIO ERROR"), and well, the only successful operation demonstrated to me was booting DOS XL from the network. This indeed shows that it works, nevertheless I can, and in a much more convenient way, boot DOS XL from my HDD, if I need it for a (weird) reason...

Not true.

Which also means that it would not hurt anyone if that register, in new implementations, was read/write.

That would be slow. Heck, I think it would be slow even on Rapidus, and even when the swapping device would not be a HDD, but the extra RAM. But it would be a fancy feature, undoubtedly. After thinking about it for a while, I guess that it would be rather difficult. Theoretically it is of course possible, but realistically... It is like porting SDX to completely new hardware: the internals of the cart would have to be completely rearranged to fit in 4k blocks. In any case, probably noone in Europe has such a machine, so we would not be able to test the port, if any were ever made. One could think of some uses, probably, yes. But - have you already used up all the 4 MB of the Axlon extension? Is this a real issue? The offcial banking register is $CFFF, so if any software exists, which use the shadows, it could probably be fixed. The worse thing is that the Axlon banking register is write-only. So it is either so that we leave the use of the expansion to the system only (unrealistic), or, when a program changes the active bank out of the system control, we have a problem: no previous configuration can be restored, because, in the first place, it cannot be read from the hardware.

Huh? This is what the C library has to offer for clrscr() and setcursor()? Why not simply putc(125) and a simple write to crscol/row? It would be not only more portable - to different Atari display handlers, at least - but also much shorter, no?

Note that the fact, that the SDX memory manager is hardware abstracted, could in theory also make possible to expand the extended bank range by swapping 16k blocks between an actual RAM bank and the swap partition on a HDD. The only bad thing would be that the swapped in bank should always be considered updated ("dirty"), because there is no method of checking if the 6502 was writing something to the memory or only reading it

I think it has been gone as of 4.49e, the SIOSET command assembled 28 November 2020 already does not support it. Yes and yes. The lowest supported divisor is now 1. Theoretically, because in practice I get stable transfers at 2. Such stuff is written in the release notes each time (whatsnew.txt). Yes, therefore the SIO driver installs own NMI handler for the transfer time.

The NMI code is not "broken", it is simply disabled.

It is not so XLESS supporting Axlon banking as SDX supporting Axlon banking: XLESS itself does not contain any code referring to any specific RAM expansion. The same is true for other utilities, e.g. resident drivers, COPY, etc. You should notice that if you e.g. copy your 2 MB file from disk to disk, COPY will do it in one read/write cycle. It is so because it uses the extension banks as copying buffer. Yes, it is a limitation of SDX memory handler: every extension bank gets own ID, aka "memory index", and that index is an 8-bit number. Therefore there can be 256 indexes in total, which seems sufficient; however, by ICD design, there are two special indexes: $00 (home/default bank) and $02 (system bank), and two others are reserved ($01 and $03). This means that the maximum number of actual extension banks SDX can "see" is 252 (or 253 if you count the home bank as one of them). On the screen shots you can see which of the banks is seen as the topmost one, it is the bank with the memory index $FC (on the Axlon, this is identical with the selection value you write to the $CFFF register). Therefore banks $FD, $FE and $FF are free and unused by the system. The index $03 is currently used to access the 65C816 linear memory, of course only in the presence of the appropriate memory manager loaded.

Ah yes, I am using the rev. D (therefore in emulation too). PCONFIG bit 5 = 1 - no CF card inserted (rev. E and up).

Not true

a) $80-$D3 is reserved for application programs, no use by OS/DOS, so you can use that freely. b) when not using FP, also $D4-$FF is free to use. And even when using FP these are usable, just remember that after a call to FP some locations will be changed. c) ZIOCB $20-$2F and the SIO variables $30-$3F are free to use with the same restriction, i.e. after a call to CIO or SIO, respectively, their contents will be lost. I do not remember at the moment, if $00-$01 is used for anything in SDX. SDX in fact uses the zero page very sparingly: $09, $0A-$0B, $0C-$0D, $15-$16, $18-$19, $1A-$1B, $43-$44, $45-$46, $47. Out of that, $15-$16, $18-$19, $1A-$1B, $43-$44, $45-$46 are temporary vectors which will get overwritten when your program does a respective system call. $09, $0A-$0B, $0C-$0D, $47 - better do not touch.

From my side I can confirm that flashing the emulated IDE+ BIOS ROM works here (PC, Win7 64-bit). I do it regularly to keep the emulation firmware/software setup as close to my real hardware setup as possible. The symptoms you are describing seem to point to a problem with the flashing process. If the software (like KMKDIAG) does not recognize the ROM, this means that it is probably empty or filled with garbage. Therefore it could be useful to see what is saved in the ROM image file. If this is confirmed, I am of course also interested in the diagnosis, because there may be something to fix on my side, too.

Not "to ROM", but, as I wrote, "to FP ROM area", i.e. RAM parallel with the said ROM.

XIO 40,#1,4,0,"D:fname.ext" in any BASIC under any decent DOS. Provided, of course, that the FP ROM area is writable (i.e. switched to RAM), as said already.

No and no. The SIO sounds would be turned off when iosnden=$00 (music playing or not, regardless). The assumption is that a program which wishes to play music during OS I/O would always set iosnden to $00. Therefore the SIO code in the OS should silence AUDCx channels *unless* iosnden=$00. And do that, by the way, not before, but after the I/O, just as the original OS does