Get a directory listing in Action!

[gozar]

I'm trying to get a directory listing in Action!. The following appears to work once, but after that it starts to destroy the program in memory:

proc getfonts()
  BYTE ARRAY fntlist

  close(2)
  open(2,"D:*.FNT",6,0)
  do
    inputSD(2,fntlist)
    printE(fntlist)
  until EOF(2)#0
  od
return

What am I doing wrong?

[flashjazzcat]

Does the array not need an assigned size?

[fujidude]

I concur with FJC. Even though it is not strictly required to dimension the array, it is usually best practice. Give it more room than you think it needs too. You can always scale it back and see if it breaks at some point. The other way is to just educate yourself on what the maximum potential size needed might be with the various DOSes it could be run under.

 

Also you should simply use:

 

UNTIL EOF(2)

 

Action is setup to understand that is true if EOF has been reached on that channel.

Edited June 28, 2015 by fujidude

[fujidude]

Okay.... I did some testing. I can run your code (exactly as you posted it) to run fine repeatedly, without messing with anything at all from what I can tell. What DOS are you using? What version of Action!? Are you just sticking to Action! IDE or are you using the a run time and trying the program stand alone?

 

By the way, Action! treats EOF(channel) as true anytime there is a non zero value in it, as I stated already. Interestingly though, it actually puts the value 136 into it when EOF has been reached on the channel. Of course I'm sure we all recognize 136 as the "End of file" error code.

 

Also, FYI, I did change *.FNT to *.* because I didn't have any font files in my test dir.

 

*** more: I would put a Close(2) just before the return also.

Edited June 28, 2015 by fujidude

[fujidude]

Update: I tested this under JAC's disk based Action! 3.7X, and I got a lockup when attempting to run a 2nd time. When I first tried it I was using a 3.6 cartridge. All of this was under Altirra.

Edited June 28, 2015 by fujidude

[1050]

DOS uses floating point routines and their atascii text buffers at 580h - 5FFh to create a directory listing. That region or the zero page floating point registers d4 thru ffh probably in use by ACTION! already?

 

What was the purpose of getting a directory listing as perhaps there are better ways to gather only the data needed.

[flashjazzcat]

DOS uses floating point routines and their atascii text buffers at 580h - 5FFh to create a directory listing. That region or the zero page floating point registers d4 thru ffh probably in use by ACTION! already?

Are you sure about this? I can grab a formatted directory listing from DOS 2.x without disturbing anything in the upper half of page zero (which is entirely used by non-volatile data in, for example, The Last Word). Does DOS 2.x really call the FP to create a three digit ASCII sector count? I hadn't noticed $400-$5FF being disturbed either, but of course I could be wrong (and if I am, I have a bug).

 

By the way, Action! treats EOF(channel) as true anytime there is a non zero value in it, as I stated already. Interestingly though, it actually puts the value 136 into it when EOF has been reached on the channel. Of course I'm sure we all recognize 136 as the "End of file" error code.

Presumably the contents of Y (if not equal to 1) are just stored in the boolean EOF variable as a convenience when SIO returns in order to save a few bytes. If that is the case, it would have the interesting effect of making MyDOS return EOF = TRUE after reading the last byte of the file, since that DOS returns 3 when the byte read is last byte in the file. Unless Action! sets EOF = 0 if SIO Status < 128. Edited June 28, 2015 by flashjazzcat

[Rybags]

Yep, I just tried with breakpoints. Dos 2.0s (would be same for 2.5), getting a directory listing nothing is disturbed from $C0-$FF or $480-$5FF.

 

Converting a 10-bit unsigned binary to decimal then ASCII probably wouldn't be a lot of work. I'd look at the source but too lazy ATM.

[ricortes]

There's some debugging features built into the monitor that help.

 

When I compile the code as written and from the MONITOR type

X Printce(fntlist) from a cold boot it gives 0 Same with Byte ARRAY fntlist(30) gives ~9000

I'm pretty sure Bill himself said to always give Arrays a dimension.

Edited June 28, 2015 by ricortes

[1050]

Are you sure about this?

Thought so at the time I posted, but checking handy source code, MyDOS indeed does it simple and dirty all on it's own just as Rybags suggests, no Floating Point done. Sorry about the senior moment and misdirection, fuzzy memory cells again, never mind.

[flashjazzcat]

Thought so at the time I posted, but checking handy source code, MyDOS indeed does it simple and dirty all on it's own just as Rybags suggests, no Floating Point done. Sorry about the senior moment and misdirection, fuzzy memory cells again, never mind.

No apology required. I wasn't 100 per cent sure myself.

[gozar]

It was a false alarm, adding a dimension to the BYTE ARRAY fixed it, as in:

BYTE ARRAY fntlist(20)

It runs several times, doesn't corrupt anything.

 

My setup is an 800/Incognito, SDX 4.47, Action! 3.6.

[fujidude]

Good to hear, but it's strange that it worked for me multiple times without dimensioning it, at least on a 3.6 cart.

[flashjazzcat]

I would have thought the undimensioned array would result in an uninitialised pointer, as intimated in post 2. So if it worked at all, it would likely be through luck that the address wasn't in the middle of code, or worse. Or does Action! allocate a fixed storage of zero size? In that case, the string would intermittently cause problems by overwriting variables occupying the same address. Either way, not desirable.

Edited June 30, 2015 by flashjazzcat

[fujidude]

From the Action! manual:

PROGRAMMING NOTES:

You should dimension the size of an array whenever possible, but there are some instances where you cannot or need not:

1. When you do not know how big it is going to be (i.e., as in a routine parameter, when you do not know how big an array is going to be passed).
2. When you are filling the array in the declaration (using either the '[<values>]' or '<str const>' construction), and you are not planning to add to the array.

 

The manual also states that variables are stored in front of the routine that they are used in. Great. But it does not say what it does about dimensionless arrays. That could mean that it does nothing about them, which is bad. But if the above programming notes are followed, there is no problem.

Edited June 30, 2015 by fujidude

[ricortes]

Completely speculation on my part, I figured Action! does it this way so it can be 'To be determined later.'

 

Might as well wax on clumsily about what I mean when I rail against strict type casting. As Flash states the internals use a pointer to arrays and the language allows you to get away with it. Using he example of the first code snippet, it would allow you do something like assign a value to pointer to the Byte Array. This is important in an Atari since they have variable amounts of RAM available depending on hardware and software handlers.

 

So lets say you want to reserve a block above screen memory. You would just do the standard lowering memtop and graphics call. You could then assign the value for fntlist something like 160*256.

 

Let's say you want to use that area/array for canned responses/help info, what have you. Action! uses the first member of a string array as its length similar to how Pascal does it. You could just make up a file of text strings appended end to end for one contiguous file. When you want print them, you would just pass the index of the statement to be printed to the Print() function. This is one of many ways to get around the limited symbol name table. The Print() function doesn't care if it is pointed into a byte array, card array, or undeclared anything for that matter. It just assumes the programmer knows what he/she wants and goes off and tries to do it.

 

On the Atari with all the embedded cursor positioning and redefined fonts, it makes for some pretty neat stuff you can do.

[+JAC!]

A dimentionless BYTE array is a pointer to an array of BYTEs. And you did not initialize the pointer, hence it writes somewhere (depending on the environment).

So you can for example put "FNTLIST=$8000" there to specify where the buffer should be and it'll work fine.