Image Map Image Map
Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 32

Thread: SBC6120 - IOB6120 FLASH trouble

  1. #11

    Default

    Sounds like IOT1 should already be programmed correctly. If it was programmed without the protect/"encrypt" bit set you can just verify it to see if it matches "IOT1B.JED".

    Just-in-case: when examining the board note the other, "IOT2", GAL is actually orientated "backwards" compared to the rest!

  2. #12
    Join Date
    Sep 2020
    Location
    Perth in Western Australia
    Posts
    125

    Default

    Quote Originally Posted by kb811 View Post
    Sounds like IOT1 should already be programmed correctly. If it was programmed without the protect/"encrypt" bit set you can just verify it to see if it matches "IOT1B.JED".

    Just-in-case: when examining the board note the other, "IOT2", GAL is actually orientated "backwards" compared to the rest!
    Thanks Kevin,

    I used my TL866CS EPROM programmer to compare Jim's IOT1B.jed with the IOT1 contents and it verified good.

    Strangely IOT2 did not match the IOT2.jed supplied by Bob Armstrong. I subsequently reprogrammed the Lattice GAL22V10B successfully to match Bob's original IOT2.jed.
    Unfortunately nothing changed.

    I can see from my logic analyser trace that the FL command latches the upper address bits using the LDAR IOT and this kind of works except that the IOT does not generate LOAD_DAR_H signal even though the LXDAR processor signal is asserted, the WRITE signal is asserted and presumably the LDAR instruction 06410 appears on MA0..MA11 (this I cannot see on my logic analyser). The C0 and C1 signal from the GAL are correctly set HIGH to indicate to the processor to put ACC on the data bus. Unfortunately the LOAD_DAR_H is missing in action so the data (upper address bits) is not latched in the IOB6120 address latch.

    I thought that maybe the 74ACT373D address latch is bad and permanently pulls the LOAD_DAR_H input low, so I lifted that pin (pin 11 - ENC), but this too didn't improve the situation.

    There are some 5 ns glitches on LOAD_DAR_H but not when I would expect them. Strangely the glitches are not linked to LXDAR which is one of the signals LOAD_DAR_H is derived from. Maybe pin 22 on the GAL is faulty?

    I have some spare ATF22V10B GALs, but my TL866CS programmer cannot program those.

    I also checked the LOAD_DAR_H signal via a multimeter from pin 22 of the GAL all the way to pin 11 of the latch and all is well.

    I wonder if there was a newer/different version of the IOT2 firmware. The one from Bob's website is Revision B.

    Best regards
    Tom Hunter

  3. #13
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    4,461

    Default

    >>> I subsequently reprogrammed the Lattice GAL22V10B successfully to match Bob's original IOT2.jed.

    The trouble is that you may now have introduced an inconsistency within the system. I have two (2) separate IOT1 and IOT2 implementations (I think). I am not sure what the differences are as I do not have the JED file for the 'ORIGINALS'.

    If you write a simple piece of PDP-8 code with an IOT instruction of 6410 - this should be the instruction (on a WRITE) that operates LOAD_DAR_H (if I read the schematic and PLD files correctly that is).

    Dave

  4. #14
    Join Date
    Sep 2020
    Location
    Perth in Western Australia
    Posts
    125

    Default

    Quote Originally Posted by daver2 View Post
    >>> I subsequently reprogrammed the Lattice GAL22V10B successfully to match Bob's original IOT2.jed.

    The trouble is that you may now have introduced an inconsistency within the system. I have two (2) separate IOT1 and IOT2 implementations (I think). I am not sure what the differences are as I do not have the JED file for the 'ORIGINALS'.

    If you write a simple piece of PDP-8 code with an IOT instruction of 6410 - this should be the instruction (on a WRITE) that operates LOAD_DAR_H (if I read the schematic and PLD files correctly that is).

    Dave
    Thanks Dave,

    This issue is getting me increasingly confused. I tried to go back to basics and follow the logic by probing the inputs and outputs of the two GALs (IOT1B from Jim and IOT2 from Bob). I tried to follow the equations which I understand and look like they should work.

    When using an oscilloscope probe to check IOT1B signals like GROUP_1_IOT (pin 15) or GROUP_2_IOT (pin 14) I see static low when I expect to execute the 6410 IOT when I see the LXDAR_L signal going low.
    Confused I check pins 18 and 19 C1 and C0 and they are static low too. When I check these on the 50 pin header ( C0 pin 7 and C1 pin 8 ), then the signals work as expected. I thought there may be some form of insulating coating on the GAL solder joints, but no matter how hard I poke into the solder joints with the scope probe the signals are static.

    I am using a mixed signal scope with 16 digital and 4 analog channels. The digital channels are wired up to the relevant 50 pin IOB6120 header plus the FLASH_L signal from IC6 (74ATC138D a 1 out of 8 decoder on the IOB6120). I use one analog channel to poke around.

    I suspect it is time to go to bed to unconfuse myself.

    I am not quite sure what you mean when you wrote "IOT instruction of 6410 - this should be the instruction (on a WRITE)". What is the "(on a WRITE)" part? I think the IOT will also assert the WRITE signal, but is there more to it?
    Don't I just issue the 6410 IOT which takes the contents of ACC and pokes that out on the data bus.

    My PDP-8 assembly skills are still minimal. I can somewhat read the code while referencing the instruction set in the manual.

    Best regards
    Tom Hunter
    Last edited by thunter0512; January 24th, 2021 at 08:18 AM.

  5. #15
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    4,461

    Default

    >>> Don't I just issue the 6410 IOT which takes the contents of ACC and pokes that out on the data bus.

    Yes, but the signal will only be active when the WRITE signal is also active (i.e. during the WRITE portion of the IOT instruction).

    I just wanted to point that out - but it seems I confused you instead... Sorry about that .

    Dave

  6. #16

    Default

    As far as know there are two current IOT1 versions available:

    The original (IOT1.JED which can still be downloaded from Bob's Spare Time Gimzos website).
    The one updated to support the IOB6120 (IOT1B.jed which can still be downloaded from Jim Kearney's website).

    One question I had with them at the time (and it is still the case at the moment) was that the one on Bob's site had a more recent file date (2918 Jul 3 2003 ./SBC6120_Design/PLD/IOT1.JED) than the one on Jim's site (2923 Jan 30 2003 ./IOB6120/PLD/IOT1B.jed).

    However, the date on the source for Bob's version (Jun 5 2001) is the oldest of both sets, so I assumed the newer date on IOT1.JED was the result of a rebuild, and so came to the conclusion it was correct to use the IOT1B with, or without, the IOB6120. The date on the source for IOT1B is more recent than the JED; I recall compiling stuff and coming to the conclusion that there were no functional changes. I haven't seen any problems that could be attributed to this. I cannot recall the whole of the exercise I went though to resolve those conflicts. I think the IOB does not work properly without IOT1B.

    As far as I can tell there is only one current IOT2 version (2142 Jul 3 2003 ./SBC6120_Design/PLD/IOT2.JED, which can still be downloaded from the Spare Time Gimzos website).

    When I was building my SBC6120-RBC and IOB6120 I downloaded versions from various places, I did not find newer or different versions elsewhere.

    I have redownloaded IOT1B and IOT2 from Jim and Bob's sites, pulled the GALs from the two SBC6120-RBC's I have and verified them against the downloads. They matched.

    The differences between my board set and Tom's seems to be that I have the "RBC" version and Vince's version of the IOB, and the more recent "BTS6120" version.

    Code:
    SBC6120 ROM Monitor V320 Checksum 3752 6072 3515 09-APR-10 21:15:39
    Copyright (C) 1983-2010 by Spare Time Gizmos.  All rights reserved.
    
    NVR: 2048KB
    IDE: Not detected
    CFC: 961MB - SQF-P10S1-1G-EC6
    IOB: ROM V0114, FPGA V0111
    C/C: 01/24/21 16:52:39
    
    >

  7. #17
    Join Date
    Sep 2020
    Location
    Perth in Western Australia
    Posts
    125

    Default

    Bob Armstrong has created a great product, but he has also has created a terribly confusing mismatch of files where the GAL sources don't match the supplied JED files and up-to-date PCB design files, gerbers and schematics are missing in action.

    I have a GAL firmware payload which clearly does not match the source. Both are the latest and greatest from Bob's website. IOT2.jed says Revision B from July 2003 but IOT2.pld says Revision 2 from July 2001.

    I am really struggling with the basics here. This shouldn't be difficult but the discrepancy between published sources and reality is just crazy.

    Could somebody please supply the correct/matching JED and GAL source files for a configuration with SBC6120, IOB6120 and FP6120?

    I am trying to debug this problem of the LOAD_DAR_H signal never beeing cleanly asserted (but glitching) but I am looking at published GAL sources which clearly don't match the programmed (published) GAL payload.

    Kevin: could you please point me to exactly where you download the IOT2.pal and IOT2.jed files from?

    Thanks and best regards
    Tom Hunter

  8. #18
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    4,461

    Default

    You are aware that the IOT2 PAL is installed on the board ‘backwards’ (i.e. the opposite way round to all of the other ICs with the same orientation)? Just want to make sure you are aware of that.

    This appears to be the same for the STG and RCB variants of the SBC6120.

    Have you downloaded the RCB PAL files just out of interest for comparison with what you have - or do you think that will confuse further?

    Dave

  9. #19
    Join Date
    Sep 2020
    Location
    Perth in Western Australia
    Posts
    125

    Default

    Quote Originally Posted by daver2 View Post
    You are aware that the IOT2 PAL is installed on the board ‘backwards’ (i.e. the opposite way round to all of the other ICs with the same orientation)? Just want to make sure you are aware of that.

    This appears to be the same for the STG and RCB variants of the SBC6120.

    Have you downloaded the RCB PAL files just out of interest for comparison with what you have - or do you think that will confuse further?

    Dave
    Thanks Dave,

    I have the files from both RBC archive and the originals from Bob's site. They match.
    Both ICs are in the correct orientation. Not much would work otherwise anyway.

    Best regards
    Tom Hunter

  10. #20
    Join Date
    Jun 2012
    Location
    UK - Worcester
    Posts
    4,461

    Default

    >>> Not much would work otherwise anyway.

    Just thought I would mention it though...

    I had to try very, very hard to put IOT2 in 'the wrong way' when I assembled my RCB!

    Dave

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •