Jump to content

Photo

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


18 replies to this topic

#1 brain OFFLINE  

brain

    Chopper Commander

  • 112 posts

Posted Mon Jan 9, 2017 2:21 AM

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



#2 apersson850 OFFLINE  

apersson850

    Moonsweeper

  • 418 posts

Posted Tue Jan 10, 2017 3:33 AM

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, Tue Jan 10, 2017 3:34 AM.


#3 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,514 posts
  • Location:Germany

Posted Tue Jan 10, 2017 6:21 AM

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.



#4 RXB OFFLINE  

RXB

    River Patroller

  • 2,726 posts
  • Location:Vancouver, Washington, USA

Posted Wed Jan 11, 2017 1:44 AM

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.



#5 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 2,726 posts
  • Location:Eagan, MN, USA

Posted Wed Jan 11, 2017 3:01 AM

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



#6 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,514 posts
  • Location:Germany

Posted Wed Jan 11, 2017 7:21 AM

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



#7 HackMac OFFLINE  

HackMac

    Chopper Commander

  • 146 posts
  • Skywalker
  • Location:Germany

Posted Sun Sep 10, 2017 9:34 AM

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"



#8 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,319 posts
  • Location:Silver Run, Maryland

Posted Sun Sep 10, 2017 10:12 AM

 

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:

 

Attached File  IAQ_X.png   16.63KB   1 downloads

 

...lee



#9 HackMac OFFLINE  

HackMac

    Chopper Commander

  • 146 posts
  • Skywalker
  • Location:Germany

Posted Sun Sep 10, 2017 10:45 AM

Thanks Lee!

 

I must have overlooked this footnote :-)


Edited by HackMac, Sun Sep 10, 2017 10:50 AM.


#10 acadiel OFFLINE  

acadiel

    Dragonstomper

  • 929 posts
  • www.hexbus.com
  • Location:USA

Posted Mon Sep 11, 2017 4:25 PM

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


Sent from my iPad using Tapatalk

#11 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,751 posts
  • HarmlessLion
  • Location:BUR

Posted Wed Sep 13, 2017 11:29 AM

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



#12 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,319 posts
  • Location:Silver Run, Maryland

Posted Wed Sep 13, 2017 1:07 PM

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



#13 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,514 posts
  • Location:Germany

Posted Wed Sep 13, 2017 2:11 PM

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


#14 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,751 posts
  • HarmlessLion
  • Location:BUR

Posted Wed Sep 13, 2017 3:55 PM

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.



#15 TheBF OFFLINE  

TheBF

    Moonsweeper

  • 308 posts
  • Location:The Great White North

Posted Thu Sep 14, 2017 6:16 AM

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



#16 Stuart OFFLINE  

Stuart

    Dragonstomper

  • 692 posts
  • Location:Southampton, UK

Posted Thu Sep 14, 2017 7:25 AM

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.



#17 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,514 posts
  • Location:Germany

Posted Thu Sep 14, 2017 7:25 AM

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.



#18 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,514 posts
  • Location:Germany

Posted Thu Sep 14, 2017 7:29 AM

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.



#19 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,751 posts
  • HarmlessLion
  • Location:BUR

Posted Fri Sep 15, 2017 3:22 AM

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, Fri Sep 15, 2017 3:22 AM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users