Atari disk image tools

[jhallen]

If anyone is interested, I've been working on some disk image tools: https://github.com/jhallen/atari-tools

 

I had some fun accessing Atari disks on a Windows-98 machines, so wrote utilities to convert .ATR to/from Dave Dunfield's .IMD (ImageDisk) format.

 

I was not happy with the existing tools to manipulate DOS 2.0s and DOS 2.5 file systems in .ATR, so I wrote a nice tool for that (called "atr") for Linux or Cygwin. It includes a directory listing as in "ls" and a filesystem checker / fixer.

 

I've been using it as part of my real machine development cycle

Edit 6502 assembly source on Linux, then type "make" to:

Compile with ATasm: https://sourceforge.net/projects/atasm/

Insert result into an OS/A disk image using my "atr" utility (ATasm is supposed to do this, but doesn't really work.. I may fix it).

Run sio2linux.

Reboot Atari, type name of command at OS/A prompt.

 

I've discovered an interesting difference between DOS and OS/A. I'm trying to make a command which when done returns to the operating system prompt (without reloading dup.sys or clearing the screen). In DOS, you set the run address $2e0 and just RTS at the end of the program. For OS/A, I find it crashes after the RTS if I set the run address. On the other hand, if I don't set the run address, OS/A uses the first segment's address as the run address and it works fine. But then of course on DOS it won't autorun after load if I do this.

[sanny]

I've discovered an interesting difference between DOS and OS/A. I'm trying to make a command which when done returns to the operating system prompt (without reloading dup.sys or clearing the screen). In DOS, you set the run address $2e0 and just RTS at the end of the program. For OS/A, I find it crashes after the RTS if I set the run address. On the other hand, if I don't set the run address, OS/A uses the first segment's address as the run address and it works fine. But then of course on DOS it won't autorun after load if I do this.

 

Yes, it seems that OS/A+ (and maybe early SpartaDOS versions) always jump to the first segment's load address after running the "run address" ($2E0).

 

In the cc65 runtime library we put a "rts" as first opcode in the load segment, and set the run address to the next byte.

 

[jhallen]

 

Yes, it seems that OS/A+ (and maybe early SpartaDOS versions) always jump to the first segment's load address after running the "run address" ($2E0).

 

In the cc65 runtime library we put a "rts" as first opcode in the load segment, and set the run address to the next byte.

 

 

Yep, this is exactly what's happening. I was trying to get the assembler (ATasm) to insert the run address with:

    *= $2E0
    .word start

But ATasm emits segments in address order, so this would appear at the beginning of the file. This works fine in DOS, but OS/A tries to call $2E0!

 

One more thing: in DOS 2.0s, if you load below $3400 it has to reload DUP.SYS. Which is fine except that in the process it clears the screen (reloads the menu).

 

So if are trying to make a command which leaves its output on the screen, but returns to the command prompt, and which works in DOS 2s and OS/A+:

1. Locate it at $3400

2. First byte at $3400 should be RTS

3. Append segment at end with start address (maybe $3401) located at $2E0.

[HiassofT]

But ATasm emits segments in address order, so this would appear at the beginning of the file.

FYI: you can force ATasm to output segments in the order they appear in your source code by using the ".bank" statement.

 

For example:

        START=$2000

.bank
        * = START
        rts

.bank
        * = $2e0
        .word START

so long,

 

Hias

[jhallen]

FYI: you can force ATasm to output segments in the order they appear in your source code by using the ".bank" statement.

 

 

Cool, this does exactly what I want. The manual even gives it as an example usage of .bank.

[jhallen]

I've updated this tool further- it now also supports DOS 2.0d double-density images. DOS 2.0d disk format is not really documented anywhere, so I wrote some notes on it:

 

https://github.com/jhallen/atari-tools

 

In DOS 2.0d, half of each directory sector remains unused. You can only have 64 files total (because the 6-bit file number is in each data sector), and I guess it was easiest to keep all 8 directory sectors, so solution is to use only half of each sector.

[dmsc]

Hi!

 

Reading about your ATR tool made me remember that I have my own tool "mkatr" that creates SpartaDOS (or BW-DOS) compatible ATR images from files, capable of creating bootable images and with subdirectories.

 

The good about SpartaDOS boot is that arbitrary Atari executable files can be booted without a DOS, so you can use the tool to create ATR images that load executables without a DOS.

 

You can see the examples at https://github.com/dmsc/mkatr/blob/master/README.mdand download a release from https://github.com/dmsc/mkatr/releases

[jhallen]

I have my own tool "mkatr" that creates SpartaDOS (or BW-DOS) compatible ATR images from files, capable of creating bootable images and with subdirectories.

 

The good about SpartaDOS boot is that arbitrary Atari executable files can be booted without a DOS, so you can use the tool to create ATR images that load executables without a DOS.

 

 

Nice! Actually I was had been wondering which tool was used to create the single game .atr images in the Holmes archive... I just tried your tool, it looks like it creates full disk images, not short .atr files.. would short images work with SpartaDOS? With DOS 2.0s it would work as long as you have the VTOC and one directory sector, so shortest is ~46K.

 

I found the DOS XE filesystem format.. I might add support for that next, but it's really a very different filesystem compared with DOS 2.0s, DOS 2.0d and DOS 2.5. On the other hand, it's an official Atari OS so it would be nice to have a tool for it.

[AtariGeezer]

I found the DOS XE filesystem format.. I might add support for that next, but it's really a very different filesystem compared with DOS 2.0s, DOS 2.0d and DOS 2.5. On the other hand, it's an official Atari OS so it would be nice to have a tool for it.

The DOS XE File System is nearly complete in my ATR Tools app

http://atariage.com/forums/topic/192052-atr-tools/page-4?do=findComment&comment=3517525

[1050]

Nice! Actually I was had been wondering which tool was used to create the single game .atr images in the Holmes archive...

AtrUtil95 1.13 would be my guess.

http://atari.kensclassics.org/a8emulators.html

http://atari.kensclassics.org/

 

When using the program and you load such an ATR it will state *KBOOT DISK* in the

directory window. If you look around a bit then you see directions for extracting the

original executable back from the ATR. "Use 'Extrct Bin' for Original."

K for Ken on KBOOT DISK, same for Kedit I assume in the 8-bit category of utilities

there.

 

I appreciate this kind of work, TIA. Main issue I have with AtrUtil is that it can't

handle filenames with spaces in them too well. For some reason when I make a

shortcut to the executable and drop it in the sendto folder it will only reliably

work on DOS compatible 8.3 file names or non long filenames despite any tweaking with

quotes around passed parameters in the registry. I suspect that portion of the

program to be running 16 bit code and if so then it's not going to do to well with

dual core processors anyway.

 

And that's where your program can shine and be usable for similar work in the

future.

[dmsc]

Hi!

 

Nice! Actually I was had been wondering which tool was used to create the single game .atr images in the Holmes archive... I just tried your tool, it looks like it creates full disk images, not short .atr files.. would short images work with SpartaDOS? With DOS 2.0s it would work as long as you have the VTOC and one directory sector, so shortest is ~46K.

Yes, any size bigger than 5 sectors is possible in SpartaDOS file system. I added an option "-x" to write an image with the minimal sector size possible, and released a new version "1.1". Note that I also fixed a few bugs in version "1.0" since my last post.

 

Download at: https://github.com/dmsc/mkatr/releases

 

I use this tool from Makefiles to generate the output ATR image directly on compilation, it is very handy.

[+kheller2]

Thank you for these tools. I used them on my Mac to create an ATR image with the flasher and firmware for Syscheck 2.2, then copied them to an SD card for my sio2sd micro.

 

I had long thought of writing an Atari Disk Driver for Linux so that ATR's could just be mounted and read/written to, but this saved me the trouble. LOL