Jump to content
IGNORED

Dumb SpartaDOS X question


DrVenkman

Recommended Posts

Yes, I've read the manual. Or at least scanned through it looking for a simple answer. If it's there and I missed it, apologies.

 

Anyway, my question is, is it possible to create a bootable floppy disk image in SpartaDOS X that contains the necessary files to be used as a stand-alone DOS boot disk for a machine that does not have SDX available? I do have .ATR images of any number of earlier SpartaDOS versions, but I'd rather not go through the trouble of trying to write one of them to a real floppy (lots of moving hardware and cables around, and I'm not sure if RespeQt can "talk" to an A8 drive without an Atari in the loop (*), so I'd have to boot up the trial version of APE/ProSystem on my PC ...

 

But it seems to me that since we can format floppy disks just fine, it should be possible to make a generally-equivalent, bootable version similar to what's available when booting a SpartaDOS 3.2 floppy. I just don't know how to do it.

 

Anyway, thanks in advance.

 

(*) I have one of Ray's "version 3.0" devices from a couple years back that can't work with real drives on the chain.

  • Like 2
Link to comment
Share on other sites

Copy one of the disk based SpartaDOS/RealDOS .DOS files to a freshly formatted SDFS disk. (or even an existing disk with files already on it, doesn't matter - its just nicer for the file to be at the beginning of the disk for quicker boot on a real drive) You'll still need to copy the .DOS files from a SpartaDOS 3.2/3.3/RealDOS etc disk in the first place. I keep a copy of those disks in a directory on my SIDE2 for quick access.

 

then use the BOOT command on the file to set the boot sectors to load that file.

 

COPY X32F.DOS D1:

BOOT D1:X32F.DOS

 

Some simple binary games and menu loaders can be made bootable this way too.

 

Thats the absolute minimum to get the system to boot. obviously to do anything useful with the dos, you might want to copy some other utilities onto the new disk, unless you're just using it to load games or something.

Edited by Nezgar
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Copy one of the disk based SpartaDOS/RealDOS .DOS files to a freshly formatted SDFS disk. (or even an existing disk with files already on it, doesn't matter - its just nicer for the file to be at the beginning of the disk for quicker boot on a real drive) You'll still need to copy the .DOS files from a SpartaDOS 3.2/3.3/RealDOS etc disk in the first place. I keep a copy of those disks in a directory on my SIDE2 for quick access.

 

then use the BOOT command on the file to set the boot sectors to load that file.

 

COPY X32F.DOS D1:

BOOT D1:X32F.DOS

 

Some simple binary games and menu loaders can be made bootable this way too.

 

Thats the absolute minimum to get the system to boot. obviously to do anything useful with the dos, you might want to copy some other utilities onto the new disk, unless you're just using it to load games or something.

 

Okay, so since I can't do this from (say) a SpartaDOS 3.2 .atr directly (since my SIO2USB device can't talk to an Atari with a real disk on the bus), I guess I can copy the contents of such an .atr disk to a folder on my SIDE2-based hard drive, disconnect the SIO2USB device and reconnect the real floppies, reboot and then copy the files from SIDE2 cart out to the floppy.

 

So no way to do this sort of thing with the SDX files already on the CAR: device, huh? Too bad. Seems like a no-brainer to make an SDX equivalent of the old Atari DOS "write DOS to disk" type functionality. Oh, well. Appreciate the help.

Link to comment
Share on other sites

So no way to do this sort of thing with the SDX files already on the CAR: device, huh? Too bad. Seems like a no-brainer to make an SDX equivalent of the old Atari DOS "write DOS to disk" type functionality. Oh, well. Appreciate the help.

It's not really a no-brainer since SDX is absolutely reliant on ROM-based components (kernel, library, etc), so anything written out to disk from CAR: is never going to be a version of SpartaDOS X you can use.

Link to comment
Share on other sites

It's not really a no-brainer since SDX is absolutely reliant on ROM-based components (kernel, library, etc), so anything written out to disk from CAR: is never going to be a version of SpartaDOS X you can use.

 

Well, no. Not the fully-functional version with all the bells, whistles, utilities and kitchen sink. But it would be nice to have a subset of the basic disk-access files/utilities able to be easily written to a floppy disk or .atr file from within SDX. I have 13 A8 computers. It's unlikely all of them will be equipped with U1MB or (eventually) Incognito2 boards or SIDE2/3 cartridges to have SDX available all of the time. And for those of us coming late to the SpartaDOS camp, and thus having no actual floppy disks with SpartaDOS on them, it'd be great if there was a "mini-SDX" available to be written to removable/portable media for booting those machines.

 

At any rate, thanks to Nezgar's help, I basically grok it now. The short answer is: copy all the necessary files from an earlier disk-based SpartaDOS .atr to a real floppy. Got it!

 

So please indulge me (and anyone else who finds him- or herself googling this in the future) if I lay out the steps in a very Dick-and-Jane fashion. :) In my case, that involves:

 

  1. Booting with my SIDE2 cart installed and real floppy drives connected, internal U1MB SDX disabled of course
  2. Use the SpartaDOS X FORMAT command to format the floppy as "Sparta"
  3. Power down
  4. Disconnect real floppy drive(s) and connect SIO2USB device
  5. Mount a legacy SpartaDOS .atr in your SIO peripheral emulator of choice (RespeQt, in my case, running in a Raspberry Pi ZeroW)
  6. Reboot Atari
  7. Copy contents of legacy SpartaDOS .atr to a folder of your choice on the SIDE2 hard drive
  8. Power down
  9. Disconnect SIO2USB device, reconnect floppy drive(s), power up drive(s)
  10. Reboot Atari
  11. Copy legacy SpartaDOS files from the folder selected earlier on the SIDE2 hard drive to the real floppy disk inserted in the drive
  12. At the SDX command prompt, make the appropriate file on the floppy disk bootable: e.g. BOOT D1:X32G.DOS

 

I'll be damned. It works. Thanks! :)

 

post-30400-0-66597100-1502054360_thumb.jpg

 

(This is the first bootable 5-1/4" floppy disk I've made in at least 31 years).

  • Like 5
Link to comment
Share on other sites

Congrats :) technically you only need the one .DOS file, everything else is optional if you want to maximize space for other things.

 

You can also make a STARTUP.BAT with 1 line:

BASIC OFF

so you don't need to hold option.

 

Other optional things can be added to it like a binary fine to run after boot

 

I always thought it was nice that disk Sparta used startup.bat and SDX used autoexec.bat, as I could share the same boot hard drive and have different bootup environments specific to each.

Edited by Nezgar
  • Like 2
Link to comment
Share on other sites

Congrats :) technically you only need the one .DOS file, everything else is optional if you want to maximize space for other things.

 

You can also make a STARTUP.BAT with 1 line:

BASIC OFF

so you don't need to hold option.

 

Other optional things can be added to it like a binary fine to run after boot

 

I always thought it was nice that disk Sparta used startup.bat and SDX used autoexec.bat, as I could share the same boot hard drive and have different bootup environments specific to each.

 

Neat, thanks!

 

Mostly this question and the subsequent discussion is due to the facts that: #1, as a teenager in the 80's and until about 2 years ago, I'd never used any DOS at all besides Atari DOS (2.5, rarely 2.0 and for a couple awful weeks at first, 3.0); SDX has been new and frankly revelatory; and #2, I'm old and have a hard time shifting mental paradigms. :) Or at least, a harder time than I used to have.

 

SpartaDOS and SDX are much more akin to MS DOS than what I'm used to using my Ataris and it's difficult to figure out what's possible and what's necessary, versus what I actually need to be able to do. And really I guess, what that boils down to is making bootable SpartaDOS disks so I can boot into my now-default command prompt type environment on real hardware, which may actually be using physical floppy disks occasionally if I've got a second or third machine up and running and otherwise no modern storage. Since I had no physical boot media formatted for SpartaDOS, I was struggling to figure out how to make more; again, plenty of .ATR files via RespeQt, but I can't use RespeQt and physical floppy drives at the same time with my device.

 

Anyway, problem solved and thank you for your help!

  • Like 1
Link to comment
Share on other sites

I would recommend getting a letigimate SIO2PC-USB device that you can keep in the SIO chain with the drives, and not need to bother powering down and re-plugging all the time.

 

:)

 

I attached an SIO plug directly to one of these: http://www.ebay.com/itm/6P-FTDI-USB-TO-TTL-RS232-Cable-F-Arduino-5v-FT232RL-USB-to-Serial-adapter-module-/262042386245?hash=item3d02f17f45:g:T9cAAOSw9r1V8PM0

 

It does (up to) 125K divisor zero with no problem, and it is a real FTDI chip.

Link to comment
Share on other sites

I would recommend getting a letigimate SIO2PC-USB device that you can keep in the SIO chain with the drives, and not need to bother powering down and re-plugging all the time.

 

 

Well, I have one that works just fine for what I need it to do. No need to slag Ray any further than his own actions have done. His device is well-made, has a real FTDI chip, it was priced reasonably for someone then-unable to make a device himself, and works great with RespeQt (and yes, up to divisor 0 speeds), works with APE, works with SIO2OSX. It even lets me make images of real floppies.

 

Anyway, my problem was solved once I realized that "bootable SDX floppy" is essentially a SpartaDOS 3.2 disk. And Nezgar helped me figure out how to make one (see above for detailed steps).

 

The end. :)

  • Like 1
Link to comment
Share on other sites

Creating a bootable subset of SpartaDOS X is possible. It would not contain, of course, the components which reside on the cartridge (notably: the library) and would also miss the cartridge control. Thus I am reluctant to the idea, because I am afraid it would create the new lowest common denominator for the application software: SDX, sure, but no library, just kernel calls.

Edited by drac030
  • Like 1
Link to comment
Share on other sites

Creating a bootable subset of SpartaDOS X is possible. It would not contain, of course, the components which reside on the cartridge (notably: the library) and would also miss the cartridge control. Thus I am reluctant to the idea, because I am afraid it would create the new lowest common denominator for the application software: SDX, sure, but no library, just kernel calls.

 

I could see this being useful for someone who wants to distribute software that requires SDX, but doesn't want to worry about if the user has an SDX cart. For example, if I wanted to write something in Turbobasic XL to distribute as a disk image, I'm stuck with using MyDOS or Atari DOS since the disk based versions of SD require osram.

  • Like 1
Link to comment
Share on other sites

  • 2 months later...
  • 3 years later...

3.2D - Oct 1988 = last official disk based release from ICD

3.2F - Feb 1994 = rebranded to FTe when released as shareware, no functionality difference

3.2G - June 1994 = Minor updates by FTe including D9: support, release notes included in the ATR, I'll have to look it up.

 

Edit... dates & details from "CHANGES.32G" file, some decent bugs squashed and annoyances handled actually:

Spoiler

What's new in SpartaDOS version 3.2g

************************************

Version 3.2f could only access drive
ID numbers from D1-D8.  Now, you can
access drive D9.

************************************

A filespec that does not contain a
drive number, such as D:TEST, will
now default to your currently logged
drive on the command line.

For example, if you are logged to D4:
a filespec of D:TEST will be converted
to D4:TEST, instead of D1:TEST as it
used to be. This change can be very
useful when running programs from
different drive numbers, since you
can access files with D: and they
will automatically be taken from
whichever drive the program was 
was started from.

You must now be careful however, to
always type D1: when you need to 
access drive 1 specifically.

************************************

A file will no longer be destroyed
when copying it to itself.  The DOS
checks for this condition, and will
report a 'File exists' error.

Commands such as:

 D4:COPY D4:TEST

will no longer destroy the file TEST.

************************************

All command line input, including all
commands, files, and drive IDs, can
now be entered in either lower case or
upper case.  Lower case was only
partially supported in version 3.2f.

************************************

Some commands have been changed, to
make them more compatible with the X
cartridge, as well as making them
easier to type.  The following changes
have been made:

CWD has been changed to CD.

CREDIR is now MD (Make Directory).

DELDIR is now RD (Remove Directory).

Note that with the Remove Directory
function now called RD, the RD.COM
ramdisk handler needs to be renamed
to RM.COM in order for it to work.

(This will be the name of the MARS8
 compatible driver to be released.)

************************************ 

There are many additional error
messages, so you should no longer see
error numbers on the command line.

************************************

A system lock-up bug has been fixed,
when the clock wraps from 12-31-1999
to the year 2000.  

Also, the day of the week offset
has been corrected for years after
2000, in the new TDLINE program.

We are 5 1/2 years 'ahead of time'<g>

************************************

Program files containing a RUNAD, can
now be reentered with the RUN command
after returning to DOS.  The normal
process of saving the starting address
for a .COM file into Sparta's internal
variables, was disrupted when the file
contained a RUNAD address.  This has
now been fixed, so all program files
will behave the same way, whether or
not they include the RUNAD address.

************************************

Several changes have been made to the
keyboard buffering routines.  When
holding a key down for auto-repeat,
the buffer will not fill up with
excess characters that the application
program hasn't used yet.  There will
at most, be one additional character
in the buffer during a key repeat.

This means that when you release a
key, the repeat process stops right
away, whereas there could have been
many additional keycodes 'stacked up'
when using version 3.2f.

The key combination Shift-Control-Esc
can be used to clear all of the keys
currently stored in the buffer.  This
gives you a way to cancel everything
in the buffer when a situation may
require you to abort.

************************************
 
The 1200XL key functions such as DMA
off, keyclick toggle, and keyboard
lock, now work properly.

************************************

The key buffer NOW DEFAULTS to OFF
due to incompatabilities with certain
programs.  It can always be activated
as part of a STARTUP.BAT file using
'key on' (even in lower case), if you
would like this feature enabled.

************************************
 
The AINIT command was removed from the
command line. However, the XIO Atari
format function can still be used
within application programs.

************************************

Even with all these changes, the DOS
file size has been reduced by 260
bytes, and the lomem has been dropped
119 bytes.  If you do not have a PBI
device, your lomem will be at $17A2.

Users with a PBI device will find
their lomem at $1BA2, since the buffer
space uses 1K at lomem, instead of the
$D800 PBI area.

************************************ 

FTe has decided to release a special
3.2 'gx' version that can bring 
memlo back down to $17A2, by placing
the disk buffers under the OS at
$C400.  This has an added benefit of
using a full 2K of buffer space,
instead of the 1K space allocated at
memlo, and will help the DOS run
faster.

However, SpartaDOS 3.2 'gx' is NOT
COMPATIBLE with BASIC XE, or any
other programs using the RAM under the
OS from $C400-$CBFF.  It is provided
for those users who don't require this
compatibility, and who would like to
have the additional RAM available.

NOTE that if you ARE NOT using a PBI
device, (such as an MIO or Black Box)
you do not need the special 'gx'
version, and will already get the 2K
buffer space and $17A2 lomem with
using the STANDARD 3.2g version.

************************************ 

SpartaDOS 3.2g and 3.2gx are being
released as Shareware on an AS-IS
basis.  If you do happen to discover
any incompatibilites, please don't
hesitate to let us know, so that we
might be able to fix the problem
in any future revisions.

This upgrade was made possible by
everyone out there who took the time
to register 3.2f  Thank You!

************************************

If you like what you see, you may
register 3.2g by sending $19.95 to
    
     Fine Tooned Engineering
        
          PO Box 66109

       Scotts Valley, CA

                       95067

This will get you all 3 manuals in
addition to the SpartaDOS Toolkit.

************************************

 

 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

On 8/11/2017 at 4:09 PM, 576XE said:

Is BW-DOS works on 400/800?

The original BW-DOS 1.30 does not work on 16k Ataris because it uses memory above $4000 at boot.

I did modification (some changes in commands: credit -> cd etc.) and change to boot up. So the version 1.31b runs on 16k Ataris but most of the external tools (e.g. copy) does not work because they are using memory above $4000. I will work on that, too, if I will find some time.

 

For more info (initially I changed it to support The!Cart) :

https://github.com/HolgerJanz/RAMCART/tree/master/BW-DOS

 

 

XBW131B.DOS

  • Like 2
Link to comment
Share on other sites

Hi!

On 4/6/2021 at 8:18 AM, janzh said:

The original BW-DOS 1.30 does not work on 16k Ataris because it uses memory above $4000 at boot.

I did modification (some changes in commands: credit -> cd etc.) and change to boot up. So the version 1.31b runs on 16k Ataris but most of the external tools (e.g. copy) does not work because they are using memory above $4000. I will work on that, too, if I will find some time.

 

For more info (initially I changed it to support The!Cart) :

https://github.com/HolgerJanz/RAMCART/tree/master/BW-DOS

I thought that you had source for BW-DOS (or contact with the author), but I see that you are starting from a disassembly.

 

I have a slightly better disassembly done about four years ago, with some of the routines identified: main.asm

Changing parts of BW-DOS without original sources is difficult because a lot of the disk access code is written in a bytecode with special move and call instructions.

 

I also have format.asmverify.asm and xfsio.asm disassembled.

 

Have Fun!

 

 

Link to comment
Share on other sites

Thanx. Unfortunately I could not reach the author. I have only a postal address in Prague from the 90th. I like BW-DOS because it does not touch the OS and Extended Ram. It is my favorite Disk DOS. I thought it is hard to disassemble because the parameter to subroutines are passed like PRINTF in SpartaDOS. If I find time I will work further on it.

Link to comment
Share on other sites

Hi!

Quote

Thanx. Unfortunately I could not reach the author. I have only a postal address in Prague from the 90th. I like BW-DOS because it does not touch the OS and Extended Ram. It is my favorite Disk DOS. I thought it is hard to disassemble because the parameter to subroutines are passed like PRINTF in SpartaDOS. If I find time I will work further on it.

Yes, but the routine at $0919 starts a simple "bytecode" interpreter from the PC position, it has a three commands depending on the bits 5 & 6 of each byte:

- 00 : JSR to any address from $0000 to $1FFF,

- 01 : Moves N bytes inside the buffer at $0D8A, N can be up to $1F bytes.

- 10 & 11 : moves N bytes from two arbitrary 16 bit addresses.

 

If bit 7 of the bytecode is 0, another bytecode is executed after this, otherwise it returns to the address following the last bytecode.

 

For example, at $07F2 the code does:

L07F2:  jsr     L0919
        ' MOVE $0D17, $02E7, 2
        .byte   $4D,$17,$42,$E7,
        ' MOVE $07F0, $000A, 2
        .byte   $47,$F0,$40,$0A
        ' MOVE $0DF2, $0CF1, 2  : END
        .byte   $CD,$F2,$4C,$F1

        txa
L0802:  sta     L0E4C,x
        cpx     #$97

So, it writes the value at $D17 to MEMLO, the value at $7F0 to DOSVEC and the value at $DF2 to $CF1.

 

Have Fun!

Edited by dmsc
Link to comment
Share on other sites

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...