Load Interrupt Driven Screen Saver for Real Iron?

[Omega-TI]

I've heard mention of a program that can be loaded into memory and when the load interrupt button is activated (like on Tursi's PS/2 adapter) will then take a screen shot and save it to disk. The thing is, I have no clue where to get this program. Does anyone have a copy that they can attach to a message here or leave a download link?

 

ThanX!

[sparkdrummer]

Just so you know, I've been looking in the pile, just haven't found it yet. It seems to me one of them saved it off in a 10 sector file?

conTInuing,

Ralph

[Omega-TI]

I've been looking in the pile, just haven't found it yet.

 

Cool, I'm looking forward to getting a copy of this as it would be a VERY HANDY utility to have. Thanks for looking.

[Tursi]

I suppose we could write one quickly enough.. there are a couple of caveats though:

 

First: did you mean for graphics mode (ie: BASIC mode), text mode (40 column), or bitmap mode? One of the limitations of the 9918A is there is no way for the CPU to ask it what mode it's in or where the screen is located. MOST apps that use graphics mode place the screen table at 0, so that is a reasonably safe (but not guaranteed) assumption, you can assume the same for text (less often though). None of this includes color or pattern information, just text.

 

The last trick is bitmap mode. With bitmap you know where the two major tables are (color and pattern), although not necessarily which is which. You can safely assume most of the time that it's in sequential order, at least.

 

Soooo.. what do you need to capture there?

[Omega-TI]

Hmm, well I was hoping for a routine I could execute before running video games, so I could have proof of high scores in games like Road Hunter, which I was over 78, 000 the other day, but I lack the proof. Being able to press F11 on the PS/2 keyboard would have been nice. Without proof, it's just another fish story.

 

AWESOME TURSI! This will be yet another reason people will NEED your keyboard mod. BTW - I'm loving mine!

[+arcadeshopper]

yeah i have this program too, dunno where though so will take some disk searching

[+Schmitzi]

Hi, do you know the exact name (or a part) of the prog ?

[Tursi]

Maybe we could just dump all of VRAM and then use an external tool to parse it -- at least that way we get more than one try at decoding it. 16k is a fair bit of data, but it would only take two SAVE calls. That seem fair?

 

There's one other caveat - there's a good chance of crashing the console when you hit the key. For it to work reliably, the LOAD hook itself can't have been overwritten (reasonably safe), the code that does the work can't have been overwritten (will take some thought about where a safe place to drop it is... supercart RAM would work in most cases?), and the running program must not be in the middle of a VDP operation, because the address will be changed (there's no way to read the address back).

 

I'll play with it this weekend if the tool doesn't turn up and suit your needs.

[Omega-TI]

Thanks Tursi! I'm sure whatever you decide will be the best approach. Just let me know which program I'll need to obtain to view the saved images. The Super Cart angle does sound like the most promising approach.

 

You know, it's a crying shame the UberCart cannot be merged with a SuperCart into one package, that would just be too damn awesome.

[Tursi]

Here's my first pass at it, and it's working in emulation.

 

screencapWIP.zip

 

In the ZIP is the TI side - use EA#3 - DSK1.VDPCAP to load, and program name START to install the hook. Now, as long as nothing messes with upper CPU RAM (where the vector is) or lower CPU RAM (where the program hides, right in the middle), the load interrupt will trigger a save of all VDP data to disk with the filename "DSK1.VDP_A". The last letter will increment every time you save (but note that each save takes 16k of disk - an SSD can only hold 5 saves).

 

There are LOTS of caveats because LOAD is a non-maskable interrupt, meaning you can literally interrupt anything the computer is doing. The most important one is that every time you press it, expect the computer to crash after the save is done, and be thrilled if it doesn't. For that matter, it may crash BEFORE the save is done if the program corrupted the loader, but most of the stuff I tested left it be.

 

The second most important one is NEVER interrupt a file operation - you can corrupt the entire disk. I'd recommend using a disk or disk image /specifically/ for saving. (I suppose HDX operations might be safer, mind ).

 

Since it's not a TSR but a hardware vector, it's not affected by resets (it is affected by power off, of course). In theory you can even change cartridges, if you don't power down, but in practice I don't recommend it. The TI carts might have been robust, but I killed an Exceltech XB back in the day by demonstrating hot swap.

 

There's no tool yet for reading the memory dump (although I thought someone did one for reading the Classic99 memory dumps??) Anyway, my vision for that is a little viewer window, a bunch of toggle buttons for cycling through the options for video mode and each register's base address, and a drop list of common configurations (like TI BASIC, Editor/Assembler, Bitmap Pattern first, Bitmap Color first, etc), to help quickly figure out the correct video memory layout. Then a button to save as BMP. (This all means you still need to get the capture file to the PC).

 

The ZIP includes two sample dumps from Classic99. I tested with the TI controller and it seems to work, so, give it a shot and see if this much is going.

 

[Omega-TI]

Tursi, U DA MAN! --- 100K THANKS!

I'll let you know the results later, hopefully later this evening, but unfortunately I have leave in 10 minutes.

Don't ya just hate it when responsibilities in the way of TI play?

[Tursi]

Story of my life. Need a way to make income off retro gear.

[Omega-TI]

Hi Tursi, I just wanted to let you know that with any luck I'll be trying it out tomorrow. I would be doing it right now, but I'm I'm on "Mom Duty" today. In fact as I write this message, I'm sitting in a beauty salon (the first of seven stops) listening to a bunch of judgmental old biddies complain about everything. Thank you WiFi!

[Omega-TI]

Here's my first pass at it,...

 

Okay, this is what I've been able to do so far on the real deal...

 

I can get it run using my Super Cart's E/A, but for some reason it's a no go using the E/A in the XB2.7S cartridge.

 

As you said, the computer does pretty much lock up after you enable the save. It will repeatedly save incremented files as VDP_A, VDP_B and so on until manually stopped.

 

I know you said their is no way to view the dumps, too bad. In the mean time I'm here for further testing and hopefully viewing.

[Tursi]

There is absolutely nothing magical about the program that would cause alternate loads of Editor/Assembler to have issues, except that it loads into the middle of low memory. What does "no go" mean? What /actually/ happens?

 

When you say "repeatedly save", do you mean continuously without pressing LOAD again?

 

And please POST one of the saves so we can do something with it. I wasn't going to write a viewer until something was done and the dumps seen to work.

[Omega-TI]

There is absolutely nothing magical about the program that would cause alternate loads of Editor/Assembler to have issues, except that it loads into the middle of low memory. What does "no go" mean? What /actually/ happens?

 

When you say "repeatedly save", do you mean continuously without pressing LOAD again?

 

And please POST one of the saves so we can do something with it. I wasn't going to write a viewer until something was done and the dumps seen to work.

 

I'll do some more testing after work tomorrow, and take some notes, possibly even video so I can make a more detailed and accurate report.. Right now I'm tired and have to get up in 6 hours.

 

However no go means no attempt at a save. Yes, repeated incremented saves WITHOUT pressing load again.

 

Okay, tomorrow evening I'll post a few saves.

 

L8R

[Tursi]

Don't need screenshots or video or any of that, those are just 'nice to haves', for sure, and only if there is anything to see. (Video especially I have a lot of trouble viewing right now). But when you give a bug report, you do have to say more than "didn't work". It's almost never to useful to say what did not happen - something always does - if that something is wrong, that's the report a developer needs.

 

In this case, it loads successfully, but does not trigger, when loaded from the EA in the XB27 cart - that's the definition of "no go" that I needed. (Sounds like something is overwriting the vector, easy to check.)

 

When loaded from EA, you press load once, and it saves continuously. That one I didn't expect -- I will double check how the interrupt works, it sounds like it's retriggering a couple of times. (So when it tries to 'return', it ends up back at the beginning of the function again). Hopefully an easy fix.

[Tursi]

I was not able to reproduce the issue with XB27 under emulation, maybe with more precise steps I could? Also I only tested with the NOMENU version for now (although I did select the menu and select the E/A from there.)

 

The looping saves is a design flaw on the keyboard controller, I fear. I did level triggered GPIO since I wasn't sure what to use it for, and I figured I'd just leave it open. However, LOAD is also a level-triggered interrupt, which means that after every instruction, it re-triggers for as long as you hold the key (in this case). The TI doesn't have a return stack, it just stores the address in a register, which means that the second time the interrupt triggers, it overwrites the original return address with the entry point to the VDP dump function.

 

I was able to simulate this in Classic99 and I have a solution that I think will work. As far as I understand the datasheet, the target address has exactly one instruction to run before the interrupt is checked again - usually you would disable interrupts there, but LOAD doesn't care if interrupts are enabled or not. So I got tricky, and that one instruction replaces the workspace in the vector, so when it retriggers (unless you can hold a key for exactly 1 instruction ), the second jump gets stored in a dummy location. When you finally release the key and it stops triggering, the code then just reloads the first workspace, which contains the true return information. (There's also a brief delay of a second or so after the release, just in case of key bounce, before it starts).

 

Unfortunately, even if this works, it doesn't mean that other LOAD triggered programs will, unless they have a workaround for repeated calls. I think I can probably fix this in the AVR (a short pulse instead of a level) and I've saved a note, but I wouldn't be able to test it.

 

Anyway, try this version, it should save exactly once per press, and in many cases may return to the calling program. It all depends on what the caller was doing, and whether a VDP interrupt sneaks in before I turn those off (though that sometimes works too ) Anyway, still no guarantee of safe return, but best effort.

 

screencapWIP2.zip

 

 

[Omega-TI]

 

Anyway, try this version...,

 

screencapWIP2.zip

 

 

 

 

Thank you Tursi!

I'll check this out after work and let you know how it works and send you the saves as well.

[+mizapf]

@tursi: Yes, this is the proper way to handle LOAD; I did that in some occasions as well, and I believe I learned it from some article in Micropendium; I don't remember who came up with this solution originally, though.

START  CLR  @>FFFC
       LWPI WS
       CLR  R0
LOOP   DEC  R0
       JNE  LOOP
       LI   R0,WS
       MOV  R0,@>FFFC
       ...
       AORG >FFFC
       DATA WS,START
       END

There's another loop behind to ensure that the LOAD switch has been released.

 

[Tursi]

Thanks, mizapf. It's actually cool to know that people were already dealing with that in software instead of hardware.

[Omega-TI]

 

screencapWIP2.zip

 

Okay using the Super Cart

 

First Capture..........TI Menu Screen......................................................... NO CRASH

Second Capture.....TI Selection Menu...................................................... NO CRASH

Third Capture........ Directory of DIsk from 4A/DOS (40 Column mode)... NO CRASH

Fourth Capture...... Directory of Disk from 4A/DOS (80 Column mode)... NO CRASH

 

Attempted saves with TI Scramble & Road Hunter - CRASHED both times with no visible attempt at a save.

 

Screen captures included on the disk image below.

 

If you have anything you want me to check, just ask, I'm at your disposal.

Results.zip

[Asmusr]

As far as I remember TI Scramble and Road Hunter are using all of the RAM both upper and lower and might even be overwriting >FFFE and >FFFF, so there is nowhere to put the screen saver code.

[+mizapf]

By the way, here is a hardware solution for using the LOAD interrupt, taken from "9900 Family Systems Design", page 4-62.

[Tursi]

Yeah, that's what the datasheet suggested too (though no picture. ) Using that would still work even if the workaround is in place, which is nice

 

And yes, TI Scramble and Road Hunter both overwrite the program lower RAM - it's not that the vector is gone, it's that the program the vector jumps to is.

 

(That gives me an interesting idea for using the LOAD interrupt for game cheats, like level skips and stuff - just set the vector to the 'next level' address of a game...)

 

We could make a supercart version, I guess (just change the AORG), but the only copies of Scramble and Road Hunter I have are carts, so they already live in that memory space too. We'd have to poke around and make a special version that fits in whatever free space may exist.

 

Which leads to the second point you brought up. I had not planned to include the F18A graphics extensions in the RAM viewer.. the sheer number of possible combinations was already pretty bad, it grows to insane with that (and I don't have draw routines for the F18A yet... maybe JS99's routines can be adapted into an offline viewer instead? But I can't do it.)

 

Well.. we'll see where it goes. We'll start with the basics.