Boot sector and memory crushing

[Foxie]

So, I got annoyed at the bloat of TOS, eating up about 100K of RAM even when booting from the auto folder. It's a bit of a problem on the 520ST!

I thought I might be able to load my application earlier in the boot cycle, before GEM drags itself into memory. So I tried writing a boot sector that calls p_exec to run my program.

Unfortunately, this crashes really, really hard. I even tried removing the p_exec and just calling the BIOS to write a string to the screen - but this crashes hard too. But, I did successfully write to the palette registers so I know my boot sector is running OK.

I suppose that it's impossible to call BIOS/XBIOS/GEMDOS from the bootsector code? Or could I be doing something wrong?


Plan B -

If it turns out I can't boot this way, I have another idea to free some RAM. I inspected os_end at $4f2 and I can see it's only using around 40K for BIOS/XBIOS. So, I'm guessing everything after is GEM? Would it be safe to overwrite everything after os_end, while still retaining the ability to call GEMDOS to load files? I don't intend to return to the desktop.

Literally the only thing I ever need to call TOS for is loading files. I don't want to write my own trackloader, because then hard disk support goes away. I suppose I could write a little loader program that loads a disk image into RAM, for hard disk users? What's the recommended solution these days?

[simonsunnyboy]

I never had problems with calling GEMDOS or (X)BIOS from bootsector code.

Years ago Grazey/PHF provided me with a skeleton to write bootsectors to floppies. I use it since then. One of my earliest uses was for the Atari Forum Demo bootsector.

Source below, exchange the actual bootsector code between bootcode and bootcode_end labels, and make sure the code uses PC relative addressing (you cannot predict the RAM address used for execution of the boot code)

Code: Select all

   ; ---------------------------
   ; ATARI FORUM DEMO  BOOTBLOCK
   ; ---------------------------
   ; (c) 2004 by Simon Sunnyboy / Paradize
   ; Version 23 May 2004
   ;

gemdos equ 1
xbios equ 14
bios equ 13

text

; init program
go:   move.l sp,a5
   lea stackend,sp

; calculate program and data size for TOS - to free unused space
   movea.l 4(a5),a5   ; a5 points 100bytes below program start
   move.l $c(a5),d0
   add.l $14(a5),d0
   add.l $1c(a5),d0
   add.l #$100,d0
   move.l d0,-(sp)
   move.l a5,-(sp)
   move.w #0,-(sp)
   move.w #$4a,-(sp)
   trap #gemdos      ; SETBLOCK Gemdos
   add.l #12,sp      ; correct stack
   tst.l d0
   bne exit      ; error occured? -> go to error
   
; -------------------------
; main program entry point:
; -------------------------
main:

   pea my_palette
   move.w #$26,-(sp)
   trap #xbios
   addq.l #6,sp


; print banner...
   pea banner
   move.w #9,-(sp)
   trap #gemdos
   addq.l #6,sp

; wait for keypress 'w' or 'q'
press_w:
   move.w #8,-(sp)
   trap #gemdos
   addq.l #2,sp
   
   ; w pressed? - then write the bootblock...
   cmpi #'w',d0
   beq read_boot
   cmpi #'W',d0
   beq read_boot
   ; Q pressed? - then terminate program...
   cmpi #'q',d0
   beq exit
   cmpi #'Q',d0
   beq exit
   cmpi #'t',d0
   beq testboot
   cmpi #'T',d0
   beq testboot
   
   ; neither w nor q? - then get another keypress   
   bra press_w

; read old bootblock from disk including BPB
read_boot:
   moveq.w #8,d0
   bsr rw_boot


;  transfer bootcode to buffer...
transfer_boot:
off:   equ $1a
   move.l #bootcode,a0
   move.w #(bootcode_end-bootcode)/2,d0
   move.l #boots+off+2,a1
.loop   move.w (a0)+,(a1)+
   dbf d0,.loop
   move.w #$6000+off,boots
   
; calculate checksum to make bootcode executable on disk...   
make_exec:
   move.l #$00000001ffffffff,-(sp)
   move.l #-1,-(sp)
   move.l #boots,-(sp)
   move.w #18,-(sp)
   trap #14
   lea.l 14(sp),sp      
   move.w d0,checksum


; write bootcode to disk....
write_boot:
   moveq.w #9,d0
   bsr rw_boot
   
   
   ; and return to program start....
   jmp main
   
   ; test bootcode routine
testboot:
   ; run bootsector routine in supervisor
   pea bootcode
   move.w #$26,-(sp)
   trap #xbios
   addq.l #6,sp
   
   move.w #8,-(sp)
   trap #gemdos
   addq.l #2,sp
   jmp main
      
   
; terminate program properly and return to desktop or shell...   
exit:   clr.l -(sp)
   trap #gemdos   ; TERM PROCESS Gemdos

;------------------------
; SUBROUTINES/ FUNCTIONS
;------------------------

; subroutine reads and writes bootcode from disk
; to/from buffer
rw_boot:
   move.w #1,-(sp)
   move.l #0,-(sp)
   move.w #1,-(sp)
   move.w #0,-(sp)
   clr.l -(sp)
   move.l #boots,-(sp)
   move.w d0,-(sp)
   trap #14
   lea.l 20(sp),sp
   rts
   
   ; gets called in SUPER
my_palette:
   move.w #$777,$FFFF8240.w
   move.w #$000,$FFFF825E.w
   rts

;-----------------------------------
data
; initialisierte Daten hier...
banner: dc.b 27,"b",15,27,"E",27,"p"
   dc.b "------------------------------",13,10
   dc.b "The Atari Forum Demo Bootblock",13,10
   dc.b "------------------------------",13,10
   dc.b 27,"qby Simon Sunnyboy/Paradize",13,10,13,10,10
   dc.b "Please insert your disk in drive A and",13,10
   dc.b "press 'w' to write a new bootsector.",13,10,13,10
   dc.b "REMOVE WRITE PROTECTION TAB!",13,10,13,10,13,10
   dc.b "Press 'q' to return to the desktop.",13,10,0
   
   even

boots:   ds.b 510
checksum:   ds.b 2

   even

   ; a nice raster bootblock
   ; ripped from a Megatari disk
   ;
bootcode:

   pea       bootmsg(pc)
         move.w    #9,-(sp)       ; print text
         trap      #1
         lea       6(sp),a7
         move      sr,-(sp)      ; save irq status
         ori.w     #$700,sr      
         clr.l     $42a.w      ; reset vector
         clr.l     $426.w       ; resvalid
         move.w    #$ea60,d0       ; loop count
         move.w     #$474,$ffff825c.w   ; color 14 = white
         
   lea       $ffff825e.w,a0   ; indirect addressing of color 15
.loop:
   clr.w     (a0)
         clr.w     (a0)
         clr.w     (a0)
         clr.w     (a0)
         clr.w     (a0)
         clr.w     (a0)
         move.w    #$001,(a0)
         move.w    (a0),(a0)
         move.w    #$002,(a0)
         move.w    (a0),(a0)
         move.w    #$013,(a0)
         move.w    (a0),(a0)    
         move.w    #$024,(a0)
         move.w    (a0),(a0)
         move.w    #$035,(a0)
         move.w    (a0),(a0)
         move.w    #$046,(a0)
         move.w    (a0),(a0)
         move.w    #$057,(a0)
         move.w    (a0),(a0)
         move.w    (a0),(a0)
         move.w    (a0),(a0)
         move.w    #$046,(a0)
         move.w    (a0),(a0)
         move.w    #$035,(a0)
         move.w    (a0),(a0)
         move.w    #$024,(a0)
         move.w    (a0),(a0)
         move.w    #$013,(a0)
         move.w    (a0),(a0)
         move.w    #$002,(a0)
         move.w    (a0),(a0)
         move.w    #$001,(a0)
         move.w    (a0),(a0)
         clr.w     (a0)
         move.w    (a0),$ffff8240.w
         nop
         ; optional keypress exit
         cmpi.b    #$39,$fffffc02.w   ; SPACE pressed?
         beq.s     .exit       ; then exit
         dbra       d0,.loop
.exit:
   move      (sp)+,sr      ; restore IRQ status
   move.w    #$000,$ffff8240.w    ; restore background color
   rts
bootmsg:
   dc.b 27,'b',15,27,'E',27,'Y',11+32,10+32
   dc.b "THE ATARI FORUM DEMO"
   dc.b 27,'Y',13+32,3+32
   dc.b 189,"'2004 http://www.atari-forum.com/  "
   dc.b 27,"b",14,27,"Y",24+32,8+32
   dc.b "THIS DISK IS VIRUS FREE!",0

bootcode_end:   dc.b 0

; BOOTSECTOR CODE END
;
; stack
stkstart:    ds.l 256
stackend:   ds.l 1   

[ThorstenOtto]

Both BIOS and GEMDOS should already be initialized by the time the bootsector gets executed, so it should be safe to use it.

I guess your code is not pc-relative. As simon mentioned, a boot sector is different than a normal program, which is relocated by Pexec. For a boot sector, you must assure that you don't use absolute addresses (except hardware I/O addresses of course).

[metalages]

I have one here to boot demo program compiled with Pure C (but my C program does not use TOS and I have rewritten the startup code of pure C).
In case it can help...
https://github.com/gibs75/demOS/blob/ma ... BOOTSTRA.S

[Foxie]

I never had problems with calling GEMDOS or (X)BIOS from bootsector code.

Years ago Grazey/PHF provided me with a skeleton to write bootsectors to floppies. I use it since then. One of my earliest uses was for the Atari Forum Demo bootsector.

Source below, exchange the actual bootsector code between bootcode and bootcode_end labels, and make sure the code uses PC relative addressing (you cannot predict the RAM address used for execution of the boot code)

Thanks for that, I'll try it in a bit ^.^

I wrote a C program to inject the boot code into a disk image file (beware: little error checking):

Code: Select all

/* Atari ST boot sector checksum fixer and code injector */
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>

int main(int argc, char **argv) {
   FILE *f, *f2;
   unsigned short checksum;
   unsigned short temp;
   unsigned long load_address;
   unsigned long fat_address;
   int i;
   int temp2;
   char filenamebuf[13];
   char firstpartname[9];
   char secondpartname[4];
   char *tempstr;

   if( argc != 6 ) {
      printf("Atari ST boot sector checksum fixer.\nUsage:\n%s diskimage.st boot_sector_code.img load_filename load_address_decimal fat_address_decimal\nThe boot sector code must be headerless raw binary, position-independent code. It can be a maximum of 452 bytes, but can be less.\n\n", argv[0]);
      return(-1);
   }

   load_address = atoi(argv[4]);
   fat_address = atoi(argv[5]);

   f = fopen(argv[1], "rb+");
   if(!f) {
      printf("Couldn't open disk image.\n\n");
      return(-1);
   }

   f2 = fopen(argv[2], "rb");
   if(!f2) {
      fclose(f);
      printf("Couldn't open boot sector code file.\n\n");
      return(-1);
   }

   fseek(f2, 0, SEEK_END);
   if( ftell(f2) > 452 ) {
      fclose(f2);
      fclose(f);
      printf("Boot sector code file is too long (maximum length 452 bytes)\n\n");
      return(-1);
   }

   fseek(f2, 0, SEEK_SET);

   /* Write initial branch instruction and the text "Loader" */
   putc(0x60, f);
   putc(0x38, f);
   fwrite("Loader", 6, 1, f);
   fflush(f);

   fseek(f, 0x1e, SEEK_SET);

   /* Write load address stuff */
   putc(0, f); putc(0, f);
   putc(0, f); putc(0, f);
   putc(0, f); putc(0, f);
   putc(0, f); putc(0, f);
   putc((load_address >> 24) & 0xff, f);
   putc((load_address >> 16) & 0xff, f);
   putc((load_address >> 8) & 0xff, f);
   putc(load_address & 0xff, f);
   putc((fat_address >> 24) & 0xff, f);
   putc((fat_address >> 16) & 0xff, f);
   putc((fat_address >> 8) & 0xff, f);
   putc(fat_address & 0xff, f);


   strncpy(filenamebuf, argv[3], 12);
   filenamebuf[12] = 0;

   /* Convert filename to uppercase */
   for( i = 0 ; ; i++ ) {
      if( filenamebuf[i] == 0 ) break;
      filenamebuf[i] = toupper(filenamebuf[i]);
   }

   /* Extract first part of filename before extension */
   tempstr = strtok(filenamebuf, ".");
   if( tempstr ) {
      strcpy(firstpartname, tempstr);
   } else {
      firstpartname[0] = 0;
   }

   /* Extract filename extension */
   tempstr = strtok(NULL, ".");
   if( tempstr ) {
      strcpy(secondpartname, tempstr);
   } else {
      secondpartname[0] = 0;
   }

   /* Pad first part of filename to 8 characters with spaces */
   while( strlen(firstpartname) < 8 ) {
      strcat(firstpartname, " ");
   }

   /* Pad extension to 3 characters with spaces */
   while( strlen(secondpartname) < 3 ) {
      strcat(secondpartname, " ");
   }

   /* Write full filename */
   fwrite(firstpartname, 8, 1, f);
   fwrite(secondpartname, 3, 1, f);

   putc(0, f);


   /* Write boot code */
   for(;;) {
      temp2 = getc(f2);
      if( temp2 < 0 ) break;
      putc(temp2, f);
   }

   fflush(f);


   /* Calculate checksum */

   fseek(f, 0, SEEK_SET);

   checksum = 0;

   for( i = 0 ; i < 255 ; i++ ) {
      temp = (unsigned short) getc(f);
      temp <<= 8;
      temp |= (unsigned short) getc(f);

      checksum += temp;
   }

   checksum = 0x1234 - checksum;

   fseek(f, 510, SEEK_SET);

   putc((checksum >> 8) & 0xff, f);
   putc(checksum & 0xff, f);

   fclose(f2);
   fclose(f);
   return(0);
}


In addition to injecting the boot sector code, it also sets the boot sector to load a supplied filename and boot it - like how the TOS disk loads and executes TOS.IMG. I couldn't actually get this part to work though. Even if the bootsector code returns with rts, it just takes me to the desktop without ever loading TOS.IMG.

The actual bootsector code I tried to use was as follows:

Code: Select all


   move.w   #$0333,$ffff8240.w

   move.l   filename(pc),-(sp)
   move.w   #9,-(sp)
   trap   #1
   addq.l   #6,sp

   move.l   envstring(pc),-(sp)
   move.l   cmdline(pc),-(sp)
   move.l   filename(pc),-(sp)
   move.w   #0,-(sp)
   move.w   #$4b,-(sp)
   trap   #1

envstring:
   dc.b   'PATH=',0,'A:\',0,0
cmdline:
   dc.b   0
filename:
   dc.b   'LOADER.TOS',0



The first instruction definitely runs - the screen turns grey. But I never see anything else besides bombs and a double bus error. I was expecting to see, at least, the text "LOADER.TOS" printed to the screen. It then tries to load and run LOADER.TOS - but I don't think it even gets that far.

I think it's all position-independent, but I must have missed something somewhere.

[czietz]

Shouldn't this be...

Code: Select all

pea filename(pc)


etc.?

[Foxie]

Shouldn't this be...

Code: Select all

pea filename(pc)


etc.?

*facepaw*

Yes, of course, you're right. Thanks for reminding me ^^

[Foxie]

So, the test results are as follows, on a 4MB STE (1.62):

From bootsector:
4,118,368 bytes free in largest block
Start address of program: A8A0
os_end: 615C

From auto folder:
4,118,118 bytes free in largest block
Start address of program: A99A
os_end: 615C

From desktop:
4,082,416 bytes free in largest block
Start address of program: 13510
os_end: 615C

So, there's a 35K saving running from the auto folder, but only a 250 byte saving moving to the bootsector. Pretty poor, to be honest. I was expecting more, because os_end is all the way down at 615C. Why can't it load the program at 615C too?

So going forward, I have two options:

I could overwrite the area between 615C and the program start (Axxx) with my own data. This could give me an extra 18K. But, is it safe? Can I still use GEMDOS after doing that? (the documentation I've read says that os_end is for BIOS/XBIOS, no mention of GEMDOS)

Or, I could just use a trackloader and take over all of the memory. This has the possibility of giving a further 24K compared to the above, and 42K better than running from the auto folder. I'll need to write a loader program for hard disk users that loads the disk image with TOS into memory above 512K, then proceeds to destroy TOS. (most hard disk users surely have several MB?)

It sounds like a lot of work writing a trackloader.

I've attached the program I used to report the memory use.

[mikro]

(you cannot predict the RAM address used for execution of the boot code)

Actually, this is an interesting point. As far as one TOS version is concerned, this should be a pretty explicit value, shouldn't it? I mean, it's the power cycle, it literally must be the same memory setup in every case.

Could be a nice optimisation for some hardcore boot intro. :)

[Foxie]

Actually, this is an interesting point. As far as one TOS version is concerned, this should be a pretty explicit value, shouldn't it? I mean, it's the power cycle, it literally must be the same memory setup in every case.

Could be a nice optimisation for some hardcore boot intro.

I did some tests with a few TOS versions. It seems they all load at slightly different addresses (but in the same general area):

1.00: 16B4
1.04: 1856
1.62: 1896
2.06: 167E
4.04: 1D00

I'm not sure if it changes depending on hard disk driver. It doesn't change based on total system memory or monitor type.

The bootsector contains fields to load a particular filename at an address of your choosing. That sounds really useful, but I can't seem to get it to work. I imagine it would blow up if you tried to load into low memory.

[metalages]

Reason why the code of my bootsector copy itself at top of the ram and jump before loading.
Then I load my program at $1000

[ThorstenOtto]

As far as one TOS version is concerned, this should be a pretty explicit value, shouldn't it?

Yes. of course. It is loaded into a static diskbuffer, which will remain the same between boots on the same TOS version. It only differs between TOS versions. But i can't see how this can be exposed to do anything useful. The address might be the same after a reboot, but the contents are of course already overwritten.

[troed]

IIRC it's definitely usable. $4C6 points to the buffer address where the boot sector will be loaded. I think, it's been some years since I believe I used it ...

(Not sure what for though )

[Foxie]

Yes. of course. It is loaded into a static diskbuffer, which will remain the same between boots on the same TOS version. It only differs between TOS versions. But i can't see how this can be exposed to do anything useful. The address might be the same after a reboot, but the contents are of course already overwritten.

I suppose the idea would be to write your code at that address, and then perform a load to bring in the remaining sectors after it. That would save needing to copy the code to a new address.

It's a shame it loads so high in memory really. You might want to take advantage of that first 6K of RAM.

I've heard that loading your code into really low memory ($100) can blow up on the Falcon (because of the MMU table stuff). Instead, load to $1000. I wonder if that's really necessary? Can the MMU be disabled?

[ThorstenOtto]

[I suppose the idea would be to write your code at that address, and then perform a load to bring in the remaining sectors after it. That would save needing to copy the code to a new address.

Yes, but for that you still don't need to know in advance where the first sector is located. Loading a harddisk driver usually works this way; the first sector contains some minimal I/O routines, while the 2nd contains code to search for the driver file in the root directory.

Can the MMU be disabled?

Of course it can, but i think it would be a bad idea. The tables are set up to map the I/O area from 0xffxxxxxx to 0x00ffffff, and also to mark that area as non-cacheable. Turning that off might have strange results when accessing I/O addresses.

[mikro]

Can the MMU be disabled?

Of course it can, but i think it would be a bad idea. The tables are set up to map the I/O area from 0xffxxxxxx to 0x00ffffff, and also to mark that area as non-cacheable. Turning that off might have strange results when accessing I/O addresses.

It isn't that bad. It's true you have to be careful about 0x00ffxxxx but the translation (or its lack of) is set by the TTx registers, i.e. you can work with disabled MMU without too much trouble (tried it in the past, worked).

[Foxie]

I tested overwriting the area between os_end and the start of the basepage. The system blows up catastrophically. I didn't even get a chance to call GEMDOS before it crashed.

So it appears that os_end is not really the end of GEMDOS. It's using the area between os_end and basepage.

[ThorstenOtto]

I tested overwriting the area between os_end and the start of the basepage. The system blows up catastrophically. I didn't even get a chance to call GEMDOS before it crashed.

So it appears that os_end is not really the end of GEMDOS. It's using the area between os_end and basepage.

That was to be expected. That variable actually does not mean anything, when the GEMDOS is linked with other parts of the OS. The Atari/DR linker assigns addresses to variables in a very unpredictable manner (by walking down its internal hashlist). In practice, that means that every new symbol you use during linking, may lead to a totally different layout. That gave me quite some headaches when compiling the TOS sources.

[Foxie]

That was to be expected. That variable actually does not mean anything, when the GEMDOS is linked with other parts of the OS. The Atari/DR linker assigns addresses to variables in a very unpredictable manner (by walking down its internal hashlist). In practice, that means that every new symbol you use during linking, may lead to a totally different layout. That gave me quite some headaches when compiling the TOS sources.

I suppose this means that it's not practical to determine which areas of memory are used for disk I/O? I was hoping it would all be clustered in low memory so I could squash everything above it.

[tcat]

Hi,

I have always wondered how boot sectors work on ATARI, ages ago, with my very 1st ATARI, I just accepted it works without much thinking about it. Now I am glad for commented routines posted here as I can follow while reading a bit about `BIOS boot parameter block' in "ST Concise Guide".

Boot block header is documented as between `$0 .. $1E' offsets, after which the actual boot code can start if present.
Offset $0 accomodates a short word branch `$60xx' BRA.S to the start of booting code.

Looking at the assembly snippet below:

Code: Select all

;  transfer bootcode to buffer...
transfer_boot:
off   equ $1a
   move.l #bootcode,a0
   move.w #(bootcode_end-bootcode)/2,d0
   move.l #boots+off+2,a1
.loop:   move.w (a0)+,(a1)+
   dbf d0,.loop
   move.w #$6000+off,boots


Would it not be better to code as:

Code: Select all

;  transfer bootcode to buffer...
transfer_boot:
off   equ $1e                            ;  offset to the boot code start
   move.l #bootcode,a0  ; copy boot code from here
   move.w #(bootcode_end-bootcode)/2,d0  ;  number of words of code to copy
   move.l #boots+off,a1  ;  skip the the boot header
.loop:   move.w (a0)+,(a1)+
   dbf d0,.loop
   move.w #$6000+off-2,boots  ;  populate $601C, BRA.S branch to code start


Is it alright to tinker the code, as I wish to learn more. A challenging exercise for me could be to, [a] remove boot sector, [b] save boot sector to a file, [c] load boot sector from a file, etc?

Many thanks.
Tomas

[tcat]

Hi Simone, All,

Inspired by your assembly code, I dared modifying it as my learning excersise. I hope you take no offence. I realised some boot codes jump $601c, some $601a, seems a matter of personal preference. $1c.w holds NHID (hidden sectors) and is not used by gemdos.

So in this code subroutine I try to check for both.

Code: Select all

; test bootcode routine
;
test_boot:
   bsr.w read_boot      ; Read boot sector
   cmpi.w #$601a,boots  ; Check for common BRA.S words
   beq.w .run           ;  to make sure boot code is loaded
   cmpi.w #$601c,boots
   beq.w .run
   bra.w wait_key
.run:   pea boots       ; Execute from buffer in supervisor
   move.w #$26,-(sp)
   trap #xbios
   addq.l #6,sp
   bra.w main


I use MadMAC assembler, or GFA-Assembler, as it runs from my single floppy installation. I am aware most people here at forum work with DevPACK, that I have no experince yet.

I expanded the program menu slightly, the executable seems doing things, I can now keep boot code in separate files `BOOT.SEC' either having 512 bytes in size when saved from prog or less when assembled externally. I put simple diagnostics to aid debugging.

BOOT.PRG.png

I wish to share the code back for comments, I need to tidy it first.
Many thanks
Tomas

[tcat]

Hi,

Here is a little program based on Simone's code. It generally installs boot sector from file, or saves current boot sector to it. It can also clear the sector or run a test if code is present.

BOOT.zip

I saved these boot codes by the prog to toy with. They are all 512 bytes in size.
You may need to rename to `BOOT.SEC' before use.

BOOTS.zip

You can also build your own as PRG files. They can be less than 512 bytes in size and contain only relocateable code.
Here is demo sector `FORUM.PRG' 300 bytes built from Simone's code. Renaming *.PRG to `BOOT.SEC' should work.

FORUM.zip

Tomas

[simonsunnyboy]

It's Simon, please, the male form
Otherwise please also do not forget to credit Grazey/PHF as the heart of the piece of software is based on his code.

[simonsunnyboy]

And nice additions, thanks for sharing your enhancements.

[tcat]

Hi Simon,

Thank you for encouragement. I have tested the prog on real thing ST. On occasion boot sector is not written and I need to cycle (L)oad, (T)est, untill I see is written, that happens when I try to write to a different floppy, changed in the drive a:\.

Is it that TOS keeps some disk cache in memory, and media change has to be forced somehow? I read somewhere that TOS looks for disk serial numbers to detect such change. I have verified disks I use for tests have different such numbers.

P.S.
Apologies for misspelling your name

Many thanks so far
Tomas