+FarmerPotato Posted October 12, 2020 Share Posted October 12, 2020 I am starting a new thread to ask questions that come up during debugging of Geneve 2020. I appreciate any insight that anyone can give! The status at this point is that I have a backplane, with cards for CPU and some Flash ROM and RAM. However, last night I replaced the crystal with a 12MHz in order to run the memory bus at 3MHz. Then I turned it on. Nothing. Horrified, I saw I had my supply set to 6V. I changed to 5V and checked CLKOUT. Nothing. Last time I checked, it was a steady 6MHz, now I expected 3MHz. Have I fried the 99105 CPU by applying 6V? This is the ceramic TMS99105AJDL, date code 9123. By itself, the CPU card is consuming 350mA, as it did before. The memory card adds 350 mA. No CLKOUT, 0V on XTAL1, 5V on XTAL2. I desoldered the crystal and put the 24MHz back in. For a while I got this clock. Then it flatlined and now it consumes 700-900mA. Generally the outputs show a flat 3.6V. Ideas? Vertical scale is 5V. So bad undershoot. From 4V down to about -2V before reaching 0. The signal is driving one input of a '645. Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted October 13, 2020 Share Posted October 13, 2020 Doesn't sound good... Dunno about the 99105... However, once upon a time... I inadvertently reversed the high/low AC voltages feeding the P/S, on my new used 4A. It seemed to be running ok. I left it on, unattended for some time. When I returned, I could smell the magic immediately! It was dead. After disassembling, I found the sound IC had disintegrated, burning a small hole through the PWB. I found the 5vdc regulator shorted, allowing approx. 18 volts DC onto the 5v rail! After cleaning thing up somewhat, surprisingly, all was well, sans sound! 1 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 21, 2020 Author Share Posted October 21, 2020 On 10/12/2020 at 8:01 PM, HOME AUTOMATION said: Doesn't sound good... Dunno about the 99105... However, once upon a time... I inadvertently reversed the high/low AC voltages feeding the P/S, on my new used 4A. It seemed to be running ok. I left it on, unattended for some time. When I returned, I could smell the magic immediately! It was dead. After disassembling, I found the sound IC had disintegrated, burning a small hole through the PWB. I found the 5vdc regulator shorted, allowing approx. 18 volts DC onto the 5v rail! After cleaning thing up somewhat, surprisingly, all was well, sans sound! Pretty hairy, burning through the 76489 (or 94624 depending). I'm re-testing my CPU on a breadboard. It might be that my cpu board has some fried chips. Maybe they are dead and just putting a lot of capacitance on the cpu pins. jbdigriz has sent me 2 cpus and I got another from polida2008. I'm into the testing. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 21, 2020 Author Share Posted October 21, 2020 Does anybody know about wire wrap bits and matching sleeves? I'm trying to get a pair, at an affordable price (say $25 each) If want to learn something about wire wrap, for constructing circuit board prototypes, try these great tutorials: https://www.specialized.net/tools/wire-wrap-tools.html https://docs.rs-online.com/dc28/0900766b80565423.pdf YouTube: So: I have a Cooper Tools electric wire wrap gun. I have one bit, one sleeve, which don't work together. I need a bit, and a sleeve to match. Without that, I'm using my long-time Radio Shack hand tool (the kind that looks like a screwdriver.) TI used wire wrap for PLCs and stuff, I guess, from the junk in their dumpster. When I was 17, a TI engineer loaned me a gun with cut-strip-wrap CSW bit, which was a breeze to use. I will settle for just a wrap bit/sleeve! Here are the parts I've found so far on the internet: 30 AWG wire, mostly 6-digit Cooper tools brand part numbers: Summary Bit Sleeve Have 501097 bit Need 507100 Sleeve (Cooper) UPC 960948 Need WB3032M Have P3032 Sleeve (these are brand OK Jonard) ES Found 511395 ES gone 507502 ES Found 990063 CSW Need 990064 with cutter and exit slot UPC 960740 AP Found 990063 CSW AP Found 990764 CSW Found 990765 CSW VERY LARGE TERMINALS - 0.066" (want 0.031 diagonal of 0.025 post) AP Need 501194 UPC 951908 Found 502129 (normally 24-26 AWG) AP Found 507063 SP Found JDV bit SP 53110, $30.50, .047" bit radius, thats .094" diameter, huge abbreviations J Jonard SP Standard Pneumatic OK OK Industries ES https://www.electronicsurplus.com/ AP https://store.armyproperty.com/ SP https://www.specialized.net/tools/wire-wrap-tools/wire-wrap-bits-sleeves Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 22, 2020 Author Share Posted October 22, 2020 Well dang... I searched for 507100 yesterday on eBay and there weren't any bargains. Then last night, I saw a seller added more inventory, including a 507100 and SB30xxx. $24 and $12. The top two on my "needs" list. So, I will have 2 matching sets of bit +sleeve. One set of Jonard brand, and one Cooper Tools! I feel lucky. It is personal tools from a retired EE: tools going back to the 70s. 2 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 13, 2020 Author Share Posted November 13, 2020 So I've been testing the 99105 CPUs on a breadboard. This is hardware weekend. I got two things out of the way: The 99105 needed about 10ms between power up and making a stable clock. With RESET held low. So I made sure my power-up RESET input was delayed enough, and very sharp. Also, the internal oscillator was doing poorly on a breadboard. I played around with the tiny (eg 30pF) capacitors until it got more stable. I also tried an external clock, which made everything smooth. I am watching bus status codes at startup time. CLKOUT is 3MHz. [Bus Status codes are 4 bits that reveal what the CPU is doing in this cycle. External memories and peripherals must parse the bus codes!] The bus status starts at 1010 (RESET). The RESET state lasts three clock cycles. (the rest is theory...) 1010 RESET 1010 RESET 1010 RESET 1101 ST status register update due to interrupt 0101 INTA RD active during WP or PC fetch for interrupt. A14=0 1001 AUMS internal ALU operation, or macrostore access 1001 AUMS 0101 INTA RD active during WP or PC fetch for interrupt. A14=1 1100 WP workspace pointer update 0110 WS WE workspace transfer R15 0110 WS WE workspace transfer R14 0110 WS WE workspace transfer R13 0011 IAQ RD instruction acquisition (fetch) 1001 AUMS 1001 AUMS 1110 MID macroinstruction detect 1001 AUMS macrostore access ... infinite loop of AUMS, but not RD ... This sequence looks pretty good! Since there is no memory hooked up, I consider this a success--the CPU chip looks ok. It just fetched a garbage instruction. note: APP is tied to RESET, so it should be going off-chip for macrostore. Hmm. A cycle begins with ALATCH high, important stuff happens after ALATCH falls, cycle ends with ALATCH high again. RESET is yellow trace, WE is red trace (analog). There are a lot of glitches in the blue digital--I have learned to ignore them when they occur mid-cycle. I am pretty sure the glitches are an artefact of my logic analyzer cable and test pins. When I check them in analog, there are no glitches. (Also you can see the CPU is drawing 193 mA.) 4 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 15, 2020 Author Share Posted November 15, 2020 Having tested all the CPUs in isolation, I am convinced my CPU was fine but some other chips are not. I made a few additions to the CPU board. LS14 to debounce the RESET button, which was a simple RC rising signal before. Not because the CPU needed it (Also, the 99105 has its own Schmitt trigger on the RESET input.) But because I can't set an oscilloscope trigger without a nice clean edge. The trigger is where the scope takes a snapshot for you. Anyhow the nice clean yellow edge, in the above post, was captured from the breadboard, and now the card can be triggered on that. Unfortunately, it took me all evening to get that soldered on neatly. But I got the same valid CPU startup sequence when testing the CPU in isolation. Prototype with ROM+RAM on perfboard. The CPU is in slot 0. The memory card (in wirewrap) is plugged into slot 1. It lays down flat and covers slots 2-7. To make debugging easier. The perfboard is covered by a sticky label, printed with all the signal names. It has room for both a right-angle and a straight connector to the backplane. Now the real problem: I no longer see any signals on the backplane, and current draw has gone from 350mA to 800mA. It's not the BIOS memory card, because I removed that--the current only goes down by an expected amount. Could be some buffers are fried from having 6V VCC. (though I'm not certain that I measured signals on the backplane before?) Bus buffers are ordinary "sacrificial" LS245-type chips, '645 actually. They replace a '244 driver, too, when the bi-directional buffers are set to output one way only. It means I have one less kind of chip to buy. I hope that is not a bad assumption--the 645 datasheet says it can drive as many loads as a 244. I'm not sure what I'm looking for--the CPU card works when it is not on the backplane, but goes dead when connected. Not even a CLKOUT. Just some impedance added to the buffer inputs/outputs, why? Ideas? Check every line of the backplane, looking for a short, again. Check output voltage on every line of the backplane Build another CPU card (yikes. But you know why OSHPark gives you 3 boards. I got 5 from Seeed Studio) Remove chips one by one Feel for a hot chip with my fingers (that extra 600mA is going somewhere) Reading I learned a lot from this series, The Ultimate Guide to Switch Debounce. https://www.eejournal.com/article/ultimate-guide-to-switch-debounce-part-1/ 4 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted November 15, 2020 Share Posted November 15, 2020 I would expect if one of the bus driver's is gone bad from your 6V adventure, that the impedance, while maybe not a full short would be very different from the good ones. Depends on how hard it is to probe... You should be able to measure outlier impedance with the board off, outside the box. So that while tedious and time consuming might point at a single chip to fix. If you are good with the ChipQuick and hot-air, then I would think removing one at a time until it livens up would be a winning strategy. If one is bad, then you'll have to anyway. You know it works when they are not connected. I think I'd start (if they are clustered just right) with chips handling control signals, and save address or data lines for last. Addresses are outputs, and a cpu should still cycle on bad instructions from bad data. The other thing you could do is reproduce the symptom outside the bus backplane... connect a pull-down resister to ground, and probe each of the bus outputs or inputs to see that they respond properly ( no effect, or desired effect if it is something like a wait state or reset line ) Just shooting in the dark. 2 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 15, 2020 Author Share Posted November 15, 2020 36 minutes ago, jedimatt42 said: I would expect if one of the bus driver's is gone bad from your 6V adventure, that the impedance, while maybe not a full short would be very different from the good ones. Depends on how hard it is to probe... You should be able to measure outlier impedance with the board off, outside the box. So that while tedious and time consuming might point at a single chip to fix. If you are good with the ChipQuick and hot-air, then I would think removing one at a time until it livens up would be a winning strategy. If one is bad, then you'll have to anyway. You know it works when they are not connected. I think I'd start (if they are clustered just right) with chips handling control signals, and save address or data lines for last. Addresses are outputs, and a cpu should still cycle on bad instructions from bad data. The other thing you could do is reproduce the symptom outside the bus backplane... connect a pull-down resister to ground, and probe each of the bus outputs or inputs to see that they respond properly ( no effect, or desired effect if it is something like a wait state or reset line ) Just shooting in the dark. I'll start checking impedance across ICs. Thanks for the brainstorming -- one of those might be the right approach--I'll try stuff! I just finished checking the backplane. There were a bunch of poor solder joints, but no shorts. I touched them up and De-Oxy. Dadgummit... now the CPU is ticking. But the power supply temporarily went to 900mA. Then a normal 400mA. And now it appears I have broken my +5V power supply lead. Dangit. Going to have to repair that. On a garbage instruction, the 99105 goes into MID interrupt 1110 and never comes out of macrocode 1001, but that's what it should do. Bus states codes - see 99105 manual, or my copy of the table here: https://gitlab.com/FarmerPotato/geneve2020/-/wikis/X.-Appendix-Reference-Tables#bus-status-codes That document is my evolving reference manual Being able to see the Bus Status in a scope.. that's really making this a pleasure to work on. On the 3rd RD pulse. Bus status code 0010 is an Immediate Operand Fetch. Wrong. Should be a 0011, Instruction Acquisition. In fact, it looks like BST3 is shorted! Uhh So, I'll look at what's going on with the '645 that has BST3 on it 2 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 16, 2020 Author Share Posted November 16, 2020 So, BST3 was just a loose wire. The CPU is actually accessing memory now, ROM and RAM. It is not getting the instruction I put in ROM. I just have to keep slogging through checks. The problem with the power draw that looked like a short, and the dead CPU with no signals, looks like this: From power-on, no clock, and it draws 900mA. If I touch the crystal pins with a screwdriver, the CPU starts clocking, and draws 400mA, and stays that way through repeated reset button-presses. At power-on, it must be the internal oscillator that fails to get going. If all the NMOS gates are neither turning on nor off, but stuck in the middle--they draw the most current. The CPU is definitely the hot chip in this state. I'm going to live with this until I re-spin the CPU board. ---- Continuing BIOS memory card checks: PSEL is high, indicating BIOS memory space, not the main memory. ROM* select is active during fetch of WP and PC RAM* select is active during store of R13 R14 R15 ROM* select is active during IAQ (instruction acquisition) The bus has A0-A14,PSEL and D0-D15, where A0-A14,PSEL is latched and driven at the cpu card. My address/data are numbered backwards from the TI convention. A0 is LSBit. MSBit LSBit A14 13 12 11 -- 10 9 8 7 -- 6 5 4 3 -- 2 1 A0 x D15 14 13 12 -- 11 10 9 8 -- 7 6 5 4 -- 3 2 1 D0 Address bus in memory cycles: RD 0400 read WP from >0000 (ROM value >8000) RD 0402 read PC from >0002 (ROM value >0008) WE 849A save WP to R13 to >809A WE 849C save PC to R14 WE 849E save ST to R15 I interpret this as: the logic analyzer is sampling a stuck bit in A9. CPU is surely fetching 0000, I see 0400. But.. there is garbage (00 or FF) at real address 0400. Yet, logically, the WP was loaded with 8080. So A9=1 must not be from actual A9. Yep, found that; probe A9 was loose. Also if the WP=8080, there is a bad bit where D7=1. If D7=1, then it also read a PC value 0088. RD 04FE Instruction acquisition. What? we should be at PC 0088 at least. This is 00FE Try again RD 0000 read WP from >0000 (ROM value >8000) RD 0002 read PC from >0002 (ROM value >0008) WP 8080 internal set WP (yes!) .. uh, I see ALATCH FFFE, then 8080,929E,8080.. but addr should be latched. Huh? WE 809A save WP to R13 at >809A WE 809C save PC to R14 WE 809E save ST to R15 RD FFFE IAQ Randomly alternating IAQ from PC 00FE or FFFE . Why? Hooking up D7:D0 (now I'm about maxed out 32 probes) I see garbage like FF, F0. It is not stable through one RD or WE. I cannot see it reading '80' from ROM, but somehow it is. Because the WP bus state OUTPUTS 8080. Er.. how is it possible for "addr" to show 8080 if ALATCH falls with addr=FFFE? the address in the latch can't change until the next ALATCH. if the CPU outputs anything after ALATCH, it only goes onto the backplane data bus. Between falling ALATCH and falling WE*, the data bus should match the addr bus. Between falling ALATCH and falling RD*, the data bus should also match the addr bus, then the 245 switches to input. Once RD* and ROMSEL* are released, however, the data bus should be Hi-Z. Two read cycles: About the only thing I get from this is that addr=0000 and addr=0002 are perfect, along with RD* and WE*. Data bus is bizarre. But yet the value 8080 is being read! CLKOUT has been glitched into oblivion. Test ROM code: Spoiler biows equ >8000 intws equ >8020 lights equ >2200 aorg 0 data biows,reset data intws,int reset limi 0 mov @4,@>FFFC mov @6,@>FFFE nmi li r12,lights sbz 0 led loop limi 2 limi 0 * 128 nops. look for instruction >1000 nop ... b @loop int li r12,lights sbo 1 led rtwp end Capacitance on the oscillator pins... On the breadboard the other day, I experimented with different added capacitance on the 12MHz crystal. A stable value there was 33pF. So I put 33pF on the cpu card. Didn't change things. I didn't know better, and on the PCB, I filled ground plane under the crystal traces. (I've already corrected that in the layout.) That's different (but how is it different from the crazy breadboard environment?) Fact: The external capacitance on this oscillator needs to be large enough to achieve oscillation (amplifying a perturbance), but not so large that it decreases the resonant frequency. Guess. When I attach the backplane, it changes the capacitance between the traces and the ground plane. But I'm not sure if it adds or subtracts. Empirically, it seems to subtract, because too little C can make an oscillator fail. I think the ground plane pour, under the crystal, causes the XTAL1 and XTAL2 to be less coupled to each other, and more to the ground plane. So that's removing capacitance from the circuit to start with. So adding capacitance back in should be the right thing? Still, going up to 33pF didn't solve it, the way it did when I experimented on the breadboard. I wonder how it changes if the backplane had its own ground connector? Right now it's just a big extension of the cpu board's power and ground connection. (Now waiting for the front panel/ATX power supply board from OSHPark, which will power the backplane.) 4 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 17, 2020 Author Share Posted November 17, 2020 More progress I continued going down the list of all bus signals. I found that, even with RD* asserted, the CPU did not enable the input data bus buffer from the bus. This is the usual '645 ('245 style) with a DIR pin. It's because DMA was stuck on. That's right, I implemented DMA on the Rev 0.1 board (or tried to). Big mistake. It's broken. Anyhow, I was afraid of this, so I included a DIP switch to bypass the DMA feature. Turns out I labeled and installed it backwards? Or the ON direction opens the switch? Open switch=no DMA. As soon as I flipped the DIP switch, bus activity exploded! Still can't explain how the bus could be hi-Z, yet I still see valid signals on the backplane for MEM and Address and a lot of others. I can't make sense of what I observe. I'm going to go on from here. Glitches Sometimes the scope enters a state of continually retriggering on RESET*. It is not a real RESET* though. I see D6-D7 glitch low just as RD* or WE* fall, then rise. The glitch is over by the time the data bus must be valid. Probably a probe thing. 3 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted November 17, 2020 Share Posted November 17, 2020 This is way out of my knowledge base, so all I can do is offer strong encouragement and moral support This is one heck of a challenge you've picked up here. 2 Quote Link to comment Share on other sites More sharing options...
+9640News Posted November 17, 2020 Share Posted November 17, 2020 Ditto to Vorticon's comments. I'm following this topic to see your progress as I am interested in the finished product. Beery 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 17, 2020 Author Share Posted November 17, 2020 I'm suspecting the bus buffer chips again. Measuring data inputs at the CPU chip (previously done on the backplane) ROM image: 0000 8000 0002 0008 Most significant bit AD0 at CPU: Values 0000 0002 AD0 1 0/1ish AD1 0 1 AD2 0 0 or 1 AD3 0 1ish AD4 0 1ish AD5 0 1 consistently AD6 0 1 most of the time AD7 0 1 most of the time --- AD8 1 1 consistently AD9 0 0 AD10 0 1 mostly AD11 0 0/1 AD12 0 1-ish should be 1 AD13 0 0/1 AD14 0 1 consistently D15_OUT Data bus at backplane LSB F0 F3 At 0000, that matches the reading of 8080 . Look like AD8 is shorted. At 0002, the ones are very weak and at any rate should not be there, except for AD12=1. Also AD8 is stuck. At 0002, AD14 outputs 1 as the address bit, which is latched as LA14 and output as B_A0 (bus LSB) Then it continues to be 1, when it should be 0. Maybe it's the bus buffer chips, maybe not. This is the signal at the ROM, D3 should be 1 at addr=0002. Instead it's this crummy, neither 0/1, yellow mush. After testing lots of pins, New finding. Some of the memory chip address inputs are unconnected. In particular, the ones that are supposed to be tied low or high always. But A0 (LSBit) is supposed to be hard-wired to 0 or 1. One ROM supplies the even (MSB) and another ROM the odd (LSB). This way, both ROMs can have the same image. (Yes, it halves the potential space.) address Even Odd ROM data 0000 0000 0001 80 00 0002 0002 0003 00 08 What I see is both ROMs driving >80, the value at byte 0000, so the word at 0000 is 8080. At 0002, the data is ... mush. If the fix were as simple as tying the floating (unconnected) inputs to 0 or 1 finally, great. Unfortunately, A1 is shorted too, and I have to figure out where I made an error in wire-wrap. This explains why the CPU is able to read 8080 from 0000, but gets random data from 0002. The floating pins tend to stay at 0, until a neighbor goes to 1, and then it's random. On the output, I measured 0s almost always where they should be, and mushy 0/1 where I expected 1s. 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted November 17, 2020 Share Posted November 17, 2020 It's probably one of the yellow or blue wires, and if not them, then one of the red wires. ? 3 Quote Link to comment Share on other sites More sharing options...
GDMike Posted November 17, 2020 Share Posted November 17, 2020 (edited) It's frustrating when you can't trust the wire wrap. It's a delicate test environment, but what's a better way... don't think there is one. Edited November 17, 2020 by GDMike Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 17, 2020 Author Share Posted November 17, 2020 49 minutes ago, BeeryMiller said: It's probably one of the yellow or blue wires, and if not them, then one of the red wires. ? Haha! love it. OK, I removed some red and black wires, and put some on in different places. The blue and yellow looked pretty so I left them. Getting cleaner! The last of the 3 WE cycles writes to 801E, which is R15 if WP=8000. Perfect. The next RD is in bus state 3, IAQ, from address 0004. My source code says this should be PC=0008 and LIMI. The next RD is in bus state 2, IOP, from address 0006. Immediate operand for LIMI. internal ALU stuff The next RD is in bus state 3, IAQ, from address 0008. The next RD is in bus state 3, IAQ, from address 000A. The next RD is in bus state 3, IAQ, from address 000C. .... PERFECT! That is, if my source was this. I must be looking at a newer src file. aorg >0000 ws equ >8000 reset data ws,start start limi 0 nops nop nop ... nops ... b @nops Here it is, looping around to the start. State Addr 3 IAQ RD 0048 B 2 IOP RD 004A DATA >0008 3 IAQ RD 0008 NOP 3 IAQ RD 000A NOP YAY! 2 Quote Link to comment Share on other sites More sharing options...
+9640News Posted November 17, 2020 Share Posted November 17, 2020 Sounds like the found the culprit. Glad my suggestion helped!!!? 1 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 17, 2020 Author Share Posted November 17, 2020 1 hour ago, GDMike said: It's frustrating when you can't trust the wire wrap. It's a delicate test environment, but what's a better way... don't think there is one. Wire wrap is pretty good! In several respects, it is more reliable than PCB. All the errors are my mistakes. For a while my printed WW layout was mirrored vs the real thing. (I found out Kicad can "print mirrored" to fix that) 2 Quote Link to comment Share on other sites More sharing options...
+dhe Posted November 17, 2020 Share Posted November 17, 2020 You mentioned DMA. I know, the MyARC HFDC was the first to claim DMA capability, although, I also heard speculation that the MyARC FDC was on an evolutionary path to having DMA. So how do you envision DMA working in the Geneve2020 - Covid Edition? 1 2 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 17, 2020 Author Share Posted November 17, 2020 15 minutes ago, dhe said: You mentioned DMA. I know, the MyARC HFDC was the first to claim DMA capability, although, I also heard speculation that the MyARC FDC was on an evolutionary path to having DMA. So how do you envision DMA working in the Geneve2020 - Covid Edition? Aha, you are the first to confirm my fear, that 2020 no longer sounds futuristic. It is a year many will be happy to be rid of. Maybe I will just call it "2000". The DMA feature will work just as TI intended. The essential is that a peripheral takes over the bus for a period, and has full access to read/write the other peripherals just like the CPU would. This is fully described in the TM 990/12 theory of operation book (a good inspiration for me) A peripheral issues a HOLD* interrupt--its sort of an interrupt outside the usual priorities. When the CPU completes the current instruction, it asserts HOLDA* and prepares to go offline in the next cycle. It turns off all its outgoing bus signals (gets off the bus). The peripheral that requested HOLD* then can drive the bus. A typical use of DMA is a disk controller that has its own microcontroller. When a disk controller has finished a read operation, say a command to read a bunch of sectors, it asserts HOLD*. When the CPU grants HOLDA*, the disk controller does a memory transfer. It copies the disk data from its own memory, into the computer's main memory. When it finishes, it releases HOLD*. The CPU releases HOLDA* and goes back to its normal state. Or at least, that's how it works on the TMS9995. The 99105 does not have a HOLDA* output pin. Instead, the 99105 outputs a 4-bit bus status code. One of these codes is HOLDA*. When this appears, an external circuit must remember that condition, because the bus status codes are one thing that vanishes 40ns after the CPU enters the HOLD state, when it gets off the bus. The external circuit puts the HOLDA* signal on the bus. So I added that circuit. It's not working right--instead of initializing to 1 at startup, it gets stuck at 0. Because there is no transition of HOLD* from low to high, it is not cleared either (it is cleared on a rising edge of HOLD*, not HOLD*=1.) The external circuit remains stuck in the HOLDA* state, even though the CPU is never in that state. So I put in a DIP switch to disconnect it if necessary. It's necessary! -------- What is it good for? Coprocessor * If I put a separate 9995 in, it can be in charge of read/write bytes from the SD cards. It can copy from main memory, then do the write while the CPU does something else. * Start up boot loader. If that 9995 asserts HOLD right after the 99105 leaves the RESET state, it can copy the BIOS ROM (maybe a 55ns FLASH part) into a high-speed RAM (10ns cycle). This is a technique introduced by the IBM PC. It may be necessary to let the 99105 run at 6MHz (and overclocked???) as the ROM becomes too slow to keep up. It's kind of hard for the 99105 to copy its own BIOS ROM into a RAM at the same address space. * Fast block memory move. The 99105 can invoke an external instruction to move memory. The FPGA drives the process more efficiently than the 99105 could. 1 Quote Link to comment Share on other sites More sharing options...
+dhe Posted November 17, 2020 Share Posted November 17, 2020 Is this the manual your referencing? http://www.bitsavers.org/pdf/ti/990/990-12/2268239_990-12Descr_Oct83.pdf 2 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted November 18, 2020 Share Posted November 18, 2020 1 hour ago, dhe said: You mentioned DMA. I know, the MyARC HFDC was the first to claim DMA capability, although, I also heard speculation that the MyARC FDC was on an evolutionary path to having DMA. I'm wondering if this is an unused feature of the cards or perhaps more likely, that the DMA capability is really just on-card DMA-like transfers to its on-board memory? I don't recall there being any DMA transfers between any Myarc controller and the TI/Geneve host and from what I know of the SCSI DSR, its data transfers to/from the host are executed with unrolled MOVx instructions. 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted November 18, 2020 Share Posted November 18, 2020 The HDC9234 always uses DMA, but only to its on-board RAM. Otherwise, it would not be able to cope with the hard disk transfer rates. 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 18, 2020 Author Share Posted November 18, 2020 1 minute ago, mizapf said: The HDC9234 always uses DMA, but only to its on-board RAM. Otherwise, it would not be able to cope with the hard disk transfer rates. Does the DSR just spin, waiting for the DMA to finish? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.