P-Box INTA, SENILA, SENILB. What the heck?

[+FarmerPotato]

I was reviewing the "TI-99/4A Console and Peripheral Expansion System Technical Data"", that blue book with schematics.

 

There are statements that are puzzling, obscure, or ... who knows what they were thinking.

 

I just had a light bulb moment about one of those.

 

The P-box interrupt line is INTA*.  Then there are 

 

SENILA* Interrupt Level A sense enable
SENILB*  "              B

 

The book says:

 

"There are two levels on which to interrupt, but the TI-99/4A supports only one (INTA*). THIS IS THE ONE YOU MUST USE.  Interrupt level status bits are defined by the Personal Computer PCC at Texas Instruments, and for the moment are not sensed by the TI-99/4A. If they were to be sensed, the TI-99/4A would cause a line to go low (SENILA*), which tells the PCB to gate its status bit to the system data bus."

 

Now I think this bizarre paragraph is describing an 8-bit interrupt code to be sent from the P-Box to the console.  

 

INTA* is a common line. Possibly, they imagined a scheme where a single card could send 8 bits of status if its DSR ROM was selected and it saw SENILA*.  More efficient would have been getting 1 bit from each card in parallel.. probably not doable though.  With only INTA*, the CPU has to call each card's DSR interrupt handling routine.

 

I imagine the PCC keeping a book of whose cards put out what codes 0-255, and for what. (who would that have been exactly? DSEG? Consumer Products?) 

 

Other systems have 8-bit interrupt codes whizzing around the data bus (Z80? 8086?).  I only got my head around it while studying the TI E-Bus Systems.  There are some schemes described there for broadcasting interrupt codes on the data bus.

 

Anyway, I don't suppose this was part of a comprehensive plan? That one paragraph description is still incoherent.  So how did SENILA* make it into the P-Box design?  And why the heck would there be SENILB* if there is no INTB*?

 

 

[+mizapf]

From some source (have to look it up) I have INTB* on pin 18.

 

This is my text in the description of the P-Box component in MAME:

 

Quote

The SENILx lines are somewhat obscure, since there has never been hardware or software that made practical use of them. The intended use can be guessed from some few traditional cards (like the TI RS232) which indeed have connections.

 

With SENILA* asserted (low), a value shall be put on the data bus, representing the interrupt status bits. It can also be used to determine the source of the interrupt: The RS232 card (in its standard configuration) uses the data bus bits 0 and 1 for its two UARTs, while in the second configuration, it uses bits 4 and 5.

SENILB* / INTB* was planned to be used with disk controllers. The PHP1240 disk controller puts the value of INTB* on D0 when SENILB* gets active (low) which reflects the INTRQ output pin of the WD1771. This signal is not used, however. Instead, the disk controller combines DRQ and IRQ and makes use of a READY/HOLD control of the CPU.

Obviously, SENILA* and SENILB* should never be active at the same time, and neither should any memory access to a card be active at the same time, for in both cases, data bus lines may be set to different levels simultaneously. One possible application case is to turn off all cards in the box, assert SENILA*, and then do a read access in the memory area of any card in the P-Box (e.g. 0x4000-0x5fff). Another possiblity is that the currently active card simply does not respond to a certain memory access, and in this case the status bits can be read.

Also note that the SENILx lines access all cards in parallel, meaning that there must be an agreement which cards may use which bits on the data bus. The lines do not depend on the card being active at that time.

 

[+FarmerPotato]

@mizapf

Is there any hint at whether the sense data would go through the ‘245 data bus transceiver or some other buffer? If cards output a few bits each (like two RS232 cards two bits each) then a ‘125 could drive just that line. 
 

interesting. 

[+mizapf]

Have a look at the schematics

 

TI Disk Controller:

 

 

RS232:

 

[+dhe]

F.PO and Mizapf thanks for this thread. I never really understood hardware interrupts, except that there are two states - Interrupt/No Interrupt and that the design on the 4a hobbled what could have been.

 

Once you get the dummies guide to interrupts finalized, can you explain how DMA operates on the 4a? I've been told the HFDC does DMA transfers - my understanding of DMA is you basically say - Move this data from here, to that there memory and the CPU steps out of the way?

 

I've been told the Myarc FDC design was trending towards a DMA transfer mode?

[+FarmerPotato]

DMA refers to this:

 

a peripheral is ready to read or write a chunk of memory (like a disk controller)

 

it asserts HOLD. 

 

The CPU sees HOLD, and goes into hold state when it finishes the current instruction.

 

CPU turns off its bus outputs and asserts HOLDA (acknowledge)

 

Peripheral sees HOLDA and takes over the memory bus to read/write data. 
 

peripheral releases HOLD signal. 

CPU resumes operating, fetches next instruction. 
 

If the peripheral is capable of clocking out memory read/write at the full speed of the memory, it is as much as 10x faster than the CPU executing MOV instructions in a loop. 
 

One roadblock is that the TI file  access always goes through VDP RAM. Alas, a peripheral in the P-Box cannot read or write VDP RAM. (Or even the PAD?) it would require the Flex cable to reverse the buffer direction of all the memory control signals like MEMEN, DBIN, WE which are output-only. 

so any DMA operation must use RAM in the P Box. If it brings its own RAM, great, but it wouldn’t need to halt the CPU to transfer between that and disk. 
 

 

 

 

 

 

 

[+mizapf]

This is the DMA handling on the HFDC. The on-board RAM is highlighted in yellow.

 

[+dhe]

ok... Maybe someone said Myarc's FDC was trending that way, because if I remember correctly, the Myarc FDC is the only disk controller with a small amount of RAM - which elevates the problem if having to put your data transfer code for ds/dd in scratch pad ram to keep up.

 

Is the Myarc source code or schematics available?

[+InsaneMultitasker]

There are references to Paolo Bagneresi having disassembled and released the Myarc FDC EPROM code, including at least one very detailed document where he identified the on-board RAM usage.  I've searched for the files without luck.  I don't know that anyone obtained his his system and/or files after he passed away. 

[+mizapf]

The 2K RAM on the DDCC1 is not used in a DMA style; the WD17xx cannot do DMA. It is mapped into the area 5000-57FF, maybe for setting up buffers.

[+Ksarul]

14 hours ago, dhe said:

ok... Maybe someone said Myarc's FDC was trending that way, because if I remember correctly, the Myarc FDC is the only disk controller with a small amount of RAM - which elevates the problem if having to put your data transfer code for ds/dd in scratch pad ram to keep up.

 

Is the Myarc source code or schematics available?

Here's a schematic for one variant of the Myarc FDC (there were several different modifications to the components on the boards over time).

A3-Myarc FDCC-1 Disk Controller Card-P1(R2a).pdf

[F.G. Kaal]

16 hours ago, InsaneMultitasker said:

There are references to Paolo Bagneresi having disassembled and released the Myarc FDC EPROM code, including at least one very detailed document where he identified the on-board RAM usage.  I've searched for the files without luck.  I don't know that anyone obtained his his system and/or files after he passed away. 

I have received an ISO file with Paolo's work after he passed away. I will have a look if I can find anything about FDC EPROM's.

[+9640News]

1 hour ago, F.G. Kaal said:

I have received an ISO file with Paolo's work after he passed away. I will have a look if I can find anything about FDC EPROM's.

Seems like I may have posted something a few years ago on here myself.

[+9640News]

17 hours ago, InsaneMultitasker said:

There are references to Paolo Bagneresi having disassembled and released the Myarc FDC EPROM code, including at least one very detailed document where he identified the on-board RAM usage.  I've searched for the files without luck.  I don't know that anyone obtained his his system and/or files after he passed away. 

I left a post in another topic area on some of Paolo's documents for the Myarc FDC.  I looked through it, and it does not appear to be the complete source code, but does detail the on-board RAM usage along with a lot of other information.

If I can think of it this evening, I will try to find an envelope I have from Paolo as I thought it had more detailed information on it than what I found here on Atariage.

Beery

 

[+InsaneMultitasker]

I found a text file  Myarc FDC RAM info from Paolo B via TI hardware compendium.txt (created on my system in 2013) that I had saved, though I know that I have (or had) much of this same information on a floppy disk.  I believe a file on the same disk mentions Paolo's disassembly of the DSR. 

[apersson850]

RAM on cards in the box is very handy. I did the same thing with the cards I designed for my own use.

[F.G. Kaal]

23 hours ago, F.G. Kaal said:

I have received an ISO file with Paolo's work after he passed away. I will have a look if I can find anything about FDC EPROM's.

The ISO file I have mostly contain Paolo's work on the PC-DSK program. So no Eprom sources there.