How to know the device of the last file loaded?

[programandala.net]

In order to make a boot file to work from any device, I need to know the current drive (flp1_, win3_, dos2_,,, whatever), I mean, the drive the boot was loaded from. I need to do something like the following (with a theorical function CURRENT_DRIVE$):

Code: Select all

REMark boot file
TK2_EXT
DATA_USE CURRENT_DRIVE$
LRESPR ext_a
LRESPR ext_b
LRESPR ext_c
LRUN main_program_bas

I found no such function in S*BASIC, MegaToolkit, TK3, Turbo Toolkit... Is there any extension or tip to get that information?

[RWAP]

There is no function for this, as the QL does not store any information about the last drive accessed.

However, if you use the PROG_USE and DATA_USE commands in Toolkit II to set up the default program and data devices, you can access them with PRINT PROGD$ and PRINT DATAD$

[programandala.net]

However, if you use the PROG_USE and DATA_USE commands in Toolkit II to set up the default program and data devices, you can access them with PRINT PROGD$ and PRINT DATAD$

I know, but the problem is I'd like to know what the current device is, to set DATA_USE accordingly.

The advantage is the user would "mount" the WIN, IMG or ZIP file into any Q-emuLator mdv slot, and boot the program, without interfering with the current "mounts" (e.g., the first device is normally used to boot the system). The same about QPC2 win slots and WIN files.

All commercial programs I remember force to use certain device in the boot (e.g. flp1). If the user wants to boot it from mdv2_ or whatever, he must edit the boot file (rename the device, change a variable, add a DATA_USE...)

I think the information of the last drive used somehow must be kept in the system, if only in some temporary store (at least, the last command interpreted). Maybe some QDOS expert could get it.

Such an extension keyword would let any program to boot from any device, just doing LRUN device_boot.

Anyway, I got an idea I'm trying: using the DEV_USE chains to try the most probable devices.

[Mr_Navigator]

Just a thought, if the command to load something from a drive can be recalled it will have the format of:

"Command ABC1_filename", if this can be put into a string, then the drive ABC1_ could be extracted

[programandala.net]

"Command ABC1_filename", if this can be put into a string, then the drive ABC1_ could be extracted

I thougth about that too and did some memory searches, just to take a look, but found nothing usable. The command could be "command filename", and the system would use the DATA_USE device. The extraction would have to check that.

The DEV_USE chains I was trying as alternative were not flexible enough. I'm using a simpler method: a function that searches for the main program in all media and returns the first match:

Code: Select all

let dev$=prog_device$
lrespr dev$&"ext_a_code"
lrespr dev$&"ext_b_code"
mrun dev$&"main_bas"

deffn prog_device$

  loc dev_offset,number,devs$,dev$
  let dev$=""
  let devs$="windosflpmdv"

  if not prog_found_in("")
    for dev_offset=1 to len(devs$) step 3
      for number=1 to 8
        let dev$=devs$(dev_offset to dev_offset+2)&number&"_"
        if prog_found_in(dev$):exit dev_offset
      endfor number
    next dev_offset
      let dev$=""
    endfor dev_offset
  endif

  ret dev$

enddef

deffn prog_found_in(device$)

  loc channel
  let channel=fopen(device$&"ayc_bas")
  if channel>0:close #channel
  return channel>0

enddef

[RWAP]

Unfortunately, no, there is nothing stored on the QL to signify where the last file opened was stored - this is partly due to the way in which the operating system's OPEN calls work, because the one call has to cope with any type of object which can be OPENed (or CLOSED).

The best way is to do what I have done with my programs - you have a small machine code routine which stores a device name in memory - you then have an installation program, which re-writes the first line of the boot file to update the name of the device where boot is to run from, and also re-writes the device name inside the machine code routine, before it is loaded.

[tofro]

Something you can do in any case if you want to know the device you've BOOTed from:

• Make a list of all valid BOOT devices (like mdv1_, flp1_, win1_, rom1_, [are there more? I can't think of any, currently. I also think there's no device type that could actually BOOT from any but the first device])
• Iterate through the list using DEVICE_STATUS (d$&"BOOT") from Turbo toolkit

This will return whether the device holds a file "BOOT", but not whether this is actually the one that was executed, but is probably the best you can get. Your code might get confused when more than one device would hold a file named BOOT, but who would do that?

Cheers,
tofro

[programandala.net]

Iterate through the list using DEVICE_STATUS (d$&"BOOT") from Turbo toolkit

Thank you for the idea. But I was searching for a more general solution: The first requirement is to include any drive number (e.g. dos3_, mdv4_), not only the 1, to let the user boot the program by hand at any time in any working session, whithout needing to boot the system (though it will not be the usual case). The second requirement is to use only TK2, because until the right device is guessed, no toolkit can be loaded. That's why I wrote the simple brute force search function to find the main program in any device.

[tofro]

Then you might want to have a look into the HOME_DIR, etc. extensions. Those are part of SMSQ/E, but should also be available as a separate toolkit.
HOME_DIR in a BASIC program evaluates to my knowledge to the drive and directory this parogram was loaded from.

Cheers,
tofro

[EmmBee]

According to the documentation, HOME_DIR under QDOS will not work for the LOAD and EX type commands.

I think the information of the last drive used somehow must be kept in the system, if only in some temporary store (at least, the last command interpreted).

You could try fetching the last line typed in by searching the system's channel definition block for #0 ... Search backwards to the start of the line; change a pointer and then use INPUT to fetch the previous line typed in. There is one small unwanted side effect: the INPUT command will print out the text again.

Code: Select all

100 DEFine FuNction LAST_LINE$
110 LOCal Sys, ch0, TOREAD, DATstart, DATfin
120 LOCal end_p, ten, esc, up, down, p, k, Lin$(136)
130  IF VER$="JSL1" OR VER$="HBA" : Sys = VER$(-2) : ELSE Sys = 163840
140  ch0 = PEEK_L(PEEK_L(Sys+120)+4*0) : REMark address of #0
150  REMark     ch0 + 112 : REMark pointer to next vacant byte
160  TOREAD   = ch0 + 116 : REMark pointer to byte yet to be read by INKEY$/INPUT
170  DATstart = ch0 + 120 : REMark start of data area
180  DATfin   = ch0 + 255 : REMark end   of data area
190  end_p = PEEK_L(TOREAD) : ten = 10 : esc = 27 : up = 208 : down = 216
200  FOR p = end_p-2 TO DATstart STEP -1,DATfin-(end_p=DATstart) TO end_p STEP -1
210   k = PEEK(p) : SELect ON k = ten, esc, up, down : EXIT p
220   REMark ctrl_space will also terminate a line - but cannot be detected
230  END FOR p
240  IF p = DATfin : POKE_L TOREAD, DATstart : ELSE POKE_L TOREAD, p+1
250  INPUT #0, Lin$ : RETurn Lin$
260 END DEFine LAST_LINE$

A point to note: suppose a user types in LRUN win5_boot, but then changes their mind, presses ctrl_space and then types in LRUN flp6_boot. When the last line is recalled, this will be:

LRUN win5_bootLRUN flp6_boot.

Ctrl_space cannot be detected and so both lines would appear together. In order to find the correct device name, the search for "LRUN" will have to be made backwards from the end of the string.

A more reliable way to recall the last line is to use a history device. One such is available on the Sinclair QL Homepage - http://www.dilwyn.me.uk/tk/history127.zip

Michael
EmmBee