Project is underway again...

http://youtu.be/WNvF2Q_xqeI

Works out of the box here:

http://youtu.be/NdFdmW4UFp0

Where do you think 8KB frame buffer lives for this driver, not to mention code to drive it? MEMTOP is dropped by 8KB, MEMLO raised somewhat...

Smaller FDISK will come eventually, but patience is required, since I have little time.

Been over this before... best thing to do is install extra RAM and run SDX in extended memory. The SIDE driver isn't really intended to be used on a 64KB machine... at least I never intended it so.

My mistake for mentioning the core's existence... we have a phrase in the UK: "you can't miss what you never had". Anyway: perk of developing for the hardware, I suppose. :) Can't wait to see all the new VBXE development which happens when the new cores are released... we'll be flooded with software, no doubt. :D

Just discovered that the M1921A will sync down to 15KHz via the VGA-in, if the input source "RGB-DTV" is selected:

http://www.atariage.com/forums/topic/19 … try2722527

VBXE image quality is somewhat better than through SCART.

Still can't get the phase/clock set correctly with ST hi-res, however - nor can I get low/med res to work (although they do work via SCART of course).

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. ;)