Antic extended mode and RAMdisks

[flashjazzcat]

I'm wondering (not having had the time to do any experiments yet) how a display using Antic extended mode on a 130XE compatible machine would behave with a RAMdisk or SDX using banked memory? I'm toying with various ideas for 80-column or proportional font display handlers but ideally I'd like to put the screen RAM and display lists in extended memory. Presumably RAM disks would play havoc with the display when DOS is switching banks in and out. They'd have to leave the antic bits in PORTB untouched. I'm just wondering whether it's a non-starter to keep the display data in extended RAM.

[drac030]

I'm wondering (not having had the time to do any experiments yet) how a display using Antic extended mode on a 130XE compatible machine would behave with a RAMdisk or SDX using banked memory? I'm toying with various ideas for 80-column or proportional font display handlers but ideally I'd like to put the screen RAM and display lists in extended memory. Presumably RAM disks would play havoc with the display when DOS is switching banks in and out. They'd have to leave the antic bits in PORTB untouched. I'm just wondering whether it's a non-starter to keep the display data in extended RAM.

 

There is no way to put CPU into one ext bank and ANTIC into another ext bank:, either one or the other (or both) have to access the base memory. Therefore, if you put the display memory into the ext RAM, and the SDX will work in the USE BANKED mode, the display will blink etc. on almost any DOS call.

 

For the future SDX releases, having in mind such programs as LW, I am planning to provide a "hub" CON: driver, which would do all the hardware-independent functions of the screen editor. This driver would maintain a set of "low level" function vectors, also accessible for programs, if they wish to bypass the "E:" for its slowness. A sort of this mechanism is already present in the CONxx.SYS drivers of 4.42, but I don't like the general layout of this. Anyway, you could try them, the description is in the manual, and share thoughts.

 

The low level functions I am planning would be: enable/disable text mode, raw put character(s), raw get character(s), scroll up, scroll down. The put char will buffer the text automatically. There will be three sets of vectors: for 40, 64 and 80 columns separately. This is where the basic console I/O drivers will hook up their code.

Edited March 1, 2009 by drac030

[Rybags]

The best you might do is "reserve" part of the RAMDisk by writing a dummy file of size a bit larger than the reserved memory you need.

 

Even then, it might need to be to an empty RAMDisk, and different DOSes might use the RAM in different order.

 

A patched DOS might be the best idea - modify it so that it never touches the first bank.

 

You still have the problem that whenever a RAMDisk file gets opened that DOS will fiddle the bank setting, not to mention that if your program fiddles the settings, the RAMDisk would probably get corrupted.

 

Then there's the problem of garbage onscreen if the banks change... it's almost the same as putting screens under the OS, so maybe just stick it there instead?

 

You could save the 1K or so for screen RAM - use a DLI each text line to switch RAM under the OS in. Give sufficient time for Antic to fetch the character codes.

 

Of course, you then need a copy of the Character set in RAM under the OS also (unless it's in normal RAM). And the whole thing collapses if you're doing any Serial activity.

[flashjazzcat]

Yeah, it sure sounds a headache. Certainly screen corruption is the primary obstacle; protecting the data from a RAM disk is another problem altogether (one I know all too well from my work on LW). The system I envisage will need upwards of 8K for the display RAM, which really impacts on application space (which is why The Last Word's code now lives under the OS ROM). The technology is there to make a pretty seamless 80 column display for the Atari8 (ACE-80 and SDX 4.42 being two good examples), but 80 column displays would be easier to live with on a regular basis if they didn't consume such large amounts of memory. It's a problem that's difficult to solve.

 

I like the idea of the SDX 64 and 80 column handlers being application programmable. The concept of having the display under the OS is probably the most attractive (it would work - or could be made to work - with SDX using banked, and the applications calling it would still have plenty of main memory), but there are numerous problems to overcome there, too. Ultimately what I had in mind was a Diamond-GOS like system (only faster), with a full range of proportional font plotting, windowing, and clipping routines. There was such a program many years ago called "Screens", and it was rather good. But having a GUI library sitting in RAM the whole time might not be practical. The alternative is to create a library which will can be integrated into individual applications. I can see a time in the future when programs like LW might get to the point where they absolutely require a GUI (with dialogue boxes, forms, scroll bars, etc) but I don't want to tie the software to a particular GOS such as Diamond: it's just too limiting (although it's very nice in theory and the API is pretty straightforward). Remember those MS-DOS applications such as DTP programs that loaded up their own GUI? I feel it would have to be something like that.

Edited March 2, 2009 by flashjazzcat

[Rybags]

Well, if you use the "Flicker" method of toggling 2 character sets for 80 columns, you save RAM, and could put the "logical character map" ie the 80x25 representation under the OS... still if you also want the Mode 2 characters under ROM you have to use the DLI tactic, charset still has to be in normal RAM.

 

Bitmap... well you could put it under ROM too but you then have the problem of having to blank the screen or present the user with something else whenever you do stuff like disk access.

You'd also have to do OS calls outside that area... no drama really.

 

Not sure how the keyboard IRQ would cope... I don't really see a problem... lots of us have done full-screen kernals to do stuff like 200-line TIP and APAC etc.

 

The one thing you do encounter is that the keyclick gets mucked up and sounds rediculous... of course you can dispense with the keyclick easily on XL & later anyway, and could easily supply your own if needed.

[HiassofT]

There is no way to put CPU into one ext bank and ANTIC into another ext bank:, either one or the other (or both) have to access the base memory.

ACK. The missing separate bank register is really a PITA and makes the separate ANTIC access mode almost unusable. Some time ago I thought about building a ram extension with such a feature (actually up to 3 bank registers: ANTIC read, CPU read, CPU write), but I never actually built it.

 

IMO the best use for separate ANTIC access (as it's present in 130XE) is to use main memory for screen data and extended memory for the CPU (program+data). Updating the screen data always requires CPU access, and if you put the screen in main memory the CPU is able to access all memory (main+extended) without any sideeffects on the screen. Only problem would be some DOSes that set the ANTIC bit to extended memory when accessing the ramdisk. But IIRC most ramdisk drivers keep unused bits at 1, meaning ANTIC would still access the main memory.

 

so long,

 

Hias

[drac030]

I like the idea of the SDX 64 and 80 column handlers being application programmable.

 

There is no other way to make the same program run on different display hardware. The hub will provide 40-column (GR.0) routines by default, apart from that I am planning to do 64-column and 80-column drivers for ANTIC (finally with DL scroll, I hope), and 80-column driver for VBXE. The greatest problem is to design the API so that it will be flexible enough and easy to use at the same time.

[flashjazzcat]

The missing separate bank register is really a PITA and makes the separate ANTIC access mode almost unusable.

I agree. This is why I won't miss the Antic mode too much when I eventually do my 320K upgrade. It's a design oversight but I suppose the Atari engineers could never have imagined the kind of stuff we'd be trying to accomplish twenty-five years after the 130XE came out. The prevailing view would seem to suggest it's easier to keep the display in main RAM and the program data in extended RAM. That means apps have to be specially written for banking code, however. The "flickerterm" technique is probably the most practical way to implement an 80 column replacement for the console device which unmodified (or minimally modified) programs can make use of.

[Cybernoid]

Wow. This thread is very interesting. I have been working on an 80 column E: and S: handler that sits in an extended bank. I, too, have been wanting to make it configurable so that it could be a 40column or 80 column handler. Funny how several people start to do the same thing...

 

What I have tried is to create the get_byte and put_byte routines, put the entry points for routines in the normal screen address space above $bc40. The first thing the code does is change the extended bank, then jump to code in the $4000-$6000 space. Then that code jumps back to the $bc40 space and turns extended banks off. For 80 columns in the extended bank you have 8k for screen ram and 8k for code. It works out okay. This way any time the OS needs to do the get_byte or put_byte routines it only modifies bits 5-2 of $d301 when these routines are called.

 

This is kind of working so far, I just have not got it to work with all the doses I want yet. You are right it is a real pain to mess with the extended bank settings since different doses do different things with $d301.

 

I'll post the handler when I get it kind of stable. It sounds like the Last Word handler is pretty cool so far...

[flashjazzcat]

Wow. This thread is very interesting. I have been working on an 80 column E: and S: handler that sits in an extended bank. I, too, have been wanting to make it configurable so that it could be a 40column or 80 column handler. Funny how several people start to do the same thing...

 

What I have tried is to create the get_byte and put_byte routines, put the entry points for routines in the normal screen address space above $bc40. The first thing the code does is change the extended bank, then jump to code in the $4000-$6000 space. Then that code jumps back to the $bc40 space and turns extended banks off. For 80 columns in the extended bank you have 8k for screen ram and 8k for code. It works out okay. This way any time the OS needs to do the get_byte or put_byte routines it only modifies bits 5-2 of $d301 when these routines are called.

 

This is kind of working so far, I just have not got it to work with all the doses I want yet. You are right it is a real pain to mess with the extended bank settings since different doses do different things with $d301.

 

I'll post the handler when I get it kind of stable.

Great! I would be very interested to see the work you've been doing on this. DOS's alterations to $D301 are going to be a stumbling block whichever approach you take. However, these problems aside, it sounds like you have something pretty workable there.

It sounds like the Last Word handler is pretty cool so far...

LW keeps the display in main RAM, thus avoiding all the problems we're discussing here. Of course, that's 8K of application space eaten up. LW's 80 column handler is pretty fast; at least on a par with ACE-80, whose author kindly let me borrow some ideas from his excellent program. Originally, LW was going to interface with various 80 column device drivers (including XEP-80), but a proprietary software-driven approach proved surprisingly successful. There's lots of scope for development, but the problem is always where to put the display data. LW already consumes everything from MEMLO up to $FFFF, plus as many expanded banks as you can throw at it!

Edited March 2, 2009 by flashjazzcat

[danwinslow]

It would probably be useful to work on some kind of standard for running code in extended banks. If we all come up with our own ways of doing it, we'll just get more confusion and incompatibilities. The normal way this kind of thing is done is that an engineering design document gets produced as a group effort, and then gets agreed upon as the standard way of doing things. Then third parties can write code that conform to the standard, and incompatibilities are minimized.

 

This document, if produced, would be a description of a very general method of running code from extended banks, ie., it would not describe how to do particular handlers or specific kinds of code, but rather a general scheme.

 

If anyone is interested, I volunteer to be the document coordinator. I have a sourceforge account set up for an atari library, so this could be a an accessible place to keep documents and example code. We can use discussion threads here for general discussion and sourceforge for storage. I would personally like to approach the technical aspects from a CC65 perspective, so I would help write some examples and so forth in C. The document itself should be language agnostic, describing what and how to do things but not how to express it in a particular language ( other than assembler maybe ).

 

What do you folks think?

[flashjazzcat]

What do you folks think?

Sounds like a good idea to me, and long overdue. Most serious applications have to consider extended memory management somewhere down the line, now that 256K machines and beyond are commonplace. The biggest headache when writing apps for the Atari8 is down to the lack of standardization, particularly with regard to stuff like memory management. I'd love to see the same coordinated approach applied to a standardized GEOS for the Atari8 somewhere down the line...

 

SDX's extended memory table is a good example of how to make memory management easier. Why not write a CIO handler or some kind of non-DOS specific memory management TSR which will provide a common application interface for handling memory (one of the program's functions could be to build a table of banking values for installed memory).

 

...thinking more about this: an "M:" handler? At the low-level, CIO could be used to put/get bytes to extended RAM (using AUX bytes for bank number and offset). A virtual memory handler would enable the tying together of more than one extended bank, so, for example, you could reserve, say, 48K of continuous extended memory using CIO and read and write to it reasonably quickly without having to worry about which bank you had to switch in and out. CIO could also handle awkward stuff like unbuffered data movement from one bank to another. CC65 could drape intuitive functions over these low-level CIO calls.

Edited March 2, 2009 by flashjazzcat

[Cybernoid]

Good ideas! I am writing my E: handler in CC65, so a coordinated effort would be good.

 

Also, I like flashjazzcat's idea of a M: handler. The only problem I see with that is it is only really good for reading and writing data to the extended banks, but what if you want to run code from extended banks... I suppose you could do a special XIO call for the M: handler that tells the handler to switch banks and run code at a specific address, then switch the banks bank and return..

 

The run code call could be use with an XIO 128 (or any number above 13):

XIO 128,#6,2,0,4000

 

ICCOM = 128

IOCB = 6

ICAX1 = bank number

ICBAL/H = run address

 

or you could pot the bank number into the ICDNO, so you could do:

OPEN #6, 12, 0, "M2:" (open extended bank 2)

XIO 128, #6,2,0,4000 (run at address 4000)

 

Of course, in basic, you cannot put the 4000 in the code, but you might have to poke the values in ICBAL/H directly, or change the address of a string somehow...

[flashjazzcat]

Good ideas! I am writing my E: handler in CC65, so a coordinated effort would be good.

 

Also, I like flashjazzcat's idea of a M: handler. The only problem I see with that is it is only really good for reading and writing data to the extended banks, but what if you want to run code from extended banks... I suppose you could do a special XIO call for the M: handler that tells the handler to switch banks and run code at a specific address, then switch the banks bank and return..

 

The run code call could be use with an XIO 128 (or any number above 13):

XIO 128,#6,2,0,4000

 

ICCOM = 128

IOCB = 6

ICAX1 = bank number

ICBAL/H = run address

 

or you could pot the bank number into the ICDNO, so you could do:

OPEN #6, 12, 0, "M2:" (open extended bank 2)

XIO 128, #6,2,0,4000 (run at address 4000)

 

Of course, in basic, you cannot put the 4000 in the code, but you might have to poke the values in ICBAL/H directly, or change the address of a string somehow...

I like it! I agree I mainly envisaged the M: handler as a data handling device, but apart from the fact that I'm sure data execution could be built into the handler as you describe, I do feel that access to data in extended banks would benefit from some standardisation as much as the execution of code in extended banks. The two issues seem to me closely linked, and any kind of agreed systems for extended memory management with regard to both data and program code would, from my point of view, be very welcome. It would be nice, for example, to be able to call a routine to, say, copy 10,000 bytes from $A000 to $3000 in extended RAM.

Edited March 2, 2009 by flashjazzcat

[danwinslow]

Here's some things I was thinking about :

 

1. A standard way to load code dynamically into extended banks. This probably implies relocatable code...at least relocatable within the bank, which adds a lot of complexity I think, but we could possibly write our own loader.

 

2. A standard way to locate and call banked code. I have been thinking here about some kind of index...say, for instance, there is always an index in the first 2k of bank 0. There would be some kind of lookup signature...maybe a specific number that identified a particular function. The index would also indicate the bank and calling address of the function. So, to call a function from banked, you would first need to resolve the 'address' by examining the index. Once its found, then you could just re-use the address info for subsequent calls, as the code should never get moved.

 

This is to support dynamic loading of drivers and library-type code at runtime. An external disk file could support symbolic name to lookup signature mapping... so a call like

load_library("mylib.bnk");

would locate bank space, load the library into it, and add entries to the lookup index at bank 0.

 

3. A standard way to pass parameters back and forth...I think this implies some kind of non-banked area to pass data in, but maybe a fixed banked area could be used. For cc65, I think the parm stack should be ok to be used, but that is language specific...but the general idea of a fixed non-banked area as a parm stack could be extended to assembler as well. The index on bank 0 could also provide information about the location of this stack.

[Cybernoid]

Here's some things I was thinking about :

 

1. A standard way to load code dynamically into extended banks. This probably implies relocatable code...at least relocatable within the bank, which adds a lot of complexity I think, but we could possibly write our own loader.

 

2. A standard way to locate and call banked code. I have been thinking here about some kind of index...say, for instance, there is always an index in the first 2k of bank 0. There would be some kind of lookup signature...maybe a specific number that identified a particular function. The index would also indicate the bank and calling address of the function. So, to call a function from banked, you would first need to resolve the 'address' by examining the index. Once its found, then you could just re-use the address info for subsequent calls, as the code should never get moved.

 

This is to support dynamic loading of drivers and library-type code at runtime. An external disk file could support symbolic name to lookup signature mapping... so a call like

load_library("mylib.bnk");

would locate bank space, load the library into it, and add entries to the lookup index at bank 0.

 

3. A standard way to pass parameters back and forth...I think this implies some kind of non-banked area to pass data in, but maybe a fixed banked area could be used. For cc65, I think the parm stack should be ok to be used, but that is language specific...but the general idea of a fixed non-banked area as a parm stack could be extended to assembler as well. The index on bank 0 could also provide information about the location of this stack.

 

 

What I am doing, is pretty simple for CC65: I setup the header for the segment of code I want to put into extra banks like this

 

	.segment "LOHEADER"
   .word   $02e2
   .word   $02e3
   .word   _extmem_set_bank0
   .word	 __CODE_LOAD__
   .word	 __BSS_LOAD__ - 1

 

 

The extmem_set_bank0 function is in a different code segment that is not part of the 0x4000-0x8000 address space. It is the following piece of code but could be anything as long as it is loaded into memory before the extra bank is:

 

void extmem_set_bank0(void)
  {
	 *(unsigned char *)0xd301 = ((*(unsigned char *) 0xd301) & 0xc3);
  }

 

This way, when I link the code together any code destined for the extra bank 0 is automatically loaded there, no matter what dos you are using...

[Shawn Jefferson]

Sounds interesting... but a couple of (mostly uneducated) comments:

 

1. cc65 has a standard extended memory API, but the Atari currently lacks an implementation. I'd like to see one done for cross-compatibility (and to tell the C64 guys that we've got one! ) Not very interesting to do I guess, since no one's done it yet. Not really on-topic, but the discussion made me think of it.

 

2. An M: device sounds interesting, but I think that extending it to also take into account calling code is going to be strange and complex. Probably each project should take care of that itself. Better, I think would be a standard library that takes into account the different DOSes and memory expansions. It sounds like flashjazzcat is almost there with that. Release that in a couple of different formats (cc65 library, asm library, etc...) and that would prove more useful than a custom M: device, IMO.

 

3. Wrathchild has done some interesting work with CC65 and extended memory. There are some posts over in the Atari 8-bit programming section from him regarding this. His methods take into account return-ing as well as calling.

 

4. Cybernoid, that's a nice implementation, and avoids the copying of code around, which is currently what I'm doing/will be doing with a cartridge-based project (same concept applies-it's just banked memory).

[drac030]

void extmem_set_bank0(void)
{
	  *(unsigned char *)0xd301 = ((*(unsigned char *) 0xd301) & 0xc3);
}

 

This way, when I link the code together any code destined for the extra bank 0 is automatically loaded there, no matter what dos you are using...

 

What if the bank the program wants to use is already taken or it does not exist? As it was pointed out above, you cannot do that without some sort of a TSR, that maintains the memory state. And this in turn is just reinventing SpartaDOS X, sort of.

[flashjazzcat]

1. cc65 has a standard extended memory API, but the Atari currently lacks an implementation. I'd like to see one done for cross-compatibility (and to tell the C64 guys that we've got one! ) Not very interesting to do I guess, since no one's done it yet. Not really on-topic, but the discussion made me think of it.

 

2. An M: device sounds interesting, but I think that extending it to also take into account calling code is going to be strange and complex. Probably each project should take care of that itself. Better, I think would be a standard library that takes into account the different DOSes and memory expansions. It sounds like flashjazzcat is almost there with that. Release that in a couple of different formats (cc65 library, asm library, etc...) and that would prove more useful than a custom M: device, IMO.

1. I have a CC65 memory management library written for the old Atari8 version which may prove useful as a skeleton starting point. It's designed for main-memory management, but does include malloc(), realloc(), free() functions, etc, managed via a linked list implemented in RA65 assembler. I'll put the whole library up here when I get time and people can do with it as they wish. Sadly (!) I'm wrapped up with LW at the moment.

 

2. I tend to agree, however CIO makes relocatable handler code easy to access. If not using CIO, we need to think of a way to tell various languages where our code and data tables reside. Re: my work with different DOSes and memory expansions: SDX is cut and dried - works great. However, I gave up on decyphering the DOS 2.5 and MyDOS RAM disk tables, opting instead to let the user configure things. If someone else can sit down and come up with some code that will reliably tell us which banks are used/unused by DOS 2.5 and MyDOS, it would be very welcome indeed. Furthermore, it's going to be essential to a project like this.

Edited March 3, 2009 by flashjazzcat

[drac030]

However, I gave up on decyphering the DOS 2.5 and MyDOS RAM disk tables, opting instead to let the user configure things. If someone else can sit down and come up with some code that will reliably tell us which banks are used/unused by DOS 2.5 and MyDOS, it would be very welcome indeed. Furthermore, it's going to be essential to a project like this.

 

Ok, but why care on DOS 2.5?

[flashjazzcat]

However, I gave up on decyphering the DOS 2.5 and MyDOS RAM disk tables, opting instead to let the user configure things. If someone else can sit down and come up with some code that will reliably tell us which banks are used/unused by DOS 2.5 and MyDOS, it would be very welcome indeed. Furthermore, it's going to be essential to a project like this.

 

Ok, but why care on DOS 2.5?

For a sense of completeness and perfectionism, for one thing! It bugs me to this day that LW can't automatically configure itself to avoid the RAMdisk on the DOS it's distributed with. And the fact is, lots of people still like using DOS 2.5. There are probably as many flavours of RAMdisk for that DOS as there are for MyDOS. MyDOS's banking table was if anything more tricky than DOS 2.5's (in my experience), so from a work investment point of view, it would be easier to discount MyDOS as well as DOS 2.5, which I don't think would be popular or practical. It would be great if all DOSes had stuck to a standard banking table structure from the word go; what a wonderful world this would be. Sadly they didn't. Unless this is going to be a SpartaDOS X only project, surely it's necessary to consider DOS 2.5 and MyDOS and the way any standardized expanded RAM code execution library might routinely obliterate their RAMdisks...

Edited March 3, 2009 by flashjazzcat

[danwinslow]

My plan for handling the used/unsused banks problem was to have a config file that describes which banks were free and which were not...probably with different sections for different dos's...the problem of telling which dos is in play is easier than trying to figure out the current banking scheme. I am not too concerned about technical difficulty; lets face it, the people who would ever use this feature will know enough to be able to modify a config file.

 

For the extended memory driver subject, I think what I have in mind is close to that, but maybe not as comprehensive as a full emem driver. I know that CC65 has an emem driver setup but I think it might not be suitable for other languages....or maybe more intensive than what I had in mind. I'd like to keep this as simple as possible. I don't want to try and work with psuedo-addresses or intervene in malloc schemes or anything like that. I just want a way to load and run regular code from the extended banks, with a standard way to lookup and call routines. I'd like to be able to dynamically load drivers and library code at runtime into arbitrary banks, and be able to obtain a calling 'address' ( which might actually be an offset into a call table in the bank index I was talking about earlier ).

 

Non-banked code would call an entry point with a reference to the function they want to run and a pointer to a parameters stack area. The emem caller function would

flip the correct bank in and call the function, then flip the bank back out when the function returns. Banked code would probably have to abide by certain restrictions...one that comes to mind would be no direct access to other banked memory. Another would be no knowledge of which bank you are in, and probably no bank flipping on your own. It might be handy to be able to map a reserved page or two in non-banked memory as a direct-access substitute, but that is edging towards full emem driver territory and I'd like to not go all the way there.

 

So, in general, I am seeing a small routine that sits in traditional memory at a specific ( configurable ) spot. This routine maintains a searchable index of callable banked code and a stack area for parms. Optimally, the index and parms would be banked as well in a specific 'index' bank. A loader routine would also exist that could be called with the name of a file to load and register banked routines. There would be a lookup function that allows non-banked code to detect the presence or absence of particular functions/drivers.

 

I have a little character-mode mouse routine, and I think I will try and mock up a demo of doing something like what I am describing with it.

 

 

But, my original question was about working co-operatively on a standard...is anyone interested in doing that? It would involve producing a document and some sample code.

Edited March 3, 2009 by danwinslow

[flashjazzcat]

My plan for handling the used/unsused banks problem was to have a config file that describes which banks were free and which were not...probably with different sections for different dos's...the problem of telling which dos is in play is easier than trying to figure out the current banking scheme. I am not too concerned about technical difficulty; lets face it, the people who would ever use this feature will know enough to be able to modify a config file.

It the most basic level, it's easy to assume DOS 2.5 and MyDOS are using the standard 130XE banks and nothing else. This kind of info could easily live in a config file. But what if the DOS 2.5 target machine is running a 256KB RAMdisk? Or none at all? Any other scheme will likely require interrogation of the current banking scheme. I absolutely agree that the DOS 2.5/MyDOS RAMdisk issue is a royal PITA, and there's no easy way around it. I think configuration must be placed in the hands of the end-user; i.e. any application using this library will have to have it's own config file set up by the user.

Edited March 3, 2009 by flashjazzcat

[drac030]

For a sense of completeness and perfectionism, for one thing! It bugs me to this day that LW can't automatically configure itself to avoid the RAMdisk on the DOS it's distributed with. And the fact is, lots of people still like using DOS 2.5.

 

While I understand the perfectionist's approach, I find it more logical to avoid forced support for a thing that can't be supported. DOS 2.5 is obsolete even from our very obsolete point of view, and seriously I don't thnik that there are really so many people who both use DOS 2.5 and are going to do wordprocessing on Atari. DOS 2.5 is for people who still have vanilla 130XE + vanilla 1050, I think such people will mostly use an emulator instead. If anyone is going to use the real thing, I guess that at least the mass storage will be upgraded to double density, and DOS 2.5 becomes useless then.

 

I am not going to convince you or suggest anything, I will just explain my point: I think supporting fewer main DOS-es (and fairly capable as well as fairly compatible like SpartaDOS, SDX, MyDOS) would be more profiteable than trying to support everything incl. DOS 2.5, which, I believe, nobody really uses for anything more serious than launching the LW from its distribution image

[flashjazzcat]

While I understand the perfectionist's approach, I find it more logical to avoid forced support for a thing that can't be supported. DOS 2.5 is obsolete even from our very obsolete point of view, and seriously I don't thnik that there are really so many people who both use DOS 2.5 and are going to do wordprocessing on Atari. DOS 2.5 is for people who still have vanilla 130XE + vanilla 1050, I think such people will mostly use an emulator instead. If anyone is going to use the real thing, I guess that at least the mass storage will be upgraded to double density, and DOS 2.5 becomes useless then.

 

I am not going to convince you or suggest anything, I will just explain my point: I think supporting fewer main DOS-es (and fairly capable as well as fairly compatible like SpartaDOS, SDX, MyDOS) would be more profiteable than trying to support everything incl. DOS 2.5, which, I believe, nobody really uses for anything more serious than launching the LW from its distribution image

Fair enough. If that proves to be a prevailing opinion, then I'm happy about the work and time it will save. I'm not and have never been a fan of DOS 2.5 and I don't want to sound like I'm creating difficulties where there are none. But this still leaves MyDOS (which I'm not especially a fan of either), which is surely still a "serious" operating system by any standards. I made some progress with it, but it was still an imperfect affair at the end of the day, so again I left configuration up to the user with that DOS. Coincidentally, SpartaDOS X 4.42 offers - to my knowledge - the only cast-iron, irrefutable method of establishing what memory is installed and what banks are used by the OS. If written correctly, the expanded RAM library will work perfectly with this OS.

Edited March 3, 2009 by flashjazzcat