Jump to content
IGNORED

Playground


senior_falcon

Recommended Posts

One way to improve the versatility of this loader would be to pass the name of the file to the loader at >3000. Probably the most direct way is to simply print the name of the file on the screen by adding a line:

15 PRINT "DSK1.PROGRAM23"

Then playground moves the loader over to >3000 and when the loader starts it would read the name from the screen and use that as the file to load.

Link to comment
Share on other sites

Falcon, you are unbelievable...

 

Truly brilliant stuff there, even though I do not 100% understand every element.

 

Sure glad youre here, man. Youve made some pretty excellent contributions, stuff many, including myself, wouldnt have thought possible.

 

I remember unearthing your old XB compiler 6 years ago and making a simple video doing some speed testing. :) Amazing how far we have come in 6 years.

  • Like 2
Link to comment
Share on other sites

I recall instances where DM1000 would not load with certain hardware in the system. I forget the specifics now but I do recall the frustration. Try loading a better program ;)

 

It's a standard TI. The problem is my code, it doesn't work with a 2nd program I tried, either. I can't seem to figure out where the problem is. Or why it would work with Classic99 and not with a standard TI. The drive controller led comes on and stays on, but the drive is not accessed.

 

I took the code to load a file from my HSGPL Menu program, which works fine. Just can't see where the problem is. :(

 

source.txt

Link to comment
Share on other sites

One small step for a frail old man...and my name isn't even Neil. :)

 

I removed the LIMI 2 and replaced it with 2 NOPs with a hex editor per a suggestion by some person not in their right mind. It now works in MESS, which it didn't before. But it still doesn't work on a real TI.

 

Gazoo

  • Like 1
Link to comment
Share on other sites

To aid debugging such things in Classic99, switch to the TI Disk controller. Set up a disk drive as a DSK Image type, quit Classic99, and edit Classic99.ini. The type for that drive will be '2', change it to '3' and restart Classic99. You can actually step through the disk DSR with this active. There are a couple of differences, like the entry point, and the emulator takes over the actual sector access, but these problems happen earlier than that. You can use Thierry's commented disassembly to help walk through the DSR and see what's going wrong.

Link to comment
Share on other sites

BASICloader.dsk

 

I managed to get the source and object code working on a real TI. I made several changes, as well as streamlining the code a little. I also removed the character definitions, since the real program I'm trying to load doesn't need them. What I have so far is included on the attached disk, with the actual program I'm trying to load. No use trying to keep it a secret. :)

 

BUT, I can't seem to convert the loader to a Playground program. :( I get the same results as before. The disk controller led comes on, but the drive led doesn't come on and there's no drive access. Odd.

 

So Mr. Falcon, might you lend your expertise one more time? I would greatly appreciate it.

 

Gazoo

 

 

EDIT: Changing the disk image type from 2 to 3 as Tursi described in the previous post seems to give an accurate representation as to if the program will work with a real TI disk controller or not. A setting of 2 allows my Playground program to work properly, 3 does not - same as a real TI. The object code works in all instances.

Edited by Gazoo
Link to comment
Share on other sites

Remember that types 1 and 2 use a DSR that /I/ wrote, which is not necessarily compatible with the TI disk controller. Unfortunately (or fortunately, but generally un), it's been shown that my code is much more forgiving than the TI unit. ;)

 

You can also turn on "Corrupt DSK RAM", and this will deliberately obfuscate areas of scratchpad and VDP that you should not be touching in order to work with the real disk controller, that can also help isolate the issue. Usually the problem boils down to modifying memory that the TI DSR relies on.

 

If it's still broken, I'll take a peek after work and see if I can figure out what's up for you. I've bumped into this enough times myself, that's why those other features are in there. ;)

Link to comment
Share on other sites

Remember that types 1 and 2 use a DSR that /I/ wrote, which is not necessarily compatible with the TI disk controller. Unfortunately (or fortunately, but generally un), it's been shown that my code is much more forgiving than the TI unit. ;)

 

You can also turn on "Corrupt DSK RAM", and this will deliberately obfuscate areas of scratchpad and VDP that you should not be touching in order to work with the real disk controller, that can also help isolate the issue. Usually the problem boils down to modifying memory that the TI DSR relies on.

 

If it's still broken, I'll take a peek after work and see if I can figure out what's up for you. I've bumped into this enough times myself, that's why those other features are in there. ;)

 

Strangely, it's your program I'm trying to load. :)

 

The problem at this point seems to be created during the conversion of the object code to a BASIC program, since the object code always works and the BASIC program works with everything except a real TI Disk Controller. I tested it with a real HFDC and real Myarc FDC and it worked ok with them.

 

You might want this if you're going to test this out, it's the BASIC Playground program I came up with.

 

BASICLOAD.zip

 

Gazoo

Link to comment
Share on other sites

One small step for a frail old man...and my name isn't even Neil. :)

 

I removed the LIMI 2 and replaced it with 2 NOPs with a hex editor per a suggestion by some person not in their right mind. It now works in MESS, which it didn't before. But it still doesn't work on a real TI.

 

Gazoo

NOP'ing a LIMI 2 isn't the same as disabling interrupts with a LIMI 0 ;) If interrupts are enabled in the GPLWS workspace then the moment you execute the DSRLNK code segment that runs from GPLWS (i.e., at the point the code encounters the LWPI GPLWS), the console may interrupt you where you least desire it. I'm not saying this is the problem but it can't hurt to rule it out. Can you trace this in Classic99? Also, keep in mind the TI card relies upon R15 and uses VDP heavily. Edited by InsaneMultitasker
Link to comment
Share on other sites

Here you go:

GAZOOLOAD is the BX program that moves the loader to >3000 and starts it up. There is one character that is not the same-don't know why. Your loader is correctly loaded when running GAZOOLOAD.

 

If you want to make changes all the files needed to recreate a modified GAZOOLOAD are in here:

PGLoader.txt and .obj is the assembly program for playground

CPUVDP.txt and .obj is the assembly program that moves your loader from >3000 to the buffer in GAZOOLOAD

MAKEBX-O is used to embed the assembly program in the BASIC loader

 

Pretty much just follow the process I described earlier.

 

GazooLoad.zip

Link to comment
Share on other sites

Here you go:

GAZOOLOAD is the BX program that moves the loader to >3000 and starts it up. There is one character that is not the same-don't know why. Your loader is correctly loaded when running GAZOOLOAD.

 

If you want to make changes all the files needed to recreate a modified GAZOOLOAD are in here:

PGLoader.txt and .obj is the assembly program for playground

CPUVDP.txt and .obj is the assembly program that moves your loader from >3000 to the buffer in GAZOOLOAD

MAKEBX-O is used to embed the assembly program in the BASIC loader

 

Pretty much just follow the process I described earlier.

 

 

This version gives the same results as the one I put together. It doesn't work with a real or emulated TI Disk controller. Tested in Classic99 with TI Disk controller enabled and on real TI. I get the same results as before, card led comes on - drive not accessed. It's strange that it works as object code, but not as a BASIC program.

 

I'm guessing that it has something to do with scratchpad, I may try rewriting scratchpad with the values after the object code is loaded with the EA cart, I had to do that trick to get one of the games on the 2meg game compilation cart to run. Can't think of anything else not allowing this to work.

 

Gazoo

Link to comment
Share on other sites

I'm guessing that it has something to do with scratchpad, I may try rewriting scratchpad with the values after the object code is loaded with the EA cart, I had to do that trick to get one of the games on the 2meg game compilation cart to run. Can't think of anything else not allowing this to work.

 

Gazoo

Yep, that's it. Playground overwrites the scratchpad from >834A to around >83D8. When you are in BASIC, >8370 contains >37D7 which is used by the disk controller. With luck just restoring >8370 to the proper value might do the trick. If this works, you should check that the CF7 doesn't put a different value there - as I recall, it is 4 bytes lower. If that doesn't work, there's a way to do CALL FILES(3) from assembly if your DSRLNK supports that. If none of these work simply restoring the scratchpad should work.

Link to comment
Share on other sites

That word at >8370 is very important to the disk controller - that's how it finds the file buffers.

 

I'll see what I can find out here. :) I didn't play with Playground yet as much as I wanted to, but I'm sure we can get it going, you're just copying the loader to memory expansion in the end, right?

Link to comment
Share on other sites

That word at >8370 is very important to the disk controller - that's how it finds the file buffers.

 

I'll see what I can find out here. :) I didn't play with Playground yet as much as I wanted to, but I'm sure we can get it going, you're just copying the loader to memory expansion in the end, right?

That's right. The loader has first been loaded to >3000, then copied from there and embedded in the TI BASIC program. The playground program just finds the start of the buffer in VDP and copies the program back to >3000, then starts it up. I think that doing CALL FILES at the beginning of Gazoo's loader (at >3000) is the way to go. As I remember it doesn't take much code to make that happen. I can get my notes out tonight on how to do that, but I bet someone will beat me to it!

Link to comment
Share on other sites

That might be enough... it might not be. I'll check if CALL FILES needs that memory address to be correct before it's called (I'm starting in like 2 minutes here). But CALL FILES from ASM is pretty easy - I used this in my slideshow app (hard coded to 1 file) and it seems to work on CF7 hardware. It's probably a little /too/ hard coded (assumes 1 file, assumes >1100 CRU disk controller), but we can expand that if needed.

 

 

* We need to implement a CALL FILES(1) before use to make loading work better
* That puts the top of VRAM at >3BDB.
FILES
 MOV R11,@SAVE  * save return address, assume DSR trashes everything
 
 LI R0,>0100
 MOVB R0,@>834C  * 1 file desired
 
 LWPI >83E0   * GPLWS
 LI R12,>1100  * We assume the disk base since this is intended for the CF7 anyway
 SBO 0    * turn on the ROM
 MOV @>400A,R1  * get pointer to the subprogram list
FILELP
 JEQ FILEDON   * no subprograms
 MOV *R1+,R3   * link to next item
 MOV *R1+,R2   * address of this one
 MOV *R1+,R0   * we are looking for length 1, name >16
 CI R0,>0116
 JEQ FILEGT
 MOV R3,R1   * nope, get next
 JMP FILELP
* Found it
FILEGT
 BL *R2    * go ahead and call it
 NOP     * skipped on success
FILEDON
 LI R12,>1100  * We assume the disk base since this is intended for the CF7 anyway
 SBZ 0    * turn off the ROM
 LWPI >8300   * our own WS back
 
 MOV @SAVE,R11  * get back return address, no telling what the DSR did
 B *R11
Link to comment
Share on other sites

The internet ate my whole post, lovely. ;)

 

To recap it - writing the top of VRAM to >8370 before starting the DSRLNK does in fact work!

 

So, the trick of how to find the top of VRAM. Unfortunately we can't save it before the jailbreak overwrites it.

 

I think it might be enough to check just two possibilities. There's a header written at the beginning of the VDP buffer space. Assuming there is only one set of disk buffers (which I believe is true for all disk controllers, including systems with disk and RAMdisk. Not sure about hard drives), then our only variants are CF7 and TICC style. We can safely assume 3 files by telling people they must run the loader as the first and only thing they do in TI BASIC. ;)

 

With that assumption, there are only two possibilities: >37D7 (TICC) and >37D1 (CF7). Add one and check VDP RAM for >AA - that's the signature byte. To be extra sure, add four to that, and check for >03 (number of files). If you get a match, that's the correct top of RAM. Write the original value into scratchpad at >8370 and it should work.

 

If you don't find either, the DSR doesn't use VDP RAM. Classic99 works like this, and though I heard of others that did (like the IDE controller), I think the others fake up VDP RAM so it looks normal. Anyway, for that case, I'd say to treat it as TICC mode and set >37D7.

 

If you want to be more flexible and try to search VDP, Thierry's notes are here, about halfway down: http://www.unige.ch/medecine/nouspikel/ti99/disks2.htm

 

I didn't see much that looked promising for being /really/ flexible, though, I'd probably go with the two addresses version.

 

 

Link to comment
Share on other sites

(as an aside.. an EA#5 loader from TI BASIC. How this would have killed back in the day.... ;) )

When the McGoverns developed Funnelweb the intention was to make it independent of whatever cartridge was in the slot. If this existed then you can be sure they would have had an option to load it via BASIC.

  • Like 2
Link to comment
Share on other sites

Would be opened so many doors... an unexpanded console would have stopped being a limitation... ah well, would have, should have, it's still awesome to me to see it broken, every single time.

 

Here's my patched version of GAZOOLOAD. I didn't want to rebuild everything, so this is just a proof of concept. I've tested against the TICC, can someone test it against a CF7 card? If it works, Gazoo, you can incorporate the concept, hopefully.

 

gloadpatch.zip

 

I didn't want to rebuild the application, but it looked like the workspace was safe to overwrite before it was switched in, so that's what I did. This is a tiny little patch that sits in the first workspace and runs before the LWPI (ie: still using GPLWS). It checks only >37D2 for the >AA byte, and sets >8370 accordingly.

 

 

 

* patch for gazoo's playground loader
* still at WP >83E0
* VDPWA in R15, that helps 
* We cheat - test for CF7 with >AA first, and if fail,
* assume TICC. This is to keep the patch tiny.
* Patch overwrites the program workspace.
* also remember to patch the B @>3042 to B @>3022
* this is only proof of concept, the final needn't
* be patched.
 
 AORG >3022
 CLR R0
 LI R1,>D237  * 37D2 swapped
 MOVB R1,*R15
 SWPB R1
 MOVB R1,*R15  * and now it's in the right order! 
 MOVB @>8800,R0  * get byte
 CI R0,>AA00  * is it AA?
 JEQ YAYSAV

 LI R1,>37D8  * 37D8

YAYSAV
 DEC R1
 MOV R1,@>8370  * save value

* roll into >3042 and continue running

 

 

 

At first I worried that the data bytes under the disk buffers might be unpredictable, but then I realized that they are /actually/ the end of your program! So the odds of false positive checking the CF7 first are zero -- or at least, under our control. This also means that sticking a unique string in there might make it possible to have a universal search for the top of VRAM without the risk of false positive... I guess it depends on whether the simple approach works in practice. ;)

Edited by Tursi
Link to comment
Share on other sites

If you don't find either, the DSR doesn't use VDP RAM. Classic99 works like this, and though I heard of others that did (like the IDE controller), I think the others fake up VDP RAM so it looks normal. Anyway, for that case, I'd say to treat it as TICC mode and set >37D7.

Other cards will usually fake the VDP header, particularly the "AA" and the CRU MSByte as some programs look for it to determine disk controller availability and address. Some programs rely upon 0x8370 to configure buffers (i.e., FunnelWeb) while others just use the value as-is to out-smart the system to their own ends. There are other VDP "tricks" folks like Bruce HArrison used for boot tracking and last file accessed routines, though many broke when Myarc eliminate the VDP dependency.

 

Nice catches by you and Sr. Falcon!

Link to comment
Share on other sites

Cool! Thanks everyone for their help with this! It works as intended, with all disk controllers (at least with the ones that I have).

 

Here's why it was so important to do this. Since GROMCFG was released, it's been possible for someone to brick their Extended Basic v2.7 Suite cartridge. And naturally, it happened. The only available way to reload this particular cartridge is through TI BASIC, because that's all you get as a menu option with a bricked cartridge. The problem has now been been addressed.

 

I just verified that it works by intentionally bricking an Extended Basic v2.7 Suite cartridge, and restoring it using the Playground program we've been working on. My needs have been met.

 

But perhaps more importantly, we now have a way to load EA5 files from TI Basic with no cartridge. I woulda never thunk it possible. Thanks guys!

 

Here's the working source I have, included is Tursi's patch. I'm sure it can be expanded to make a universal EA5 loader, which would be really cool.

 

Gazoo

 

source (1).txt

Edited by Gazoo
  • Like 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...