Error saving in assembler editor

[kynrek]

Is anyone familiar with the assembler/editor cartrige? I keep getting error - 164 when trying to save my source code over an existing file using the command LIST#D:MYFILE. the manual says that it will overwrite existing files but it does not seem to be to be working.

 

I checked the assembler editor manual and there is no entry for 164 and I don't understand what is causing this error to occur. I am saving using LIST#D:MYFILE. The initial save works but when I change lines of code and try a subsequent save on the same file then it fails. Maybe the assembler editor cartridge is not closing the file after the list command completes? I am using the Altrra emulator

 

The manual pages do warn about using the file name of an existing file but it states that the destination will be overwritten (which is what I want to happen but I get a 164 error instead)

[Kyle22]

I'd say your disk has become corrupted.

 

Here's what Page6 has to say:

 

Error-164 File number mismatch.

There are two possible causes of this error. The first relates to the use of the POINT statement. Having OPENed a disk file, you can refer to any byte within that file by moving an internal pointer with the POINT command. To do this you must specify: the channel number on which the file is open, the sector number and the byte number within that sector. If the sector specified by you does not form part of the OPEN file, this error is returned to you. POINT can also generate other errors - see errors 166 and 171.

The second cause of this error will hopefully never be seen with today's reliable disk drives. Disk files are stored on the disk as sectors of data, each sector holding 128 bytes. Of these, only 125 bytes are program data, the other three hold information needed by the disk drive. This includes the file number as present in the directory, and the number of the sector holding the next part of the file (i.e. the next sector to be read or written to). When moving to the next sector, the drive checks that the sector does indeed belong to the correct file. If the file number does not match, then error 164 is returned. This shouldn't be seen with present day drives, but was apparently a fairly common problem with the early 810s. If it occurs and you haven't been tampering with the disk structure, your drive may need servicing.

[_The Doctor__]

he's using an emulator so I doubt a real drive is involved..... so the questions would be... is he using an atr.. it he using h: drive.... and what DOS is he using with what disk image.

Edited May 15, 2017 by _The Doctor__

[1050]

I have:

164--LINKS ON DISK MESSED UP DUE TO FAILURE TO CLOSE AN OUTPUT FILE

 

Sorry I have no clue as the source of that, it was saved as if there were

only one flavor of the holy grail. At the time it could not possibly

have occurred to me that some asshat might have wrote it in the

first place and while doing so did some creative reaching into his

backside.

 

Flavor of DOS well may an issue so do tell and what size of ATR is

this happening on? eg. - PC measured kilobytes of file length please.

[Kyle22]

It looks as if this could happen to the (disk or .ATR) if RESET was pressed while actively writing to a file.

[1050]

Yes, any number of things as well.

 

I suspect it's DOS 2.5 ATR with DOS 2.0 and he might be past sector 720 where

DOS 2.0 can't see any more where the 2.5 put the file at? Something funky

is going on, the exact flavor needs a bit more information forth coming.

 

Xuel mentions in the other thread that it's a DOS based error number,

and the light comes on. My text is possibly from the MyDOS manual, yours

from another DOS and 164 means different things in different DOSes. But

we still don't know which DOS it is or for that matter where my text is

actually from for the 164 error. I do know that often I post error texts

and it's wrong. Only now it dawns me the why of it.

[_The Doctor__]

shut off before saving completed? that's possible.. We need way more information about what's being used, as I eluded to earlier....

 

Original Poster kynrek more information please!

Edited May 16, 2017 by _The Doctor__

[kynrek]

I think I solved the problem. I beleieve BASIC was being loaded and was causing a memory conflict with the assembler editor.

(does the 800xl load basic when another cartridge is loaded?)

 

I'll have to double check the dos version I was using.

Edited May 16, 2017 by kynrek

[vitoco]

I don't think that Atari BASIC is the problem. Both of them use the same 8K of memory. It's one or the other, not both. I used them for years in a real 800XL and even changed between them without rebooting (swapped using PORTB).

 

Anyway, error 164 is not a cartridge error but a DOS error. It will also happen if you try to read the file, to overwrite that file from BASIC or using the copy command from DOS menu (DUP.SYS). I'd suggest to copy all the remaining files to a fresh diskette and format the one that fails.

 

What could cause that error in that file? It happens when the file id verification bits does not match the expected while reading or overwriting the file. There are many ways to get such corruption, for example:

 

- A physical failure in a data sector, then copy all the remaining sectors to another media, leaving that sector blank.

 

- Writing on a diskette with a corrupted VTOC table. A new file could overwrite data sectors from other files. Reading overwritten files will find a sector that belong to another file.

 

- Pressing RESET while writing a file to the diskette.

[kynrek]

I was getting the same error in both the emulator(s) and on my physical 800xl so it couldn't have been a physical disk failure.

 

I created a blank atr file using the atari800 emulator for Linux and then used dos2.5 to "write dos files" the started saving files to the disk image and started seeing the error in both the Linux emulator and the windows altarra.

 

I suspected basic because I saw a bunch of code executing in the debugger that I didn't assemble there. I started my program at $1000 and when I ran t1000 there were extra instructions there which is why I suspected a basic cartridge interference.

Edited May 17, 2017 by kynrek

[vitoco]

Starting at $1000 ?!?!?!

 

That´s the answer. You've overwritten DOS during the compilation to memory or when loading the binary from disk, causing a corruption of the FMS.

 

You must start over MEMLO, $2000 for sure.

[Rybags]

PMSL. If the source code is kept in Ram you'd need to assemble to an even higher address.

 

Try the SIZE command. It'll display 3 hex numbers onscreen. 1st is the start of Ram which the assembler will use to store the source, 2nd is the start of free Ram (which will bloat out a bit during an assembly), 3rd is the top of free Ram, just under the Display List and screen memory.

 

The AsmEd cart is a memory hog with source code as it stores line #s as 16-bit binary but the program itself entirely as Ascii, not tokenized like Mac-65 or Basic.

So in general the source code will be a minimum of about 5 times the size of the object it creates.

 

You can use the LOMEM command to change the start of memory that AsmEd uses but it has to be the first command you use (even before SIZE which is annoying).

So if you wanted you could bump the start of it's memory up a bit and put the object code just above the normal MEMLO location.

 

Myself - I just put stuff at $600 if it's small, otherwise just put into the middle of free Ram. Generally you'd not get into trouble assembling to about $7000 unless your source got really big.

[kynrek]

Excellent! Thanks for getting me an answer, no wonder I was going crazy! Yeah I'm not sure where I got $1000 from I just got a few books that say $600