Jump to content
IGNORED

FIXED: RESET repeats in FORTI-2 interface


FarmerPotato

Recommended Posts

So, for the umpteenth time I have tore down my FORTI-2 sidecar and rebuilt it. The previous board actually worked to spec. It buffered the address and memory bus, and supported the 4A with reads and writes.

 

The current board is causing this awful behaviour where the RESET repeats after a few cycles. I don't know where else to look, but what I don't understand is what normally generates the RESET signal.   Maybe if someone could explain that area to me, I would see the solution.

 

RESET.thumb.PNG.19badfc7941d1bd308ceba31a663b885.PNG

 

Yellow = RESET line. Blue = PHI3

 

If I remove my sidecar, the 4A is fine. When I connect it, this happens again. Sometimes it just locks up--no RESET* low, but no MEMEN* either.

 

I've checked for shorts. I've checked these signals on other side port pins:

 

IAQ 3.5V

MEMEN 5V

RESET 5V..0V

DBIN  5V..0V

A15    0

WE    4.5V

PHI3   0-4V

CRUCLK 4.5V

 

Address pins show random values with  a solid 0-4.5V edge. Actually, A12, A13, A14 are active during the few cycles after RESET. I see some random values on A0, not sure when.

 

HOWEVER the data bus shows >FF during the high pulse of RESET, but it never rises above 1V. I know the D lines should be like 4.5V.

 

My board has 4 74LVC245A birectional buffers. All of them have DIR=1 (away from the console).

 

U1 buffers the Data bus. The DIR pin has a 3.3K pullup to VCC to keep data pointed away from the console bus. I'm driving this to 1 as well.

     U1 may be part of the problem...

     OE (in my schematic, DBEN1) was mistakenly routed to another input. I'm driving it from a wire, because floating inputs are bad!

     On the RESET high-going edge, the output lines echo the weak 1V signal seen on the Data bus pins, even though OE is high!

 

U2 buffers the 8 control signals and has OE=0, which looks good.

U3 and U4 buffer 16 address lines, OE=1, DIR=1.
 

I think the board was working before. There was a 3.3K pullup on U2's DBDIR which may have been flaky. I fixed that by replacing it with a shunt.

 

There is also a LV125 3-state buffer driving the CRUIN line, but it is turned off. 

 

Here is the schematic (mistakes and all. "corrected" is for the next revision.) Since it's not fair to describe it but not show it. (This is only the interface half of the project BTW)


 

IceTea_v02.thumb.png.63d3de72ee1b2f2cbf018fcef3813dc6.png

 

The main idea here is to multiplex and encode all the side port signals into just 16 lines.

 

There are 3 control lines in (DEC), 3 out (ENC), and an 8 bit bus (which switches very very fast). The PLD encodes states of the 4A memory cycle: read LSB, read MSB, write LSB, write MSB, read CRU, write CRU, and the user sends back DEC states to drive the various DBEN1, ABEN1, ABEN2, DBDIR.

 

The previous revision, 0.1, squeezed all the lines onto 24 pins, but failed to meet timing for CRU. 

 

One exciting feature is dual DBEN1 and unused DBEN2. This interface is intended to go on the 16 bit data bus eventually.

 

  • Sad 1
Link to comment
Share on other sites

/RESET is generated by the TIM9904 clock chip, and is triggered by the power-up reset circuit and the reset input from the cartridge port (so inserting a cartridge generates a /RESET pulse). I don't see your circuit interfering with either of those. If you remove the '245s and '125 from your card one at a time, does the problem go away? Is one of those causing the problem ... although I don't see how as they are all buffering away from the console.

 

 

Edited by Stuart
  • Like 2
Link to comment
Share on other sites

Thanks folks.

 

One plan then is to remove all the chips. 

 

One focused question is: does the RESET pin of the side port come FROM the 9904's RESET out signal (9904 pin 5 FFQ), or does it go TO the cartridge port pin 1 network that can force a reset input TO the 9904 (clock generator pin 4 FFD.)

 

The TI schematics book doesn't say!  The Bunyard manual describes the side port RESET pin  as an output, without commentary.  And, the P-box interface buffers RESET through a 244, so, I don't see why my 245 buffer is any different. (I use LV245As everywhere instead of LS244s, for the nice pin layout and one less part to order.)

 

I think I did not see the RESET behavior when I had a flaky signal on the 245's OE. If so, the buffer might have been in Hi-Z state. Maybe when active, it is putting a load on RESET? Also, before the RESET behavior, I saw some bad behavior on the A15 line! Programming the MiniMemory resulted in a lot of bad writes to odd addresses.

 

I think it's possible that my LV245A is bad.  I have used LV245As successfully up until this revision, I don't think I'm wrong in interfacing TTL out to LV cmos in (The A in 245A indicates 5V input compatible.)

 

 

Link to comment
Share on other sites

And Thierry's page answers that: Yes, side port RESET* is an output.

http://www.unige.ch/medecine/nouspikel/ti99/tim9904.htm

 

The 9904 FFQ (RESET*) output does go to the side port pin 3. It is buffered twice, though, to add a slight delay (according to the datasheet for 74LS04, about 25ns).

 

I don't see a way that my side port card could be messing with the cartridge port auto-reset circuit, given that side port RESET* is an output.

 

My next working theory is that when the 9900 retrieves the vector at >0000, it sees all >FFFF because I'm messing up the address or data bus somehow. I don't see any information that the 9900 could do anything but lock up in that case, nothing that it do to cause the 9904 to issue another reset.

 

Are there any other ways the 9900 or 9901 can cause the 9904 to do a RESET? maybe a CRU bit? It does  look like my console is trying to read CRU in this jam.

 

 

Link to comment
Share on other sites

2 hours ago, FarmerPotato said:

Are there any other ways the 9900 or 9901 can cause the 9904 to do a RESET? maybe a CRU bit? It does  look like my console is trying to read CRU in this jam.

 

Potentially they could cause a jump to the reset vector, but it is only the 9904 that can change the state of the /RESET hardware signal. As far as I can see. Are you able to monitor the /RESET input to the processor, and compare that with what you see coming out of the side port? In case your '245 is trying to drive the /RESET output?

Link to comment
Share on other sites

Clutching at straws, perhaps also try replacing the TIM9904 (or it might be an older 74LS362 with 48 MHz crystal) if it is socketed. The /RESET output is synchronised by clock phase 3, and some of the other phases are instrumental in generating A15, so if connecting your board is somehow stressing it (not sure how!) it might be messing with the clock outputs? Or try monitoring the clock phase outputs?

Edited by Stuart
Link to comment
Share on other sites

9 minutes ago, Stuart said:

Potentially they could cause a jump to the reset vector, but it is only the 9904 that can change the state of the /RESET hardware signal. As far as I can see. Are you able to monitor the /RESET input to the processor, and compare that with what you see coming out of the side port? In case your '245 is trying to drive the /RESET output?

I think it is past time to open up a console, solder on a bunch of little wires, and bring it out to a logic probe header. Yeah! Borg console!

 

 

  • Thanks 1
Link to comment
Share on other sites

6 minutes ago, HOME AUTOMATION said:

It's cute how they used different numbering.

 

I keep wondering if c606, r606 figure into this ...probably not

 

I don't see where c506, r514 go. I imagine they go to the cartridge port.

c506, r514 - the circuit diagram is a bad copy - they connect to the line to the left, that goes up towards the top of the page.

 

Link to comment
Share on other sites

1 minute ago, Stuart said:

c506, r514 - the circuit diagram is a bad copy - they connect to the line to the left, that goes up towards the top of the page.

 

 

I think that line goes to cartridge port pin 1, the reset pin. Also on the typeset schematic, C506 has its value in  mH. It's not an inductor. 

 

  • Haha 1
Link to comment
Share on other sites

Here's a sample of what's working correctly.

 

You can see the MEMEN and WE signals. Unfortunately DBIN is not visible.

 

ENC shows what state the CPU is in.

 

ENC 000 default, can be reading CRU.

ENC 010 begins a memory write cycle

ENC 011 is writing a LSB byte (the CPU is actually writing to 16 bit RAM, so A15 is not true here and there is only one write pulse.)

ENC 001 would be a read cycle (you can't see DBIN)

 

This proves out my idea of encoding the CPU state into 3 bits.

The address bits are scrambled because I wired them in the same order as the side port (this will be unscrambled in software.)

read-write.thumb.PNG.47d6746e1cf753cc23274272cdf6a8f2.PNG

Definitions

 

ENC states (from the PLD) (write/read from 9900 point of view)

/*    000 read CRU (default)    MEMEN=1  */
/*    001 read memory 1 LSB   MEMEN=0, DBIN=1, A15=1    */
/*    010 transition                  MEMEN=0, DBIN=0, WE=1 */
/*    011 write memory 1 LSB   MEMEN=0, WE=0 , A15=1  */
/*    100 write CRU                 MEMEN=1, CRUCLK=0 */
/*     101 read memory 2 MSB  MEMEN=0, DBIN=1, A15=0     */
/*    110 write memory 2 MSB   MEMEN=0, WE=0, A15=0   */
/*    111 reset                           RESET=0 */


DEC states (to the PLD)  DEC[2:0] (read/write from 9900 point of view)
/*    000 read memory LSB  DBEN1=0, DBDIR=0   */
/*    001 read memory MSB (FUTURE 16 bit bus) */
/*    010 write memory LSB   DBEN1=0, DBDIR=1   */
/*    011 write memory MSB (FUTURE 16 bit bus)  */
/*    100 write address MSB ABEN1=0  bus scrambled  */
/*    101 write address LSB  ABEN2 =0  bus scrambled  */
/*    110 drive CRUIN=0      CRUEN=0, CRUBIT=0       */
/*    111 drive CRUIN=1      CRUEN=0, CRUBIT=1         */

 

  • Like 1
Link to comment
Share on other sites

11 minutes ago, GDMike said:

I've got lots of runner wire(wire wrap) for that purpose! Don't ya just a hate these traces not being able to handle it. But even WW can't save every thing..darn

Yeah, its really wire wrap. I did everything with wire wrap long ago. Nowadays people are mystified when I show wire wrap.

I used copper braid to clean up the pads after removing the chip.

That must have damaged the trace.

  • Like 1
Link to comment
Share on other sites

17 minutes ago, TheBF said:

I have used a soldapult for many years. If you keep it clean and lubricated it seems to work quite well.

However the new ones seem to break 10X faster than the old ones. ?

 

I haven't tried one of those lately. I have a Hakko vacuum gun but I have destroyed pads after 2-3 repetitions with it.

 

  • Like 1
Link to comment
Share on other sites

Usually I say to myself, " I think it's going to get worse", and it does. I remember telling myself, I do that a lot cause no one else understands, when I repaired a bad board on a beautiful Panasonic stereo "this is the last time I can do this to this board, it's now or NEVER BOARD!!! And that seems to help, that amp section still kicks!!!. Sharpen that solder tip, and go for it!!

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