+FarmerPotato Posted November 18, 2020 Author Share Posted November 18, 2020 53 minutes ago, dhe said: Is this the manual your referencing? http://www.bitsavers.org/pdf/ti/990/990-12/2268239_990-12Descr_Oct83.pdf That is a short version of the one I recall reading. It's all in there somewhere. Ah, here's the bigger one I remember. http://www.bitsavers.org/pdf/ti/990/990-10/0945417-9701B_990-10_HWRef_Nov80.pdf I must be thinking of the TILINE interface, which allows for memory transfers both ways between CPUs. 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted November 18, 2020 Share Posted November 18, 2020 I don't remember all details; it's many years ago that I wrote the emulation. (Just had a short look in the specs...) In general, there are status bits that indicate the completion of a command and the kind of completion (success, failure). You can also set an interrupt for the completion of a command. I'd have to look into the HFDC DSR to check which way it is working. 2 Quote Link to comment Share on other sites More sharing options...
+dhe Posted November 18, 2020 Share Posted November 18, 2020 I think the only place I really remembering DMA work was in the copy command of MDOS. MDOS would check ram free and cut loose DMA Transfer of the files directly into ram - as much as was available - did really phenomenal things with disk copies - suck it all in, spew it all out! The copy code for MDOS is rather lengthy.... 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 18, 2020 Author Share Posted November 18, 2020 It might be the RAM is not working. I have a bigger test program that does a CRU operation early on. I see the bus state is B, which is UI cycle. I see that the red trace, ALATCH, skips a beat . That is, the CPU adds a wait state, which it does for all CRU instructions. If I go back a little way, I see the CPU has fetched an instruction from 0018. It writes to 8018, which is R12, then reads from 8018. Presumably the read from 8018 is the SBZ executing and computing the address. Here is the list file: 0018 0018 020C 20 li r12,lights 001A 2200 0019 001C 1E00 20 sbz 0 led Unfortunately, the address bus in the CRU cycle shows FFFF. Maybe the RAM is not working. (sbz should produce the address 2201. the last bit of addr is MEM which is 1. I didn't display the CRU output bit of 0 here.) Something else is not working. The IO state is supposed to cause the bus signal: Address Signal 0000-7FFE SERENA* serial CRU enable 8000-FFFE PARENA* parallel CRU enable I see neither one. Reviewing the schematic.. PARENA* is broken in a dumb way. SERENA* would not activate if address is 8000 or up. I bet that if I troubleshoot the RAM, then I will get SERENA* . but parallel CRU is broken on this version of the CPU card. I didn't look at the RAM as much as the ROM yesterday. 1 Quote Link to comment Share on other sites More sharing options...
pnr Posted November 29, 2020 Share Posted November 29, 2020 On 11/18/2020 at 12:16 AM, FarmerPotato said: It's kind of hard for the 99105 to copy its own BIOS ROM into a RAM at the same address space. Actually, the original Cortex did that, using a technique called "write under". Initially, reads are from ROM, but writes to the same addresses are sent to RAM. Once the copy is complete, the ROM is switched off (using a CRU bit) and both reads and writes go to RAM. There are wait states for slow ROM access. On 11/18/2020 at 12:16 AM, FarmerPotato said: 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. Have you considered the TMS9911 DMA controller? Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted November 29, 2020 Author Share Posted November 29, 2020 2 hours ago, pnr said: Actually, the original Cortex did that, using a technique called "write under". Initially, reads are from ROM, but writes to the same addresses are sent to RAM. Once the copy is complete, the ROM is switched off (using a CRU bit) and both reads and writes go to RAM. There are wait states for slow ROM access. Have you considered the TMS9911 DMA controller? Thanks! I did not look at the TMS9911, I assumed it would not be obtainable. I was, so far, just implementing HOLD* and HOLDA*, which could be connected to a 9911. But the 9911 fits in with "use real chips". If it's done in the FPGA, it is just a memory-to-memory block move by the DRAM controller, not access to peripherals (and the DRAM transfer would work just by generating wait states, not HOLD*). I saw something like write-under on a 6502 or Z80 forum. There was one instruction that read through whole range of addresses, perfect for caching. Need a little loop instead. Write-under might not be such a stretch. I have a PLD that drives the ROM*/RAM output switch and bank bits. I could re-purpose the LED bit as the state bit. I have a spare flip-flop and LS125 tri-state gate, that could be used to generate one wait state. I think I just have inputs RD* and WE* and outputs ROM OE* and RAM WE*. If it is in "write under" state, ROM OE*= RD*, and !RD* to RAM's WE*. When in "run state" it sends only RD* to RAM's OE*. write under state (state=0) ROM OE* = RD* RAM WE* = RD* RAM OE* = 1 run state (state=1) ROM OE* = 1 RAM WE* = WE* RAM OE* = RD* I don't have to squeeze into PLD space for these--just one LS157 will do. Additional logic for whether ROM or RAM page bits are on the high address lines, and RAM CE*. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted December 8, 2020 Author Share Posted December 8, 2020 Hobby time has been scarcer lately, but here's a small update. I've changed the crystal to 3MHz, and now the RAM is working fine. So it was just a matter of my RAM being too slow for a 6MHz machine. Going to stay at 3MHz for the time being as it makes testing easier. Last night, I scrutinized every bus cycle of my tiny2 test program, all good. So encouraging. Tiny2 test used workspace registers, turns CRU bits on (At 6MHz, R12 was failing to read back from RAM) and copies a string from ROM to RAM. I verified each cycle through the logic analyzer. It's tougher because it doesn't capture the whole run at once. But it's repeatable every time, so I just specify microseconds-after-RESET to capture what I want to look at. It ends up in a JMP $ waiting for an interrupt, which I haven't tested yet. I need to make NMI a de-bounced button. Bouncing interrupts suck. Then the front button de-bouncer panel, I re-soldered as a cabled module. In crimping cables, I've graduated from "sucks less" to "finally adequate". Oh yeah, the green lighted power switch, picoPSU, ATX power distribution board, and quiet server fan are installed, and work great. Love that physical feedback. The PCB mounting holes were not usable (partly, because PCB mouse nibbles hurt the exact fit.) I just need to re-cut some plastic--not a priority. (Electronics Goldmine had this box of 24 super-slim server fans for $12!) A 9902 is attached and wired into a USB adaptor cable, so the next, tiny3 test program, will be serial port test code. 2 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted December 8, 2020 Share Posted December 8, 2020 2 hours ago, FarmerPotato said: A 9902 is attached and wired into a USB adaptor cable, so the next, tiny3 test program, will be serial port test code. Sounds like progress. Let me know if you need anything for serial port test code. I am getting more confident in my cross-assembler output so I could try porting some of my working code into a some kind of repeating string sender if that has any value. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted December 9, 2020 Author Share Posted December 9, 2020 Continuing "tiny2 test" INTA (acknowledge) pin asserts on bus state 5 (INTA) SERENA pin asserts on bus state B (IO) On RESET, clear LED with SBZ 0 String copy to RAM "Hello World!" Compare string in ROM and RAM If good, turn on LED with SBO 0 Then JMP $ NMI button works, code turns on LED with SBO 1, returns with RTWP Tests run 100 times with same outcome All tests pass! This concludes tiny2 test. 3 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted December 31, 2020 Author Share Posted December 31, 2020 Trying to debug serial I/O. I'm using the AdaFruit FTDI Friend 5V, between the PC and the 9902 (just 0-5V levels. No MAX232 yet.) First I got familiar with logic analyzer capturing bits from the PC TX. 2400 bps, 8N1. Starting off slow. On my board, tiny3.a99 test program initializes the 9902 at >1380. I observed all the CRU operations to load the rate registers etc. I'm confident that all is well on the software side. Logic analyzer captures show it doing all the right things. Problem is, the 9902 chip select doesn't seem to assert. My CRU decoder is an LS138. One of the enables (G2A*) is my SERENA* signal which indicates CRU access. The other 5 inputs are some address bits. Y2* out decodes base >1380 and goes to the 9902 chip enable. I can see all the proper inputs but no Y2*... I tried replacing the LS138 and got wackier results. Suddenly, the new LS138 is sucking the SERENA* signal down to 2.5V! That's messing with a '645 driver output from the CPU board. Is it really sinking enough current to screw up the driver? Naturally all the outputs are ~2.5V too. I tested all my LS138 on a breadboard. The original has no Y2* low output, all outputs are always high regardless of ABC inputs. It has been in my board for a lot of test cycles, and it is definitely bad. The other chips test good. So, bad LS138 chip, stable behavior but all outputs high (wrong). Good LS138 chip, erratic behavior and even the inputs get screwed up. Also, a separate LS138 is working as a memory space decoder--no issues there. I checked every socket pin for shorts.. at least at the bottom of the socket. The first couple LS138 were Fairchild. The first one of those is now bad. All the good chips act erratically, Fairchild and TI brand, plus one TI HCT138. Mostly from Unicorn Electronics. Maybe the 9902 is bad, and the chip enable is a short. Or worse, not a real 9902... Ideas? Remove the 9902 and check the LS138 alone. Check whether the chip's pins are really making contact? (bad socket) Re-check all the wires to the LS138 to see if any of them go to dumb places. Vacuum the boards looking for stray bits of metal. Go over the board with a microscope looking for bad connections. Here's a snapshot of some CRU activity. The code. First SERENA* assert is for the sbo 12. li r12,>1380 sbo 14 load control register li r0,>8B00 8N1 ldcr r0,8 * begin screen capture sbo 12 skip interval reg, go to reception reg li r0,>009c 2400 ldcr r0,11 reception rate register ldcr r0,11 emission rate register 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted December 31, 2020 Share Posted December 31, 2020 (edited) Are all of the enables good? one is supposed to be active-high. High 10k pull-ups on the outputs might help. After doing, that, removing the '138, do you still get erratic values at the pull-up point? caused maybe by the downstream circuit? Edited December 31, 2020 by jedimatt42 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted December 31, 2020 Author Share Posted December 31, 2020 21 minutes ago, jedimatt42 said: Are all of the enables good? one is supposed to be active-high. High 10k pull-ups on the outputs might help. After doing, that, removing the '138, do you still get erratic values at the pull-up point? caused maybe by the downstream circuit? The bad '138, the enables are all stuck high (tested bad on breadboard, outputs stuck high when in the board.) A good '138 (tested on breadboard) becomes erratic in the board. Enable outputs are ~2.5V, especially the G2A* input pulls SERENA* to ~2.5V (SERENA* is the output from a '645 driver and indicates a CRU cycle.) (I use '645 drivers for both the '244 and '245 roles.) Removing the '138 or leaving in the bad one, there is no interference with the bus signals like SERENA*. Quote Link to comment Share on other sites More sharing options...
Willsy Posted December 31, 2020 Share Posted December 31, 2020 Yes. Was thinking, it sounds like one of the inputs is floating. Either because you forgot to tie it low or high (G1 input is active high) or because of a bad connection. Quote Link to comment Share on other sites More sharing options...
Willsy Posted December 31, 2020 Share Posted December 31, 2020 2 minutes ago, FarmerPotato said: Enable outputs are ~2.5V, especially the G2A* input pulls SERENA* to ~2.5V (SERENA* is the output from a '645 driver and indicates a CRU cycle.) (I use '645 drivers for both the '244 and '245 roles.) Can you scope the outputs? If they're sitting at half of VCC then there's a good chance they are oscillating, which would again cause me to suspect floating/unconnected inputs. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted December 31, 2020 Share Posted December 31, 2020 3 minutes ago, FarmerPotato said: The bad '138, the enables are all stuck high (tested bad on breadboard, outputs stuck high when in the board.) A good '138 (tested on breadboard) becomes erratic in the board. Enable outputs are ~2.5V, especially the G2A* input pulls SERENA* to ~2.5V (SERENA* is the output from a '645 driver and indicates a CRU cycle.) (I use '645 drivers for both the '244 and '245 roles.) Removing the '138 or leaving in the bad one, there is no interference with the bus signals like SERENA*. Have you tried decoupling caps on Vcc of the 138 and/or other chips? Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted December 31, 2020 Author Share Posted December 31, 2020 8 minutes ago, Willsy said: Can you scope the outputs? If they're sitting at half of VCC then there's a good chance they are oscillating, which would again cause me to suspect floating/unconnected inputs. I removed the 9902 which sinks Y2* into its chip select. Here the red trace is the Y2* output of the '138, yellow is the G2A* input which is driven by bus signal SERENA*. They are unusually noisy. This capture is during a TB 27 instruction. BST is bus status from the 99105 (B indicates a CRU cycle) AD is address/data, you only see the address just after ALATCH* goes low. (LSB of an address is CRUOUT, not part of the 16-bit address) The address 13B7 (really 13B6) is the CRU address of a TB 27 instruction. CLKOUT is 3MHz RDBENA* is the direction of the backplane data bus WE*, RD* are the read and write strobe INTA well thats interrupt acknowledge seen right after RESET SERENA* indicates a CRU cycle. CRU... is the CRUOUT line. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted December 31, 2020 Author Share Posted December 31, 2020 11 minutes ago, TheBF said: Have you tried decoupling caps on Vcc of the 138 and/or other chips? Hmm, this 138 didnt have its own 0.1uF decoupling cap, but others are sprinkled around the board. Closest, there is one 0.1uF cap on the VCC/GND lines to the 9902, '138, 9906 (same as '259), '125. I removed the 9902, same result. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted December 31, 2020 Share Posted December 31, 2020 2 minutes ago, FarmerPotato said: Hmm, this 138 didnt have its own 0.1uF decoupling cap, but others are sprinkled around the board. Closest, there is one 0.1uF cap on the VCC/GND lines to the 9902, '138, 9906 (same as '259), '125. I removed the 9902, same result. Since that 138 is acting weird I would try one a close to the Vcc pin as possible. Can you see noise on the circuit GND when referenced to a "real" Lo Z ground? Wild shot in the dark. Is the power supply negative floating? (old analogue guy here. It's where I go first) 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted December 31, 2020 Author Share Posted December 31, 2020 9 minutes ago, TheBF said: Since that 138 is acting weird I would try one a close to the Vcc pin as possible. Can you see noise on the circuit GND when referenced to a "real" Lo Z ground? Wild shot in the dark. Is the power supply negative floating? (old analogue guy here. It's where I go first) I inserted the 5V power/gnd wires at the 138 socket, its definitely connected. The current > 500mA indicates something is oscillating (duh) because it was normally around 350mA. Here red is the B and yellow is SERENA*. It seems to be TRYING to go low A5 >0040 A6 >0080 A9 >0400 A10 >0800 A11 >1000 Selector A2:0 equal to 010 activates O2* (aka ABC and Y2* in TI datasheet) So that actually >1000 to >1300 are aliases, >1400 to >1700 are aliases, and so on. It's just temporary. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted December 31, 2020 Author Share Posted December 31, 2020 6 hours ago, Willsy said: Yes. Was thinking, it sounds like one of the inputs is floating. Either because you forgot to tie it low or high (G1 input is active high) or because of a bad connection. I checked the inputs vs the backplane. All are under 0.5 ohms, except G1 which is 0.8 ohms. Quote Link to comment Share on other sites More sharing options...
pnr Posted January 1, 2021 Share Posted January 1, 2021 (edited) When I look at the scope output picture(s) I am surprised by some of the signals. It is not clear why CLKOUT should not show a nice regular square wave, and I don't think that the BST lines should change state when the AS signal is low. Is it possible that the scope / analyser is not grounded and hence mis-measuring the signals? If your system is multi-board, is it possible that ground does not feed through? Or a ground loop perhaps? Edited January 1, 2021 by pnr Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 2, 2021 Author Share Posted January 2, 2021 6 hours ago, pnr said: When I look at the scope output picture(s) I am surprised by some of the signals. It is not clear why CLKOUT should not show a nice regular square wave, and I don't think that the BST lines should change state when the AS signal is low. Is it possible that the scope / analyser is not grounded and hence mis-measuring the signals? If your system is multi-board, is it possible that ground does not feed through? Or a ground loop perhaps? AS = you mean ALATCH? I've been getting all those glitches in the digital, that are not there when I look at the analog, or use the GPIO as inputs. The VB-8012 is an all-in-one power supply, 2 analog scope channels, 32 digital logic analyser, 8 digital I/O, func generator. When I use the digital I/O lines for clock input, there are no glitches. I have used those for BST and CLKOUT and they look fine. So I think it is crosstalk in the 32-wire cable. I thought it might be crosstalk between the bundle of digital leads (there are 32) which have a 8-inch ribbon cable. So I substituted the short connector without the 8-inch extension, no difference. I lowered the sampling rate, and lowered the logic threshold from 2V to 1V and it got somewhat better. Ground From the VB-8012 all-in-one, its 5V/GND power supply goes into my backplane. The logic analyser has 4 ground wires, which I put in near the signals measured. I believe all the WW pins add an extra 0.5 ohm (to both digital lead/gnd.) But that's the only ground loop I can think of. So I thought I had a common ground reference. I am not using the grounding lug on the scope. Not sure what I would attach to for an earth ground? Should it make any difference? The mains is a 3-prong power cord. There are 2 cards plugged into the 8-slot backplane now: the CPU PCB, and this memory+9902 prototype in wire wrap. The PCB has a pretty solid ground pour. The wire wrap has a branching ground tree, which goes back to 3 ground pins at the backplane. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 2, 2021 Author Share Posted January 2, 2021 I have removed 4 chips (including the 138) and the problem goes away. One LS125 was the only chip with floating inputs, and SERENA was the gate enable (it gates an active CRUIN onto the IN or AD0 pin). Going to put it back together tomorrow. Quote Link to comment Share on other sites More sharing options...
pnr Posted January 2, 2021 Share Posted January 2, 2021 Happy to hear that you found the problem. Yes, with AS I meant ALATCH; I was working with a M68K recently and got the signal names confused. Wow, that VB-8012 is a serious bit of kit. Does it have an input mode that adds some hysteresis to the 32 inputs? If so, it could maybe help with the cross-talk. Maybe @Jimhearne and @Stuart have suggestions -- they are much better with hardware issues than I am. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 5, 2021 Author Share Posted January 5, 2021 On 1/2/2021 at 5:03 AM, pnr said: Wow, that VB-8012 is a serious bit of kit. Does it have an input mode that adds some hysteresis to the 32 inputs? If so, it could maybe help with the cross-talk. Maybe @Jimhearne and @Stuart have suggestions -- they are much better with hardware issues than I am. I don't see any hysteresis option. Just the sampling rate and threshold. Lowering the sampling rate helps. I guess the other thing would be to construct a debug board with buffers. I don't know of a Schmitt trigger other than '04 or '14 inverters (so double up?). Maybe a row of LVC245A that I use a lot of (to connect to 3.3V chips). These have a rise time of 10 ns/V and might eat the glitches. The VirtualBench was rolled out to university labs while I worked at NI. I had a small part rolling it out to TechShop. I got this one for the employee price. Otherwise, buying separate tools would probably have had an advantage, except for convenience. It's a PITA to write automated tests in LabVIEW, but I've done it for my PLDs. (NI=National Instruments, not Texas Instruments, not National Semi (now part of TI), NI=Not Into making calculators since 1976!) 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.