I can see zero rational argument against using the Harting connectors - period. The Harting connectors weren't perfect (what is?), but they were sturdy and made for solid connections. Mobility between computers is neither here nor there. Things are mobile enough when they're loose and fall out. :) The cables can be a universal length - no problem. The only problem with the Harting connectors is their price, but I think they're worth it.

I've been working with these IDC contraptions for long enough to experience bent gold-pins and the whole assembly rocking in its socket, be it machine socket or precision socket. Or is the intention to solder the adapters directly into the motherboard? Nooooooo... :)

Not only thinking about it, but coding it. Simple (!) task-switching was the original plan (frozen background applications), then cooperative multitasking, and finally I opted to go for pre-emptive. Tebe has (it turns out) already described the approximate process elsewhere on this forum, some seven or eight years ago. It's perfectly possible to get the context-switching overhead down to a manageable level, at 50/60 times per second.

That's not to assert that several CPU intensive applications can appear to run simultaneously at full speed on the 6502. No-one would expect that. The fact is that most GUI applications are typically waiting for messages, and thus "not ready". Such processes would receive no CPU time until there's something in their queue. Most of the time, the user experience would still be similar to simple task-switching, although much more flexible than that.

This copying of program code from extended to main memory would probably work fine for a task-switcher, but not for pre-emptive or even cooperative multitasking. The GUI will switch context simply by switching banks, and copying small segments of the stack and page zero.

Certainly more RAM = more concurrent processes, but with the envisaged average GUI application size being 10-25KB, I still struggle to imagine how 256 16KB banks could be filled. Even if every application used 64KB for code plus data, that's still 16 large applications running at the same time on a 1MB machine. :) Of course there are DOS overheads too, if I still decide to sit the system on top of DOS.

But - 640KB seemed like more than enough PC RAM in the 80s, so I have no special objections to the idea. :)

It was only through implementing "external" pointers that I finally became convinced by your argument. :)

Note: sector values have always been absolute internally, but FDISK had hitherto presented them as relative to the APT base.

Doesn't look nearly as bad as I'd thought, anyway (at least with a small FAT in front) :)

Ignore huge number in last slot: bug.

FDISK does not use extended RAM at all. DEVICE SPARTA OSRAM is indeed recommended in 64KB... it places the sector buffers in the $C000-$CFFF region, thus conserving conventional RAM.

I can reduce the RAM requirement of FDISK by alleviating the (somewhat pointless) provision for up to 128 partitions. APT provides for a virtually unlimited number of partitions, but this was (I think) designed to compensate for the 32MB SDX partition size limit. In fact, only one or two people I'm aware of use more than half a dozen partitions. ;)

There's also a version of FDISK which is completely self-contained (which does not require the SDX library, nor DLLs, and is a conventional, stand-alone Atari binary file which runs at $2000) and runs with any DOS. I'll put this up on my website tomorrow, and I'll do some work on reducing the memory requirement of the application soon.

Great stuff - many thanks. :) If I get stuck with writing, I'll be back asking for more help. ;)

Do the SIO routines in XBIOS use the Pokey timers? In short, I could use a custom SIO routine which doesn't disable IRQs or NMIs and can work with - say - a Pokey interrupt triggering 800 times a second and a lengthy DLI running once per frame. High bitrates aren't really needed...

Nice font in the screenshots... other than that, someone please email me some questions in English. :)

Toolkit disk of SDX 4.46. :)

Right: low-down on FAT and APT, etc. If you want to have a FAT partition on the HDD which you can use with the FAT16.SYS driver, the partition entry in the APT partition table needs to point to the FAT partition as described in the MBR of the hard disk. This is the only way the partition will be visible to the PC AND to the Atari, since the Atari PBI / soft driver doesn't look in the MBR for partitions: it looks in the MBR for the APT entry, which is a pointer to the APT partition table. What's needed is a facility to LINK an APT partition entry to one of the MBR FAT partitions. I've done this with a hex editor before and it worked well, but I need to code something up in FDISK. It's not the easiest proposition, however, since I bascially need to add an MBR partition table browser to the software. You'd then select "Create external FAT partition", browse entries in the MBR, and press enter when you find the one you want. The Atari and PC would then both see this entry as - say - drive D:, and you could load the FAT driver on the A8 read files from it. If you put the FAT driver on CAR, you could even make it the boot partition. :)

Really, I'd like to add to FDISK the ability to create more than one FAT area on the disk, and this means a mini MBR partition table editor. So it's a question of finding the opportunity to get it done. I realize the FAT/APT size selection is about the weakest area of the software, and this is partly (though not entirely) because of the need to be concise in the 8KB CAR: version of FDISK.

The XEX loader does its own FAT housekeeping, and (in the final version) will simply "register" FAT partition information with the PBI driver. This relieves the PBI BIOS of having to parse MBRs and extended partition entries. The XEX loader will (when mounting an ATR, for example), simply pass the cluster number of the ATR to the PBI BIOS, along with the number of the registered FAT partition (which the XEX loader previously registered) the ATR resides in.

Good point regarding PG UP/DN. The paged approach makes more sense in a multi-column display (such as TLW in 80 column mode), I suppose.

Why not limit files per directory to 256? My math: 23 (size of RAW entry) * 256 = 5,888 bytes. Sure - I can understand the desire to accomodate the theoretical upper limit of entries, but does anyone actually put more than 256 files in a directory?