[hatari-devel] Executing program with Hatari (was: [Bug #17567] ...)

Eero Tamminen eerot at users.berlios.de
Tue Oct 5 22:15:55 CEST 2010


Hi,

On Tuesday 05 October 2010, Miro Kropacek wrote:
>> What this would use as a hard disk emulation directory, the last part
>> of the path and current dir if no path is given?
>
> This is one way, but it's possible to do it even simpler.
>
> Does Atari800 have an OS and multiple versions of it? :-)
>
> Actually, it does. It's even worse, it has plethora of 3rd party DOSes as
> disk support is not built-in. So, how it works you ask? Pretty simple, as
> every OS has support for bootstrapping from some device. So you
> essentially create such device media (diskette or hard disk) and
> *bootstrap* from it (everything done in memory of course, no physical
> file is created). So, the simplest solution for this task is to create
> MSA in memory, copy needed file(s) there and install bootstrap code
> (bootloader) for execution. Simple and efficient. Decision, what to use
> for let's say 10 MB files, custom MSA size or harddisk image, I leave up
> to you as you've got far better knowledge what's possible :)

Creating disk images from directory contents is a bit problematic:
- Given directory may have extra stuff
- Floppy image size is limited to couple of megs, whereas
- Hard disk image needs a HD driver and (as can be seen from Hatari manual
  HD section) there's no single solution that would be suitable for all
  TOS versions
- Creating images needs extra tools (mtools) which people might
  not have installed and creating large images is slow
- If the program that is run creates files that you would like to
  access afterwards, getting them from disk image (especially
  HD image) is pretty complicated

So I think GEMDOS emulation is better solution.  You can check Hatari's
"zip2st.sh" and "atari-hd-image.sh" scripts for complications on creating
disk images.


> As Hatari is a low level emulator, the problem is delaying the execution
>
> > until the OS is ready for the program to run and inserting stuff inside
> > the emulation.
>
> Nope, you just make cold-boot everytime ;) This is how its done on
> Atari800 -- it's bootstrapping after all.

I meant that the OS needs to boot before program can be run.
Programs may need OS services (e.g. GEM) to work.


> Thomas, do you see any feasible way to do that from inside Hatari?
>
> What about my proposal?

Basically it's the same thing as what the script I did does except it
adds also the complication of creating a disk image.

I was thinking that if Hatari could create the INF file virtually, then
the program could be in a read-only directory, e.g. on CD.

Thomas?


>> I think it's much easier to do/kludge from outside.  Attached is a shell
>> script for that and desktop.inf file that it uses as a template. 
>> Before using the script, modify it to point where you saved the INF
>> file.
>
> This is a neat idea!  It's nearly perfect (I can use it immediately) but
> requires additional handling (existing directory structure, 

You don't need any extra directory, you can run it from the directory
where you are. Hatari GEMDOS emulation doesn't care if the directory
has extra files, it truncates & converts all files names to legal GEMDOS
file names for TOS.

Or if you want program to be run from a subdirectory, not be at the root
of the emulated drive, the script might take an additional directory
argument.


> access rights for write, ...)

I considered creating a temporary directory where the INF file and
program would be copied, but that would work badly in case:
- if program would need extra files, or
- if script would copy the whole dir, but that would have extra files
  (say your DVD ISO image collection)
- source files would have funny access rights on which the program
  depends on
- If you want the files program writes to be available afterwards


New version of the script checks that creating the temporary INF file
succeeded and complains if it didn't.


> but on the other hand let user to freely use any 
> additional input files (my solution would require to manually select file
> structure on our MSA/HDD image, making it even worse in case of
> subdirectories).
>
> Maybe Hatari installation should include a script like that?
>
> Yes, any mention about this possibility is certainly useful!

OK, this requires it to install INF files to the system and that place
to be stored to the script when the script is installed.


Hatari package for Linux distros could then even register a Linux
binfmt_misc handler that invokes Hatari automatically when one clicks on
an Atari binary.  (Like some people have done with Wine and Window programs
or Java VM and Java programs.)


> > GEMDOS Cconout() & Cconws(), BIOS Bconout()?
>
> GEMDOS is perfectly fine, it's about text being printed by normal
> programs, I doubt any printf-like code will use something from BIOS.
>
> Note that this may have funny effects because also many other things
> could
>
> > be using these and your host terminal's escape sequences and control
> > characters most likely differ from Atari ones.  Filtering escape &
> > control characters would probably be a good idea with something like
> > that.
>
> This isn't that critical. Can be added later, if needed at all.

It might be nice for the cases when the messages disappear too fast to read
them.  Unfortunately it seems that e.g. EmuTOS messages cannot be catched
this way[1].

[1] You can check what OS calls are being used by tracing:
- enabled "--bios-intercept" and use "--trace bios,xbios"
- enable GEMDOS HD emulation and use "--trace gemdos"
- enable extended VDI resolution emulation and use "--trace vdi"


	- Eero
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hatari-tosrun.sh
Type: application/x-shellscript
Size: 1320 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20101005/9bff1e7b/attachment.bin>


More information about the hatari-devel mailing list