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

[brain]

Looking at the PEB, I see that SBE, MBE, LOAD, and IAQ are terminated at the "firehose" connector and do not show up in the PEB. Though SBE and MBE are easily reconstructed (ala SS in the PEB), does any sidecar actually use LOAD or IAQ?

 

Jim

[apersson850]

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 January 10, 2017 by apersson850

[+mizapf]

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.

[RXB]

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.

[+Vorticon]

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...

[+mizapf]

I had the Widget, but switching sometimes crashed the console.

[HackMac]

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"

[+Lee Stewart]

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:

 

 

...lee

[HackMac]

Thanks Lee!

 

I must have overlooked this footnote :-)

Edited September 10, 2017 by HackMac

[+acadiel]

Corcomp load interrupt switch. Didn't it branch to somewhere in upper 24K when you used it?

 

 

Sent from my iPad using Tapatalk

[Tursi]

LOAD branches to a BLWP vector at >FFFC, IIRC.

[+Lee Stewart]

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

[+mizapf]

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

[Tursi]

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.

[+TheBF]

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.

[Stuart]

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.

[+mizapf]

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.

[+mizapf]

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.

[Tursi]

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 September 15, 2017 by Tursi

[HOME AUTOMATION]

 

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...

 

 

...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)???

 

[HOME AUTOMATION]

Perhaps the changes I've made are at the heart of the issue???

 

 

The test program:

SBO/SBZ 22

SBO/SBZ 23

operate test lamps

SBO/SBZ 16

gate the NMI

 

 

[HOME AUTOMATION]

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.

[atrax27407]

If you are having problems with the shared interrupt line when running a terminal program, there is a fixed DSR for both the TI and CorComp RS232.

[HOME AUTOMATION]

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