Developing an Atari API

[Timothy Kline]

I'm entering that danger zone of the afternoon mental wall, so please forgive me if this has been discussed ad nauseum on the forum to little or no avail...

 

But has anyone ever entertained the notion of coming up with an Atari 8-bit API (Atari Peripherals Index) that mod developers could use to allow programmers to identify add-ins and modifications of any given computer...?

 

I picture it in my head as some sort of index that would work during the boot process, when the DOS or OS would do a cursory check of a pre-determined index in memory somewhere once the mods/add-ins are initialized. Each device would have an assigned API ID that, if found, sends the DOS or OS over to a special table where it would find allocated memory usages, device ID, and any other relevant information that could become accessible to the programmer either through the API vector, or direct (and risk later incompatibilities). This would have the added advantage of allowing multiple add-ins play nice with each other since the index and table assigns/allocates their respective memory addresses.

 

It'd be the closest thing to an Atari PNP operation, too.

 

Just a random brainworm...

 

--Tim

[+Stephen]

I think that Steve Carden's RealDOS can iterate and find almost every Atari mod out there. He would definitely be the one to ask.

[flashjazzcat]

A thing to remember is that many Atari peripherals are PNP to begin with and don't really need explicit identification or specialised calls. The SIO is a good example, since it's completely hardware abstracted and you don't particularly need to care whether there's a 1050 or SIO2SD hooked up to the machine: the methods for establishing disk volume size, etc (e.g. PERCOM blocks), are largely the same. The Atari's OS design makes it easy for different devices not to get in one another's way (CIO handler table, PBI device selection, etc). This even applies to hard disks, especially those adhering to the APT standard: the same partitioning software works with all the compliant devices because they all use the exact same API (with hardware abstracted by the drivers). There's nothing to stop you detecting and reporting a bunch of hardware at boot time, of course, but it's usually a largely cosmetic undertaking since you generally end up accessing everything using standard protocols anyway.

[Timothy Kline]

A thing to remember is that many Atari peripherals are PNP to begin with and don't really need explicit identification or specialised calls. The SIO is a good example, since it's completely hardware abstracted and you don't particularly need to care whether there's a 1050 or SIO2SD hooked up to the machine: the methods for establishing disk volume size, etc (e.g. PERCOM blocks), are largely the same. The Atari's OS design makes it easy for different devices not to get in one another's way (CIO handler table, PBI device selection, etc). This even applies to hard disks, especially those adhering to the APT standard: the same partitioning software works with all the compliant devices because they all use the exact same API (with hardware abstracted by the drivers). There's nothing to stop you detecting and reporting a bunch of hardware at boot time, of course, but it's usually a largely cosmetic undertaking since you generally end up accessing everything using standard protocols anyway.

 

Thank you, FJC, and you're right about the Atari's peripheral system being pretty much device agnostic.

 

I guess I was just thinking of a way to set up a certain specificity with modifications and add-ins (for example, a RAMBO 256k add-in vs a Newell vs a U1MB mod; a VBXE mod vs the upcoming Ultimate Video Upgrade mod... and so on). Plus, decrease the chances for overlapping memory usage between mods--more specifically, those which use banking.

 

This would allow anyone who wants to write a program to perform a check via the API and, if a certain mod is present, adapt to the special features of the mod--or in other cases, check explicitly for a mod, and then return a message stating that the program requires such-and-such in order to run.

 

Hope this makes a modicum of sense... O.o

 

--Tim

Edited May 26, 2016 by Timothy Kline

[flashjazzcat]

I see what you're getting at, and bundling together a library of code to detect VBXE, Stereo Pokey, etc, would probably be useful (such things are scattered around on various Wiki pages at the moment). RAM upgrade detection has been covered in a few topics, and since the majority tend to work in largely the same way (i.e. via PORTB bits), the best idea is usually to just establish the number of 16KB banks via software (an application usually doesn't care if an upgrade is RAMBO or Ultimate, only how many banks are available for use). Of course a couple of RAM upgrades used different banking addresses, and now you have the possibility of 65C816 linear RAM to think about as well.

 

The possibility for overlaps/clashes tends to occur more with control registers rather than RAM itself (i.e. an internal RAM upgrade and a PBI HDD using the same location for the RTC, for instance), but scrupulous research by hardware designers tends to keep things right. There were a few lists floating around the forum a while back describing all the common register locations. It's probably due an update. Meanwhile, a range of hardware is discussed in Phaeron's Altirra Hardware Reference manual, which should be required reading for hardware and software developers alike.

 

If the idea is to create a binary blob which spits out a software-readable description of what's in the machine, then that could be quite useful, although it would be difficult to create something concise and generic. When writing applications (in my experience, at least), usually one needs to establish a couple of things pertinent to the task at hand. For example, a word processor might need to know a) which DOS is running (in order to handle subdirectories or the lack thereof using a certain set of XIO commands), b) what display device is present (VBXE, etc), and c) how much RAM there is and which bits control it. It need not care whether the RAM belongs to Ultimate 1MB, RAMBO, Compy Shop, etc - just that there is (say) 320KB of it and that SpartaDOS X is already using 16KB of it (and SDX already provides an API for establishing the total RAM in the machine, which bits of PORTB select it, as well as how much RAM is free). With some other DOS (which doesn't report the RAM present), a hardware test is required (which will in turn yield the banking bits). So an intermediate layer would need to interface with both environments.

 

Meanwhile, the word processor probably will not care (and nor should it, owing to device agnosticism) whether the primary storage device is an IDE Plus 2.0, SIDE2, MIO, Black Box, XF551, SIO2PC or SIO2SD.

Edited May 26, 2016 by flashjazzcat