115 replies to this topic

[Faicuai]

Frankie, on Sat Feb 4, 2012 4:29 PM, said:

I was going to try and explain how but I just found a blank one I had instead.

http://www.uspsa-clu...sc/BLANKSDX.ATR

THANKS (!!) This certainly helps.

F.

[Stephen]

Faicuai, on Sat Feb 4, 2012 2:22 PM, said:

3. I wonder if it is possible to take advantage of the RamCharger installed on the Indus, in combination with SDX. Oddly enough, I was able to run Indus "GTSYNC ON" command (I copied the executable out of DOS XL into a working/boot SDX-formatted image). It DOES RUN, and activates track-buffering on the Indus, but both (SDX and INDUS) do not seem to exploit it.

I see you have a RamCharger. Have you played with CP/M yet? I love it, but I have not been able to get the terminal to work from SDX.

[trub]

Faicuai, on Sat Feb 4, 2012 2:22 PM, said:

Now, I do have a few questions, based on my setup (800XL+Ultimate1MB, Nuxx SDrive as boot, and twin IndustGT+RamCharger as floppy):

1. So far, it seems that the only speed-factors I can set the SDrive to work with SDX is around $06 to $05. Anything higher, either the SDX and/or the Nuxx seem to lose track of what they are doing (e.g. multiple file copying within the Nuxx or between Floppies and Nuxx, for instance). Not sure if there is anything else I need to tune on SDX, in terms of buffers, etc.

2. When cold-booting (both 800XL from OFF-state, and Nuxx, witl all leds lit), and running a simple Autoexec.bat stored in SDRIVE.ATR boot image (with nothing other than screen-color changes, mem /x command, and a couple of SET definitions), the system does correctly detect the presence of the Indus, and makes it spin a bit, but it usually leaves the unit spinning at track 00 indefinitely (no disk read or transfer takes place, just spins). This goes away by issuing a "DIR" on the Indus, and it returns to track 39, and stops, as it should. No biggie, but it is there.

3. I wonder if it is possible to take advantage of the RamCharger installed on the Indus, in combination with SDX. Oddly enough, I was able to run Indus "GTSYNC ON" command (I copied the executable out of DOS XL into a working/boot SDX-formatted image). It DOES RUN, and activates track-buffering on the Indus, but both (SDX and INDUS) do not seem to exploit it.

Ad.1
SDX SIO driver handles different high speed protocols, including UltraSpeed, Indus SuperSynchromesh, XF-551. This is achieved by the price of UltraSpeed index not below 4 or 5 (although APE USB interface is reported to work with index 3).
In the future releases we are considering a "lite" UltraSpeed driver (without other high speed protocols) dedicated especially for SDrive/SIO2SD users with boosted US index.

Ad.2
This is an issue in Indus firmware. It seems to accept hi-speed commands even if not programmed with Synchromesh routines.

Ad.3
SDX has nothing to do with track buffering. If programmed with DOS XL SuperSynchromesh driver, the drive will do the buffering. SDX will communicate in the regular way. However, reports exists that DOS XL SuperSynchromesh driver has some bugs making it unreliable with SDX (but I haven't examined this yet).

[lemiel]

So we need to find somebody who will wrote extended with track buffering synchromesh code from current indus.sys.

[lemiel]

So we need to find somebody who will wrote extended with track buffering synchromesh code from current indus.sys.

[Faicuai]

Stephen, on Sat Feb 4, 2012 10:01 PM, said:

Faicuai, on Sat Feb 4, 2012 2:22 PM, said:

3. I wonder if it is possible to take advantage of the RamCharger installed on the Indus, in combination with SDX. Oddly enough, I was able to run Indus "GTSYNC ON" command (I copied the executable out of DOS XL into a working/boot SDX-formatted image). It DOES RUN, and activates track-buffering on the Indus, but both (SDX and INDUS) do not seem to exploit it.

I see you have a RamCharger. Have you played with CP/M yet? I love it, but I have not been able to get the terminal to work from SDX.

Yes, sir, I have played a bit with CP/M (with IndusGT+Ramcharger as BOOT drive). Quite interesting to explore (although UGLY colors for the 80-col. virtual console)... This was right before the arrival (and install) of the Ultimate1MB board, though. I have not yet ran actual CP/M applications, but it is a revealing demonstration of how much the Indus GT could enhance the user experience by allowing the Atari to run yet ANOTHER O/S written for another CPU, without ever leaving your keyboard). In other words, TWO computer-systems, in one. That's why IndusGT was simply the overall finest drive you could afford back-then.

I would love to see it running to its full potential (including track-buffering and using RamCharger's assets) via the wonderful SDX.

I also did notice that I cannot format Indus-floppies in Ultra-skew, from SDX "format" command (at least, not with v1.20 Indus EPROM).

F.

[Stephen]

Faicuai, on Sun Feb 5, 2012 8:11 AM, said:

Stephen, on Sat Feb 4, 2012 10:01 PM, said:

Faicuai, on Sat Feb 4, 2012 2:22 PM, said:

3. I wonder if it is possible to take advantage of the RamCharger installed on the Indus, in combination with SDX. Oddly enough, I was able to run Indus "GTSYNC ON" command (I copied the executable out of DOS XL into a working/boot SDX-formatted image). It DOES RUN, and activates track-buffering on the Indus, but both (SDX and INDUS) do not seem to exploit it.

I see you have a RamCharger. Have you played with CP/M yet? I love it, but I have not been able to get the terminal to work from SDX.

Yes, sir, I have played a bit with CP/M (with IndusGT+Ramcharger as BOOT drive). Quite interesting to explore (although UGLY colors for the 80-col. virtual console)... This was right before the arrival (and install) of the Ultimate1MB board, though. I have not yet ran actual CP/M applications, but it is a revealing demonstration of how much the Indus GT could enhance the user experience by allowing the Atari to run yet ANOTHER O/S written for another CPU, without ever leaving your keyboard). In other words, TWO computer-systems, in one. That's why IndusGT was simply the overall finest drive you could afford back-then.

I would love to see it running to its full potential (including track-buffering and using RamCharger's assets) via the wonderful SDX.

I also did notice that I cannot format Indus-floppies in Ultra-skew, from SDX "format" command (at least, not with v1.20 Indus EPROM).

F.

I'll send you the 80 col driver where I tweaked the colours. Makes a HUGE difference.

[Faicuai]

Stephen, on Sun Feb 5, 2012 2:17 PM, said:

I'll send you the 80 col driver where I tweaked the colours. Makes a HUGE difference.

Definitely looking forward to it.

Also, If you can let me know which particular sector/area of the file contains the color registers (foreground/background), so I can also experiment with a vis-a-vis comparison I would like to conduct, between Indus CPM and SDX 80-col. display).

Thanks!

[Stephen]

Faicuai, on Sun Feb 5, 2012 7:26 PM, said:

Stephen, on Sun Feb 5, 2012 2:17 PM, said:

I'll send you the 80 col driver where I tweaked the colours. Makes a HUGE difference.

Definitely looking forward to it.

Also, If you can let me know which particular sector/area of the file contains the color registers (foreground/background), so I can also experiment with a vis-a-vis comparison I would like to conduct, between Indus CPM and SDX 80-col. display).

Thanks!

I just found my notes. The cursor colour is at offset $B4, the Text is offset $D7, and the Background is offset $DC. To find these, I did a disassembly of the code. Strip the 1st 6 bytes off, and look for LDA $02C0 (cursor), LDA $02C5 (text), and LDA $02C6 (background). The values I used (that match my SDX, Ice-T, and LastWord settings) are $08 for cursor, $0D for text, and $B0 for background.

[Faicuai]

trub, on Sun Feb 5, 2012 4:17 AM, said:

Faicuai, on Sat Feb 4, 2012 2:22 PM, said:

Now, I do have a few questions, based on my setup (800XL+Ultimate1MB, Nuxx SDrive as boot, and twin IndustGT+RamCharger as floppy):

1. So far, it seems that the only speed-factors I can set the SDrive to work with SDX is around $06 to $05. Anything higher, either the SDX and/or the Nuxx seem to lose track of what they are doing (e.g. multiple file copying within the Nuxx or between Floppies and Nuxx, for instance). Not sure if there is anything else I need to tune on SDX, in terms of buffers, etc.

2. When cold-booting (both 800XL from OFF-state, and Nuxx, witl all leds lit), and running a simple Autoexec.bat stored in SDRIVE.ATR boot image (with nothing other than screen-color changes, mem /x command, and a couple of SET definitions), the system does correctly detect the presence of the Indus, and makes it spin a bit, but it usually leaves the unit spinning at track 00 indefinitely (no disk read or transfer takes place, just spins). This goes away by issuing a "DIR" on the Indus, and it returns to track 39, and stops, as it should. No biggie, but it is there.

3. I wonder if it is possible to take advantage of the RamCharger installed on the Indus, in combination with SDX. Oddly enough, I was able to run Indus "GTSYNC ON" command (I copied the executable out of DOS XL into a working/boot SDX-formatted image). It DOES RUN, and activates track-buffering on the Indus, but both (SDX and INDUS) do not seem to exploit it.

Ad.1
SDX SIO driver handles different high speed protocols, including UltraSpeed, Indus SuperSynchromesh, XF-551. This is achieved by the price of UltraSpeed index not below 4 or 5 (although APE USB interface is reported to work with index 3).
In the future releases we are considering a "lite" UltraSpeed driver (without other high speed protocols) dedicated especially for SDrive/SIO2SD users with boosted US index.

Ad.2
This is an issue in Indus firmware. It seems to accept hi-speed commands even if not programmed with Synchromesh routines.

Ad.3
SDX has nothing to do with track buffering. If programmed with DOS XL SuperSynchromesh driver, the drive will do the buffering. SDX will communicate in the regular way. However, reports exists that DOS XL SuperSynchromesh driver has some bugs making it unreliable with SDX (but I haven't examined this yet).

Forgot: THANKS for your detailed response.

In any case, SDX is an (overall) solid and wonderful piece of work. It shows how far Atari-8bit series could have delivered.

F.

[atari8warez]

drac030, on Sun Nov 20, 2011 3:06 PM, said:

Not yet. I am now at pains of translating the general programming manual to English, when this is complete, I may proceed with writing sections of it on writing the drivers.

How's the pain drac030.. Is it subsiding?...
When do you think we can expect the english manual?

Thanks a lot for the effort by the way....

[drac030]

flashjazzcat, on Fri Jan 13, 2012 5:01 AM, said:

Don't know where KMK got to, but I've identified a problem with the SDX formatting menu when using VBXE. If the calling application has an XDL display set up - whether an overlay or with DMA turned off - the formatting menu doesn't show up (since it uses an Antic DL). I wonder if it might be a good idea for the formatting menu to forcibly (temporarily) re-enable DMA and turn off any active XDLs.

The name of the problem is probably: "fjc did not load S_VBXE driver".

[drac030]

@atari8warez: don't really know. Some 40% of the manual (33 pages out of 80) have already been translated.

[flashjazzcat]

drac030, on Sat Mar 10, 2012 3:58 AM, said:

The name of the problem is probably: "fjc did not load S_VBXE driver".

Where is it written in stone that an application which uses a VBXE display MUST use the S_VBXE driver? The formatter doesn't react well to an XDL being enabled by any other means. This is not my fault.

[drac030]

@fjc: to remind your own words:

Quote

I wonder if it might be a good idea for the formatting menu to forcibly (temporarily) re-enable DMA and turn off any active XDLs.

This is what exactly S_VBXE driver does. It is of course "nowhere written in stone". But ignoring OS drivers you're risking that you'll in turn be ignored by the OS. That's what apparently happens and it is not my fault

[flashjazzcat]

So if I install the S_VBXE driver it'll still turn off the XDL when I enter the formatter menu, even if the underlying application is circumventing the driver? Great.

By the way, since I have your attention, how does IDE Plus 2.0's beta APT BIOS lay out 128 / 256 byte sectors? All bytes in lower half / quarter of sector, or interleaved with dummy bytes?

[drac030]

flashjazzcat, on Sat Mar 10, 2012 5:19 AM, said:

So if I install the S_VBXE driver it'll still turn off the XDL when I enter the formatter menu, even if the underlying application is circumventing the driver? Great.

Provided that the driver knows that an XDL display is active. You'll probably have to enable a VBXE mode through the driver, then circumvent it as you like (by setting up own XDL etc.).

Another method is to provide own driver. In any case, the formatter is not a place to contain code handling all possible video hardware, to enable own display it has to use an external driver.

Quote

By the way, since I have your attention, how does IDE Plus 2.0's beta APT BIOS lay out 128 / 256 byte sectors? All bytes in lower half / quarter of sector, or interleaved with dummy bytes?

Interleaved, IIRC.

[flashjazzcat]

drac030, on Sat Mar 10, 2012 5:29 AM, said:

Provided that the driver knows that an XDL display is active. You'll probably have to enable a VBXE mode through the driver, then circumvent it as you like (by setting up own XDL etc.).

Another method is to provide own driver. In any case, the formatter is not a place to contain code handling all possible video hardware, to enable own display it has to use an external driver.

Fair point. I suppose you can't have your cake and eat it, as they say. I guess the simplest solution is not to format disks from LW's disk menu if using the VBXE enabled version.

Quote

Interleaved, IIRC.

Thanks. I would check myself, but I seem to be at war with the equipment this morning. I just wanted to be sure that a couple of new drivers are compatible with IDE Plus.

Edited by flashjazzcat, Sat Mar 10, 2012 5:37 AM.

[drac030]

flashjazzcat, on Sat Mar 10, 2012 5:36 AM, said:

I guess the simplest solution is not to format disks from LW's disk menu if using the VBXE enabled version

I didn't know that there is a religion which so explicitly forbids doing a JSR to a softloaded driver. But it must be nothing less than that, I suppose. As I am thinking about it this way, I would even be able to point out few more faithful members of that church.

[flashjazzcat]

Hey, I listened to some people at the time (especially one quite loud voice telling me to use proprietary code)... maybe it was the wrong decision. There seemed to be good reasons for doing it my way, as there are good reasons for doing things your way. I'm sure my concerns about performance were totally unfounded. I have nothing against S_VBXE, and I've used it for one other project. It seems most at home under SDX, although I'm aware it can be installed with pretty much any DOS. The driver (like all your software) is wonderful, and please don't take the fact I didn't use it in this instance as an insult or a snub. I have nothing but admiration for it. Unfortunately, sometimes I like to use a project as an opportunity to delve into the workings of the hardware. To respond "my way or the highway" when I raise issues is fair enough. You have sufficient headaches maintaining a DOS which has to work with everything under the sun.

Perhaps if LW detects it's running under SDX it should disable the XDL before calling the formatter itself.

[drac030]

Contrary to what may seem natural, I really do not care much if anyone except me is using my software, because I write it for myself. And share.

I'd only like to point out, that this thread began when you "identified a problem". What I am telling you, it is a pseudo-problem with an easy and natural solution. While I respect the natural right of any software developer to do things his own way, I find odd that you tend to go strange workarounds (like: "no formatting at all", or "detect SDX and disable XDL"), yet calling them "the simplest solutions". While it is not really my problem, I'd like to reserve a right for myself to express my opinion.

Short: I find the objections unreasonable.

[flashjazzcat]

drac030, on Sat Mar 10, 2012 6:35 AM, said:

Contrary to what may seem natural, I really do not care much if anyone except me is using my software, because I write it for myself. And share.

I'd only like to point out, that this thread began when you "identified a problem". What I am telling you, it is a pseudo-problem with an easy and natural solution. While I respect the natural right of any software developer to do things his own way, I find odd that you tend to go strange workarounds (like: "no formatting at all", or "detect SDX and disable XDL"), yet calling them "the simplest solutions". While it is not really my problem, I'd like to reserve a right for myself to express my opinion.

Short: I find the objections unreasonable.

Well, I've already conceded that it's right and proper that the formatter shouldn't contain kludge code to handle the XDL when S_VBXE isn't installed. But unless we're taking a long and pedantic journey into the realm of semantics (which seems to be the case), I see nothing wrong in general with remarking that the fact the formatter has issues if an XDL is active is "a problem". It just so happened that the problem was all of my own making, and lay with the application. It's certainly not your problem, not a fault in SDX, and I apologize for soiling this thread by raising the subject in the first place.

As for "strange workarounds", I try and I try to convey irony in forums but it never seems to work out (note emoticon after "...not to format disks"). As for the second option ("detect SDX and disable XDL"): what's wrong with that? Sounds like a simple solution to me. Or is no solution other than rewriting my application so that it uses S_VBXE sufficient penance to repair the indignation my original remark caused?

No doubt if I had used the driver (which - by the way - would have required far more significant changes to the base code than my eventual solution, which - admittedly - is a compromise owing to the fact that there's hardly any code space left), there'd be complaints from some other quarter, so - while I do value the opinions of others and I am gratified if my software is useful to the community - I concede that I will never be able to please everyone, so I might as well please myself.

Edited by flashjazzcat, Sat Mar 10, 2012 12:42 PM.

[atari8warez]

flashjazzcat, on Sat Mar 10, 2012 12:40 PM, said:

I concede that I will never be able to please everyone, so I might as well please myself.

That's the whole idea, you guys are both good on what you're doing, so enjoy it... and when you share your work and somebody appreciates it, it's certainly a nice bonus....

[drac030]

flashjazzcat, on Sat Mar 10, 2012 12:40 PM, said:

Or is no solution other than rewriting my application so that it uses S_VBXE sufficient penance to repair the indignation my original remark caused?

If you'd care to read post #67 more carefully, and understand it literally, without adding anything what's not there, you'd see that I have never suggested any *rewrite* nor that your application should not contain proprietary code, nor that it should be based on the driver. What I told you, is how to tell the VBXE driver (and therefore also the SDX formatter) that _an_ XDL display is active. Nothing more, nothing less.

"Make yourself a sandwich" is not a phrase in which you could reasonably see "build yourself a food factory".

Edited by drac030, Sun Mar 11, 2012 5:39 AM.

[flashjazzcat]

I suppose it depends on how many sandwiches one typically consumes.

It's easy enough to add a couple of hooks to LW either side of the formatter call which will point to JSR in the stock version but be overlaid by code to disable / enable the XDL when the VBXE driver is present. I don't find this an especially inelegant solution, given that even the stock version of the program contains this code in the loader:

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.

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.

Edited by flashjazzcat, Sun Mar 11, 2012 6:50 AM.