Altirra and development with DOS

[rudla]

Hi,

 

I'm developing some software that requires DOS using my favorite emulator Altirra.

There are many nice options, but I think one extra option would be very helpful in my scenario.

I would like to have an option like /state <x>, which would load altirra saved state (*.altstate).

This could be used to quickly load state, where the DOS is started and fully initialized (ideally together with some option to have a disk mounted).

 

However, that's not all, /run command would still work. So after the image is loaded, Altirra would load EXE and break at exe start adress or just run the exe (same as if without /state option).

 

That way, we can quickly run the developed program with dos initialized.

 

Maybe we can think of the /state switch as an alternative to resetting the machine (reset the machine to specified state).

 

What do you think, would it be useful?

 

Rudla

 

[phaeron]

Hooking to load an executable post-DOS is problematic. The current executable hook executes when DOS would normally boot, so it's in a well-defined environment. Once DOS boots, it's essentially the running program and inserting the executable load into that is harder. Each DOS is different including CP vs. menu and there are very few defined vectors/commands. Some aspects of DOS also don't get updated properly if it doesn't load the executable. For example, DOS 2.0S needs to see a load segment above $3400 to realize that DUP.SYS needs to be reloaded. Best approach I can think of would be a custom AUTORUN.SYS loader but that requires hooks that the emulator doesn't have yet.

 

There are some alternatives, though. If you only need a DOS and not a specific DOS, the best approach would be to enable the H: device and turn on its option for also hooking D:. This will enable DOS file access for your program without having to load a DOS. You also won't have to assemble a disk image as H: works off of loose files. Another way is to boot a virtual disk with your executable as AUTORUN.SYS, but you will have to load symbols and set breakpoints manually as the emulator won't see the program load to do that automatically.

[baktra]

Another possibility would be to incorporate dir2atr to your cross-platform building process.

With that, result of your build process will be always a disk image with DOS 2.5 and AUTORUN.SYS.

[Rybags]

Next best thing is to use an NTFS directory as H:

Then use the CP or menu in Dos to load the newly compiled program.

[rudla]

The idea is, that we would use the /state switch to specify the well-defined environment (kind of replacing the boot) and then just load the exe into this environment. So instead of hooking into boot process, it is skipped and replaced by /state.

 

It would be possible to save the emulator state after the developed application was loaded from DOS, thus solving for example the DOS 2.0S problem. Of course this is slightly hard-core option, but I thing it could work.

 

I understand, that the environment initialized this way may not be fully correct (for example preventing me from returning to DOS correctly), but it may still be very useful.

 

Thanks for tips with H: device.

 

To baktra & Rybaks. Thanks for ideas, that's bacially how I do it now.

However the idea is to have the build environment, where I can hit a hotkey and BANG!, my exe is in debugger in the emulator, with symbols loaded and all the beautiful bells & whistles we already have in Altirra. Loading the application from dos within emulator ruins this user experience completely.

Edited December 22, 2017 by rudla

[Rybags]

Are you building the application by PC based tools or inside the emulator?

 

A save state that has your Dos environment in a ready to load the executable sounds feasible. But really, just booting an ATR is probably just as fast.

Most emulators have speedup options for emulated disk I/O, which you should use if you want less wait time.

 

Also worth a look at JAC's WUDSN environment which allows quick startup after compiles. Though not sure if it allows pre-booting Dos then loading your program as well.

[rudla]

I'm using PC with Altirra, MADS and VisualStudio Code.

[ricortes]

An easy way of doing this would be to just have a couple of instances of the emulator running and as Rybags says, have the MADS output go to your H: device. Should be able to quickly determine compatibility for anything from a 400 to 130xE.

[phaeron]

If you do end up booting DOS and loading the executable that way, you'll need to use the .loadsym command to pull in the symbols. After that's done once, the .reload command will pull in updated versions without needing to retype the filename.

[rudla]

Ideally I would only load DOS and create savestate. Symbols would automatically be loaded with /run on command line i would use when running the emulator next time.