SpartaDOS X 4.45

[drac030]

lda $d000
sta $d080

 

The purpose of this code (suggested by Candle) is to perform a reset of VBXE in case the CON driver is present (without this, the loading screen of the stock version was not displayed properly). I'm assured the code has no effect if VBXE hardware is not present.

 

That's like dropping a bomb over a power plant to switch off a light bulb. I wonder how you ensure later that the CON display is enabled back when the LW quits?

 

Regarding rewrites: your suggested solution still implies that the S_VBXE driver is present, and this is not necessarily the case. It therefore makes no sense to me to rely on a call to S_VBXE to notify the formatter that the XDL should be disabled. Since we can't rely on the S_VBXE driver being present at all with the current arrangements, it seems perfectly logical to me that the application should handle temporary disabling of the XDL itself, via the LW's overlay driver for VBXE.

 

If you already check the presence of SDX, one additional check and an init call (which you can later overwrite with other code) would free you from any additional code wrapped over a call to the formatter. But if you want to waste space ...

[Marius]

Imho drac030 wins the prize for most friendly and subtile participant of this thread!

 

[flashjazzcat]

I wonder how you ensure later that the CON display is enabled back when the LW quits?

 

I don't. Display is fine when LW quits. Bear in mind issue surfaced with stock (non-VBXE) version of the program. I wonder how a non-VBXE aware application which sets up its display using a custom DL and not a CIO call is to avoid disturbance by the CON display? CON evidently doesn't react to changes to the DL pointer (as does, for example, the TD line), and I'm genuinely curious regarding other possible solutions which wouldn't require changes to any affected application. It would seem to be a tricky situation to manage.

 

If you already check the presence of SDX, one additional check and an init call (which you can later overwrite with other code) would free you from any additional code wrapped over a call to the formatter. But if you want to waste space ...

 

The "one additional check" being for the presence of the S_VBXE driver. What happens if it's not there? I'd still have to use my own method of disabling the XDL.

 

Nevertheless and dispite the foregoing: your suggested method is fully comprehended, and it's understood that it will always be the best possible solution regardless of alternatives. Not much else to be said, except thanks.

Edited March 11, 2012 by flashjazzcat

[drac030]

I wonder how you ensure later that the CON display is enabled back when the LW quits?

 

I don't. Display is fine when LW quits. Bear in mind issue surfaced with stock (non-VBXE) version of the program. I wonder how a non-VBXE aware application which sets up its display using a custom DL and not a CIO call is to avoid disturbance by the CON display?

 

That's exactly the price for not using CIO calls: ignoring the OS causes the OS to ignore you. Now I don't quite understand, why you seem trying to avoid OS calls at any cost, even when you must already see that this causes more kludges to be necessary to workaround the arising problems.

 

BTW. if you: a) reset the VBXE, b) setup it anew by changing the pointer to XDL, overwriting the VBXE memory etc., c) do not use CIO calls, d) do nothing other to enable the CON upon LW exit, and still e) "display is fine after LW quits", I have nothing else to say that it must be some (horrible) coincidence that all this works together. Or the religion not only has faithful, but also its miracles?

 

CON evidently doesn't react to changes to the DL pointer (as does, for example, the TD line), and I'm genuinely curious regarding other possible solutions which wouldn't require changes to any affected application. It would seem to be a tricky situation to manage.

 

I wonder what CON could do with a pointer to DL? I think it should be obvious to anyone that a) DL is useless for an VBXE-based driver (in fact, CON isn't even VBXE-based, it is completely hardware-abstracted), b) an "E:" driver is no place to contain code manipulating all possible video hardware. The correct way - as I already wrote above only to be ignored - is this:

 

1) enable a standard (Antic-based) mode via a CIO call

 

2) change the display configuration (DL pointer etc.) as you wish

 

3) do GR.0 upon exit

 

With VBXE 80-column display active manipulating the DL is not possible, because there is NO DL there then, naturally, and the DL pointer is void.

 

What happens if it's not there? I'd still have to use my own method of disabling the XDL.

 

No, there is a misconfiguration problem at user's side then. The formatter to correctly cooperate with a VBXE display must be supported with the display driver, not loading the driver is asking for trouble, and this is the end of the matter.

[flashjazzcat]

Sigh... I've seen plenty of software which sets up custom DLs without first doing a CIO call to set up a screen mode. I wasn't levelling this as a criticism of the CON driver - just wondering how one might deal with the situation. If you only wish to support software written with consideration of the driver in mind, then that's perfectly laudible.

 

The fix for VBXE was suggested by Sebastian, who I believe designed the hardware. I can't see the point of arguing a fanny's hair width about it if you've already decided you're right. Clearly every situation can be retro-fitted so that it's somehow refusing to cooperate with drivers or OS conventions. Because of that it's pointless continuing the discussion. I'm wrong and you're right, as I've already said.

 

The TD line driver reacts to DL changes, so why is it not necessary to use a CIO call to preserve the TD display? Doubtless there's an easy rebuttal to that point... perhaps that if one has a VBXE board in the machine, there's no possible need to use non-VBXE software or anything that's not programmed to play nice with the drivers. But once again, you're right and I'm wrong, so I won't further humiliate and embarrass myself by trying to question your wisdom.

 

In short: I absolutely did not want loading of the S_VBXE driver to be a requirement for VBXE support in LW. No amount of gain saying will change that fact. I use the excellent S_VBXE driver for other purposes, but not this one. The idea that an application shouldn't interact directly with the hardware is - IMO - ludicrous, since circumventing hardware abstraction has been an accepted practice on the A8 since the year dot. The Antic version of the word processor couldn't use hardware abstraction for the 80 column mode because there was no such device driver (at least nothing fast enough, and don't forget it runs on DOSes other than SDX). There was no argument about the stock version of the program accessing the frame buffer directly, but it's not OK for a VBXE application.

 

OK - that's fine. If it breaks, it's all my fault.

Edited March 17, 2012 by flashjazzcat

[drac030]

If you only wish to support software written with consideration of the driver in mind

 

I thought I already asked you at least once to avoid adding to my posts what's not there.

 

Despite that: plenty of already existing badly written applications, whose authors are afraid of doing JSR CIOV? So what? You're writing a new one, is it an argument to you that you shouldn't use a CIOV call just because some crap written in 1982 (or 1992, or whenever) doesn't use it either? If so, I find it weird.

 

The TD line driver reacts to DL changes

 

So what? I am genuinely curious in what way this is a relevant example, if, as I already wrote above, when CON is active, DL does not exist? So what do you want it to manipulate or react to?

 

so why is it not necessary to use a CIO call to preserve the TD display?

 

? Sorry, I don't understand. What CIO call to preserve what?

 

In short: I absolutely did not want loading of the S_VBXE driver to be a requirement for VBXE support in LW. No amount of gain saying will change that fact.

 

I am fine with that, I just want to be sure that you understand that any amount of trouble you get from that decision is not a fault of the OS. This is really very simple: ignore the OS, get the OS to ignore you, have troubles you asked for.

Edited March 17, 2012 by drac030

[atari8warez]

The idea that an application shouldn't interact directly with the hardware is - IMO - ludicrous, since circumventing hardware abstraction has been an accepted practice on the A8 since the year dot.

 

It was also a guarantee for future incompatibility ... What was the Translator disk for???

 

The OS is there for a reason, simple as that, who wants to reboot after every single app who wants to mess with the hw the way it sees fit.

Edited March 17, 2012 by atari8warez

[flashjazzcat]

If you only wish to support software written with consideration of the driver in mind

 

I thought I already asked you at least once to avoid adding to my posts what's not there.

 

The intent is pretty clear to me. Every rebuttal ends in "use the VBXE driver", so what else am I to conclude?

 

Despite that: plenty of already existing badly written applications, whose authors are afraid of doing JSR CIOV? So what? You're writing a new one, is it an argument to you that you shouldn't use a CIOV call just because some crap written in 1982 (or 1992, or whenever) doesn't use it either? If so, I find it weird.

 

I missed the meeting where it's written that one should call CIOV before setting up a custom DL. There is no need until the goalposts are shifted by an unprecedented situation. I have no special objection to adding a CIO call to LW's init block if it amicably solves this particular problem, but I find the dismissal of any older software not easily amended as "crap" to be rather short-sighted. I recall a review of Diamond GOS which cited problems caused by "software which assumes that the display is in mode 0 by default, which is no longer the case". Perhaps if Diamond had set the display to mode 0 when loading non-GUI software, the problem would have been eased. I certainly expect to come up against similar problems myself when handling legacy applications, and I'm sure some workable solution can be found which doesn't involve writing off a lot of software which didn't do things in a particular way.

 

The TD line driver reacts to DL changes

 

So what? I am genuinely curious in what way this is a relevant example, if, as I already wrote above, when CON is active, DL does not exist? So what do you want it to manipulate or react to?

 

Why does the TD line react to changes to the DL at all? If it was patched into the CIO handler so that it reinstalled itself only after OS mode changes, it would probably disappear quite a lot. As for the DL not existing: well, it exists as soon as an application sets one up, surely. But no matter - luckily it's no problem to add a CIO call in the case of LW.

 

so why is it not necessary to use a CIO call to preserve the TD display?

 

? Sorry, I don't understand. What CIO call to preserve what?

 

To preserve the TD display. If an application changes the DL (to set up a custom display), the TD line reappears because it monitors changes to the vector. If the TD line only reacted to CIO mode changes, this wouldn't be the case.

 

In short: I absolutely did not want loading of the S_VBXE driver to be a requirement for VBXE support in LW. No amount of gain saying will change that fact.

 

I am fine with that, I just want to be sure that you understand that any amount of trouble you get from that decision is not a fault of the OS. This is really very simple: ignore the OS, get the OS to ignore you, have troubles you asked for.

 

Of course - and I fully understand and accept that, as I keep saying. Apart from anything else, I just didn't see that the average DOS 2.5, MyDOS, or BeweDOS user should be obliged to install S_VBXE (I forget the footprint of it) to use one application which - as it happens - provides its own driver of 2KB in size which does no more or no less than is required to get the LW VBXE editor display on the screen. I don't see a large number of other applications - outside of SDX - which use the VBXE display at all, and (considering the UI device handler I once suggested making, but was told it would be better as a DLL loaded as required by applications which needed it, rather than uselessly sitting there in memory when it's not being used) I considered a small proprietary driver to be the best solution at the time. When a large number of cross-DOS applications are developed which use the S_VBXE driver, the decision will no doubt end up looking rather short-sighted.

 

As proprietor of the particular DOS SpartaDOS X, you have the right to prescribe best practice guidelines for software intended to run well under that OS. Were LW intended solely for use under SDX, and assuming the S_VBXE driver was just as fast as the proprietary driver solution, perhaps I would have used it. I am not oblivious to the underlying elegance of hardware abstraction, although it's quite a difficult ideal to maintain on a machine with limited resources and processing power.

 

You do an excellent job, Konrad, and it's not my intention to be obstinate. I'm just trying to make the best of the situation, since it's not convenient for me to perform major redesign work on the application in question at the moment. At least I now have a better understanding of the task at hand and the parameters I'm working with.

 

The idea that an application shouldn't interact directly with the hardware is - IMO - ludicrous, since circumventing hardware abstraction has been an accepted practice on the A8 since the year dot.

 

It was also a guarantee for future incompatibility ... What was the Translator disk for???

 

The OS is there for a reason, simple as that, who wants to reboot after every single app who wants to mess with the hw the way it sees fit.

 

As I said: if it's always been perceived as best practice to do an OS call to set up a stock graphics mode before creating your own, then that's my bad. I can see no reason for it unless the default conditions are silently changed. This is what VBXE does (or a driver which implements graphics modes using it), since it's a fairly fundamental hardware modification. On the most fundamental level, the CIO screen handler has rarely been employed by word processors on the 8-bit to actually feed characters to the screen, because it's far too slow. That wasn't seen as poor programming practice - it was just seen as a reasonable solution to the problem. In a perfect world, every application would interact with the display through the CIO, and every application would then work with 64 and 80 column drivers, XEP-80 drivers, S_VBXE, etc, etc.

Edited March 17, 2012 by flashjazzcat

[atari8warez]

"As I said: if it's always been perceived as best practice to do an OS call to set up a stock graphics mode before creating your own, then that's my bad."

 

If one is programming for an Atari 2600 (a dedicated game machine) it may not be the best way of doing things, but programming for an 8 bit computer (or for any computer for that matter) is best done using the "official" OS calls. That is of course if you really care about how your software will behave with feature releases of the OS.

 

RESET key seems to be a very popular button to use on Ataris, simply because of software ignoring published guidelines in the quest of absolute performance (which is sometimes NOT the ultimate objective).

 

You have the luxury of working with a system (atari) which allows you to peek and poke everywhere in the 64K range to your hearts content. Try this with a midrange IBM computer for example (if you can of course ). But that's why those computers always run rock solid, the only time you need to reboot (or re-IPL as the saying goes in that world) is when and if the power goes-off (well, just remembered we had UPS for that too )

 

 

I am sure your LW will still be as nice even if you decided to go VBXE driver way, it will have the additional advantage of being "compatible" as well.

[Shawn Jefferson]

"As I said: if it's always been perceived as best practice to do an OS call to set up a stock graphics mode before creating your own, then that's my bad."

 

If one is programming for an Atari 2600 (a dedicated game machine) it may not be the best way of doing things, but programming for an 8 bit computer (or for any computer for that matter) is best done using the "official" OS calls. That is of course if you really care about how your software will behave with feature releases of the OS.

 

The only place I've seen CIO called first to setup and then modify it into a custom display list, is in BASIC programs. Why would a more advanced program do this? It's much easier to create your own custom DL, placed in memory appropriately for your program, same with the screen.

 

Of course, if you are wanting to be compatible with a DOS such as SpartaDOS, and its myriad of add-on functionality, you are going to have to take these things into account in some way (even if just to tell users not to use TDLINE, or CON drivers with your software.) I've always thought that the format functionality in SpartaDOS X was neat, but I don't understand why it has to have custom screen that requires a custom DL, etc... is there just an API you can call for format, pass it the appropriate parameters (gathered from your own GUI interaction with the user perhaps)?

[drac030]

If you only wish to support software written with consideration of the driver in mind

 

I thought I already asked you at least once to avoid adding to my posts what's not there.

 

The intent is pretty clear to me. Every rebuttal ends in "use the VBXE driver", so what else am I to conclude?

 

This not "my intent", but your prejudice. You so easily read "the VBXE driver call" where "a standard OS call" (like to enable GR.8 mode) is suggested, that there is even some variety of conclusions to do.

 

Despite that: plenty of already existing badly written applications, whose authors are afraid of doing JSR CIOV? So what? You're writing a new one, is it an argument to you that you shouldn't use a CIOV call just because some crap written in 1982 (or 1992, or whenever) doesn't use it either? If so, I find it weird.

 

I missed the meeting where it's written that one should call CIOV before setting up a custom DL.

 

And you only accept suggestions made on meetings. Heh.

 

There is no need until the goalposts are shifted by an unprecedented situation.

 

You already stumbled upon such an unprecedented situation: new hardware and new drivers for it. For the old hardware also has drivers, and it is also good to use them when the situation requires, like for upward compatibility.

 

I have no special objection to adding a CIO call to LW's init block if it amicably solves this particular problem, but I find the dismissal of any older software not easily amended as "crap" to be rather short-sighted.

 

You didn't specify which software you respect, so I naturally assumed that crap is also included. Short sighted? When a program does not work, I delete it. Short sighted task is writing a program which does not work, even if there are no circumstances whic could really prevent it.

 

I recall a review of Diamond GOS which cited problems caused by "software which assumes that the display is in mode 0 by default, which is no longer the case". Perhaps if Diamond had set the display to mode 0 when loading non-GUI software, the problem would have been eased.

 

It might. But since Diamond GOS appeared which makes the GR.0 no longer the default (which meeting stated, that the DUP.SYS has to work in GR.0, btw.?), then it should become clear, that it is a good programming techinque to explicitly switch to the required video mode. And it should be clear, that it is good programming technique to use OS call to do the switch. Otherwise, in case any new video hardware is used, with any new drivers (or even old hw with new drivers, like GOS), the program assuming such things as DUP.SYS operating in GR.0 will run into problems, and for me has a good chance to undergo DEL fname.

 

I certainly expect to come up against similar problems myself when handling legacy applications, and I'm sure some workable solution can be found which doesn't involve writing off a lot of software which didn't do things in a particular way.

 

Kludges to support legacy applications have the unfortunate effect of supporting unclean (and most of the time just bad) programming techniques forever.

 

The TD line driver reacts to DL changes

 

So what? I am genuinely curious in what way this is a relevant example, if, as I already wrote above, when CON is active, DL does not exist? So what do you want it to manipulate or react to?

 

Why does the TD line react to changes to the DL at all? If it was patched into the CIO handler so that it reinstalled itself only after OS mode changes, it would probably disappear quite a lot. As for the DL not existing: well, it exists as soon as an application sets one up, surely. But no matter - luckily it's no problem to add a CIO call in the case of LW.

 

TD reacts because it hooks up the VBL vector and monitors the top of the DL for the presence of the JMP to own DL. I still fail to see any relevance here: even if CON monitored DL pointer on VBL (wasting CPU time), then what if the pointer changes? Call the routine switching video modes? Inside interrupt routine? How do you know, besides, that the user wants the mode to be changed? In case of the TD it is easy, because TD does not hog the entire display, so the user's display does not change. Would you like a TD version which would force the display to GR.0 every time you want to change it to GR.8 for instance? I guess not.

 

Of course - and I fully understand and accept that, as I keep saying. Apart from anything else, I just didn't see that the average DOS 2.5, MyDOS, or BeweDOS user should be obliged to install S_VBXE (I forget the footprint of it) to use one application which

 

? How a DOS 2.5, MyDOS or BeweDOS user is suposed to use SDX Formatter? Isn't this your prejudice speaking again?

 

I'm just trying to make the best of the situation, since it's not convenient for me to perform major redesign work on the application in question at the moment.

 

COULD YOU PLEASE POINT OUT WHERE IN THIS THREAD I SUGGESTED A "MAJOR REDESIGN" OF THE "APPLICATION IN QUESTION"? This is not a rhetorical question, please answer.

[atari8warez]

One question gentlemen/women of this thread.

 

Is there any zero-page locations not used by Spartados / SDX ???

 

I may be to naive to expect that but wanted to ask anyway.

 

Thanks

[drac030]

atari8warez: in what sense "not used"? Application programs (such as command.com) will use the zero page locations normally allowed to be used by applications, i.e. $80 onwards. The resident parts (such as sparta.sys) will only use locations supposed to be used by OS while doing I/O, i.e. $30-$3F and $42-$49.

 

As for the rest of the thread, I suppose Scott Adams might have read it:

 

http://www.dilbert.com/fast/2012-03-25/

 

[flashjazzcat]

And you only accept suggestions made on meetings. Heh.

 

Figure of speech. I shouldn't use them here, apparently.

 

There is no need until the goalposts are shifted by an unprecedented situation.

 

You already stumbled upon such an unprecedented situation: new hardware and new drivers for it. For the old hardware also has drivers, and it is also good to use them when the situation requires, like for upward compatibility.

 

Clearly then accessing VBXE under SpartaDOS X implies mandatory use of S_VBXE from your point of view. I think we all get that now. Unfortunately LW works under several different DOSes, and I don't want to maintain a special SDX version at the moment, as I say.

 

I recall a review of Diamond GOS which cited problems caused by "software which assumes that the display is in mode 0 by default, which is no longer the case". Perhaps if Diamond had set the display to mode 0 when loading non-GUI software, the problem would have been eased.

 

It might. But since Diamond GOS appeared which makes the GR.0 no longer the default (which meeting stated, that the DUP.SYS has to work in GR.0, btw.?), then it should become clear, that it is a good programming techinque to explicitly switch to the required video mode. And it should be clear, that it is good programming technique to use OS call to do the switch. Otherwise, in case any new video hardware is used, with any new drivers (or even old hw with new drivers, like GOS), the program assuming such things as DUP.SYS operating in GR.0 will run into problems, and for me has a good chance to undergo DEL fname.

 

I feel much better knowing this.

 

I certainly expect to come up against similar problems myself when handling legacy applications, and I'm sure some workable solution can be found which doesn't involve writing off a lot of software which didn't do things in a particular way.

 

Kludges to support legacy applications have the unfortunate effect of supporting unclean (and most of the time just bad) programming techniques forever.

 

In a perfect world, kludges to support legacy apps aren't necessary. I guess some of us see a perfect world out there, while others don't.

 

TD reacts because it hooks up the VBL vector and monitors the top of the DL for the presence of the JMP to own DL. I still fail to see any relevance here: even if CON monitored DL pointer on VBL (wasting CPU time), then what if the pointer changes? Call the routine switching video modes? Inside interrupt routine?

 

Hardly... I thought something changing the DL would be significant of something attempting to set up an Antic display, so you'd shut off the VBXE display.

 

How do you know, besides, that the user wants the mode to be changed? In case of the TD it is easy, because TD does not hog the entire display, so the user's display does not change. Would you like a TD version which would force the display to GR.0 every time you want to change it to GR.8 for instance? I guess not.

 

None of this is required. I never suggested forcing the display to GR. 0 at any stage, so please do not imply meaning which is not in the original posts. As I say, changes to the DL imply changes to the display. Does TD react to DL changes via the interrupt mechanism just through convenience, since it's already attached to the stage 2 VBL? Almost certainly so. But if TD (which admittedly was written a long time ago) conformed to the idea that an application should only create a custom display after first invoking an OS display via CIO, then it wouldn't have to monitor the DL and react to dynamic changes at all, would it?

 

Of course - and I fully understand and accept that, as I keep saying. Apart from anything else, I just didn't see that the average DOS 2.5, MyDOS, or BeweDOS user should be obliged to install S_VBXE (I forget the footprint of it) to use one application which

 

Again - please don't imply things in my posts which aren't there. You're saying LW should use S_VBXE to access the hardware. I'm saying I don't want to write multiple versions of the same application. So tell me this: if a single, unified version of LW relies on S_VBXE to access the hardware, how is the DOS 2.5, MyDOS or BeweDOS user meant to avoid installing said driver before running the application? And tell me what this has to do with the SDX formatter's obvious non-existence in said disk operating systems? The answers, of course, are a) they can't, and b) nothing at all, but it doesn't fit the situation to simply admit that, does it?

 

I'm just trying to make the best of the situation, since it's not convenient for me to perform major redesign work on the application in question at the moment.

 

COULD YOU PLEASE POINT OUT WHERE IN THIS THREAD I SUGGESTED A "MAJOR REDESIGN" OF THE "APPLICATION IN QUESTION"? This is not a rhetorical question, please answer.

 

You want everything to access VBXE through the S_VBXE driver. Everything that doesn't, doesn't fit. So it needs to be rewritten or deleted.

 

Can I say again the situation is abundantly clear now, and has been for several posts.

[drac030]

I'm just trying to make the best of the situation, since it's not convenient for me to perform major redesign work on the application in question at the moment.

 

COULD YOU PLEASE POINT OUT WHERE IN THIS THREAD I SUGGESTED A "MAJOR REDESIGN" OF THE "APPLICATION IN QUESTION"? This is not a rhetorical question, please answer.

 

You want everything to access VBXE through the S_VBXE driver.

 

Please stop trolling and answer the question above. I suspend any discussions with you until you do that, and until you point me out my post, where I say what you're imputing.

[candle]

just for note here: i never saw version of volcow commander/dos navigator or norton commander requireing use of ansi.sys to get color display

they simply draw directly on screen

why not using the "proper" driver just to get buffer pointer and screen resolution and using that information back? it would give both performance and compatibility

[flashjazzcat]

COULD YOU PLEASE POINT OUT WHERE IN THIS THREAD I SUGGESTED A "MAJOR REDESIGN" OF THE "APPLICATION IN QUESTION"? This is not a rhetorical question, please answer.

...

 

Please stop trolling and answer the question above. I suspend any discussions with you until you do that, and until you point me out my post, where I say what you're imputing.

 

Pointless. It was obviously a rhetorical question, since I doubt you're anything but intimately familiar with what you've written here, and you clearly believe that none of your comments could be taken to mean that you were advocating a major redesign of the application in question. So if you want me to go back and quote remarks where I believe the implication is that you'd prefer it if I redesigned the display segment of the program (starting with post 62, where you began lamenting my non-reliance on your driver) so that it uses S_VBXE just so that you can retort by saying that's not the case, then I won't because it's a waste of everyone's time. Let's save precious minutes and agree that you never actually typed - in upper or lowercase letters - "Please perform a major redesign of the application in question".

 

There - that's better isn't it.

 

Moreover, if part of what you've advocated in subsequent posts is a compromise similar to the approach Candle suggests, then OK - that's not a major redesign of the entire application. It's a rather awkward compromise, perhaps, but on the other hand, I don't want to do major redesign work on my display code, so why not.

 

Regarding trolling - who was it who floated this debate back up to the top of my to-do list today via a link to a Dilbert cartoon? Can you explain to me in what way the link to the Dilbert cartoon is a direct response atari8warez's question, or indeed to any question posed since your post on Tuesday? Extraneous, inflammatory, and derisively appended to a discussion I hadn't responded to in five days... and you accuse me of trolling because I'm then inspired to attempt a response to your earlier points? Was I not supposed to see it, or what?

 

(Don’t worry, by the way: the above questions are all rhetorical).

 

So - OS call before setting up splash screen: check. Possible reference to S_VBXE driver (if detected) to deal with formatter problem: check. DL doesn't exist when CON80 display is active: check. TD line uses DL to detect mode-change only because it's convenient to do so: check.

 

The only place I've seen CIO called first to setup and then modify it into a custom display list, is in BASIC programs. Why would a more advanced program do this? It's much easier to create your own custom DL, placed in memory appropriately for your program, same with the screen.

 

I have to agree. There was simply no persuasive reason to perform redundant processing by calling the OS before setting up a custom DL – until now. DOS not running in graphics 0 still wouldn’t cause a problem – until now (regarding the latter, by the way, presumably those applications which "assumed the display was in graphics 0 when it wasn't" under Diamond GOS didn't fall over because of custom DLs, but because they immediately wrote to the E: device when the display was actually in hi-res mode).

 

Of course, if you are wanting to be compatible with a DOS such as SpartaDOS, and its myriad of add-on functionality, you are going to have to take these things into account in some way (even if just to tell users not to use TDLINE, or CON drivers with your software.)

 

KMK has every right to make best practice recommendations for software running under SDX, as I’ve said. The question is how much one is willing to bend to support things which don’t fit neatly into the grand plan. The OS designer has every right not to bend at all.

 

I've always thought that the format functionality in SpartaDOS X was neat, but I don't understand why it has to have custom screen that requires a custom DL, etc... is there just an API you can call for format, pass it the appropriate parameters (gathered from your own GUI interaction with the user perhaps)?

 

I’m inclined to agree about the formatter too. Brilliant though it was when people were using a myriad of different floppy drive capacities, etc, the requirement to perform bulk formatting from within an application has perhaps lessened today (although it's pretty academic, since the same "pop-up" formatter is employed when the format operation is called directly from the DOS prompt). Moreover, much of the time the only variable information is the drive letter assigned to the volume or partition, and this is implicit in the XIO call. When I format hard disk partitions or ATRs, ninety-nine per cent of the time I choose the drive letter and leave everything at the default (there’s not much to change when writing the directory structure to a partition, in fact). Even the Volume Name I usually change direct from the CP later on.

 

However, the formatter does take away a great burden from those programs which wouldn’t otherwise be able to support a large number of formatting options. We must also remember that those applications which would prefer to simply write the directory structure to an empty disk, bypassing the formatter entirely, may do so via the SpartaDOS X API.

Edited March 25, 2012 by flashjazzcat

[atari8warez]

atari8warez: in what sense "not used"? Application programs (such as command.com) will use the zero page locations normally allowed to be used by applications, i.e. $80 onwards. The resident parts (such as sparta.sys) will only use locations supposed to be used by OS while doing I/O, i.e. $30-$3F and $42-$49.

 

 

All I wanted to know was if the zero page locations mentioned in Mapping the Atari as user accessible still are... Been a quite a while since that book was written and many new hw and software (especially SDX) might have changed the "map of the universe"

Thank you for the info.

 

And for the rest of this thread, could you guys please take it easy with each other, the amount of time spent on this thread might have been used for some productive work

[atari8warez]

The only place I've seen CIO called first to setup and then modify it into a custom display list, is in BASIC programs. Why would a more advanced program do this? It's much easier to create your own custom DL, placed in memory appropriately for your program, same with the screen.

 

I have to agree. There was simply no persuasive reason to perform redundant processing by calling the OS before setting up a custom DL – until now. DOS not running in graphics 0 still wouldn’t cause a problem – until now (regarding the latter, by the way, presumably those applications which "assumed the display was in graphics 0 when it wasn't" under Diamond GOS didn't fall over because of custom DLs, but because they immediately wrote to the E: device when the display was actually in hi-res mode).

 

Of course, if you are wanting to be compatible with a DOS such as SpartaDOS, and its myriad of add-on functionality, you are going to have to take these things into account in some way (even if just to tell users not to use TDLINE, or CON drivers with your software.)

 

KMK has every right to make best practice recommendations for software running under SDX, as I’ve said. The question is how much one is willing to bend to support things which don’t fit neatly into the grand plan. The OS designer has every right not to bend at all.

 

fjc look, you can't have it both ways, you either follow the OS ways or ignore it and do it your way. Obviously you are seriously concerned about SDX compatibility for your LW otherwise we wouldn't have had this thread, then if that's the case the best advice is to follow the OS procedures. It's really that simple... turning the thread into a "you said this, you said that" won't really help anybody.

 

You said: "The question is how much one is willing to bend to support things which don’t fit neatly into the grand plan. The OS designer has every right not to bend at all".

 

Of course, the OS designer determines how the machine will be run and how apps will behave (ask Bill Gates - lol-), if you want to be compatible you would have to bend as much as it's required. The other option is to take over the computer like AtariWriter/Paperclip and many others did in the past, but that's the old way of doing things,that is at least in the modern computing era.

[Kyle22]

Hi All.

 

If I remember correctly, the Indus track buffer Z80 code has a bug in the SIO timing. This timing is done by counting clock cycles of each instruction. I had a completely working INDUS.SYS at one time that would program both RAM equipped and regular Indus. I wish I had it now

 

Good luck with the project, I *KNOW* it can be done.

 

-K

[Faicuai]

Hi All.

 

If I remember correctly, the Indus track buffer Z80 code has a bug in the SIO timing. This timing is done by counting clock cycles of each instruction. I had a completely working INDUS.SYS at one time that would program both RAM equipped and regular Indus. I wish I had it now

 

Good luck with the project, I *KNOW* it can be done.

 

-K

 

...This would be REALLY nice... although, and in all fairness, I have performed some basic RWTEST benchmarks with {DosXL+Synchromesh+DosXL Formatting in double-density} vs. {SDX+SDX-optimized Formatting in double-density}, and SDX simply trounces its DosXL counterpart (SDX churns about 3500-3900 bytes/sec writing, and about 7000-7500 bytes/sec reading).

 

Seems like SDX's INDUS.SYS may be more efficient and/or (possibly) extra buffering leveraging the Atari's own RAM. I wonder what further gains would be realized by having Indus.sys tapping into on-board IndusGT RAM (ramcharger).

 

F.

[sup8pdct]

Hi All.

 

If I remember correctly, the Indus track buffer Z80 code has a bug in the SIO timing. This timing is done by counting clock cycles of each instruction. I had a completely working INDUS.SYS at one time that would program both RAM equipped and regular Indus. I wish I had it now

 

Good luck with the project, I *KNOW* it can be done.

 

-K

 

...This would be REALLY nice... although, and in all fairness, I have performed some basic RWTEST benchmarks with {DosXL+Synchromesh+DosXL Formatting in double-density} vs. {SDX+SDX-optimized Formatting in double-density}, and SDX simply trounces its DosXL counterpart (SDX churns about 3500-3900 bytes/sec writing, and about 7000-7500 bytes/sec reading).

 

Seems like SDX's INDUS.SYS may be more efficient and/or (possibly) extra buffering leveraging the Atari's own RAM. I wonder what further gains would be realized by having Indus.sys tapping into on-board IndusGT RAM (ramcharger).

 

F.H.

 

I believe that bug has been fixed with SDX version of indus.sys.

I do believe there were 2 versions of syncromesh. A slow one at about 38k baud (early version) and one around 76K baud (latter version included with sdx).

 

James

[lemiel]

68k (SuperSynchromesh and indus.sys), but indus.sys is not enabling track buffering with Ramcharger now.

New indus.sys probably enables only 68k on CA2001 what was not working before (instead of using 38k synchromesh or ca2001.sys (written by Draco (I am not 100% sure) in early 1990's - I have diskette from Atari Magazyn with it), which I think contains the same Z80 code.

If I understand correctly, indus.sys never supported track buffering, only super synchromesh did it.

But maybe trub will write more.

 

And maybe this is open field to someone to add support for it, sources are available.

And maybe this programming code can be used to program Indus GT into Ultraspeed enabled drive with 68k speed?

[Kyle22]

I wish I could remember better, that was back in the FTe days (mid 90's). I *THINK* it may have been a delay that I added between the receipt of the command frame and the 'ACK' sent by the drive. It was just a few cycles more. I wish I still had the source code!!! I found and fixed it within a few hours. I made a (never released, one of a kind) SDX 4.23 for my personal use, although, with the other bug fixes I did, it *SHOULD* have been officially released. INDUS.SYS with RAMCharger Track Buffering sounds like RAPID FIRE Machine Gun!, EXTREMELY FAST! I don't remember the baud, but it must have been around 70K. IIRC, more than 2 tracks/ second. You could watch the track display count up VERY quiclky. It would fool the RPM command to show over 1000. This was around the time when we were struggling with money, and trying to perfect the ill-fated MARS8 board. We did have working prototypes, the only problem was, it would randomly lock up on the un-released game Deflektor. I lost my SDX 4.23 cart in a move, and all my source code when FTe moved to Arizona, along with many other things like my favorite Universal (EPROM & PAL) Programmer Sunrise Z1000B.

 

Some lucky person (when they auctioned off our warehouse) got my TeleVideo CP/M system (TS-816 based, with my own customized OS called Network-NZ) that I did all my Z-80 programming on.

 

If anyone still has a TVI-816, I found a few tapes that *MAY* or *may NOT* have something useful on them. I will be happy to send the tapes to anyone who can read them, and hope and pray my *COMMENTED* GTSYNC source code is on one of them.

 

Also, please remember, Back in the day, many people got mad at Mike, the founder of FTe because of the pre-order money not being returned. I HAD NOTHING TO DO WITH THAT! That said, Mike Hohman is a great guy. I am *NOT* (well, maybe a little) defending him for what he did... Back in the day, he did what he had to do to survive. We really *DID* use the money to develop new products, but, UNfortunately it went FLOP

 

I wanted Mike to release the MARS-8 'as-is'. It worked with 90+ percent of software, but, he, and myself to some degree are perfectionists. Deflektor is a cool game

 

I ONE HUNDRED PERCENT (100%) Endorse the Ultimate 1M Internal SDX upgrade that's out there now, I want one! As soon as I get the money I will buy one. I would like to see the option of empty sockets for various OSS ROMs, BASIC-XL, XE, MAC-65, etc.

We had a working IDE device, much like MyIDE, but I made a circuit to latch the upper 8 bits so we could use all of the IDE drive capacity. It was the 512 byte sector thing that we had trouble with back in the day.

 

I sure wish that I knew then what I know now And, on the other hand, I wish I knew now what I have forgotten from a long time ago...

 

Why is it that M$ made a great OS in 2001/2002 and called it XP /2003, and now they make GARBAGE? Load up a Win7 box, go to command prompt, and type VER! You will get NT V6.xx.xxxx Just like Vista! It's not really version 7 (seven)!

 

Atari lasts forever on SDX, or even DOS 2.xx (or MyDOS, SmartDOS, TopDOS, etc.) Atari is TIMELESS! We don't worry about OS upgrades for security, or other reasons.

 

 

OK, I have rambled on enough.... Good luck to anyone who can find the original, COMMENTED Indus RAMCharger source! We had it, so it MUST be out there somewhere...

 

 

-Kyle

Edited March 29, 2012 by Kyle22

[Kyle22]

BTW, Mike Hohman, if you are reading this, PLEASE, PLEASE, PLEASE Contact me. (Pittsburgh, PA Area Code) 353-9082, e-mail cornholio_0202 AT msn.com.NOSPAM, (use common sense) or message me here on AtariAge.

 

Thanks!

 

-K

 

Also, to prove you are really Mike (other than your voice on the phone), please tell me what you had in the trunk of your (beautiful) white Dodge Aspen that I told you to get rid of before it rusted the trunk out... BTY buddy, I (after a lot of searching, have a Sunrise Electronics Z-1000B stacked full of static RAM to the max.

 

Gimme a call, Mike, PLEASE!

Edited March 29, 2012 by Kyle22