Proposal: Atari 8-Bit Desktop Distro

[pixelmischief]

As many of you know, one of the things that the Amiga community enjoys is a number of carefully-curated, turn-key configurations to choose from: Classic WB, Amiga-In-A-Box, AmigaSYS, and AmiKit. They include a well-configured OS and a suite of best-in-breed applications. Effectively, they implement the "distro" model. Linux does the same for PCs, of course. This makes getting up, running, and productive on these platforms a snap. I would like to propose that we develop something similar for the Atari 8-Bit.

 

Pursuant to this, do any of the more prolific of our local celebrities have a reference image that they work from? I am imagining a 16MB ATR with everything one would need to use their Atari as the best version of a daily driver that the platform is capable of. And what do any/all of us think this would consist of? Currently, I am building up a SpartaDOS-driven configuration. It has The Last Word and Fast BASIC "installed" and working. I am now trying to get SynCalc up, but having trouble with VBXE's 80-column mode.

 

We look forward to a day when FJC's GOS is ready for prime time. Until then, however, let's cobble together a turn-key entry point for people who just want to get started already.

[+SoulBuster]

I do something similar for my STs. I have 3 Megafile 44s and 5 unbranded SyQuest 44s. I have one disk that has all the software that I want on every machine every time I set one up (currently have 4 set up, Falcon, Mega STe, Mega 4 and a 1040 STF, going to set up another Mega 4). I also have a floppy with HDDriver on it to get hard drives configured quickly. I store the floppy in the same case as the 44 meg disk so it is all together when I need it.

 

I think it is a great Idea.

[Gunstar]

This is something I've been working on, on and off for myself with SpartaDOS X and MyIDE II with FJC's driver. I want to set-up a software 80-column environment for programming, with either SpartaDOS's 80-column support or Omniview on my 1200XL. Of course TLW already has it's own software 80-column built in. Eventually, once I learn, I want to hack my own OS with FPP, 80-column and touch-tablet cursor control for programming environments, if I can't get it set up more modular through SpartaDOS X (80 column and touch-tablet cursor control with a driver?) There are plenty of OS's with good FPP already onboard.

 

But all the main application programs ready to go, etc. like you say and Autobat and other batch files to bootstrap everything the way I want it. But I want mine set up for Turbo BASIC, BASIC XE, ACTION! and MAC/65 or other. I was planning on a different floppy boot-up disk that would have an autobat file different on each boot-up disk from floppy drive 1 (my HDD starts at 5 allowing real or virtual drives 1-4), to start up other batch files on the HDD solution per programming environment wanted. Of course I have a lot to learn about SpartaDOS X yet, and I may find a better boot-strapping solution for different environments I can choose from a menu/list at boot-up directly from the HDD partition. I guess maybe a batch file doing that selection menu might do...but it's fun using the floppy drive to boot-strap my HDD system, old-school.

 

The problem I see with your plan, which I love, is so many environment options with the 8-bit already, with upgrades and HDD solutions of different types and configurations, I'm not sure that there can be one made that works for everyone. It seems at least several different versions need to be set up for different OS/memory/DOS/HDD solution upgrades and configurations.

 

For the longest time I've been trying to do this with Diamond GOS, ATOS and was hoping maybe FJC's GUI would be the answer, but I have finally given up on it through a GUI environment and just want it all done with SpartaDOS X, 80-column (I could even settle for SpartaDOS 65 column if need be) and touch-tablet support for cursor in E: mode wtih legacy software (the more touch-tablet, trackball or mouse compatible the better) and I'll be satisfied.

 

But the main applications, beyond languages I want to get set up like this are TLW, Syn-series apps, XLENT softwares Printware series, several key graphic art programs I like to use, so far. But another issue I have is finding .xex versions of most of these apps instead of ATR's.

Edited December 20, 2018 by Gunstar

[flashjazzcat]

The problem I see with your plan, which I love, is so many environment options with the 8-bit already, with upgrades and HDD solutions of different types and configurations, I'm not sure that there can be one made that works for everyone. It seems at least several different versions need to be set up for different OS/memory/DOS/HDD solution upgrades and configurations.

Exactly right. We already have a partition table standard for mass storage devices which has been adopted or at least supported by the sane developers, and a hard disk image which works with SIDE2 will work with SIDE/U1MB, Incognito, IDE Plus and any device capable of running the SDX soft-drivers (SIDE.SYS, MYIDE.SYS, etc). But a general consensus cannot be reached on what is the best DOS (it's SDX), so any disk image presented will have to be supplied in two or more different formats. Have fun preparing the MYDOS version, since any application which opens the disk with a drive number in the device name will automatically access the root folder.

 

The thing is: such a 'distro' is not that hard to produce for yourself in the exact form you yourself require it. The FastBASIC ATR I prepared for the OP required the following steps:

• Start my emulated U1MB machine in Altirra
• Create a new ATR on D1: and mount the FastBASIC ATR on a different drive number
• Format said D1: SDFS
• Copy everything from the FastBASIC ATR to D1:
• Create a folder called 'DOS' on D1:
• Copy the required drivers to the 'DOS' folder and create a CONFIG.SYS and AUTOEXEC.BAT

Slightly abridged, of course. But CONFIG.SYS is generic and will require some tailoring to the host environment.

 

Another thing: 'Desktop' may be something of a misnomer, since it suggests that application launching will be accomplished via a desktop metaphor, which does not appear to be the intention. In any case: the desktop metaphor appears to be the least efficient manner of launching software none of which employs said desktop metaphor.

[fujidude]

After reading FJC's post above, I'm kind of surprised that SDX isn't as universally adopted as I thought. I guess to me, it's hard to imagine why anyone would prefer to choose anything else for a de-facto standard. Sure, I can see wanting to mess around with other stuff once in a while. But if I were asked which one DOS should be the standard, the one that software and hardware are developed to work under, it would have to be SDX without hesitation.

[Faicuai]

NOTHING out there touches SDX.

 

SDX, and its hand-on-hand integration with Ultimate-1MB, Incognito and SIDE/2, have completely redefined everything I thought the Atari could do and be. Especially now, that I can compare directly to CP/M and ALL versions of MS-DOS.

 

When I go back to Atari DOS, MyDos, and the flurry of tiny little half-assed, half-baked DOSes out there (most of them useless beyond quickly loading files), I immediately notice the massive downgrade.

 

P.S.: If Konrad / Drac and SDX team are reading... What F-kick_ass product you have there! Just thanks for ALL the work and, most importantly, your interest in PRODUCTIVITY and PERFORMANCE !!!

Edited December 20, 2018 by Faicuai

[flashjazzcat]

First objection is usually that SDX boots from ROM and therefore requires some discreet hardware (cartridge, internal mod, etc). That means you have to install or plug something into each machine on which you need to run SDX (and you need to purchase something, e.g. a flash cart). Second objection is usually that SDX uses a CLI (despite the fact it includes an optional menu interface, another menu front-end which openly imitates the DOS 2.5/MYDOS menu, and latterly a Norton-style file manager for those who like that kind of thing). Third objection is that it's too complex (despite the fact it boots right up and is basically operational without any configuration at all).

 

Another problem is that it's not much good distributing software on SDFS formatted media unless the recipient is able to run SDX.

 

So there are some appreciable obstacles to universal adoption.

[pixelmischief]

First objection is usually that SDX boots from ROM.

 

What are the barriers and practical limitations to SpartaDOS being a disk-based operating system?

[flashjazzcat]

 

What are the barriers and practical limitations to SpartaDOS being a disk-based operating system?

 

Probably speed and storage. There's a library bank used by the relocating linking loader for fixing up global symbols, plus a lot of functions (printf, etc) held in a ROM bank, and then you have increasing amounts of the OS farmed out to the CAR: device as external commands. Migrate all that ROM-based content to RAM and permanent storage and the thing becomes a bit unwieldy.

 

Of course there are disk-based versions of SpartaDOS: the ICD 3.x variants and BeweDOS being the two I can recommend, although things seem a bit ascetic after being used to SDX for so long. BeweDOS is interesting in that it handles SDFS volumes and leaves the Shadow RAM unoccupied (SpartaDOS 3.x runs under the OS, meanwhile).

 

Note that no DOS other than recent SDX versions will handle 512 byte hard disk sectors; SDX handles them in SDFS and FAT16 format (the latter read-only). None of the older disk-based SpartaDOS variants should be used with 512 byte sector volumes, and SDFS also had a version bump during the past few years which introduced some (I think backwards compatible) changes to the boot sector.

 

One of SDX's great strengths is the fact it boots entirely from ROM, but it's also a chief obstacle to its universal adoption as a standard.

[pixelmischief]

I hear you on the challenges presented by the lack of universal acceptance for SpartaDOS and the daunting number and variety of configurations found in the wild. So, what we DON'T do is get caught up in trying to be all things to all people. Let's pick a reference configuration and start there.

 

SpartaDOS X 4.43 Cart

Supported Storage Adapter

APT Disk Partition

 

Software gives purpose to hardware. If we build a turn-key solution - one that boots up first time and includes a suite of software known to be best in their class, configured, and ready to run - people will get on board.

[Gunstar]

That works for me as long as SpartaDOS X 4.47 & 4.48 are still fully compatible with 4.43.

 

What about memory configurations? Are you sticking with 64K base. A menu to choose from? Auto detect and alter accordingly?

Edited December 20, 2018 by Gunstar

[fujidude]

As I see it, SDX must be in ROM (bank switched at that) due to all the code it has. That's true on a stock machine. But, what if you have a machine which has a substantial RAM upgrade, like 320K on up? Could all the SDX wonderfulness then be able to be able to be booted from disk into expanded RAM? The lowest common denominator in disk storage is an 810 able to handle SSSD (90K), but I have to believe most Atarians these days have at least enhanced density (130K) if not SSDD (180K) capable drives. Isn't it conceivable at least that a fair amount of what is SDX could fit on one floppy? Those who need much of the SDX functionality that deals with HDD, flash memory cards, etc., would have plenty of boot storage to bring in the additional software they need.

 

So I guess what I'm suggesting is a pure disk based SDX that is still full function, but requires a decent RAM expansion. Being able to utilize PORT B, Axlon, or even 65C816 linear memory to load the OS into would support pretty much all mainstream RAM expansions. What I don't know, is what proportion of active users are still stocker only; is very many? If it is imperative to support pure stockers, then perhaps just enough core of SpartaDOS could be loaded (similar to past disk based SD) to let them at least use the disk format and software which is able to run in stock memory configurations.

Edited December 20, 2018 by fujidude

[_The Doctor__]

I think the speed at which a cartridge moves in and out, as well as direct pbi devices (MIO ramdisk on up, so many other PBI/IDE/EmuCart interfaces using solid state media) have made the whole of it such that it should be able to use all the methods available. The leaner, Spartan, and more modular the better, even at divisor zero swapping something in or out becomes pretty much painless. While almost all PBI/Cart devices can stuff things faster than ram banking schemes, it would still be Nice to have a sort of SpartaDos X unchained edition... there might be a decent way to formulate a hybrid ROM/RAM/Soft disk. Sounds like a serious bit of heavy lifting though. If Sparta fights to it's way back remain Spartan and modular it would be very nice to have it works it's best in all forms. A unified Sparta. 300 held the hot gates. 300...

Edited December 20, 2018 by _The Doctor__

[pixelmischief]

I think our target audience for the first iteration can be assumed to have some combination of a cart solution to serve SpartaDOS X and a storage solution to serve the APT partition. As far as memory requirements are concerned, this should support most stock configurations, even if not all applications will run. Also, I misquoted the Sparta version. I meant to quote the latest.

 

I mean this first iteration to be lean and focused. However, as a greater number and variety of configurations are added to the support list, detection and automation should perform configuration switching in a way that is transparent to the user; even performing multiple reboots if necessary.

[flashjazzcat]

As I see it, SDX must be in ROM (bank switched at that) due to all the code it has. That's true on a stock machine. But, what if you have a machine which has a substantial RAM upgrade, like 320K on up? Could all the SDX wonderfulness then be able to be able to be booted from disk into expanded RAM?

It may seem like a real eureka moment to suggest that much of SDX's code-base could be housed in extended RAM, and while I wouldn't for a moment suggest such a thing is impossible, I don't think it would be easy. The problem with Atari RAM upgrades is that the banking window is at a fixed location. It therefore becomes extremely difficult for code situated in one RAM bank (or simply in base RAM between $4000-$7FFF) to access data or interact directly with the contents of any other extended bank. The address space of PBI firmware (which may have as many banks as you like under the math pack ROM) is not contended by anything other than the math pack and other PBI device handlers (which are usually invisible to one another anyway). Likewise the banked ROM (or even RAM) of an 8 or 16K cartridge has full access to every area of the machine aside from base RAM in the cartridge's own address space.

 

The SDX library includes a function called 'printf' which provides formatted string output. It appears that this function (which is only accessible when the SDX library is present, which is to say when the SDX cartridge ROM is enabled and not suppressed via the 'X' command) resides mainly in cartridge ROM, and relocatable, native SDX applications have references to 'printf' fixed up to an address in ROM (as I recall, at least; in any case, the call ends up in ROM, even if not directly). Since printf lives in ROM, it's able to access the caller's formatted string and pointers to arguments no matter where they are in base or extended RAM.

 

Now: I assume the intention wouldn't be to re-implement SpartaDOS 3.x and place all library and kernel code under the OS ROM, since that would create compatibility issues with a lot of titles (TBXL, TLW, etc). So presumably all code, buffers, drivers, symbols, relocating loader, etc, would have to live in extended RAM ($4000-$7FFF) or below the usual recommended MEMLO address (between $700-$2000). So that ~6K of base memory needs to contain all code which requires unobstructed direct access to data belonging to applications in base RAM (e.g. something calling 'printf') and/or code and data residing in extended banks. Which is to say: if 'printf' lives in extended RAM, it cannot be directly called from any code in either a different extended bank or any code in base memory in the same $4000-$7FFF area. An indirect call could be made to code in $700-$2000 which would page in the appropriate extended bank first, but the 'printf' routine in said extended bank would then be denied direct access to the caller's formatted string and list of pointer arguments were they situated in the same address space. Some circuitous method would be required to first cache the printf arguments in some area of RAM accessible to code in extended memory.

 

Likewise things like HDD drivers need sector transfer code to be situated outside of the banked RAM window, since they'll commonly be required to transfer sectors directly to sector buffers which may reside in extended RAM. Of course the driver and the sector buffers might happen to reside in the same RAM bank, in which case great. But if the calling application wishes to transfer a sector directly, or the file system driver simply needs to burst a sector in or out of main memory in the same address space as the driver code, the thing falls apart. The existing SIDE.SYS driver places the transfer code in main memory for exactly this reason, even though a sizeable section of the driver is also stored in the DOS extended bank. But all this stuff which needs to be outside of the banking window all adds up... especially when we suddenly find ourselves without a banked cartridge ROM.

 

As I say: certainly possible, although I think the likelihood of DLT undertaking such a thing is quite remote. But there are some very important reasons why SDX was delivered on a banked cartridge in the first place.

Edited December 21, 2018 by flashjazzcat

[pixelmischief]

[T]here are...reasons why SDX was delivered on a banked cartridge in the first place.

 

Yeah. Let's not, at least to begin with, get into anything that makes fundamental changes to the software components we use or the way they work, save maybe patching application software. Let's keep to this reference configuration:

 

SDX on Cart

SDX compatible storage adapter

APT partition

 

I think that our target audience will have at least this.

[Gunstar]

SDX on cart, check: Dropcheck Super SDX w/r-time and pass through for MyIDE 2.

SDX compatible storage adapter, check: MyIDE 2 thanks to FJC's driver.

APT partition, check.

 

Bonus: 192-512K memory from either internal Rambo or external Syscheck. 256-576K total ram. Technically even more available ram if I count the 512K sram on-board MyIDE (not all used by MyBIOS or SDX since I use other internal (32-in-1) or external OS's (Syscheck) and have SDX on cartridge). If I want MyBIOS, I can even flash it to the 32-in-1 or Syscheck too!

Edited December 21, 2018 by Gunstar

[fujidude]

It may seem like a real eureka moment to suggest that much of SDX's code-base could be housed in extended RAM, and while I wouldn't for a moment suggest such a thing is impossible, I don't think it would be easy. The problem with Atari RAM upgrades is that the banking window is at a fixed location. It therefore becomes extremely difficult for code situated in one RAM bank (or simply in base RAM between $4000-$7FFF) to access data or interact directly with the contents of any other extended bank. The address space of PBI firmware (which may have as many banks as you like under the math pack ROM) is not contended by anything other than the math pack and other PBI device handlers (which are usually invisible to one another anyway). Likewise the banked ROM (or even RAM) of an 8 or 16K cartridge has full access to every area of the machine aside from base RAM in the cartridge's own address space.

 

The SDX library includes a function called 'printf' which provides formatted string output. It appears that this function (which is only accessible when the SDX library is present, which is to say when the SDX cartridge ROM is enabled and not suppressed via the 'X' command) resides mainly in cartridge ROM, and relocatable, native SDX applications have references to 'printf' fixed up to an address in ROM (as I recall, at least; in any case, the call ends up in ROM, even if not directly). Since printf lives in ROM, it's able to access the caller's formatted string and pointers to arguments no matter where they are in base or extended RAM.

 

Now: I assume the intention wouldn't be to re-implement SpartaDOS 3.x and place all library and kernel code under the OS ROM, since that would create compatibility issues with a lot of titles (TBXL, TLW, etc). So presumably all code, buffers, drivers, symbols, relocating loader, etc, would have to live in extended RAM ($4000-$7FFF) or below the usual recommended MEMLO address (between $700-$2000). So that ~6K of base memory needs to contain all code which requires unobstructed direct access to data belonging to applications in base RAM (e.g. something calling 'printf') and/or code and data residing in extended banks. Which is to say: if 'printf' lives in extended RAM, it cannot be directly called from any code in either a different extended bank or any code in base memory in the same $4000-$7FFF area. An indirect call could be made to code in $700-$2000 which would page in the appropriate extended bank first, but the 'printf' routine in said extended bank would then be denied direct access to the caller's formatted string and list of pointer arguments were they situated in the same address space. Some circuitous method would be required to first cache the printf arguments in some area of RAM accessible to code in extended memory.

 

Likewise things like HDD drivers need sector transfer code to be situated outside of the banked RAM window, since they'll commonly be required to transfer sectors directly to sector buffers which may reside in extended RAM. Of course the driver and the sector buffers might happen to reside in the same RAM bank, in which case great. But if the calling application wishes to transfer a sector directly, or the file system driver simply needs to burst a sector in or out of main memory in the same address space as the driver code, the thing falls apart. The existing SIDE.SYS driver places the transfer code in main memory for exactly this reason, even though a sizeable section of the driver is also stored in the DOS extended bank. But all this stuff which needs to be outside of the banking window all adds up... especially when we suddenly find ourselves without a banked cartridge ROM.

 

As I say: certainly possible, although I think the likelihood of DLT undertaking such a thing is quite remote. But there are some very important reasons why SDX was delivered on a banked cartridge in the first place.

 

I appreciate your weighing in on this, though I must confess I'm not nearly as well versed as you in how this all works in the nitty gritty levels. Therefore, this will likely seem like a dumb question but: If the CPU doesn't see a difference between ROM or RAM as far as addressing, why would it be so much harder to deal with RAM banks being switched in and out as opposed to the ROM banks of the SDX cart already doing the same thing? If the answer is already in what you wrote I apologize, but if so I wasn't able to properly discern it.

[pixelmischief]

I have an Ultimate Cart, a MyIDE II, an IDE 2 Plus, an SIO2IDE, an SIO2SD, and an SIO2PC. Let's start working through what devices can provide what. Here's a link to the Google Sheet. I've done a first rough pass for what devices I am aware of and what I think they support. The "Confirmed" column should get filled with the name of person who does, in fact, confirm that the device supports what is indicated by the "X" marks. If not, then change and confirm.

 

https://drive.google.com/open?id=1JVjZlfIksiBoTNgSJ079WzN2iACt80I7deT_mojwT9g

[flashjazzcat]

If the answer is already in what you wrote I apologize, but if so I wasn't able to properly discern it.

It is, and it's all about address space. I tried to explain as best I could but don't feel bad if it didn't come across right. Basically: if everything (code, data, drivers, buffers, applications) is more or less residing in different banks which all appear in the same 16K window, it can get complicated. Having code in a banking window (i.e. the cart) in a totally separate address space makes it easier.

[Mr Robot]

I have an Ultimate Cart, a MyIDE II, an IDE 2 Plus, an SIO2IDE, an SIO2SD, and an SIO2PC. Let's start working through what devices can provide what. Here's a link to the Google Sheet. I've done a first rough pass for what devices I am aware of and what I think they support. The "Confirmed" column should get filled with the name of person who does, in fact, confirm that the device supports what is indicated by the "X" marks. If not, then change and confirm.

 

https://drive.google.com/open?id=1JVjZlfIksiBoTNgSJ079WzN2iACt80I7deT_mojwT9g

 

When you say the Ultimate Cart 'provides' SDX, do you mean 'can run the cart image'? If so pretty much all of the flash carts out there can do that. There are images for these devices

 

intSDX128 and intSDX128 "flash"

IDE Plus 2.0 interface

Maxflash 1Mb

Maxflash 8Mb

Maxflash MyIDE+Flash

MyIDE II RAM

MyIDE II ROM

SIC! Cartridge 256k

SIC! Cartridge 128k

SIDE HDD cartridge

SIDE2 HDD cartridge

SuperCart cartridge

Ultimate1MB

Turbo Freezer 2005

Incognito board

Turbo Freezer 2011

 

Also, carts like AVG/Ultimate Cart/The!Cart can run almost everything.

 

XEL-CFII / XEL-CFIII provide storage as well.

 

By 'storage' do you only mean APT HDD partitions? I'm not sure SIO2SD does that

 

I'd update the sheet but I only have view access.

[_The Doctor__]

this takes me back to why some 8k banking ram schemes were kicked around as opposed to 16k banking schemes. it's what's in those chunks that matters... two 8k chunks are not the same as one 16k chunk when you have small modules to bop around. although with the size of some of Sparta's stuff these days...

 

have to take into consideration how SDX currently can fill a bank when care is givin to the order and what it is sticking in there, could take a bit of thought... but might be doable. Vague remembrance of 4k being used for this and that back in the 800 days...

Edited December 22, 2018 by _The Doctor__

[Gunstar]

Vague remembrance of 4k being used for this and that back in the 800 days...

IIRC, your talking about the 52K 800, there is 4k of ram hidden under the OS or some kind of shadow ram that never gets used, even by the OS, I think it resides in the same area as part of the XL/XE's 16K under OS does. There were some 3rd party ramcard upgrades that took advantage of it with their own drivers for whatever, as I recall.

[pixelmischief]

When you say the Ultimate Cart 'provides' SDX, do you mean 'can run the cart image'?

My bad. I just meant 'Cart'. Generically, any device that can 'provide', 'host', 'present' SDX as a cart will suffice.

 

By 'storage' do you only mean APT HDD partitions? I'm not sure SIO2SD does that

Suddenly, I'm not sure why I have been insisting on APT partitions. In emulation, I simply use 16MB ATRs. The focus for the project is to minimize configuration complexity for the user and to curate the best collection of software that will work with SDX; though I think we may make some concessions on an application's ability to return cleanly to SDX on exit.

 

I'd update the sheet but I only have view access.

This is fixed. You can edit now. If you want to offer a new structure for working with the info, please create a new sheet in the workbook and we can all decide to move to that version.

[BillC]

IIRC, your talking about the 52K 800, there is 4k of ram hidden under the OS or some kind of shadow ram that never gets used, even by the OS, I think it resides in the same area as part of the XL/XE's 16K under OS does. There were some 3rd party ramcard upgrades that took advantage of it with their own drivers for whatever, as I recall.

The Mosaic 64K RAM card allowed access to the RAM from 48K to 52K and could select between 4 different 4K banks at this location. This memory was even available to BASIC by increasing the value of RAMTOP(IIRC a "POKE 106,208).

 

One card could be used in the 400, and up to 3 in the 800.

 

https://www.atariarchives.org/creativeatari/The_Mosaic_64K_RAM_Card.php