Jump to content
IGNORED

SpartaDOS X 4.45


drac030

Recommended Posts

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.

As of SDX 4.45 Indus.sys contains three versions of synchromesh code (all 68kbps): INDUS GT 1.1, INDUS GT 1.2 (most common), CA-2001 (with support from sup8pdct). Track buffering is not yet implemented, but it will surely be in one of the next releases :)
  • Like 1
Link to comment
Share on other sites

(...)

 

As of SDX 4.45 Indus.sys contains three versions of synchromesh code (all 68kbps): INDUS GT 1.1, INDUS GT 1.2 (most common), CA-2001 (with support from sup8pdct). Track buffering is not yet implemented, but it will surely be in one of the next releases :)

 

(...)

 

 

 

...SALIVATING here! :-D

 

This will close the story, in full-circle, and put the IndustGT, back on the stratosphere, where it simply belongs.

 

I do look forward to this upgrade, hopefully in a not-so distant future.

Link to comment
Share on other sites

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.

As of SDX 4.45 Indus.sys contains three versions of synchromesh code (all 68kbps): INDUS GT 1.1, INDUS GT 1.2 (most common), CA-2001 (with support from sup8pdct). Track buffering is not yet implemented, but it will surely be in one of the next releases :)

An even better reason than CP/M to keep my Indus hooked up :)

Link to comment
Share on other sites

As of SDX 4.45 Indus.sys contains three versions of synchromesh code (all 68kbps): INDUS GT 1.1, INDUS GT 1.2 (most common), CA-2001 (with support from sup8pdct). Track buffering is not yet implemented, but it will surely be in one of the next releases :)

 

hmmm. I thought i included track buffering. I have no way to test it so maybe it doesn't work at the moment.

James

Link to comment
Share on other sites

Sure you did, thanks :) However the driver for DOS XL (GTSYNC) has a different structure from Sparta's INDUS.SYS. Z80 code chunks are basically the same, but they will be arranged in a different way. Additionally, a command line option will allow the user to turn on or off the buffering.

Link to comment
Share on other sites

I could not check this track buffering with CA2001, my sramcharger module is waiting for resend after post office send it back without notifying me.

 

...FYI, when SuperSynchroMesh is loaded, the "BF" message appears (and stays, for the most part) in the Track-Readout display. It does temporarely show sector-counts, but most of the time comes back with the "BF" reminder (at least, that's the way DosXL original code handles / shows it).

Link to comment
Share on other sites

I could not check this track buffering with CA2001, my sramcharger module is waiting for resend after post office send it back without notifying me.

 

...FYI, when SuperSynchroMesh is loaded, the "BF" message appears (and stays, for the most part) in the Track-Readout display. It does temporarely show sector-counts, but most of the time comes back with the "BF" reminder (at least, that's the way DosXL original code handles / shows it).

 

Yes. i did see that in the z80 code, only when the track buffering is enabled. It shouldn't matter what dos is used.

 

James

Link to comment
Share on other sites

  • 2 weeks later...
  • 3 weeks later...

I have a special ramdisk for the 65816 with extended (linear) ram. It used to work well under 4.42 or 4.43 and the MyIDE driver under the 65816 OS, but I can't get it to work now.

 

By necessity, it must be on D1: (not CAR:)

 

So my CONFIG.SYS file looks like this: (BTW, I love Quick ED!)

 

DEVICE SPARTA OSRAM

DEVICE SIO

DEVICE ATARIDOS

DEVICE JIFFY

DEVICE D1:RAMD816L .........(Note: the driver file name is RAMD816L.SYS, residing in the root directly of D1:/A:)

 

If I do a CHKDSK or DIR, all I get is "138 Device does not respond"

 

Am I setting this up incorrectly, or does did something change? If something has changed, don't bother trying to fix it -- hopefully this is just my syntax error.

 

BTW, can this device be added from the command processor rather than CONFIG.SYS? If so, is the syntax the same or?

 

Thanks,

Larry

Link to comment
Share on other sites

  • 2 months later...

Bug Report for MENU.COM

 

After receiving and installing my Ultimate1MB I strated to play around with SDX and found this.

I am not sure if this has already been reported but here we go.

 

When there is no physical drive on drive A: and with a ramdisk on drive O: do the following:

 

D1:TYPE CAR:MENU.COM >>O:MENU.COM
D1:TYPE CAR:APPEND.COM >>O:APPEND.COM
D1:O:
DO:MENU

 

MENU.COM will load and will display the directory of drive O: showing two files copied with the above commands.

Exit the MENU and do the following:

 

DO:D1
D1:MENU

 

The MENU will load and display an error message: "138 Device does not respond" (as there is no physical drive D1)

Press ENTER and the MENU will display the exact same files on drive O: as if they were also on drive A:

 

I beleive the buffer holding the directory entries was not properly initialized (to blank) in between the two invocations of the MENU.COM

You can actually manipulate (i.e delete) the non-existant files from D1: using the menu commands.

Edited by atari8warez
Link to comment
Share on other sites

Does SpartaDOS X now boot an external cart before it initializes itself? I speak specifically of the SIDE hardware build... I've heard that the FAT XEX loader can appear regardless of the position of the SIDE switch (which alters the base address of the ROM between that of SDX and the emulated external cart). I understood that SDX took complete precedence over any external cart and only invoked the cartridge via the CAR command.

 

Anyone else experienced this?

Link to comment
Share on other sites

  • 3 weeks later...
  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...