Start MULTIPLAN cartridge from FG99 automatically

[wolhess]

Hello, maybe someone can help me to start Multiplan automatically.

I have read in various threads that you can change a cartridge so that this cartridge program starts automatically.
How does this work using the example of the Multiplan module?

 

I regularly work with a Multiplan table on my TI system.
         (Console, FG99, PEB, TIPI, EVPC2 80 Column card, SAMS 1MB, TI Disk Controller with 80 Track 
         mod, 1x5.25“ 360KB, 1x3.5“ 360K, 1x5.25“ 90K, Rave 99 Speech Adapter+speech card) 

         Force Command version 1.17, tipi version 2.23 (dsr vom 24.02.2021)

 

To do this, I start Force Command from FG99 and select Multiplan in 80-character mode via an "AUTOCMD" menu.
The TIPI directories are mapped in the AUTOCMD and the Multiplan cartridge is loaded.

 

This results in the TI showing the title screen and then I can start Multiplan with ENTER and choice 2 for Multiplan.
With another ENTER the Multiplan application loads.

 

If the Multiplan Cartidge Module starts automatically, the Title screen + Enter + Option 2 would be omitted.

Perhaps there is also a patch to skip the selection "INSTALL PROGRAM DISK - PRESS ENTER KEY TO LOAD"

and run Multiplan directly?

 

This is what I do now:

     

   1) Run Force Command                     2) Select Multiplan and map the tipi directories

 

    

  3) Press any Key                               4) Select 2 for Multiplan

 

    

  5) Press ENTER to load MP                  6) Multiplan is running

 

 

This is the menu part in my AUTOCMD to run Multiplan

MP80:
cls
color 15 1
echo Setting up Microsoft Multiplan
tipimap DSK1 TIPI.MM.P.80.TIMP
tipimap DSK2 TIPI.MM.P.TIMP.TAB
tipimap DSK3 TIPI.MM.P.TIMP.UTIL
tipibeeps
echo Loading Microsoft Multiplan cartridge
fg99 PHM3113G

 

 

And this is the Multiplan .bin File: PHM3113G I use in my FG99

phm3113G.BIN

 

 

Thank You for any hints to make the multiplan.bin file autorunning.

[HOME AUTOMATION]

As I recall, after loading the new image, FORCE COMMAND uses a BLWP @>0000 to invoke the TI TITLE SCREEN. I image this instruction could simply be altered or patched to execute a machine code address. However, starting a GPL program would probably need some setting-up first. I'm afraid I haven't had a great need for this... so not sure how.

 

The FG99 feature that auto-loads a single image, requires only one image to be present on it's SD card, and that also leaves you at the TI TITLE SCREEN.

 

I have come up with a method to get a GPL or ROM image to start automatically from FG99 power-up. But that wouldn't address doing it through FORCE COMMAND.

 

Sounds like a job for @jedimatt42.

[wolhess]

I was thinking more of a change in the Multiplan GROM similar to the autostart of Gazoo's XB 2.7 Suite.

[HOME AUTOMATION]

Afraid I'm not familiar with Gazoo's XB 2.7 Suite.

 

Perhaps all you need is something like the way AUTOCMD works.

I can't test this out right now as I don't have my 32k or TIPI set up now...

 

I just gave this a power-up header...

 

         phm3113G.BIN

 

[wolhess]

9 hours ago, HOME AUTOMATION said:

Afraid I'm not familiar with Gazoo's XB 2.7 Suite.

 

Perhaps all you need is something like the way AUTOCMD works.

I can't test this out right now as I don't have my 32k or TIPI set up now...

 

I just gave this a power-up header...

 

          phm3113G.BIN 40 kB · 7 downloads

 

Wow, I tested your modified bin file right now and it runs directly in the Multiplan screen without showing the title screen.

 

But then nothing else is working. The cartridge shows the Multiplan "Press Enter Key To Load" but no key pressing is accepted.

 

Also in the unmodiefied bin file you can press the "blank" key to change the colors, now nothing happens.

 

I think the Multiplan cartridge is a litle bit more complicated than a normal game cartridge.

[HOME AUTOMATION]

3 hours ago, wolhess said:

But then nothing else is working.

I dug out the 32k so I could run FORCE COMMAND, and received the same results.

Last I knew(it's been a while), FORCE COMMAND, copies the FG99's reload sequence code into PAD, and loads the new image from there. So I suppose PAD needs to be re-initialized before the new program can run properly. This could perhaps be done from the new image.

 

One issue I see, is that PHM3113G.BIN seems to use all 40k of GROM. If so, that will complicate things slightly. I thought TI only used 6k GROMS. Perhaps the additional 2k is garbage, but it doesn't seem to repeat. Do you know anything about that?

 

I don't know anything about this module...

[HOME AUTOMATION]

So, I think the way to go, might be to...

Add a PHM3113C.BIN to the image.
Change the GROM to GRAM.

Replace the first couple bytes ahead of the GPL program with an XML up to ROM, reload PAD, and restore the original GPL bytes from there, then RETURN.

 

For simplicity, the needed PAD data could be obtained from a Classic99 MEMDUMP(at TI TITLE SCREEN), and copied into the ROM, using a HEX-EDITOR.

[wolhess]

1 hour ago, HOME AUTOMATION said:

So, I think the way to go, might be to...

Add a PHM3113C.BIN to the image.
Change the GROM to GRAM.

Replace the first couple bytes ahead of the GPL program with an XML up to ROM, reload PAD, and restore the original GPL bytes from there, then RETURN.

 

For simplicity, the needed PAD data could be obtained from a Classic99 MEMDUMP(at TI TITLE SCREEN), and copied into the ROM, using a HEX-EDITOR.

OK, I think that's a bit beyond my knowledge.

[HOME AUTOMATION]

Small changes, should only take about 1/2 hour to an hour. As much as I would rather be working on this...

My time is being commanded on many fronts today. This will unfortunately have to wait until the wee hrs., that is, assuming I survive the day!!!

 

   P.S. Not guaranteed to work either. But, hopefully it will.

[+arcadeshopper]

8 hours ago, wolhess said:

Wow, I tested your modified bin file right now and it runs directly in the Multiplan screen without showing the title screen.

 

But then nothing else is working. The cartridge shows the Multiplan "Press Enter Key To Load" but no key pressing is accepted.

 

Also in the unmodiefied bin file you can press the "blank" key to change the colors, now nothing happens.

 

I think the Multiplan cartridge is a litle bit more complicated than a normal game cartridge.

likely it doesn't set it's own environment but expects the title screen to do it

 

[HOME AUTOMATION]

Yes Greg, it appears that is the only real issue here.

[HOME AUTOMATION]

 So, I did survive the day! Though, neither my personal issues or the auto-start issue were completely successful...

So, I can expect to be pretty busy this week.

 

I spent about 3 hours fooling with this tonight... I thought I had my code laid out well enough... But, there were still some issues... While debugging(with Classic99), I discovered my trampoline code was over-writing it's source and destination registers at >83E0. So tomorrow I'll temporarily move the WORKSPACE to 32k. Also realized I'll need to restore the GRAM write address as well, after restoring the GPL byte(only had to change one byte, as the second just happened to be correct)?.

 

   So, tomorrow's another day!

[+jedimatt42]

I could add a GROM address parameter to the Force Command FG99 command. Using the same mechanism my XB command uses.

 

Edited May 19, 2021 by jedimatt42

[+jedimatt42]

I don't know what HA did in his first attempt, but it seems to me simply setting the powerup address in the GROM header to the program address you want auto started should work for any GROM. 

 

The program address can be found by looking at the program entry list in the GROM header. That will be the first list entry. View that GROM address. The first 2 bytes there will be the address of the next entry, or >0000 if at the last entry in the list. The second 2 bytes will be the program address you may set as the powerup address. The subsequent bytes describe the menu text. If the menu text isn't the entry you want, go to the address of the next entry. 

 

It is GROM, so odd addresses are valid. 

 

But maybe this is exactly what HA did?

[HOME AUTOMATION]

1 hour ago, jedimatt42 said:

I could add a GROM address parameter to the Force Command FG99 command. Using the same mechanism my XB command uses.

 

Sounds interesting!

 

My efforts didn't pay-off last night. I got tired after a first attempt, and managed to get some sleep at a more reasonable hour, for a change.

 

For some reason the data I exported from Classic99 looks wrong. will re-attempt.

 

I've had luck with something similar before. Might have to gig that up. ugh.

[HOME AUTOMATION]

I was about to debug this after a change, but then it loaded and seemed to work. There are still a couple odd issues though.

One which shouldn't be to hard to correct is that after a quit, things go awry again.

 

Stranger still...

 

If I run my code with WP set to >B000, it works. But if WP is set to use RAM at >7500 it does not.

This anomaly is tricky to debug since I don't know how to force RAM at >7000, in Classic99.

So, maybe give this a spin, and let me know! I still don't have TIPI or a floppy drive set-up.

 

   phm3113G.BIN phm3113C.BIN

[HOME AUTOMATION]

I've re-exported the PAD data from Classic99. Not sure what went wrong the first time. Maybe windows didn't update the file. Maybe the file was updated when I closed Classic99. This time I paused the program, as recommended in the debugger's docs. Also verified the data against the debugger's, w/o closing Classic99 first.

So, now the QUIT issue is solved!

 

Not sure why I Can't seem to get away with using >7500, as a WORKSPACE POINTER... This means that this image wont start w/o 32k. FORCE COMMAND needs that anyway, and I switch back to MULTIPLAN's original WP at >83E0, before starting it. Still it would be nice to get this image to start more universally. ...Oh well.

 

   phm3113G.BIN  phm3113C.BIN

 

[HOME AUTOMATION]

9 hours ago, jedimatt42 said:

The program address can be found by looking at the program entry list in the GROM header. That will be the first list entry. View that GROM address. The first 2 bytes there will be the address of the next entry, or >0000 if at the last entry in the list. The second 2 bytes will be the program address you may set as the powerup address. The subsequent bytes describe the menu text. If the menu text isn't the entry you want, go to the address of the next entry. 

D'oh! I did goof that up. I was pointing the POWER-UP entry, at the list, rather than at the program's entry address. haha. Curiously, after correcting this, MULTIPLAN starts normally from power-up, but not from FORCE COMMAND, so perhaps at least, all this effort was worth it.

 

Not to put the blame on FORCE COMMAND. Ralphb, does point out that:

 

"A "fragile" program is a program that makes certain assumptions about the state of scratchpad RAM and VDP RAM when it starts. Try loading the program directly to RAM by copying this image file as the only file on an SD card. This will provide the exact environment the program expects.

If this doesn't help, the image may be incompatible. Please send a note to the developer at r@0x01.de for further analysis."

 

...also:

 

"A few programs, however, don't expect to be started by something other than the TI 99 menu, or have difficulties to deal with the remnants of previously run programs left over by a warm reset. In rare cases, this may lead to graphical glitches or other unexpected behavior. Also, some GROM programs written specifically for the TI 99/4, may confuse the menu system of the TI 99/4A.

Please refer to the troubleshooting section for a list of programs with known issues."

 

My thoughts are that perhaps if FORCE COMMAND, restored PAD, to it's "TI menu-page" state, then ran the FinalGrom99's re-load code, from 32k, than perhaps POWER-UP images might behave better.

 

 

Edited May 19, 2021 by HOME AUTOMATION
spellin' ellen

[wolhess]

On 5/19/2021 at 11:10 PM, HOME AUTOMATION said:

I've re-exported the PAD data from Classic99. Not sure what went wrong the first time. Maybe windows didn't update the file. Maybe the file was updated when I closed Classic99. This time I paused the program, as recommended in the debugger's docs. Also verified the data against the debugger's, w/o closing Classic99 first.

So, now the QUIT issue is solved!

 

Not sure why I Can't seem to get away with using >7500, as a WORKSPACE POINTER... This means that this image wont start w/o 32k. FORCE COMMAND needs that anyway, and I switch back to MULTIPLAN's original WP at >83E0, before starting it. Still it would be nice to get this image to start more universally. ...Oh well.

 

    phm3113G.BIN 40 kB · 2 downloads    phm3113C.BIN 8 kB · 2 downloads

 

Hi,

Your bin files work completely. Many Thanks.

Now I can select "Multiplan" in Force Command and run directly in the Multiplan start screen.

 

What I read from your previous explanations, two steps were necessary for the Multiplan autostart.
1. Enter the program entry address for the automatic start and
2. Establish the system environment as after a reset via the title screen.

 

If you have a little more time, could you please explain how you changed everything exactly to enable the autostart and function?

 

I am interested in how you found the program address for point 1 and how you created the system environment for point 2.

And somehow you must have taught the Multiplan module that the second bin file with the system environment is loaded before the main program?

 

I was reading the nouspikel.com website with the standard header summary.

As far as I understand you have also entered the address of the program list in the field for the power-up list.

The change of address 0x003 from 00 to 52, the address 0x0012 from D6 to D8 and the handling of the C file is unclear to me.

 

I looked at the old and the new GROM file and looked for differences.

 

This is the original GROM file:

 

 

And this is the modified GROM file_

 

Wolfgang

[+Vorticon]

Any reason why Multiplan is insisting on loading from the real DSK1 drive?

I have DSK1 mapped to a TIPI folder and Auto is checked in the TIPI config...

 

[+Vorticon]

On 5/16/2021 at 8:30 AM, wolhess said:

Hello, maybe someone can help me to start Multiplan automatically.

I have read in various threads that you can change a cartridge so that this cartridge program starts automatically.
How does this work using the example of the Multiplan module?

 

I regularly work with a Multiplan table on my TI system.
         (Console, FG99, PEB, TIPI, EVPC2 80 Column card, SAMS 1MB, TI Disk Controller with 80 Track 
         mod, 1x5.25“ 360KB, 1x3.5“ 360K, 1x5.25“ 90K, Rave 99 Speech Adapter+speech card) 

         Force Command version 1.17, tipi version 2.23 (dsr vom 24.02.2021)

 

To do this, I start Force Command from FG99 and select Multiplan in 80-character mode via an "AUTOCMD" menu.
The TIPI directories are mapped in the AUTOCMD and the Multiplan cartridge is loaded.

 

This results in the TI showing the title screen and then I can start Multiplan with ENTER and choice 2 for Multiplan.
With another ENTER the Multiplan application loads.

 

If the Multiplan Cartidge Module starts automatically, the Title screen + Enter + Option 2 would be omitted.

Perhaps there is also a patch to skip the selection "INSTALL PROGRAM DISK - PRESS ENTER KEY TO LOAD"

and run Multiplan directly?

Do you any issue having Multiplan use TIPI mapped drives for the program disk? I can't get it to work....

Edited May 22, 2021 by Vorticon

[HOME AUTOMATION]

On 5/21/2021 at 4:04 AM, wolhess said:

Oh boy! That 'R' at >6003 is supposed to be an 'X'. It was only supposed to be changed temporarily while I investigated the WP not working when at >7500. The 'X' is supposed to allow GRAM, as well as RAM, at >7000-7FFF. Gram is required so the two bytes I have overwritten at >60d6, >60d7, can be restored by instructions in my code that runs from RAM/ROM at >7d00. Actually a 'G' should suffice, since my code doesn't seem to require RAM, and I can't get the WORKSPACE to work from that RAM address range anyway...

 

I have determined that IMAGES re-loaded from FORCE COMMAND are not able to get CPURAM at >7000, at least when they are started from a GROM. It appears that perhaps GRAM is accommodated, but I'm still looking into this. I'm not sure if this is related to FORCE COMMAND's somewhat altered re-load method, or if the issue effects FinalGrom99 re-loading globally.

 

This issue has dominated my TI time for a few days now, and if global, may hamper some of my development plans, should I ever continue with them. So, I'll probably bring this up with Ralphb, at some point, as I am becoming frustrated, in an effort to get to the bottom of this.

 

 

      P.S. More to come.
 

Edited May 23, 2021 by HOME AUTOMATION
changed >03 to >6003 for clarity ...above, 0x0000 is loaded at >6000 in GROM(MEDIUM MEMORY)

[HOME AUTOMATION]

1. The WORD reserved for a POWER-UP list address in the GROM HEADER, is at >6004, I simply copied that address from the next word ...reserved for a PROGRAM list address, at >6006(>600F). At >600F is >0000, >60D6.

 

>60D8 is the GPL program's(Multiplan) entry address. I changed it from its original value to >60D6.

 

On 5/21/2021 at 4:04 AM, wolhess said:

And somehow you must have taught the Multiplan module that the second bin file with the system environment is loaded before the main program?

 

So, >60D6, is my GPL program's(only a single 2-Byte instruction) entry address. I had to overwrite the original data/instruction(s) at >60D6(>E4, >70), with >0F, >70. The GPL instruction I am using is >0F(XML), at TABLE >7, PROCEEDURE >0. Table >7 starts at CPU address >6010. Each entry in the TABLE is a one word address vector(branch address), which points to the entry address of the actual procedure(program) >0, being the first(at >6010). At CPU >6010, is the entry address of my assy. code(>7D00). 

 

2. At >7D00, I Switch the WORKSPACE from >83E0, to >B000(32k HIGHMEM), by using(LWPI). I then copy 256 Bytes, from >7000, to >8300(PAD),(using trampoline code). I copied the 256 Bytes, at >7000, from Classic99's, MEMDUMP.BIN, after pausing the DEBUGGER while at the TI's selection menu, and choosing Dump RAM(F10), from the Debug menu. MEMDUMP.BIN can be found in Classic99's main folder.

 

Next I started writing CPU to GRAM trampoline code, in order to restore the two bytes that I had previously overwritten at GRAM address >60D6(E0), >60D7(70). Since the second Byte(>70) was the same, I didn't bother to complete the code, instead moving on to restore the WORKSPACE to >83E0. Later I remembered that I needed to re-write that second byte(>70), in order to have the GPL address register land at the proper GPL entry address(>60D8) when I RETURN. Rather than complete the GPL trampoline code, I simply re-copied the transfer instructions again, as I was doing all this in the HEX-EDITOR anyway.

 

Finally, I RETURN control to the GPL interpreter(Branch *R11). Multiplan starts.

 

Some programs require more initialization than this when starting from a POWER-UP header! Such as setting VDP REGISTERS, and loading of the lower case character set. OMG!

 

I learned most of what I accomplished here from these, some years ago:

 

Standard headers

 

GPL: the GROM language (I) ...XML

 

Part II ...XML TABLE

 

TI Circuit Diagrams ..> ...last two pages(POWER-UP ROUTINE)

 

E/A, 16.4 VDP ACCESS, 16.5 GROM ACCESS.

 

 

             P.S. Gotta go, my shoulder is aching from too much typing.

                     -HA. 

Edited May 23, 2021 by HOME AUTOMATION
Capitalization

[wolhess]

17 hours ago, Vorticon said:

Do you any issue having Multiplan use TIPI mapped drives for the program disk? I can't get it to work....

I can load Multiplan from the mapped tipi drive (DSK1.) and I load the data file from a mapped tipi drive DSK2.

without an issue.

In my tipi configuration I have AUTO=OFF.

 

But I have load and save issues with the Multiplan tabel files when I use the 80 column version.

My 80 column Multiplan only loads an existing table file. I can work with this file and I can save it using the same file name. If I will save a new file it doesn‘t work. 
So I have to use the 40 column version to create a new file or to save an existing file to a new name.

[wolhess]

On 5/22/2021 at 12:48 AM, Vorticon said:

Any reason why Multiplan is insisting on loading from the real DSK1 drive?

I have DSK1 mapped to a TIPI folder and Auto is checked in the TIPI config...

I have always observed this behavior if the program is not found on the assigned TIPI drive. Then the DSR searches for the DSK1 device on other CRU addresses and finds the TI disk controller and my physical DSK1 on CRU 1100.

As a rule, I have just entered a wrong path or file name.