avatar_sucram

Turbo Pascal - open anoter program with parameters

Started by sucram, 12:59, 11 December 17

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

sucram

Hello,

I would like to execute the command SUBMIT.COM EXE.SUB with my Pascal program.

First I tried the following:
Quoteprocedure comaufruf;
var comdatei : Text;
begin
  Assign(comdatei,'SUBMIT.COM EXE.SUB');
  execute(comdatei);
end;


It is not possible to specify a parameter file. If I write ASSIGN(comdatei,'SUBMIT.COM'); the program submit.com starts, but that is not that, what I want.


So I tried the BDOS function 47.
The following code gives me the output: M: SUBMIT.COM?
QuoteVar cmdline : String[128] absolute $80;
Begin
  cmdline:='SUBMIT.COM EXE.SUB');
  bdos(47,$80);
End.

How could it work?

Best regards,
Marcus

SRS

Maybe you need to call BDOS 47 via BDOS 50:


https://www.seasip.info/Cpm/bdos.html

QuoteSupported by: CP/M 3 and later; CP/M-86 v1.1 Entered with C=32h, DE=address of parameter area. Returned values vary.
Under CP/M 3, the BIOS should not be directly called, except possibly the character I/O and USERF calls. Instead, this function should be used. The parameter area is formed:
pb+0:   DB  bios-function   ;0-32 pb+1:   DB  bios-a      ;Value for A register pb+2:   DB  bios-c      ;Value for C register pb+3:   DB  bios-b      ;Value for B register pb+4:   DB  bios-e      ;Value for E register pb+5:   DB  bios-d      ;Value for D register pb+6:   DB  bios-l      ;Value for L register pb+7:   DB  bios-h      ;Value for H register 
In a banked CP/M 3 system:

       
  • A successful call to function 9 (SELDSK) will return HL pointing to a copy of the Disk Parameter Header in common memory, rather than the original. This copy may be overwritten by subsequent BDOS calls, so grab it while you can.
  • A call to function 12 (SETDMA) will be followed by a call to function 28 (SETBNK) with A=1 (TPA bank).
  • For functions 16 (SECTRAN), 20 (DEVTBL) and 22 (DRVTBL), the value returned in HL and BA will be the result the BIOS returned in HL. For other functions (apart from SELDSK above) L and A will hold the value the BIOS returned in A.
  • Function 27 (SELMEM) will be ignored.
Under 16-bit versions, this function should be used for all BIOS calls; only character I/O BIOS calls are permitted. The parameter area is formed:
pb+0:   DB  bios-function pb+1:   DB  bios-cl pb+2:   DB  bios-ch pb+3:   DB  bios-dl pb+4:   DB  bios-dh

Another idea might be to write your "exe.sub" content into "PROFILE.SUB" and reboot cp/m (via RST 0 or BDOS 0) . That will SUBMIT PROFILE.SUB (if it is CP/M 3) an boot (Autostart.bat ...)

Last command in your new EXE.SUB replacement PROFILE.SUB should be era PROFILE.SUB to reuse that each time.



JohnElliott

Quote from: sucram on 12:59, 11 December 17

So I tried the BDOS function 47.
The following code gives me the output: M: SUBMIT.COM?
How could it work?

From your screenshot it looks to me like it is working -- you told CP/M to behave as if you had typed the command M:SUBMIT.COM EXAMPLE.SUB, and CP/M did. I'm guessing it didn't run the SUB file because you didn't have a copy of SUBMIT.COM on drive M:.

JohnElliott

Quote from: SRS on 21:17, 11 December 17
Maybe you need to call BDOS 47 via BDOS 50:
BDOS 50 is for calling BIOS functions, not other BDOS functions, so this won't work.

Quote from: SRS on 21:17, 11 December 17
Another idea might be to write your "exe.sub" content into "PROFILE.SUB" and reboot cp/m (via RST 0 or BDOS 0) . That will SUBMIT PROFILE.SUB (if it is CP/M 3) an boot (Autostart.bat ...)

And here you're confusing terminating a program (with RST 0) with rebooting the whole operating system. PROFILE.SUB is only run on a full operating system reload, and the user is not going to be impressed by programs arbitrarily rewriting their PROFILE.SUB file. Not to mention that rebooting when what you actually want to do is chain to another command is serious overkill.

There is a .SUB file that's run when a program terminates, but it's not PROFILE.SUB -- it's $$$.SUB on the CP/M temporary drive. To chain a command that way, you'd:

       
  • Get the temporary drive (BDOS 31h with DE pointing to a word containing 0050h). If it's 0 use the current drive.
  • Write $$$.SUB. Each record is 128 bytes; the first byte is the length of the command and the remaining up-to-127 are the 0-terminated command text. The records will be executed in reverse order.
  • Terminate.
For example, to execute PIP followed by DIR, the $$$.SUB file might look like this:

0100: 03 44 49 52 00 00 00 00 00 00 00 00 00 00 00 00 .DIR............
0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0180: 03 50 49 50 00 00 00 00 00 00 00 00 00 00 00 00 .PIP............
0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................


sucram

Quote from: JohnElliott on 23:33, 11 December 17
From your screenshot it looks to me like it is working -- you told CP/M to behave as if you had typed the command M:SUBMIT.COM EXAMPLE.SUB, and CP/M did. I'm guessing it didn't run the SUB file because you didn't have a copy of SUBMIT.COM on drive M:.


It seems that there is no M: SUBMIT.COM file, but it is there.

JohnElliott

You can double-check the behaviour of the system call with SID. This worked for me:
M>SID
CP/M 3 SID - Version 3.0
#a100
0100  mvi c,2f
0102  mvi e,0
0104  jmp 5
0107  .
#s80
0080 00 "M:SUBMIT.COM EXAMPLE.SUB
0098 1A 0
0099 1A .
#g100


sucram

Good morning,

the call over SID works also for me:

[attachimg=1]

sucram

It's not a nice solution, but using two .sub files can help prevent the problem.

Already the first application has to be started with SUBMIT SUB1.SUB. SUB1 will call the second batch file with SUBMIT SUB1.SUB in the next step. The SUB2.SUB file created at runtime simply needs to start the process over again with SUBMIT SUB1.SUB. If the batch process is to be ended, an empty file SUB2.SUB must be created.

The video shows the mutual call of two batch processes. In this case, it is an infinite loop because the SUB2.SUB file is not generated at runtime.

[attach=2]

JohnElliott

Quote from: sucram on 10:42, 12 December 17
Good morning,

the call over SID works also for me:

I wonder if Pascal is setting up the buffer at 80h correctly. If I put the command there as a Pascal string rather than a C string, I get the same error you do:

M>sid
CP/M 3 SID - Version 3.0
#a100
0100  mvi c,2f
0102  mvi e,0
0104  jmp 5
0107  .
#s80
0080 00 18
0081 00 "M:SUBMIT.COM EXAMPLE.SUB
0099 00 0
009A 53 .
#g100
M:SUBMIT.COM?
M>


Powered by SMFPacks Menu Editor Mod