RAD

[scuzzb494]

Hi

One of the interesting things about mucking around with DOOM on the AF CD was that it created a RAD disk on the machine that just would not go away. Anyway it wasn`t there today so I had a play myself with RAD. Thing was as I mucked around I get a checksum error on RAD.. which is strange. I then decided to Quickformat RAD and this converted it to EMPTY as I didn`t name it, complete with TrashCan. Then I removed the RAD icon from the DOSDrivers drawer and the thing still wouldn`t go away, and again had a checksum error...

Anyway I recalled the old 'remrad' command from the Shell and the poor thing finally died. Would have been OK if it hadn`t have eaten up the ChipRAM. Still, can't understand how it got a checksum error though. Can anyone educate me please ?

scuzz

[SamuraiCrow]

If you had less than 880k of free "kick tag" memory available then that would cause the RAD device to have an error.  Since the RAD device is a bootable device it has to be in a kind of memory that survives a warm-reboot.  That's why it ate up your chip RAM.

[scuzzb494]

Hi

Thing is that the RAD survived a system shut down and reboot even after I had removed RAD from the DosDrivers drawer. The only way I could kill it was to enter the killer remrad from the shell. I had hardly touched the capacity of the RAD before I got the Checksum. What was amazing to me was that having played with DOOM from a CD the resultant DOOM_RAD could not be located on the machine. And I had switched the computer off a few times, and it still appeared. Yet this morning it had gone. I have a Blizzard Turbo with SCSI KIT, 3 hard drives, ZIP, CDROM 32MB RAM on a desktop A1200.

scuzz

[Merc]

Actually it is possible to have RAD live in fast RAM, I always set mine up that way.  You just have to change BufMemType in the dosdriver.  

I guess if you had fast RAM on an expansion board that didn't make itself available soon enough on reboot, you might lose it, but I never had that problem on a variety of Amigas and RAM expansions.

[scuzzb494]

Hi

BufMemType is set to value 1, so what would this change to. The Blizzard is probably the culprit here I guess. I will create a custom RAD and have a play.

scuzz

[Piru]

Actually it is possible to have RAD live in fast RAM, I always set mine up that way. You just have to change BufMemType in the dosdriver.

This is utter nonsense. Filesystem bufmemtype has nothing to do with memory type used for RAD.

[Piru]

Powering the system down for 30 seconds erases the RAD for sure.

RAD is supposed to survive reboot.

[Chain]

"remrad force" be with you...

[scuzzb494]

Hi

Sorry. Think we are at cross purposes. The RAD was resident in the DEVS/DOSDriver drawer so will activate each time you reboot or start from cold. Thing was I got a checksum on this. And even after restart it still had the checksum. I had some fun formatting the RAD and renaming then deleting but wouldn`t go away without remrad. Anyway.. I have been reading that you should really just launch from Storage. I think its the way the workbench is loaded using the Blizzard. Probably wrong, but working on the old double click now.

scuzz

[Fade]

Hey scuzzb494

Try this little program from Aminet http://aminet.net/disk/misc/statram31.lha and I don't think you will want to go back to the old rad program.

Enjoy

[Merc]

@Piru

All I can say is it always worked for me, on more than one Amiga.   Setting bufmemtype to fast would allocate RAD in fast RAM.  Go figure...

[Piru]

@Merc

All I can say is it always worked for me, on more than one Amiga.

Your amigas have MEMF_KICK set on all fast memory then. In this case RAD is always in fast memory, regardless of what you do.

Setting bufmemtype to fast would allocate RAD in fast RAM.

No it does not. As I said already, bufmemtype has nothing to do with location of the RAD itself. It only affects the buffers used by the filesystem itself. And default bufmemtype of 0 is in fast memory already...

[zipper]

When 3.9 was new, I tested my config by booting from a 20 MB RAD disk.