Jump to content
IGNORED

Bringing up "Geneve 2020": Debugging Help Please!


FarmerPotato

Recommended Posts

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?

 

BadClock.thumb.PNG.fae57311d524f830f029adf44678977c.PNG  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.

Link to comment
Share on other sites

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.:skull: 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!

  • Like 1
  • Sad 1
Link to comment
Share on other sites

  • 2 weeks later...
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.:skull: 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.

 

 

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

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.

 

Wire Wrapping Sleeve, 507100 by Wi

 

Wire Wrapping Bit, SB30MSH-B by OK M&T, 30 AWG

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

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.

 

213287394_J2PerfectInitialization.thumb.png.2d91ea959225c709ec61f702ae92597a.png

 

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

 

 

  • Like 4
Link to comment
Share on other sites

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.

 

IMG-1428.thumb.JPG.3d9f97356356c214ec317fd5b920c921.JPG

 

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/

 

 

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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. 

 

 

1454646256_J2afterbackplanereflow.thumb.png.55d31785173040e2da3612c222497dc0.png

 

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

 

 

 

  • Like 2
Link to comment
Share on other sites

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:                                 1366791272_J2ReadingWPPC.thumb.png.cbde1c861b3ed75186aea9daf5983d4b.png

 

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

 

 

 

 

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

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!  

 

1584002132_J2BusActivitywithDMAoff.thumb.png.2b17e2ad2f00d45975fa036d741d3c65.png

 

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.

 

  • Like 3
Link to comment
Share on other sites

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.

1125124746_J2crummyD3read.thumb.png.55dd5d74a6fda576286d5189a337a688.png

 

 

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.

 

 

 

  • Thanks 1
Link to comment
Share on other sites

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.

 

1224106105_J2reads0004.thumb.png.efa13c1c320a3051c6ec9ff833d7835f.png

 

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

 

 

ImageImageImage

 

 

Here it is, looping around to the start.

 

646044124_J2loopsaround.thumb.png.5b2d583200ddb41ce368c73928da1871.png

State     Addr
3 IAQ RD 0048     B 
2 IOP RD 004A     DATA >0008
3 IAQ RD 0008     NOP
3 IAQ RD 000A     NOP

 

YAY!

 

 

  • Like 2
Link to comment
Share on other sites

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)

  • Like 2
Link to comment
Share on other sites

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?

 

 

  • Like 1
  • Haha 2
Link to comment
Share on other sites

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.

 

 

 

 

 

 

 

 

 

 

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...