Jump to content
Sheddy

Binary loader when finished repeat from start?

Recommended Posts

So, I'm trying to create a slide show exe which will loop back once the last  slide is done. With a standard exe we can chain load and show pictures with init. However once at the end of the file, is there a safe way to set things back to start over at the beginning of the file that will work with all binary loaders from different DOSes? I assume the exe will not know how it has been called or what its file name is. I'm pretty clueless about doing things with DOS and couldn't see an obvious way to do this, so hope this is a simple thing. Thanks.

Share this post


Link to post
Share on other sites

Can't be done (probably).  There's no standard mapping for work variables for binary files other than the Init/Run vectors.  And the only valid control via CIO if in fact it's even invoved with the particular loader, is NOTE/POINT which is only valid when a file is opened for update (and even then the usage might be absolute or offset sector depending on the Dos in use).

 

If you used a disk with custom loader and/or Dos that you knew was always present then you could probably do it.

 

I do remember the MULE bload file I got in the day - it took over the load process.  From memory it had an initial section that took it exactly to the end of a sector, so then it's loader knew for sure that the DCB setup for the next SIO read would be at the correct point.

In theory you could do something like that (and save the sector info for later re-read) but there are presumptions that if not met will mean it'll likely not work:

- Dos or loader in use has 125 data byte payload per sector.

- Loader updates DCB info with next sector pointer once a sector has loaded.

- Device in use is actually one that uses SIO in the same manner as a stock disk drive.

Share this post


Link to post
Share on other sites

Hi!

4 hours ago, Sheddy said:

So, I'm trying to create a slide show exe which will loop back once the last  slide is done. With a standard exe we can chain load and show pictures with init. However once at the end of the file, is there a safe way to set things back to start over at the beginning of the file that will work with all binary loaders from different DOSes? I assume the exe will not know how it has been called or what its file name is. I'm pretty clueless about doing things with DOS and couldn't see an obvious way to do this, so hope this is a simple thing. Thanks.

With most DOS (but not with the mini loaders), binary loading uses IOCB #1, so you can cheat: create a segment with a INIT vector just before the point you want to return to, in the init code call "NOTE" and store the file pointer, then at the last segment also create a INIT code that calls "POINT" with the stored pointer. So, DOS will continue reading your file from the old location!

 

The file will have segments like:  <ff ff> <first_data> <note_code> <INIT: note_code> <slide_1> ..... <slide_N> <point_code> <INIT: point_code>

 

Have Fun!

  • Like 1

Share this post


Link to post
Share on other sites

My mistake with Note/Point.  I was thinking it's only valid in "update" mode but is also fine with read mode.

 

But I do feel you'd be limited in what situations you could get it to work.

 

Similar to this situation is Ridiculous Reality.  Fairly sure it's a single binary file that loads progressively while you complete each level including the last.  Then the game ends and you have to reboot if you want to play again.

Share this post


Link to post
Share on other sites

As it is a slideshow, I assume that the file would be a bit longer then. So a whole atr containing everything is imho best way to share.

If you chain all together and start the pics with ini, you can reboot at the end jumping to $e477. This method depends just on the fact, that a restart of the show only occur, when the file stays at the initial atr. When the user moves it away, restart (of the show) is gone.

 

Or you have to write your own loader (which depends on the used DOS, too), that loads the different files. There you can loop the way you want. Here you are sure (when the user copies all the files) the show works as you wanted, but only, if you coded correct for usual DOS systems. If user has some other DOS in use, the whole show might crash.

 

The other option needs enough RAM. Load every picture in RAM and switch then. This should always work as planned, but only if user has enough RAM.

 

I would choose the first option. You can never be sure the user won't change anything, but then he has to live with it.

Share this post


Link to post
Share on other sites

Additional to that is the warm disk reboot trick.

 

Thanks to how the OS works you can force a disk reboot by calling WARMST ($E474), then use code in a CASINI section to clear the WARMST flag at 8, zero the BOOT flag at 2 then the OS will attempt a disk boot without clearing memory.

You could even put a keypress into CH to select a menu option if required.

  • Like 1

Share this post


Link to post
Share on other sites

Thanks guys, that is all very insightful. 

I would be looking for maximum portability. I guess some modern device handlers/emulators binary load might  just "magically" inject exe segments into memory too.

 

I had read that NOTE only worked in update mode too in OS manual. That'd be a great trick though. The mini DOSes would be a natural for something like a slideshow to squeeze in as many slides as possible, so may have to rule that out.

 

Ironically I had started out using ATR and switched to XEX thinking it'd be more portable.

Problem then becomes what to do with larger than standard 90/120K disk. Do we just start using 256 byte sectors for bigger?

 

 

Share this post


Link to post
Share on other sites
Posted (edited)
20 minutes ago, Sheddy said:

Problem then becomes what to do with larger than standard 90/120K disk. Do we just start using 256 byte sectors for bigger?

To stay compatible with original Atari hardware, you should stay at medium/enhanced density, as this is what most people can boot with their ancient drives. Quad or double density is possible with enhanced drives (double) or the XF. 

Other formats won't do on original drives, but for sure on most newer things or hard disc interfaces (MyDOS up to 16 MB) 

 

You could tell the user to boot next disc, when needed in bigger shows and release with some more atr files. 

Edited by pps
  • Like 2

Share this post


Link to post
Share on other sites

ATR is extensible to 16 Meg but then you're tying yourself more to emulation devices and less to real ones including the IDE types.

 

Maybe the ideal would be a small Dos that allows Note/Point and also supports different media+emulated disk sizes.

  • Like 1

Share this post


Link to post
Share on other sites
22 hours ago, Rybags said:

Maybe the ideal would be a small Dos that allows Note/Point

Did you order this? ;)

 

  • Thanks 1

Share this post


Link to post
Share on other sites

Another thought I had was save/restore of relevant work area.  Since we don't know what is used though that would mean everything from bottom of memory to potentially $7FF or a little higher for a loader.

For Doses, probably a bit trickier.  I get the feeling that there'd be work variables associated with binary load embedded in most Doses.

  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

I think you're right Rybags about work variables judging by my initial failed experiments with trying to use just NOTE with DOS 2.5 during its binary loader as suggested by dmsc. 

 

It's a simple PC utility I'm making to create the disk/exe slides so I may just stick to plain disk sectors and no DOS to save added complexity in it writing to a DOS ATR. As a key feature of the utility is to be able to extract the original picture XEXs again I think portability to other DOSes may be less of an issue.

 

I was ideally hoping to not rely on any particular DOS at all and just be able to distribute XEX and rely on fundamental binary loader functionality common to them all. So, for example, just drag and drop XEX onto Altirra and instant slide show. But the lack of being able to implement a loop function that way, (which I believe most people would think is an essential feature for what has to be a pretty small slideshow), is a literal show stopper (Terrible pun).

 

Edited by Sheddy
Grammar

Share this post


Link to post
Share on other sites

You can still take over loading yourself. Set an init vector, then perform all the CIO I/O by yourself, not depending on the Dos. This works with all DOSes I am aware of. Actually, TurboBasic does just that to be able to load itself behind the Os.

Share this post


Link to post
Share on other sites

Yeah - emulators will be a problem - I'm fairly sure Altirra and Atari800Win+ at the least use the inject method for Xex files.

So no resident work variables to be found.

The problem with "taking over CIO" - you'll find that most compact loaders don't use CIO at all.  You can usually have a smaller footprint by just using DSKINV directly and doing the sector link and BLoad stuff yourself.

Share this post


Link to post
Share on other sites

ATR is a very good container for things like slideshow... what are the disadvantages of this solution?

Share this post


Link to post
Share on other sites

Yep ATR is a good container. If I could just use exe/xex on its own though  I wouldn't need to write any loading code at all and leave it to the binary loader

Share this post


Link to post
Share on other sites

ATR has the disadvantage of often tying you to a device type or being wasteful in that a single image is miniscule compared to what the device could handle.  Additionally the disadvantage that aside from imagine entire medium sized partitions, not always useful on IDE type devices.

 

16 Meg ATR - great, but won't work on real (legacy) drives.

Small media based ATR - wasteful on emulated devices and the likes of SIO2SD.

 

An alternative can be to insist the pic show is loaded from a Dos.  Downside in that you have that several K lost overhead.

Advantage that you can be flexible in how the presentation is stored.  20 floppies or a single partition of a bigger device.

 

Write the program such that it looks for a particular file and if it's not there it knows which disk to prompt for, allowing the user to have the 1 big or 20 small floppies or images that they can mount on demand.

Share this post


Link to post
Share on other sites

is this work to be distributed on 20 diskettes? let's talk about the facts and don't force a man to work that is 99% wasted.

Share this post


Link to post
Share on other sites

setting warmstart vector to restart procedure? 

 

so after finishing just jump to warmstart and restart?

Share this post


Link to post
Share on other sites
4 hours ago, Heaven/TQA said:

setting warmstart vector to restart procedure? 

 

so after finishing just jump to warmstart and restart?

Imho warm start or cold start depends of what stays in RAM, when only warm start is used. Cold start could be the better option if you want to be sure that nothing unexpected happens. But maybe I am totally wrong, as you all know I'm just at lower coding skills than other people around here.

Share this post


Link to post
Share on other sites

Thanks all. Plenty of ideas there to try and to learn about. Much appreciated.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...