The classic way:
Burn the ISO file to a CD, and boot the CD
or
'dd' the ISO file to a usb stick, and boot the usb stick.
This uses the boot loader contained in the ISO,
so you don't need to know anything about what you are booting.
Puppy has always supported this.
It does not activate the '/sbin/isoboot' script,
so there is no appropriate location for a SAVESPEC file.
The loopback way:
The ISO file is mounted as a loop device,
and the boot uses the files inside it like a "frugal" install.
This uses the boot loader already installed on the booting machine,
and it needs to know the boot parameters for the thing that is being booted.
The boot parameters required for various Linux's are "all over the place",
hence the inclusion of a '/boot/grub/loopback.cfg' file in the ISO.
This is a grub2 config file that can boot the contents of the ISO using the grub2 loopback mechanism.
So grub2, using the '/boot/grub/loopback.cfg', can boot the contents of the ISO,
without the user knowing the boot parameters required by the thing being booted.
For other booting situations, the '/boot/grub/loopback.cfg' should be used as a template.
Puppy supports this by including a '/boot/grub/loopback.cfg' file in any released ISO files.
And via the '/sbin/isoboot' script in 'initrd.gz',
and a '<boot-isos>/SAVESPEC' to control the save location.
(Where <boot-isos> is the path to the directory containing the ISO files.)
The grub2 loopback mechanism:
This is an image loopback mechanism, rather than an ISO loopback mechanism.
ISO is just one of the supported image file formats.
I have successfully booted a '.sfs' file, with suitable contents, using this mechanism.
So the Puppy script '/sbin/isoboot', should probably be called '/sbin/imgboot'.
And it is logical for it's boot parameters to be "img_dev" and "img_loop".
Also, should probably refer to <boot-imgs>, rather than <boot-isos>.