Running E/A #5 from Extended BASIC loader

[+adamantyr]

Hey guys. Need some help with this one...

 

In particular, this one is focused on the internals of Extended BASIC, So I know we have some guru's around here on the subject. (Hey Rich!) I'm disappointed that the TI Tech pages fail to have any memory dumps or extensive exploration of the Extended BASIC cartridge.

 

I forget where I got it from, but I found this method long ago to execute the start of an EA option #5 program through Extended BASIC:

100 F$="DSK1.PROG" :: ON ERROR 200
110 CALL INIT :: CALL LOAD(8196,251,214) :: CALL LINK("OPT5",F$)
200 PRINT "DEVICE ERROR!":"CORRECT AND PRESS A KEY"
210 CALL KEY(0,K,S) :: IF S=0 THEN 210 ELSE RETURN 100

Clearly it's linking to some subprogram that's part of Extended BASIC's initializations called OPT5... I'm not sure why it's loading >FBD6 to >2004, but I presume it's over-writing a utility vector of some kind, the value there upon INIT is >4000 initially.

 

Anyway, this method works fine with most option 5 programs, but fails with my CRPG loader.... Probably because I'm placing my load program in low memory. I have it at the >3000 mark, so it should be preserving the part of low RAM it needs, but it still fails and just cycles endlessly.

 

Can anyone describe exactly what the above routine is doing, and if there's anything I can do to make it work? I could see the XB utility only working in high memory, so I suppose in that case I'll just have to embed the assembly code using SYSTEX and execute it directly...

[RXB]

Well RXB GPL source code is the Extended Basic sources if you go and delete all the RXB sections (I always label them) you could have a XB original source.

 

Also now we have the XB ROM source code too.

 

So this request for a dump of XB confused me?

Edited November 14, 2017 by RXB

[senior_falcon]

Hey guys. Need some help with this one...

 

In particular, this one is focused on the internals of Extended BASIC, So I know we have some guru's around here on the subject. (Hey Rich!) I'm disappointed that the TI Tech pages fail to have any memory dumps or extensive exploration of the Extended BASIC cartridge.

 

I forget where I got it from, but I found this method long ago to execute the start of an EA option #5 program through Extended BASIC:

100 F$="DSK1.PROG" :: ON ERROR 200
110 CALL INIT :: CALL LOAD(8196,251,214) :: CALL LINK("OPT5",F$)
200 PRINT "DEVICE ERROR!":"CORRECT AND PRESS A KEY"
210 CALL KEY(0,K,S) :: IF S=0 THEN 210 ELSE RETURN 100

Clearly it's linking to some subprogram that's part of Extended BASIC's initializations called OPT5... I'm not sure why it's loading >FBD6 to >2004, but I presume it's over-writing a utility vector of some kind, the value there upon INIT is >4000 initially.

 

Anyway, this method works fine with most option 5 programs, but fails with my CRPG loader.... Probably because I'm placing my load program in low memory. I have it at the >3000 mark, so it should be preserving the part of low RAM it needs, but it still fails and just cycles endlessly.

 

Can anyone describe exactly what the above routine is doing, and if there's anything I can do to make it work? I could see the XB utility only working in high memory, so I suppose in that case I'll just have to embed the assembly code using SYSTEX and execute it directly...

There is more to this XB program than meets the eye. What you don't see is the embedded assembly routine. CALL LOAD(8196,251,214) tells the CALL LINK routine that the subprogram name table starts at >FBD6 and if you look there using Classic99's debugger you should see OPT5, two spaces and the address where OPT5 starts. I'm guessing it copies assembly code from high memory into low memory and then runs it from there, but it also is possible that the assembly code runs directly from high memory.

 

Getting this to work for you would be tricky. You'd probably have to disassemble the code to see what it does and then jigger things so it is loaded and run from a location that does not disrupt your own code. It might be easier to just rewrite the code.

[RXB]

With so many XB versions and only a few that can run anything even C or Assembly EA5 or EA3 I recommend you pick a updated XB cart like RXB or another similar XB with these features.

 

RXB 2017 will have CALL EA("DSK.VOLUMENAME.FILENAME") that will see if the file is EA3 or EA5 and automatically load the proper version.

(I will use a section of RXB CALL CAT that looks for the file attributes and decide what loader to use.)

(I should mention "DSK#.FILENAME" will also work.)

 

RXB 2017 will also have CALL XB("DSK.VOLUMENAME.FILENAME",1) this will run XB programs and does a CALL FILES(1), NEW then RUN "DSK.VOLUMENAME.FILENAME"

Yes you can finally have CALL FILES(0) if you want or up to CALL FILES(15) of course the XB program could only be 1 line long.

[+adamantyr]

There is more to this XB program than meets the eye. What you don't see is the embedded assembly routine. CALL LOAD(8196,251,214) tells the CALL LINK routine that the subprogram name table starts at >FBD6 and if you look there using Classic99's debugger you should see OPT5, two spaces and the address where OPT5 starts. I'm guessing it copies assembly code from high memory into low memory and then runs it from there, but it also is possible that the assembly code runs directly from high memory.

 

Getting this to work for you would be tricky. You'd probably have to disassemble the code to see what it does and then jigger things so it is loaded and run from a location that does not disrupt your own code. It might be easier to just rewrite the code.

 

Yeah, I did look in the debugger and there is nothing at that address at all following the INIT or the LOAD command. Nor can I find any trace of an OPT5 label anywhere in memory or in the Extended BASIC binaries.

[RXB]

 

Yeah, I did look in the debugger and there is nothing at that address at all following the INIT or the LOAD command. Nor can I find any trace of an OPT5 label anywhere in memory or in the Extended BASIC binaries.

LOL that is a sign that someone loaded it and saved it with XB using SAVE "DSK1.PGM" so the Syntax part was not copied.

[Tursi]

I have an EA#5 loader for XB that was based on the Scratchpad loader a group of us collaborated on over at Yahoo a few years ago. Our belief is that it should load darn near anything (that EA can), as it has no 32k memory constraints at all (once the first DSRLNK call is made, it's running from scratchpad). You can give it a try: http://harmlesslion.com/software/loader

 

Source is included

Edited November 14, 2017 by Tursi

[+adamantyr]

I have an EA#5 loader for XB that was based on the Scratchpad loader a group of us collaborated on over at Yahoo a few years ago. Our belief is that it should load darn near anything (that EA can), as it has no 32k memory constraints at all (once the first DSRLNK call is made, it's running from scratchpad). You can give it a try: http://harmlesslion.com/software/loader

 

Source is included

 

Precisely what I was looking for, thanks!

 

P.S. Worked like a charm too!

[+jedimatt42]

I have an EA#5 loader for XB that was based on the Scratchpad loader a group of us collaborated on over at Yahoo a few years ago. Our belief is that it should load darn near anything (that EA can), as it has no 32k memory constraints at all (once the first DSRLNK call is made, it's running from scratchpad). You can give it a try: http://harmlesslion.com/software/loader

 

Source is included

I've been working on adapting this to run as CALL TIPI("TIPI.TIPICFG") from my DSR ROM. But, from TI BASIC, not XB.

 

So from the scratchpad_loaderXB, I've borrowed all the code that sets up VDP, I've added code to just make sure the ISR space is in a safe state (no user ISR, and default flags)

LIMI 0 is in play.

 

I've gutted the DSRLNK calls in favor of internal routines in my DSR ( since I'm already in there, and one DSR cannot LNK to one in a different ROM anyway... )

I have it working to the point that it loads the programs into memory perfectly, but it won't launch them.

 

I stay in ROM except to run SBZ 0, LI R12,>0000, B *R9 ( where R9 holds the address from the first file loaded, in GPLWS )... So I copy that code up into scratchpad at >8380 and B @>8380

 

This turns off my DSR, clears R12 and then jumps to the loaded code.

 

Some programs just show me a green screen. My own code in TIPICFG runs to a point, but when it gets to user input, it just starts making a tone, and pressing keys changes the tone... there should be no tone.

Launching it from EASY BUG after resetting works fine.

 

If I have the EASY BUG cart in, I can reset afterwards, then go in and for instance run EA000 to launch for instance PARSEC after it was loaded. Works great!

 

Is there something different about the TI BASIC environment I need to account for?

 

---

 

I've been doing the setup code, then loading the program images, then setup scratchpad, and launch... but I think it shouldn't matter if I just load first before performing the vdp setup... So I'm going to try a varient, that just does the VDP setup, scratchpad cleanup, and launches A000. Then I should be able to debug in Classic99 with a program previously loaded by EA.

I burned about 18 eproms yesterday testing/debugging... mostly thrashing back and forth...

 

---

 

-M@

[+jedimatt42]

Well... the debugging technique is working... My DSR and EA'grom are defined together as a cart. With a breakpoint set to the loaded program's launch address, I can warm-reset classic99, then go into BASIC, and CALL TIPI("...") and step through things... since I don't have to interact with the real TIPI hardware by commenting out the disk IO in my CALL TIPI routine...

 

It still doesn't work... DM2K draws itself up nice, but it looks like once it goes into keyboard input, it just goes nuts... It gets stuck in a part of the console ROM that ti-intern labels as "negative interpreter code" branching back to >00C0 all the time.

 

I'll just try fixing up scratchpad ram next, comparing GPLSWs, and ISR workspace... Any other parts of scratchpad that control program flow? Zero'ing out scratchpad is probably necessary... I see my WP is still 8300 which is unusual when in the ROM code. So time to build a 'control' program, and step through it.

 

-M@

[+Lee Stewart]

... It gets stuck in a part of the console ROM that ti-intern labels as "negative interpreter code" branching back to >00C0 all the time.

-M@

 

The original TI programmers called that section “INSTRUCTIONS WITH A & B OPERANDS”. >00C0 is the B-operand section. You may know that this area is very near the beginning of the GPL Interpreter and I should think its WP should be GPLWS (>83E0) not >8300 if you got there on purpose.

 

...lee

[Tursi]

The scratchpad loader didn't have any language restrictions... in fact the XB code is an adaptation of the original E/A code. But the fact that it fails from a BASIC environment is surprising.

 

The symptoms you describe SOUND like scratchpad corruption on the surface -- something tried to call a console ROM routine that expected scratchpad to be intact. I guess keyboard would count for that... though I'm not sure why we didn't have that problem elsewhere. Try restoring a valid-ish GPLWS (or at least R12-R15) at the beginning of execution (you can breakpoint and do it in the Classic99 debugger) just to see if it makes any difference?

 

The same program/loader works okay from the XB loader? Double check scratchpad usage too. I used IIRC every single byte marked as "safe" in the E/A manual, but that doesn't mean they were safe for TI BASIC. Also, the code relies on starting up in memory expansion with lots of room to get ready for the jump to scratchpad, so make sure those assumptions aren't biting you (ie: running from ROM?)

[+jedimatt42]

Eventually I found that it the console ISR eventually causes a B to >0000, which is just crazy talk, since there is no code there, just vectors.

 

I'm coding with a fever ( as in winter head cold ) so instead of finessing my way through initializing the ISR space, I did brute forced it. I used classic99 to write down the state and code it into my ROM. In GPLWS, I set R12-R15, and all of >83C0->83DF

 

and now my gcc apps load and run, DM2K worked... AMBULANCE loaded, but I still hear a difference, an off pitch sound. and PARSEC crashes shortly after the title screen... The important one is my TIPICFG tool... that is working.

 

But I'll keep gnawing away at the scratchpad state. I'd like to get it perfect-ish... LOL... I'll double check that the code I kept isn't expecting to write to itself, and double check the 'safe-ness' of where I'm stuffing my launch code in scratchpad... Sounds like a good reason to get the EA binder out!

 

Thanks for the insights!

 

-M@

[Tursi]

Sorry I can't give you more immediately... let's see if I can track down the original thread. Maybe starting from the non-XB version is better...? (Although maybe not, the EA version relies on the EA utilities to start up).

 

(No, I can't, since I deleted my Yahoo account and the SWPB group, where I think we developed it, is restricted.)

 

But here's the original E/A loader - this version WAS working from TI BASIC with Editor/Assembler.

 

 

scratchloader.zip

[+InsaneMultitasker]

Just a shot in the dark here - you said you wrote down the state of 83c0-83df. Are you loading 0x83c4 with something other than 0x0000 thus inadvertently calling the user interrupt routine via the console interrupt processing routine?

[+jedimatt42]

My early attempts were to zero out the user interrupt explicitly, but then I switched to copying in this block of data:

A83C0
DATA >2517,>0000,>0000,>0204 -- Random number seed >2517, 4A interrupt flags >0000, 4A User Interrupt routine >0000, default key type >02, key columns >04
DATA >05FF,>FF00,>0484,>0000 -- 3 more bytes of keyboard noise, VDP sound list >0484, sound list flags >0000
DATA >1100,>4070,>E000,>000A -- Search pointers for GROM and ROM...
                                looks like CRUBASE of DSR, and address in DSR of last found loader... those are wrong for TIPI... but shouldn't matter.
                                then we have VDP Register 1, and screen blank timer... Maybe I should set that to a higher value just to be safe.
DATA >0070,>83E0,>0074,>D002 -- these last four don't make much sense to me... 

Once things are working solid, I should stop setting the Random number seed... Or gaming from TIPI might get boring.

 

-M@

[Tursi]

I dug around TI Intern a bit, and also set some breakpoints in Classic99 to watch operation...

 

Looks like >83D8 is used for scratch return storage (for instance, KSCAN stores a return address there at >02B2). >02AE explicitly loads >0070 as part of GPL SCAN to force return to GPL.

 

>83D0 is also the interrupt workspace, so the other values you are seeing there probably came from the console interrupt call (>83E0 - calling workspace, >0074 - return address, >D002 - calling status register).