Atari Macro Assembler with Large Drives?

[ballyalley]

I've been trying this evening to get the Atari Macro Assembler to work with large disk drives to assemble a program from a 1986 issue of ANALOG (the program is called Incoming! and can be found in this posting: http://atariage.com/forums/topic/225636-wanted-side-2-of-disk-for-analog-magazine-38-jan-1986/).

 

AMAC assembles Incoming! fine and it creates an object file that runs okay under Altirra (which is how I'm running AMAC). The trouble is that I want a LISTing on disk. The LISTing is over fifty pages when printed to a printer (really the "Printer Output" in Altirra). Over 50 pages fills up a single density drive at about 34 pages. I've been trying to get AMAC to work with the H: drive (no go), a RAM disk (works... but only garbage is written to the directory), and other disk densities under MYDOS 4.53 (get write errors).

 

I'm using the following command in AMAC:

 

D2:INCOMING.ASM H=0 R=F L=D3:

 

Any idea on how to make AMAC LIST to a disk drive (it only accepts D1-4) that's larger than 707 sectors? AMAC doesn't even like Enhanced density disks...

[Rybags]

You sure it's not working to H: ?

 

If you examine a listed program there'll be differences since only ATASCII uses code 155 for CR where DOS/Windows usually expects CR/LF which is 13,10.

 

Additional to that, I can't see how a language could get fussy over ED disks. Atari's device independence usually means an app shouldn't care what device you're dealing with (although some will specifically expect a D: device) - generally an application can't even tell what kind of disk you're using, 256 byte sector, SD or ED, whatever.

Getting fussy over D5: and over might be more a DOS problem too - DOSes will have drive buffers and file buffers so usually have bitflags to tell which drives are valid. Although many DOSes will only give support up to D4:

 

All that aside, there's better assembler options out there as well.

Edited May 21, 2014 by Rybags

[flashjazzcat]

I used to use AMAC with 360K floppies under MyDOS. Quite possible that the assembler filters out drive numbers other than 1-4, and doesn't like listing outputs other than D:, P:, and E:, although I don't recall. I do remember that AMAC was quite fussy about DOS, and early SDX versions didn't work with it because they didn't return CIO status $03 on reading the last byte of a file (prior to returning EOF after the final byte had been read).

Quite a nice assembler, though, and there's an excellent article by Nick Kennedy:

 

http://mixinc.net/atari/amac.htm

[ballyalley]

You sure it's not working to H: ?

Well, it gave me an error of some sort last night, I don't remember exactly what it was. I'll try it again today to give the feedback about it.

 

If you examine a listed program there'll be differences since only ATASCII uses code 155 for CR where DOS/Windows usually expects CR/LF which is 13,10.

Understood. I use a few a couple of different programs to view ATASCII files that have other ATASCII codes besides just CRs (BASIC listed files, for example). I used to use a program that would convert ATASCII CR to DOS/Windows CR/LFs, but I forget what it was called. Any suggestions for one?

 

[...] although some [applications] will specifically expect a D: device [...] many DOSes will only give support up to D4:

I think that's the case here with AMAC. The manual states:

 

There are four options for producing the assembler listing:

 

L =Dn: - List output to specified disk drive (n= 1, 2, 3, or 4).

L=P: - List output to printer.

L=S: - Output listing to the screen.

L=0 (Default) - Do NOT produce listing.

 

I setup a RAMdisk in MyDOS as D4:, but the output that was sent to it from AMAC got jumbled inside the directory. It was quite strange. I tried listing the output to a printer and that does work, but some of the characters are not "understood" in Altirra's "printer output." Some chatacters are replaced with questions marks, when in a file listed to disk they look fine.

 

All that aside, there's better assembler options out there as well.

I'm using this assembler as the source code was written specifically for it. I don't want to change anything at all, I just want the LISTing. It's an interesting, fun (hard!) game- especially for a magazine type-in program.

[ballyalley]

I used to use AMAC with 360K floppies under MyDOS.

Okay, this is nice to hear. So it's a matter of changing SOMETHING that I'm doing to get this to work for me.

 

I do remember that AMAC was quite fussy about DOS

The version of AMAC that I'm using is 1.0A. I'm using the ATX disk dump from AtariMania. I THINK it has the copy protection intact. Maybe disk protection has something to do with the trouble-- although I doubt it as otherwise I can't see that I'd be able to assemble at all. Also, maybe I'm not using the latest version of the assembler. Any idea what the last version of AMAC was?

 

Here's my assembly procedure:

• I boot with a MyDOS disk (D1:)
• Run AMAC from D2:
• I use D3: as a work disk to hold the assembly listing.

This works with single-density floppies, although the unfinished assembly listing does fill-up D3: to capacity. Strangly, the assembly doesn't fail when the disk is full. AMAC just writes all that it can to the disk (about 34 of the 50 or so pages) and finishes the assembly without incident.

 

there's an excellent article by Nick Kennedy

I did find that-- it was quite helpful to get me going before I found the AMAC manual (AtariMania's link to the manual is broken).

 

I'll try some alternate methods later today (or maybe tomorrow)... but without specific problems to look-out for I feel that I'm shooting in the dark. So, any more avenues that I might look into?

[flashjazzcat]

I think I still have my old AMAC MyDOS setup on 360K floppies. I'll check when I get home.

 

Found it. Actually SS/DD MyDOS (180K). Copying to an ATR...

Edited May 21, 2014 by flashjazzcat

[flashjazzcat]

This is what I was able to salvage:

 

AMAC_MyDOS.atr

 

MyDOS 180KB, DD/SS. AMAC.COM has the copy protection removed. Worked with the source files I tested but I didn't bother experimenting with listings.

 

The most interesting discovery was that AMAC still doesn't work with SpartaDOS X. Just locks up after the first pass.

 

[Rybags]

Possibly it could be patched to allow higher drive #s and remove other device limitations.

 

It's annoying when you use old apps or Doses and they don't work properly because of these reasons.

[flashjazzcat]

Well, the only clue I can offer is to study how the assembler reacts to the values it finds in ICSTA (the IOCB status) following a CIO call. Many years ago, I noticed DOS 2.5 and MyDOS returned $03 upon returning the last byte of a file, providing no attempt has been made to read beyond the end of the file, and that AMAC appears to depend on this behaviour. I understand that SDX has been changed to follow this scheme (or was it just the AtariDOS driver - I forget). Nevertheless, after CIO returns, AMAC seems to ignore Y and pull the status out of ICSTA. If it doesn't recognize the code contained therein (it's matched against a series of known values), it appears to give up.

Edited May 21, 2014 by flashjazzcat

[ballyalley]

This is what I was able to salvage:

 

AMAC_MyDOS.atr

 

MyDOS 180KB, DD/SS. AMAC.COM has the copy protection removed. Worked with the source files I tested but I didn't bother experimenting with listings.

 

Thank you! After some delays, I finally just got a chance to try assembling with this version of MyDOS and AMAC and...

 

I'm pleased to report that this version of AMAC works fine with MyDOS and a RAM disk setup as D3!

 

The assembly language listing of "Incoming!" takes up 1,150 sectors on the D3: RAM disk-- which is about 140K on my PC when transferred to my hard disk via the H: drive. The assembly listing is 55 pages, but that's formatted with short pages. When I created the pdf all 55 "pages" fit on 29 pages.

 

Here's what the zipped ATASCII assembly listing of Incoming! as AMAC created it:

 

Incoming! (Analog Computing)(January 1986)ATASCII Assembly LISTing.zip

 

Here's the same listing "printed" as a pdf:

 

Incoming! (Analog Computing)(January 1986)Assembly LISTing.pdf

 

I'm going to investigate this some more, but my primary goal is done.

 

Thanks for the help, the tips, and the converted disk!

[flashjazzcat]

Great! If you discover any mods I did other than removing the simple copy protection, let me know. I can't recall changing anything else.

Edited May 24, 2014 by flashjazzcat

[+bhall408]

On 5/21/2014 at 3:27 AM, flashjazzcat said:

I used to use AMAC with 360K floppies under MyDOS. Quite possible that the assembler filters out drive numbers other than 1-4, and doesn't like listing outputs other than D:, P:, and E:, although I don't recall. I do remember that AMAC was quite fussy about DOS, and early SDX versions didn't work with it because they didn't return CIO status $03 on reading the last byte of a file (prior to returning EOF after the final byte had been read).

I think this is the problem I am running into...

 

(I'm doing this in Atari800MacX emulating an 800XL)

 

I'm trying to compile a small project where there is a main file and 2 includes. It seems as soon as AMAC hits the first include, it then reads all the sectors of the disk, and manages to corrupt the include file.

 

I'm using SpartaDOS 3.2g.

 

Did that end of file problem end up getting fixed in SpartaDOS?

 

I'm picking between this, and converting all the projects I have to ca65 (tedious, as neither DASM nor ca65 support AMAC source files directly - lots of differences in macro handling and compiler directives) and compiling in terminal on my Mac.

 

 

[+bhall408]

OK, solved my own problem...

 

After I updated to the current version of SpartaDOS X, everything worked fine!