SCSI Pal's

[RickyDean]

@Don O'Neil and @Jeff White

I have a 1992 WHT REV E SCSI card that has 3 PAL chips on it, U13, U12, and U7. Do you possibly have the Pal Jed files for these 3, or replacement PAL's? Or do I need to contact Richard Bell? I think I blew one of these a couple of weeks ago, and I have tested or  replaced all the IC's that I could. The 244 buffer at U3 blew out and damaged the socket, but I believe at a minimum that I also messed up the Pal at U7. I bought this from one of you around 1993 to 95, I think at Lima Ohio.

Edited January 19 by RickyDean

[humeur]

So I too am looking for these components if you ever have the equations or the jedec file I am also interested.

 

Alors moi aussi je recherche ces composants si jamais tu as les equations ou le fichier jedec je suis aussi intéressez .

[RickyDean]

58 minutes ago, humeur said:

So I too am looking for these components if you ever have the equations or the jedec file I am also interested.

 

Alors moi aussi je recherche ces composants si jamais tu as les equations ou le fichier jedec je suis aussi intéressez .

Understood, I am probably getting a DuPal device soon. I can try decoding these and will hopfully get good jedecs to work with. The exception will propbably be the one I believe is damaged, the U7. But I'll not distribute them, even if I get good files, until the person(s) who own the rights to the original PALCE's give their permission. And I'll still need the one or more that is damaged.

[humeur]

I would wait until this goes on sale

 

J'attendrais que cela soit en vente.

[+mizapf]

I have the JEDEC files for the F revision from Don. I don't know whether this is helpful, though.

[RickyDean]

27 minutes ago, mizapf said:

I have the JEDEC files for the F revision from Don. I don't know whether this is helpful, though.

Does the F revision have the U7 location as depicted in the photo above? The left most 74ls244 U3 sets right under it, which is the one that blew out on me, if your board is not numbered the same as mine, it may be different. I think it may tie into the pin 4 of the PowerUp Config switch and into the Eprom? This would be U7 16V8 GAL, WHT Part #: CRU v1.0 in the original White Scsi hardware manual.

 

I was trying out some jed files on my Corcomp controller two weeks ago and as I was plugging in a floppy drive emulator to it, I had pulled the card out some, with the floppy cable, unknown to me. I turned on the machine and heard a sound and some of that magic smoke/smell came out. Of cousre the rest is history, it also killed the Interface card and possibly the PEB, voltages don't seem right. 14+ at the 5 volt side and 24+ at the 12 volt side. Right now I'm trying to get them operational again.

Edited January 21 by RickyDean

[+mizapf]

This is difficult to say, as I don't have the card itself, just the files from Don O'Neil, including the schematics. Maybe you should get in contact with Don directly.

[RickyDean]

15 minutes ago, mizapf said:

This is difficult to say, as I don't have the card itself, just the files from Don O'Neil, including the schematics. Maybe you should get in contact with Don directly.

Well I did start this thread with @Don O'Neil. Can you provide the those files and the schematics, I can look at them, try them out?

Edited January 21 by RickyDean

[+InsaneMultitasker]

5 hours ago, RickyDean said:

I was trying out some jed files on my Corcomp controller two weeks ago and as I was plugging in a floppy drive emulator to it, I had pulled the card out some, with the floppy cable, unknown to me. I turned on the machine and heard a sound and some of that magic smoke/smell came out. Of cousre the rest is history, it also killed the Interface card and possibly the PEB, voltages don't seem right. 14+ at the 5 volt side and 24+ at the 12 volt side. Right now I'm trying to get them operational again.

Ouch!  Hopefully, the damage will be minimal.  Never a good time when this happens    Alas, you/many of us know, cards designed for a clamshell are subject to this problem. One of the worst offenders is the Geneve with its keyboard, joystick, mouse, and video cable.  Same goes for floppy controllers and similar cards with those rear connection points.  We need a TILT warning like the old pinball games.

 

[humeur]

13 hours ago, mizapf said:

I have the JEDEC files for the F revision from Don. I don't know whether this is helpful, though.

Hello, is your card like this if yes I would like these files to repair mine

 

Bonjour, ta carte est elle comme celle-ci, si oui je veux bien ces fichiers pour réparer la mienne.

 

 

[RickyDean]

6 hours ago, humeur said:

Hello, is your card like this if yes I would like these files to repair mine

 

Bonjour, ta carte est elle comme celle-ci, si oui je veux bien ces fichiers pour réparer la mienne.

 

 

Could you also post a good picture of the back of the card, I'd like to see how it was changed from mine in that revision.. Great looking card.

[+mizapf]

These are the JEDEC files for the revision F.

SCSI-ADD.JED SCSI-CRU.JED SCSI-DMA.JED

[humeur]

22 minutes ago, mizapf said:

These are the JEDEC files for the revision F.

SCSI-ADD.JED 1.62 kB · 0 downloads SCSI-CRU.JED 897 B · 0 downloads SCSI-DMA.JED 1.66 kB · 0 downloads

Thank very very thank

 

Merci merci

[RickyDean]

5 hours ago, mizapf said:

These are the JEDEC files for the revision F.

SCSI-ADD.JED 1.62 kB · 6 downloads SCSI-CRU.JED 897 B · 5 downloads SCSI-DMA.JED 1.66 kB · 5 downloads

Just as soon as I get a PEB box working, I'll test these on a revision E. After seeing how similar Rev F is, I'm hoping the GAL's were the same. If there is a difference, I believe it will probably lie in the DMA Gal.  I understand that DMA was changed some or activated in later revisions?

[+Ksarul]

2 hours ago, RickyDean said:

Just as soon as I get a PEB box working, I'll test these on a revision E. After seeing how similar Rev F is, I'm hoping the GAL's were the same. If there is a difference, I believe it will probably lie in the DMA Gal.  I understand that DMA was changed some or activated in later revisions?

Wasn't the activation of DMA the purpose of the SNUG daughter boards?

[+mizapf]

Not the DMA as such, but the Block Mode DMA (which is called PDMA in GeneveOS). Mind that "DMA" always means transfer to the RAM on the SCSI card, never into main memory.

[+dhe]

P = Pseudo

[RickyDean]

20 minutes ago, Ksarul said:

Wasn't the activation of DMA the purpose of the SNUG daughter boards?

Don't know, wasn't very active in TI stuff at the time due to work and stuff. I'd have liked to have been more active at the time. I missed a lot.

[+mizapf]

6 hours ago, dhe said:

P = Pseudo

This was in fact a bad choice for a name because all DMA on the SCSI card is pseudo. I already talked to Tim about that, but there is currently no need to rename PDMA to e.g. BDMA.

[Jeff White]

22 hours ago, mizapf said:

Not the DMA as such, but the Block Mode DMA (which is called PDMA in GeneveOS). Mind that "DMA" always means transfer to the RAM on the SCSI card, never into main memory.

You may be thinking of the HFDC which can only transfer to the onboard RAM via DMA.  The 99/4A and Geneve do not allow true DMA to main memory.  Thus, the HFDC always does a double-transfer: (1) drive to onboard RAM; (2) onboard RAM to VDP RAM or CPU RAM depending on the MSbit of the device number.

 

The pDMA of the SCSI card can transfer directly to main memory with the >2x (Level 1) routines if MSb is set.  In fact, these routines handle 256-, 512-, 1024-, and 2048-byte sectors depending on the 2nd and 3rd MSb’s of the device number.

 

The HFDC allows both PAB and destination memory to be in either VDP RAM or CPU RAM — VV, VC, CV, or CC.

 

The SCSI DSR requires PAB to be in VDP RAM but destination in VDP RAM or CPU RAM — VV or VC.

 

pDMA means the CPU is controlling the transfer of data by memory-mapped port to/from main memory/VDP RAM with automatic handshaking of bytes.  This was accomplished on the first generation Rev E board with a feedback loop on the DMA GAL.

 

What was unknown at the time was how critical the timing was.  The SCSI ports appear at even bytes for byte-transfers, and even and odd bytes for word transfers.  I.e., by clearing a CRU bit, a MOVB @SCSIRD,*Rx+ could be used.  By setting that CRU bit, MOV @SCSIRD,*Rx+ could be used.  Obviously, for CPU RAM transfers.  

 

The tricky part of the design was getting the automatic handshake to happen between the bytes transferred during a single MOV instruction.  That it worked at all on the 1st boards built with the 3 jumper wires added for the capability was stunning.

[+mizapf]

But if we had real DMA, how could the SCSI card gain bus master access? I don't know of any card that would be able to become bus master. For instance, on the Geneve, I'm pretty sure you cannot push data from outside into the DRAM on the Geneve board.

 

[...] I think we're not exactly talking about the same thing here; I have to rewrite my answer.

[Jeff White]

4 minutes ago, mizapf said:

But if we had real DMA, how could the SCSI card gain bus master access? I don't know of any card that would be able to become bus master. For instance, on the Geneve, I'm pretty sure you cannot push data from outside into the DRAM on the Geneve board.

 

What I know from the SCSI card and its DSR is that the CPU picks up the bytes from the NCR53C80 in DMA mode. In the end, in DMA transfer, you just have a sequence of MOVB from the memory location where the controller is mapped. There were even attempts with MOV for word accesses, but those failed with the TI-99/4A because of the byte order.

 

And to my understanding, also from the 53C80 manual, doing the handshake by program code instead of a DMA controller is called pseudo DMA, isn't it?

The SCSI card has no DMA controller and the bus does not allow it.  Because of byte order, word transfers with the 99/4A would do odd-byte then even-byte, opposite of Geneve, and require a SWPB.  That is the point of having a DIP switch to select 99/4A or Geneve.

[+mizapf]

What I meant by "DMA" is that the device (here, the SCSI controller) can become a bus master and directly access main memory. Systems usually make use of a special DMA controller chip for that purpose. But the TI systems (99/4A, Geneve) are not designed for that, although the CPU has an input pin /HOLD.

 

I think what you referred to was the ability (of the CPU, via the driver) to load the data directly into CPU memory (saving vice versa) without going through VRAM or without pushing the data on an onboard RAM on the controller card and then downloading the data from that onboard RAM (which is done by the HFDC).

 

Letting the CPU do the DMA handshake with the controller chip (and then pushing the data wherever it wants to) is what is described in the specs as "pseudo DMA".

[Jeff White]

15 hours ago, mizapf said:

What I meant by "DMA" is that the device (here, the SCSI controller) can become a bus master and directly access main memory. System usually make use of a special DMA controller chip for that purpose. But the TI systems (99/4A, Geneve) are not designed for that, although the CPU has an input pin /HOLD.

 

I think what you referred to was the ability (of the CPU, via the driver) to load the data directly into CPU memory (saving vice versa) without going through VRAM or without pushing the data on an onboard RAM on the controller card and then downloading the data from that onboard RAM (which is done by the HFDC).

 

Letting the CPU do the DMA handshake with the controller chip (and then pushing the data wherever it wants to) is what is described in the specs as "pseudo DMA".

Agreed, but a few points of clarification.

 

The 5380 SCSI controller chip requires a DMA controller to do true DMA to/from memory.  With the 99/4A and Geneve, that would have had to be a DMA controller with local memory on the card as done by and required by the HFDC.

 

With SCSI card, the CPU is in full control of data I/O.  After setting up data R/W, the CPU checks a CRU bit to determine when the data is ready.  Once that happens, multiple MOVB or MOV instructions are used to transfer the data.  The handshake is automatic during each byte transfer rather than relying on further CRU bit tests or status register tests.  I.e., the  handshake for each byte is implicit during the transfer rather than with additional CPU instructions.

 

The TI DSR makes use of onboard RAM to “juggle” the translation of 512-byte physical sectors to 256-byte logical sectors.  The Geneve performs the “juggling” in main memory, IIRC.  @InsaneMultitasker or @9640News would better know.

 

AFAIK, the level 1 source code has never been made available.

[+mizapf]

Do you happen to know how /EOP is working? This is where my attempts of emulating the SCSI system in MAME got into a stall. For that reason, the WHTech card does not support the PDMA ON setting in MAME.

 

My problem was, more precisely speaking, that I did not understand how the SNUG DSR worked with the block mode DMA without losing the last byte or word (byte/word transfer).