Jump to content
IGNORED

Does anything use LOAD* and IAQ at the side port?


brain
 Share

Recommended Posts

The only real use for LOAD and IAQ I've seen was to implement hardware single step debugging capability.

A debugger program sets up a shift register, which shifts through a suitable number of IAQ signals, then generates a LOAD (non-maskable) interrupt. The "suitable number" of instructions was chosen to give the debugger what's needed to call the user's program and execute exactly one instruction there, then interrupt back to the debugger to observe the result.

 

The debugger delivered with the Editor/Assembler package actually supports this, but the hardware isn't there in a standard TI 99/4A. It probably is in a TI 990.

Edited by apersson850
  • Like 2
Link to comment
Share on other sites

I once made use of the LOAD interrupt - in my Speecoder tool. The idea was to allow for swapping the cartridge while the program is running so you could dump the speech data, in particular in game cartridges. When you change the cartridge, you either trigger the reset of the console, or (if you taped the reset pin) you had some chance of crashing the console. Then you could press the LOAD interrupt switch that I mounted at the backside of my console, with the vector pointing to the Speecoder program, and if the console did not wreak havoc on the memory during the crash, you could continue working with the tool.

Link to comment
Share on other sites

I messed around with a Assembly program that when you press Load Interrupt it would save VDP, Scratch Pad and upper 24K to Hard Drive file then switch to another PGRAM cartridge, and you could switch back.

It ran in lower 8K space and was cool but really had no real value for use, other then you could switch back and forth.

It only worked from EA to XB cart.

Link to comment
Share on other sites

I once made use of the LOAD interrupt - in my Speecoder tool. The idea was to allow for swapping the cartridge while the program is running so you could dump the speech data, in particular in game cartridges. When you change the cartridge, you either trigger the reset of the console, or (if you taped the reset pin) you had some chance of crashing the console. Then you could press the LOAD interrupt switch that I mounted at the backside of my console, with the vector pointing to the Speecoder program, and if the console did not wreak havoc on the memory during the crash, you could continue working with the tool.

 

Or you could use the Navarone widget :) Harry Wilhelm used it that way for his Beyond Video Chess program to switch between the Video Chess cart and the EA cart while Video Chess was running...

Link to comment
Share on other sites

  • 7 months later...

By the way...

I thought about the IAQ signal of the TMS9900 the last days and I ask me what does the X instruction do with it?

Is the IAQ signal active while fetching the operand of the X instruction?

 

I can't find any answer here, in the books of TI or with help of the web search engine of my choice.

I only can test this behavior with a very large effort. But perhaps one of you know whats happen?

 

P.S.

I often read here, that some of us name the IAQ signal something like "Interrupt acknowledge doohickey"... That is wrong!

Correct is "Instruction acquisition"

Link to comment
Share on other sites

By the way...

I thought about the IAQ signal of the TMS9900 the last days and I ask me what does the X instruction do with it?

Is the IAQ signal active while fetching the operand of the X instruction?

 

I can't find any answer here, in the books of TI or with help of the web search engine of my choice.

I only can test this behavior with a very large effort. But perhaps one of you know whats happen?

 

P.S.

I often read here, that some of us name the IAQ signal something like "Interrupt acknowledge doohickey"... That is wrong!

Correct is "Instruction acquisition"

 

This from page 24 of the TMS9900 Microprocessor Data Manual:

 

post-29677-0-49736500-1505060052_thumb.png

 

...lee

  • Like 2
Link to comment
Share on other sites

This from Thierry Nouspikel’s TI-99/4A Tech Pages at “Processors”-->“TMS9900”:

 

 

IAQ Instruction acquisition. This output pin indicates that the TMS9900 is acquiring an instruction. It can be used to detect illegal opcodes or to prevent LOAD* to last longer than one instruction. On the TI-99/4A, IAQ and HOLDA are combined via an OR gate and presented to the peripheral port. However, the flex cable connector does not carry that signal to the PE-Box.

 

...lee

  • Like 1
Link to comment
Share on other sites

There was a clever trick about debouncing LOAD I once read in some magazine, possibly Enthusiast'99, which did not use IAQ. The first word of the LOAD handler should clear FFFC. Example (if I recall correctly):

 

 

FF20: CLR @>FFFC
FF24: LWPI >8300
FF28: CLR R0
FF2A: DEC R0 
FF2C: JNE $-2
FF2E: LI  R0,>FF00
FF32: MOV R0,@>FFFC
continue with code
...
FFFC: DATA >FF00,>FF20
  • Like 3
Link to comment
Share on other sites

I learned about that issue myself when I built the screen capture code for Omega ...

 

For anyone who doesn't know, LOAD is a level-triggered, non-maskable interrupt. This means that as long as it's active, it will continually retrigger. When it triggers, it writes the return information into the new workspace, then jumps to the pointed-at code. The problem is that when it's triggered from a button or other means that doesn't have insight into the system's state, it will probably fire multiple times. The first time, it writes the correct program return information. The second time, well, it's in the handler, so the return information saved off is to go right back to the handler again. There's no stack, so the original return data can be lost if you don't do something about it in the one instruction of safety you get.

 

That code is kind of clever - as long as load retriggers, R0 will never count down to zero. Only issue I see is that it induces an extra delay after LOAD is de-asserted before the code starts. Took some thinking for me to understand why it clears >FFFC -- but I see now. That prevents the load re-triggers from overwriting the original return address by placing the new (temporary) workspace in ROM. When LOAD stops triggering, R0 will be allowed to count down, and when it does the code will continue.

 

I did something similar to that in Omega's tool, I remember, though I think I ended up using two workspaces or an overlapping one at least. I'll have to dig it up and see what I did, it's fun to compare solutions.

  • Like 2
Link to comment
Share on other sites

Could the LOAD line be confiscated and used to create a proper RS232 interrupt?

 

What I mean by proper is used for RS232 only, so as to reduce the size and complexity of the ISR allowing faster communication and lower overhead on the main program.

 

It would require running a connection from the RS232 card. I have not looked at the drawings to see if there are any open pins on the Expansion box buss. And based on Tursi's response on multiple triggers it might want some conditioning logic added to the RS232 board.

 

I kind of salivate knowing there is an available interrupt vector in RAM. :)

Link to comment
Share on other sites

Could the LOAD line be confiscated and used to create a proper RS232 interrupt?

 

What I mean by proper is used for RS232 only, so as to reduce the size and complexity of the ISR allowing faster communication and lower overhead on the main program.

 

It would require running a connection from the RS232 card. I have not looked at the drawings to see if there are any open pins on the Expansion box buss. And based on Tursi's response on multiple triggers it might want some conditioning logic added to the RS232 board.

 

I kind of salivate knowing there is an available interrupt vector in RAM. :)

 

You'll have to continue salivating, Bill. The /LOAD signal is present on the console edge connector but isn't routed down the flex cable to the PEB.

Link to comment
Share on other sites

You mean circumventing the whole DSR search? Because this is actually what uses a lot of processing time. If you know that the LOAD interrupt can only be triggered by the RS232, you can indeed create a fast response handler, but the downside is that LOAD is a non-maskable interrupt; you'd have to send it through a logic gate so that you are able to suppress it.

  • Like 1
Link to comment
Share on other sites

You'll have to continue salivating, Bill. The /LOAD signal is present on the console edge connector but isn't routed down the flex cable to the PEB.

 

I just thought about the idea from SNUG where they led the VDP interrupt from their EVPC card through a separate cable into the console. Also here, you could use a separate wire, but this means some soldering job and more.

Link to comment
Share on other sites

Yeah, as mentioned, it's a fast interrupt vector, but you have to be careful. It was also mentioned above that you can technically use IAQ to make LOAD last just one instruction (preventing retriggering), which would be helpful for a fast interrupt since you would not need to catch retriggering OR debounce.

 

I found my code, and it's got both of those - my debounce time is more than? the other's, and I use an entire second workspace (which I never use otherwise) for the retriggered interrupts, but otherwise much the same:

 

HOOK
* HW WORKAROUND. The PS/2 adapter I released outputs GPIO pins
* as a level output, based on how long you hold the key. LOAD
* is a level-based interrupt, so it will trigger repeatedly
* as long as the key is held. After the first repeat, we lose
* the return information, so we take advantage of the ONE instruction
* we get to change the workspace to an alternate, dummy one.
* that way, when the level is finally released, we have a
* chance at actually surviving the process.
	MOV @wp2adr,@>FFFC			* replace vector workspace with a dummy
	
* Now kill interrupts! (VDP int may have happened above, but
* that /should/ be okay, though you can also interrupt THAT. 
* RTWP will restore the original interrupt settting and if we
* don't muck with anything...)
	LIMI 0

* now, a brief delay to act as a debounce time within which
* it is still safe for LOAD to retrigger.	
	CLR R0
S3L3
	INC R0
	DECT R0
	JNE S3L3
	
* okay, now pretend that only the first workspace matters to us
* we can safely disregard the second one.
	LWPI wp
Edited by Tursi
  • Like 1
Link to comment
Share on other sites

  • 10 months later...

 

There was a clever trick about debouncing LOAD I once read in some magazine, possibly Enthusiast'99, which did not use IAQ. The first word of the LOAD handler should clear FFFC. Example (if I recall correctly):

FF20: CLR @>FFFC
FF24: LWPI >8300
FF28: CLR R0
FF2A: DEC R0 
FF2C: JNE $-2
FF2E: LI  R0,>FF00
FF32: MOV R0,@>FFFC
continue with code
...
FFFC: DATA >FF00,>FF20

Wake the dead... thread...

 

While this method is convenient and effective for a manual trigger. This method tested "unreliable" for rapid re-triggers.

 

That prevents the load re-triggers from overwriting the original return address by placing the new (temporary) workspace in ROM.

Unless... an interrupt occurs between restoring vector workspace...

 

LI R0,>FF00

MOV R0,@>FFFC

 

and...

 

RTWP

 

resulting in... being trapped in the handler!

 

 

Yeah, as mentioned, it's a fast interrupt vector, but you have to be careful. It was also mentioned above that you can technically use IAQ to make LOAD last just one instruction (preventing retriggering), which would be helpful for a fast interrupt since you would not need to catch retriggering OR debounce.

Still same problem. The second or third instruction could be interrupted by rapid IRQs.

 

Plus new problem: IAQ is paired("ORed") with HOLDA at the side port.

 

Result... when using the recommended 9900 interrupt generator circuit...

 

post-64523-0-87783200-1533087248.jpg

 

...the double signal prevents programs running in 32k memory from being interrupted!

 

Opening the console to solder another line would be rather difficult at this juncture.

 

So... is there a simple way to reconstruct IAQ (block HOLDA)???

 

Link to comment
Share on other sites

Problem solved/Never existed:

I connected the dedicated IAQ(9900 pin7) to the LOAD Generator circuit and Voila;

 

...NO IMPROVEMENT. :? :? :? :? :? :? :? :? :? :? :? :? :?

I had noticed after uploading the test program that LWPI WS1's R12(leftover from another step in the testing) applies to CRU operations but was not cleared. I guess I assumed for a moment that the MINIMEM's object code LOADER would zero values while setting up the BSS 32 buffers. Not so. During some of my tests the values were left zeroed from previous test runs...

Resulting in my usually trustworthy indicator lamps, not triggering in a consistent manor. Misleading me to believe that HOLDA was responsible.

After all R12 values were zero, everything ran like a charm while using IAQ/HOLDA from the side port.

I think this link belongs on this thread. If the trick/tip works, which I trust it well might! It would almost suit my original desires...

Using interrupts

 

 

P.S. If it seems like I singled anyone out...
...It's only because I recognized that you are knowledgeable. :cool:

Link to comment
Share on other sites

I am using the Load interrupt to trigger a polling sequence that shifts data in from cascaded shift registers connected to various external sensors. My current mark is to accommodate 10 scans per second each drawing in 96 switch positions and comparing them to their previous states in order to determine which need servicing. while maintaining ample overhead for the main program to juggle control operations and scheduling. Next I may attempt to add a PISO shift register to an OR gate connected to 1st D flipflop's CL input to try and force/allow a certain number of instructions to execute between successive IRQs. I tend to keep internal interrupt off whenever possible.

Thanx though ;)

  • Like 1
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...
 Share

  • Recently Browsing   0 members

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