win_extender_bas

[pjw]

Howsabout this tweak

I used to be pretty sure that COPY_H wouldn't do anything different than COPY on block devices.

I'd have assumed it was invented to force the header being transmitted over pure serial devices (where COPY wouldn't)

Tobias

All I can say is it appears to work for me. So try it and see

[pjw]

I dont know about the "reserved word" at $3A. Anyone?

I believe the long word at $38 was originally intended to store the date of last access (Andrew Pennell's QDOS Companion mentions it as 'reference date'). However it was never used as such. V2 drivers store the version number in one word and the file index number in the other word. The latter is necessary because of the introduction of subdirectories, since there is no linear relationship anymore between directory entry number and the file index number as used in the allocation map.
It also means that the maximum number of files per drive is limited to 65535, or maybe even 32767...

No, the limit would be per directory. You can have many more that 65k files on the same drive. But by the time you get to a few thousand files and directories in the same directory (or in the root directory) things slow down so badly that, at least for this generation of CPUs, the limit is the sheer inconvenience of it

As Ive never seen any program that uses the backup date (though there was a DP program, cant remember which, that supposedly used it) my Qlone routine (somewhere above) omitted to maintain it. As it may be important in some settings, let me therefore rectify that by dumping an updated version in my next post. Id rather only use keywords available in SMSQ/E, and not any external toolkits for this routine.

Way back in 1989 when I got my Miracle 30MB hard disk I wrote a program called HARDBAK that used the backup date to decide whether or not to backup a file. I believe it's also on Dilwyn's archive.

Well, thats taken care of now. I hope nothing got broke out there meanwhile!

I suppose that to be allowed to allude to "clone", my routine should also maintain the access and file type-dependent information if it exists, even when the file type is zero? It seems an awful fiddle merely to pander to an undocumented poke. Anyone using this could simply mark the file as special by using one of the remaining 252 unused file types. Does anyone have an opinion on this?

I remember QBOX stored the date of last modification of a MESSAGES_BBS file at header location 10. By comparing this date with the last logon date, QBOX could tell a user if there were new messages in a message area. The file type was still zero though. I wouldn't mind if you don't care about this, though

I cared after all. Its done.

[NormanDunbar]

Evening All,

Winback sets and uses the file backup date. On a new drive, never backed up before, the dates are 1961 if I remember correctly. After a backup, the date is set to "now" by Winback. If the file is opened and updated, the date is changed and the file automatically becomes eligible for another backup.

WinBack allows for full or incremental backups, if I remember correctly.


Cheers,
Norm.

[janbredenbeek]

No, the limit would be per directory. You can have many more that 65k files on the same drive. But by the time you get to a few thousand files and directories in the same directory (or in the root directory) things slow down so badly that, at least for this generation of CPUs, the limit is the sheer inconvenience of it

After reading the qxl.win documentation I found out it's not a file index number but a link into the map (which is a linked list of groups of sectors, M$ would call them clusters). Since the map entries are 16-bit words the limit is the number of groups (and if that would exceed 65535 the group size is simply expanded). My 100MB QXL.WIN file has 4 sectors per group so there are 51200 groups.
In any case, the word at $3A in the header is a file id which should be unique for the whole disk (even across subdirectories).

Way back in 1989 when I got my Miracle 30MB hard disk I wrote a program called HARDBAK that used the backup date to decide whether or not to backup a file. I believe it's also on Dilwyn's archive.

Well, thats taken care of now. I hope nothing got broke out there meanwhile!

I've taken a look at the source and it does have clever (but dirty) tricks like setting the QL clock to the update date of the file being backed up in order to preserve it! Back then there was no other way to do this if you wanted to backup to FLP since the FLP driver wasn't V2 capable at that time.

Jan.

[Ralf R.]

Would be interesting to know, what the keyword "BACKUP" in the Tyche ROM does.

[pjw]

Well, its done. I put together a single script to "stretch" a QLWA hard disk in one operation:
Answer a few simple questions and let rip! Depending on the number of files on the source
disk, the process takes no more than a minute or two. The whole procedure is as safe and
simple as I can make it. Ive used the basic methodology for a number of years on my own
setups to maintain efficient and healthy hard disks.

Its called QLWARZ (suggested pronunciation "quartz" rather than "QL warts") for "QLWA
virtual hard disk ResiZer". It can be found at Dilwyn's under Utilities at
http://www.dilwyn.me.uk/utils/index.html.

It can also be used to "shrink" hard disks or simply to refresh them (defragment and remove
any holes after deletions, etc). The readme offers tips on finding optimal disk sizes.

This version is for QPC2 only, although the QLWA virtual hard disks are standard across a
number of emulators. Other versions may be produced if there is sufficient interest.

Caveat: There are as many QL environments as there are QL users. While Ive covered all the
scenarios discussed here, and then some, there may be conditions I could not have
envisaged in my wildest dreams - the so called unknown unknowns. You are advised to read
the instructions, take the necessary precautions, try it out with care, and check the results.
Use at own risk!

[NormanDunbar]

I think there are still problems with parts of Dilwyn's Web site, including the utils area.


Cheers,
Norm.

[pjw]

I think there are still problems with parts of Dilwyn's Web site, including the utils area.

Probably my fault: I included the full stop in the url. It should be:
http://www.dilwyn.me.uk/utils/index.html <duh!>
Fixed now.

[NormanDunbar]

Nice piece of code there Per.

Cheers,
Norm.

[pjw]

Nice piece of code there Per.

Thank you, Norm. I hope it will be of some use!