Re: New Board Development - SBC6120-RBC Edition [message #560 is a reply to message #454] |
Sun, 24 April 2016 09:13   |
 |
Andrew B
Messages: 467 Registered: October 2015 Location: Near Redmond, WA
|
Senior Member Administrator |
|
|
I built up my prototype board yesterday.
No magic smoke! But no POST either Dug out my Open Bench Logic Sniffer....
The HD-6120 has power, ground, clock, I can see it indicating /RUN is high during /RESET when I push the reset button and then coming back online, and the CPU sending out instruction fetch cycles...
THe BTS6120 POST routine is pretty extensive, if the ROMs and the POST code display are working it will change the POST LEDs even before testing the RAM.
A few possibilities at this point:
-I made some kind of screwup on the board layout.
-My 22V10s are not programmed properly. I did some file hacking to allow my Chinese programmer to actually program the 22V10s. The software said it was able to both program and read back the fuse maps, but it's still suspect.
I'll keep everyone posted..heh... if you want to build your boards and help with debugging that's great, or if you want to wait I totally understand, a cut & jumper fix if required will be way easier on an unbuilt board.
[Updated on: Sun, 24 April 2016 09:15] Report message to a moderator
|
|
|
|
Re: New Board Development - SBC6120-RBC Edition [message #563 is a reply to message #454] |
Sun, 24 April 2016 22:11   |
 |
Andrew B
Messages: 467 Registered: October 2015 Location: Near Redmond, WA
|
Senior Member Administrator |
|
|
Yeah, I've done a lot of chip swapping today figuring things out. I managed to get the chips out of my original board (machine tooled sockets + not perfectly formed DIP leads with some outward preload on them = super super hard to remove....and the decoupling caps being so close to the sockets in the original board design don't help either) and piggyback in some dual swipe slots to make swapping things in and out easier for testing.
Confirmed that my MEM GAL and ROMs are good and work in a the STG board (I made 28C256->27C256 pinout adapters out of some some sockets by cutting off pin 1 on the bottom of the socket, adding a small jumper line between Pin 27 -> Pin 1 under the IC, and bending out Pin 27 of the IC to make the 28C256s work in the original Spare Time Gizmos boards). IOT GALs are no good.
However, even with all of the known working chips out of the original STG board, the new board doesn't work.
I also reviewed the schematic for the SBC boards, and found a pretty huge mistake.
The memory address order on the ROM chips follows a strange order, and I totally missed reproducing that when I laid out the board and screwed it up.
Here's the relevant part of the original SBC6120 schematic:

And he's my schematic:

(Note that because KiCAD doesn't support "heterogeneous buses" with different designations within the bus like MA, EMA, etc, I changed the extended memory address signals EMA0, EMA1, and EMA2 to MA12, MA13, and MA14 for the purposes of routing the buses cleanly around the different parts of the schematic. I went back and confirmed that at least I did that right.....  .
In order for these boards to work one of two things has to happen:
-An adapter shim needs to be made to plug into the sockets, or the ROMs need to be put off to the side on a breadboard, such that the address lines are switched back to their correct order.
-We need to write a Python script to load the Intel hex file, make a pair out of each address/8-bit byte of data, exchange the address bits as they are switched in the hardware, sort the pairs by address, and output a modified hex file such that each address outputs the correct byte of data even though the lines are scrambled.
So sorry guys, I feel like an idiot. I can probably design up a simple adapter board that will make the fix a little more cleanly for the 4 of you and have some made....
|
|
|
|
|
|
|
Re: New Board Development - SBC6120-RBC Edition [message #568 is a reply to message #567] |
Mon, 25 April 2016 07:13   |
 |
will
Messages: 213 Registered: October 2015
|
Senior Member |
|
|
Try the attached.
Contents as per the "SW" directory, with these additions:
romscrambler: A short python script to scramble the ROM contents
scramble: A shell script which uses srecord to convert the high/low HEX files to binary, scrambles them, then converts the resulting binaries back to intel HEX format.
The other files are the output of running the "scramble" script:
271L.ROM, 271H.ROM: Binary versions of 271L.HEX, 271H.HEX
271L-SCR.ROM, 271H-SCR.ROM: Scrambled ROMs (binary version)
271L-SCR.HEX, 271H-SCR.HEX: Scrambled ROMs (intel hex version)
Let me know if it works!
Will
Copy of the "romscrambler" script follows for those who don't want to download the .tar.gz just to see it:
#!/usr/bin/env python
import sys
# map of address pin connections: bus address line -> ROM address line
addr_line_map = {
0: 11,
1: 10,
2: 9,
3: 8,
4: 7,
5: 6,
6: 5,
7: 4,
8: 3,
9: 2,
10: 1,
11: 0,
12: 14,
13: 13, # we got one right!
14: 12,
}
def scramble_addr(busaddr):
romaddr = 0
for bus_bit, rom_bit in addr_line_map.iteritems():
if busaddr & (1 << bus_bit):
romaddr |= (1 << rom_bit)
return romaddr
if __name__ == '__main__':
# check command line arguments
if len(sys.argv) != 3:
print "syntax: %s [inputfile] [outputfile]" % sys.argv[0]
sys.exit(1)
# start with an empty ROM (0xFF = unprogrammed byte)
data_out = [chr(0xFF)] * (2**len(addr_line_map))
# load data from input file
data_in = open(sys.argv[1], 'rb').read()
if len(data_in) > len(data_out):
print "Error: input file larger than expected (max %d bytes)" % len(data_out)
sys.exit(1)
# scramble it
for addr, value in enumerate(data_in):
data_out[scramble_addr(addr)] = value
# write result to output file
open(sys.argv[2], 'wb').write(''.join(data_out))
[Updated on: Mon, 25 April 2016 07:14] Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: New Board Development - SBC6120-RBC Edition [message #589 is a reply to message #454] |
Thu, 28 April 2016 09:00   |
 |
Andrew B
Messages: 467 Registered: October 2015 Location: Near Redmond, WA
|
Senior Member Administrator |
|
|
Just an update:
With my logic analyzer I've been able to see the board working its way through the ROM bootstrap code. It sets POST code 7, then tests the CPU, then sets POST code 6, does a really simple test of a couple words of RAM to make sure reading and writing works, copies a ROM bootstrap into RAM, then starts copying the contents of the ROM over to RAM.
I've still trying to trace out POST 5 and POST 4 (which is where it's hanging up). It seems like it's getting stuck in an infinite loop of JMPs for some reason. I only have 16 channels of my logic analyzer so I'm basically watching the data bus, /RESET, /READ, /WRITE, and /RAM_CS.
Since so many things are working so well, this is kind of maddening!
Hopefully tonight I'll be able to check what's going on around the other two post codes and figure out where this infinite loop is coming from.
|
|
|
Re: New Board Development - SBC6120-RBC Edition [message #590 is a reply to message #454] |
Thu, 28 April 2016 21:30   |
 |
Andrew B
Messages: 467 Registered: October 2015 Location: Near Redmond, WA
|
Senior Member Administrator |
|
|
It's alive!!!
(If you don't want to read all this, skip to the bottom for the 1 jumper wire that needs to be soldered on as a fix).
I traced out the POST process with my Open Bench Logic Sniffer, specifically honing in on POST code #4 where the board is hanging. The relevant section of code from the ROM monitor is:
; Make sure that panel memory and main memory are distinct...
POST+4 ; set the POST code to four
STA ; put -1 in location 0 of panel memory
DCA @[0] ; ...
CPD ; and then put 0 in the same location
DCA @[0] ; ... of main memory
SPD ; back to panel memory
ISZ @[0] ; and increment -1
JMP . ; if it doesn't skip something is wrong
I looked at DX11-DX0, the POST11 LED signal, /READ, /WRITE, and /RAM_CS:

Above we can see the POST code being set to 4 (first cursor), -1 being written to location 0 of main memory (second cursor) and 0 being written to location 0 of panel memory (third cursor). However, when the CPU reads back location 0 of what is supposed to be main memory (=-1) it gets 0, increments it to get 1, and then goes into the 'JMP .' infinite loop (I assume . means 'this address' .
So, our two types of RAM - the 32kwords of panel RAM (so named because it is intended for storage of programs that replace the not-present switch panel in this embedded PDP-8) are overwriting the 32kwords of main RAM. Why?
The HD-6120 datasheet says the CPU pulls /LXMAR low to latch the address registers for main memory, and pulls /LXPAR low to latch address registers for panel memory. Bob Armstrong's MEM GAL does things a little differently - /LXMAR gets run to one of the RAM address lines directly - so main RAM (/LXMAR low) is 1/2 of the RAM chips, and panel RAM (/LXMAR high) is the other half:

But where does that LXMAR signal come from. On the CPU sheet, there is no output to a global net:

And, therein lies the problem. I copied the original schematic pretty exactly into KiCAD, including this lack of a global net connection where /LXMAR is generated at the CPU. Apparently the software Bob Armstrong used considered all labels to be global and hooked everything up properly - but KiCAD did not, so we ended up with 2 nets:
-/LXMAR going from the CPU to the MEM GAL
-/LXMAR going from pin 31 of 1 RAM chip, to Pin 31 of the other, and to J4 of the Expansion connector.
To get the board up and running, the two need to be connected. I recommend running a jumper on the underside of the board from Pin 4 of the MEM GAL to Pin 31 of the nearest RAM chip, like so:

With this fix in place and the 're-arranged' ROM files provided by Will above, I get a good bootup to the BTS6120 ROM monitor prompt, can list the Help on all of the monitor commands, etc!!
Yay!!
-
Attachment: HANG.png
(Size: 37.63KB, Downloaded 1228 times)
-
Attachment: LXMAR-RAM.png
(Size: 11.08KB, Downloaded 1204 times)
-
Attachment: LXMAR-CPU.png
(Size: 18.53KB, Downloaded 1169 times)
-
Attachment: Prototype-Fix.JPG
(Size: 469.90KB, Downloaded 1215 times)
|
|
|
|
|
|
|
Re: New Board Development - SBC6120-RBC Edition [message #596 is a reply to message #594] |
Fri, 29 April 2016 08:15   |
 |
Andrew B
Messages: 467 Registered: October 2015 Location: Near Redmond, WA
|
Senior Member Administrator |
|
|
will wrote on Fri, 29 April 2016 05:33I can confirm that the original Dialight 5554403F ("LED 2MM QUAD 5V YELLOW", DigiKey part 350-1798-ND) fits the PCB footprint and that there is plenty of space to install a wire jumper in place of the current limiting resistors. It's quite a small part.
Sweet.
Current list of updates for v1.0:
1. Connect 2 /LXMAR nets (add global net output for /LXMAR on CPU page of schematic)
2. Fix ROM address line order (probably swap RAM lines to match too just for OCD-ish reasons)
3. Add jumper+PTCC fuse to feed VCC to IDE pin 20 for CF card adapters.
4. Move RAM chip footprints a little bit away from the ROM chips (no room for inserting a chip puller if you want to remove the chips!)
[Updated on: Fri, 29 April 2016 08:18] Report message to a moderator
|
|
|
Re: New Board Development - SBC6120-RBC Edition [message #603 is a reply to message #596] |
Sat, 30 April 2016 15:40   |
 |
Andrew B
Messages: 467 Registered: October 2015 Location: Near Redmond, WA
|
Senior Member Administrator |
|
|
OS/8 is up and running! I transferred the images linked on http://www.sparetimegizmos.com/Hardware/SBC6120_Builders.htm via the ROM Monitor 'DL' command per the kermit instructions in the SBC6120 User's Guide. This takes about 3 hours per image. The main OS/8 image goes to partitio 0 ('DL 0000') and the OS/8 Games went to partition 1 ('DL 0001')
Somehow I've ended up with no working CF card reader since my digital cameras all use SD cards now. I've got one on the way - at which point I can make an image files that could be written with win32diskimage/dd, which will be a much faster way to get started.
Note that the serial port settings for the ROM Monitor and OS/8 are, annoyingly, different. The monitor wants 8N1 and OS/8 is 7N1. So when you use the 'B' command in the monitor to start OS/8, you then have to change your serial terminal settings to match.
[Updated on: Sat, 30 April 2016 15:41] Report message to a moderator
|
|
|
|
|
|
|
|
|