Binary loader when finished repeat from start?

[Sheddy]

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.

[Rybags]

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.

[dmsc]

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!

[Rybags]

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.

[pps]

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.

[Rybags]

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.

[Sheddy]

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?

 

 

[pps]

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 May 5, 2020 by pps

[Rybags]

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.

[+DjayBee]

22 hours ago, Rybags said:

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

Did you order this?

 

[Rybags]

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.

[Sheddy]

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 May 6, 2020 by Sheddy
Grammar

[thorfdbg]

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.

[Rybags]

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.

[xxl]

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

[Sheddy]

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

[Rybags]

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.

[xxl]

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.

[Heaven/TQA]

setting warmstart vector to restart procedure? 

 

so after finishing just jump to warmstart and restart?

[pps]

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.

[Sheddy]

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