SBC6120 - IOB6120 FLASH trouble

[thunter0512]

Hmmm ...

I wrote a small loop using the SBC6120 monitor which continuously issues the 6410 IOT (as suggested by Dave earlier) and the LOAD_DAR_H signals works perfectly.

I see two nasty glitches on the C0 line but this is not critical in this specific context because C0 only determines if ACC is cleared or not (C1 determines the direction and IS critical). The C0 glitch is a bug in the IOT1B firmware which should be fixed (but may be harmless).

Now why is the FL command and the associated 6410 IOT not generating LOAD_DAR_H ???

The monitor program reports itself as version V266 from 3 July 2003.

So a dumb little user program issues the 6410 IOT and LOAD_DAR_H is asserted as expected. The monitor program in the FL (FLASH download) context does the same and the LOAD_DAR_H is NOT asserted.

Why???

Thanks and best regards
Tom Hunter

[daver2]

>>> Why???

$64,000 question...

BTS is running in panel mode isn't it - not in 'user program' space.

I wonder if that is pointing us in the right direction?

EDIT: Memory management settings come to mind for accessing the data - but not the IOT itself... Need to look into the PAL coding and see if there is anything that would affect the output. May be worth looking around IOT1 and IOT2 to see which signals are different - and whether they are used or not in the decoding of the LXDAR...

Dave

[thunter0512]

>>> Why???

$64,000 question...

BTS is running in panel mode isn't it - not in 'user program' space.

I wonder if that is pointing us in the right direction?

EDIT: Memory management settings come to mind for accessing the data - but not the IOT itself... Need to look into the PAL coding and see if there is anything that would affect the output. May be worth looking around IOT1 and IOT2 to see which signals are different - and whether they are used or not in the decoding of the LXDAR...

Dave

Thanks Dave,

I am a bit lost with this "panel mode". I will have to read up about this to understand the difference between "panel mode" and normal "user PDP-8" mode.

The signals used to assert LOAD_DAR_H in the two GALs are:

in IOT1
[MA3-8] = 410 and LXDAR input is used to work out that this is a 641X IOT.
GROUP_1_IOT and GROUP_2_IOT outputs are set both high when a 641X IOT has been decoded (LDAR is one of 4 possible IOTs in this context).

in IOT2
If both GROUP_1_IOT and GROUP_2_IOT inputs are high then we have an IOT 641X.
[MA9-11] == 0 and 641X means we have an LDAR IOT (6410).
if LDAR and WRITE are active it sets the LOAD_DAR output high.

There is no obvious way for the "panel mode" to interfere unless it somehow affects [MA3..11], LXDAR or WRITE. On my logic analyser I see that LXDAR and WRITE are Ok, so that leaves only [MA3..11].

It is possible that the encoding of LDAR changed and the code in EPROM is different from the source even though both claim to be version 266.

It is 2:15 am so time for bed. Hopefully tomorrow I can resolve this mystery.

Thanks and best regards
Tom Hunter

[daver2]

Have a good rest!

I would check pin 2 (GROUP_1_IOT), pin 1 (GROUP_2_IOT), pin 6 (WRITE) and pins 3, 4 and 5 (MA9, 10 and 11) around PAL IOT2 to see if any of these pins change appearance depending upon whether you are running the IOT instruction or the FL command.

If there is an observable difference in the output signal from pin 22 of IOT2 - we must be able to see it as an input (or combination of inputs) to the PALs somewhere...

A (very) quick introduction to panel mode:

Without a physical front panel there is no possible means of debugging a 6120-based system - hence panel mode. In order to access and debug a PDP-8 program running in 'program space' means that the panel ROM can't use any of the program space itself. It therefore has its own ROM and RAM acting as a surrogate front panel.

However, the PDP-8 is required to be able to read from - and write to - both program space (in order to debug and load software) as well as its own panel memory. In order to do this, the general way is to have some form of memory mapping so that indirect memory references access 'program space' and non indirect memory references access panel memory. Of course - lots of possible strategies are valid here...

EDIT: So, there shouldn't be any difference regarding an IOT of '6410' in either context. However, there are a lot of 'ifs, buts and maybes' around the usage of the flash memory etc. It does appear to make much use of the memory mapping features (i.e. MM2 and MM3 pseudo instruction IOTs). If these latches are not working correctly - the data may not be correctly read or written. However, it shouldn't affect what is latched into the DAR...

Dave

[thunter0512]

Thanks Dave,

I think I now understand the panel mode and the logic implemented in the memory GAL dealing with MM0 - MM3.

Bob and Jim sent me the latest and greatest GAL firmware source and JED files, and I successfully programmed the two GALs with my TL866CS programmer (it does the original Lattice parts but not the new Atmel parts).

I have also rebuilt the BTS6120.plx sources (after building Windows binaries of the PALX assembler and PDP2HEX) and loaded the newly generated hex files into two EPROMs (I built Jim's source file and there are some small differences in the generated hex files between my build and Jim's - odd).

At least now I have a fully consistent set of GAL and EPROM sources & binaries and can rebuild as needed.

It turns out earlier I was getting confused by the LOAD_DAR_H glitches as they obscured the real one. Looking at them on the analog channel of the scope you can see some high speed oscillations wiggles well above the logic 1 threshold.

Here is a screenshot of the scope showing the glitch:

SBC6120_glitch1.png

I suspect it is cross talk as it occurs just as the CPUDX[4..11] (D0 - D7) on the scope changes from 0xFF to 0x8D.
D8 in red (labelled "ldar") is LOAD_DAR_H.
D14 in blue (labelled "lxd") is LXDAR - note how LXDAR remains high throughout the glitch.
Analog channel 1 in yellow set to 2V/div is LOAD_DAR_H as seen on pin 11 (ENC) of the 74ACT373D octal latch.

The result is some garbage getting latched in the address latch so the FLASH verify fails.

If I trigger on a pulse duration of at least 100 ns on the LOAD_DAR_H line and I get reliable triggers on the real (non-glitch) signal at the time I expect them.

I clearly see a 0x00 on the data lines CPUDX[4..11] when the real LOAD_DAR_H happens.

Here is a screen shot of a good LOAD_DAR_H - note how the data is 0x00:

SBC6120_real_LDAR.png

Earlier Jim Kearney suggested that "74HC373 works better". It is a slower part so maybe less sensitive to any possible glitches.

Thanks and best regards
Tom Hunter

[kb811]

Bob and Jim sent me the latest and greatest GAL firmware source and JED files...

Ah, interesting. Are they updated compared to what can be downloaded from their websites?

I have also rebuilt the BTS6120.plx sources (after building Windows binaries of the PALX assembler and PDP2HEX) and loaded the newly generated hex files into two EPROMs (I built Jim's source file and there are some small differences in the generated hex files between my build and Jim's - odd).

I think there will be at least one difference as the monitor displays a build time and date at start-up... that will have been set at compile time, not hard coded - look for "SYSNM3" in the code.

Earlier Jim Kearney suggested that "74HC373 works better". It is a slower part so maybe less sensitive to any possible glitches.

My SBC6120s have been built with 74HC373s (SN74HC373N)... There is an ACT373 on the IOB.

[thunter0512]

Ah, interesting. Are they updated compared to what can be downloaded from their websites?



I think there will be at least one difference as the monitor displays a build time and date at start-up... that will have been set at compile time, not hard coded - look for "SYSNM3" in the code.



My SBC6120s have been built with 74HC373s (SN74HC373N)... There is an ACT373 on the IOB.

The GAL firmware sources and JED files are different as compared to what is on their websites. It seems I cannot attach a ZIP file, so if you PM me with your email address, then I can send the latest files to you.

I didn't think of the date/time - thanks.

I have a few of the SOIC-20 package SMD parts on order (hopefully Friday). I don't want to start hacking around with a through hole DIL part.

Surprisingly even with a 1k pull-down there is some ringing on the LOAD_DAR_H line. The maximum amplitude with the pull-down is about 1.6 volts which is between valid TTL levels. Of course my 100 MHz scope may not capture the real peak. Somehow there is a surprising amount of energy in the ringing that it is not dampend with the 1k pull-down.

I am reluctant to go to an even smaller pull-down. I don't want to overload the GALs output drive capability.

As you are also using the ACT373 I now wonder if you are using the FP6120 or just the IOB6120 piggy-backed on the SBC6120. The LOAD_DAR_H signal goes through a longer path when using the FP6120 with the potential to pick up more cross-talk.

Thanks and best regards
Tom Hunter

[thunter0512]

Success!

On a hunch using a wire I connected pin 15 (LOAD_DAR_H) of the 50 pin header (J4) on the SBC6120 directly to the 74ACT373 latch-enable pin while leaving the 1k pull down in place.

It is happily (albeit slowly) downloading the firmware ...

I am using a throttled TeraTerm for the download (2 ms delay per character and 500 ms per line), but will use Kermit with its prompt capability once this finishes.

Thanks for all the help!

Best regards
Tom Hunter

[daver2]

Good old noise and ringing...

Well done in getting it to run though. Have fun...

Dave

[DougIngraham]

Surprisingly even with a 1k pull-down there is some ringing on the LOAD_DAR_H line. The maximum amplitude with the pull-down is about 1.6 volts which is between valid TTL levels. Of course my 100 MHz scope may not capture the real peak. Somehow there is a surprising amount of energy in the ringing that it is not dampend with the 1k pull-down.

I am reluctant to go to an even smaller pull-down. I don't want to overload the GALs output drive capability.

If you are trying to get rid of ringing you should use a snubber. In case you don't know a snubber is a resistor with one end connected to ground and the other end connected to a low value ceramic cap (0.001 uf as an example). The other side of the cap is connected to the signal you want to get rid of the ringing on. There are ways to calculate the values but the quickest way is to look at the frequency of the ringing. Add a cap from ground to the signal. You have the correct capacitance when the ringing is about half the frequency of the original. Then you start playing with resistance. For your purposes try somewhere in the 10 to 20 ohm range. I am guessing this will be too large and you will want to work your way down. This was a trick I learned from a power engineer when designing power supplies. It takes less time to find experimentally than running the numbers and you can never buy the value the equations spit out anyway so you still have to experiment to find out what works good enough. Because of the capacitive coupling the snubber only presents a load at the transition time so your output gates do not suffer any real additional heating.
Good luck!