[hatari-devel] [hatari-tracking] [Bug #17567] Execution of given path

Miro Kropacek miro.kropacek at gmail.com
Tue Oct 5 21:03:11 CEST 2010


Hi,

I think for features it's better to discuss them on the developer
> mailing list and leave bug tracker for bugs.
>
OK, I hope it wont produce much noise from other threads in my mailbox.

> hatari --exec $HOME/atari/projects/something/file.prg
>
> As that's not an image, it needs GEMDOS hard disk emulation & the program
> work with that (i.e. it cannot e.g. be a MiNT program).
>
> No necessarily, see below.


> 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 :)

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.

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

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, access rights
for write, ...) 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!

Hatari emulates printer and serial at hardware level and its the HW stuff
> that's being redirected.  PRN, AUX & CON are higher level OS concepts.
> There's no separe CON hardware, screen is handled as pixels.  I.e. this
> will
> require OS level interception.
>
Ah, sure.

Hatari already has support for VDI, GEMDOS, BIOS and XBIOS interception, but
> all of them require user to use additional options as each will have some
> drawback.  Which actual OS functions you're interested to redirect?
>
> 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.

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20101005/27b84988/attachment.html>


More information about the hatari-devel mailing list