RetroBrew Computers Forum
Discussion forum for the RetroBrew Computers community.

Home » RBC Forums » General Discussion » New Board Development - SBC6120-RBC Edition
Re: New Board Development - SBC6120-RBC Edition [message #560 is a reply to message #454] Sun, 24 April 2016 09:13 Go to previous messageGo to next message
Andrew B is currently offline  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 Sad 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 #562 is a reply to message #560] Sun, 24 April 2016 18:58 Go to previous messageGo to next message
gkaufman is currently offline  gkaufman
Messages: 186
Registered: October 2015
Senior Member
Andrew -

You should receive the 22V10's and 16V8 I programmed for you in tomorrow's mail. Finger's crossed.
Re: New Board Development - SBC6120-RBC Edition [message #563 is a reply to message #454] Sun, 24 April 2016 22:11 Go to previous messageGo to next message
Andrew B is currently offline  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. Sad Sad Sad

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:
index.php?t=getfile&id=47&private=0

And he's my schematic:
index.php?t=getfile&id=48&private=0

(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..... Rolling EyesWink.

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 #564 is a reply to message #563] Sun, 24 April 2016 22:47 Go to previous messageGo to next message
Garth is currently offline  Garth
Messages: 29
Registered: April 2016
Location: Southern California
Junior Member
If you make an adapter to de-scramble the lines, just make a single one for programming, instead of one for each board produced. (See if it's easier than writing your Python script to de-scramble it.)

http://WilsonMinesCo.com/ lots of 6502 resources

[Updated on: Sun, 24 April 2016 22:49]

Report message to a moderator

Re: New Board Development - SBC6120-RBC Edition [message #565 is a reply to message #564] Sun, 24 April 2016 23:11 Go to previous messageGo to next message
Andrew B is currently offline  Andrew B
Messages: 467
Registered: October 2015
Location: Near Redmond, WA
Senior Member
Administrator
The nice thing about the Python script is that Will is in the UK and it saves on postage ;)

There is already a library for Intel Hex files (https://pypi.python.org/pypi/IntelHex/1.5Wink so it looks like it should not be hard to do this in software. Create 2 IntelHex objects. Load the original file into one. Step through each address starting with 0. Write the byte at that address to the corresponding 'scrambled' address. Write out the new file at the end.

(I'm also working on a breadboard de-scrambler just as a sanity check)
Re: New Board Development - SBC6120-RBC Edition [message #566 is a reply to message #565] Mon, 25 April 2016 02:38 Go to previous messageGo to next message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
Hi guys

I think a little Python script is in order. It's just a matter of putting the data in the "right" place in ROM in order to match the scrambled address lines. Funnily enough I was idly daydreaming in the shower about pretty much this yesterday -- I was thinking the order of the address pins to a RAM really don't matter, but if you scramble the address pins to a ROM you have to scramble the contents to match.

Anyway, easily fixed with a little software. And as you say the postage for software is $0 Smile

My suggestion: Use srecord to convert to binary, use a python script to appropriately scramble the binaries, then use srecord to convert back to the format your programmer expects (or just feed the binary direct to your programmer, which is what I plan to do).

PS I am very happy to write this script. Can you provide the ROM hex input file? I'll have a bash this evening.

[Updated on: Mon, 25 April 2016 02:38]

Report message to a moderator

Re: New Board Development - SBC6120-RBC Edition [message #567 is a reply to message #566] Mon, 25 April 2016 05:51 Go to previous messageGo to next message
gkaufman is currently offline  gkaufman
Messages: 186
Registered: October 2015
Senior Member
Will -

Look here in the SW sub-directory (271L.HEX and 271H.HEX)

https://www.retrobrewcomputers.org/lib/exe/fetch.php?media=b oards:sbc:sbc6120-rbc-edition:sbc6120_design.zip

will wrote on Mon, 25 April 2016 02:38
Hi guys
PS I am very happy to write this script. Can you provide the ROM hex input file? I'll have a bash this evening.


Re: New Board Development - SBC6120-RBC Edition [message #568 is a reply to message #567] Mon, 25 April 2016 07:13 Go to previous messageGo to next message
will is currently offline  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 #571 is a reply to message #454] Mon, 25 April 2016 12:48 Go to previous messageGo to next message
Andrew B is currently offline  Andrew B
Messages: 467
Registered: October 2015
Location: Near Redmond, WA
Senior Member
Administrator
will - thanks for the sweet code! I will try the 'scrambled' ROMs as soon as I get home tonight.

Indeed, the RAM address lines also had a strange order on the original SBC6120. I asked Robert Armstrong about that and it turns out the original board was a hand-layout, the order made the layout a bit easier. Since I was using Freerouting (and different RAM chips) I switched the order back to match the chip pins.

I totally missed the ROM order in the process though.

Assuming the modified ROMs work - do you guys think I should do another board rev to fix the order to maintain chip to chip ROM compatibility with the original boards - or we could standardize on re-ordered ROMs for the RBC version so the address lines match up.
Re: New Board Development - SBC6120-RBC Edition [message #572 is a reply to message #571] Mon, 25 April 2016 13:05 Go to previous messageGo to next message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
I'd re-spin the board for the final run to maximise compatibility with the original SBC6120.

There will be just five machines in the world that need the special ROM scrambling Smile

It think ROM updates are likely to be infrequent so this is unlikely to be a headache even for those five builders.

Just doing my parts order now -- which switch did you have in mind to fit the new S1 footprint?
Re: New Board Development - SBC6120-RBC Edition [message #573 is a reply to message #572] Mon, 25 April 2016 15:07 Go to previous messageGo to next message
Andrew B is currently offline  Andrew B
Messages: 467
Registered: October 2015
Location: Near Redmond, WA
Senior Member
Administrator
will wrote on Mon, 25 April 2016 13:05

Just doing my parts order now -- which switch did you have in mind to fit the new S1 footprint?


https://www.retrobrewcomputers.org/forum/index.php?t=msg& ;th=51&goto=471&#msg_471

I bought the Digikey example part listed in my prior post.
Re: New Board Development - SBC6120-RBC Edition [message #574 is a reply to message #573] Mon, 25 April 2016 15:20 Go to previous messageGo to next message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
Ah, rats. I should have read more carefully. Never mind, just went digging through my parts bin looking for a chip and came across exactly that type of switch, I think it is a spare left over from building the Zeta 2 -- so I've got something suitable.

I went with the original quad LED part too so I will fit wire jumpers at R11--R14.
Re: New Board Development - SBC6120-RBC Edition [message #575 is a reply to message #574] Mon, 25 April 2016 15:45 Go to previous messageGo to next message
Andrew B is currently offline  Andrew B
Messages: 467
Registered: October 2015
Location: Near Redmond, WA
Senior Member
Administrator
You might want to fit check that, I realized after I made the boards that the resistors may need to be .010" farther back from the LED footprints for the original LEDs to fit (or you might need to put the jumper wires on the bottom of the board and cut the joints flush on the top of the board for it to fit.
Re: New Board Development - SBC6120-RBC Edition [message #576 is a reply to message #575] Mon, 25 April 2016 16:10 Go to previous messageGo to next message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
Thanks for the tip -- normally I would have fitted the LEDs last. I shall report back on what seems possible.
Re: New Board Development - SBC6120-RBC Edition [message #577 is a reply to message #576] Mon, 25 April 2016 16:12 Go to previous messageGo to next message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
PS reading about the PDP-8 it seems they number their bits backwards! (I suppose there was little precedent to copy)

So I may have got the mapping reversed in the program -- but it's easy and hopefully obvious how to reverse it.
Re: New Board Development - SBC6120-RBC Edition [message #578 is a reply to message #454] Tue, 26 April 2016 04:01 Go to previous messageGo to next message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
Hi Andrew

Can you please advise - does the IDE interface supply power on pin 20 so that it can be used to power an IDE to CF adapter? The STG user manual indicates pin 20 on the IDE is no-connect, so could one just easily patch in a connection to VCC?

Thanks

Will
Re: New Board Development - SBC6120-RBC Edition [message #579 is a reply to message #454] Tue, 26 April 2016 08:05 Go to previous messageGo to next message
Andrew B is currently offline  Andrew B
Messages: 467
Registered: October 2015
Location: Near Redmond, WA
Senior Member
Administrator
IDE Pin 20 is NC just like the original board.

I could probably add a jumper to feed VCC to that pin in the final revision.

Just a running list of updates so far:
1. Fix ROM address line order
2. Move LEDs resistors slightly away from LEDs
3. Add jumper to feed VCC to IDE pin 20

Since the address line order was already take into account on the original schematic, your Python code should work fine. I got caught up with some other stuff last night and it will probably be tonight before I can try it.
Re: New Board Development - SBC6120-RBC Edition [message #580 is a reply to message #579] Tue, 26 April 2016 09:35 Go to previous messageGo to next message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
Yes a jumper to VCC would be a good idea. Even better would be a footprint with 0.2" spacing to take a PPTC -- I now fit these in place of a jumper on all my IDE boards. If you accidentally plug a CF adapter in one pin out of alignment it can short VCC to GND, I burned out a trace on my Mark IV SBC this way! The PPTC would trip before any traces burn out. It is possible to fit them to 0.1" spaced holes but it's a bit untidy; 0.2" would be perfect.
Re: New Board Development - SBC6120-RBC Edition [message #581 is a reply to message #580] Tue, 26 April 2016 11:16 Go to previous messageGo to next message
gkaufman is currently offline  gkaufman
Messages: 186
Registered: October 2015
Senior Member
Board arrived yesterday, unfortunately I arrived home too late to start construction.

At this point I'll probably wait to hear if the scrambled roms work properly, but the board looks very nice!

- Gary
Re: New Board Development - SBC6120-RBC Edition [message #582 is a reply to message #454] Tue, 26 April 2016 22:33 Go to previous messageGo to next message
Andrew B is currently offline  Andrew B
Messages: 467
Registered: October 2015
Location: Near Redmond, WA
Senior Member
Administrator
Well, with the 're-arranged' .HEX files from Will, and a set of GALs from Gary (verified to work in my original STG board) I get POST codes up to 'Memory test error' per Page 18 of the SBC6120 User's Guide.

However: I was pressing on/seating some of the chips on my board, and the post codes went all the way to the 'BTS6120 running' and a string of register values from the ROM monitor displayed on the serial terminal. So it seems likely that I *may* be having some problem with this specific board, and not the design.

Re: New Board Development - SBC6120-RBC Edition [message #583 is a reply to message #582] Wed, 27 April 2016 08:51 Go to previous messageGo to next message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
Anyone got a suggestion for how I can program these Atmel ATF22V10C GALs?

I have an Autoelectric TL866A programmer.

I have programmed the ATF16V8B but my programmer does not seem to support the ATF22V10C.

As an alternative I have several Lattice GAL22V10C chips left over from the KISS-68030 build. I believe these would be an acceptable substitute but I am not 100% sure -- can anyone throw light on this?

Thanks!

Will
Re: New Board Development - SBC6120-RBC Edition [message #584 is a reply to message #583] Wed, 27 April 2016 08:53 Go to previous messageGo to next message
ab0tj is currently offline  ab0tj
Messages: 70
Registered: October 2015
Location: Colorado
Member
Hi Will,

I did not have success programming either brand of 22V10 chip with my TL866A. It sounds like others have been able to make the Lattice chips work, but not the Atmel chips. I ended up ordering a Wellon programmer which seems to program both brands with ease.
Re: New Board Development - SBC6120-RBC Edition [message #585 is a reply to message #584] Wed, 27 April 2016 09:35 Go to previous messageGo to next message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
Hey

I have got the GAL22V10C chips programmed with the IOT1 and IOT2 code. I really just want to confirm that they are drop-in replacements for the ATF22V10C in this circuit -- ie avoid blowing anything up!
Re: New Board Development - SBC6120-RBC Edition [message #586 is a reply to message #585] Wed, 27 April 2016 10:41 Go to previous messageGo to next message
gkaufman is currently offline  gkaufman
Messages: 186
Registered: October 2015
Senior Member
I have used both Atmel and Lattice 22V10's in the SBC6120 without difficulty.

I have also never had luck programming 22V10's on the TL866A.

I'm happy to program the GAL's for folks as long as they send them to me and provide a return mailer or cover shipping.
Re: New Board Development - SBC6120-RBC Edition [message #587 is a reply to message #586] Wed, 27 April 2016 10:46 Go to previous messageGo to next message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
Gary

ATF22V10C and GAL22V10C both programmed and verified fine with the TL866A for me. I assume this means they will work.

Thank you for the confirmation that GAL22V10C can be used in the SBC6120 circuit. That's what I will try.

I did have one GAL22V10C which did not work in the KISS-68030; I replaced it with another chip programmed identically and it worked fine. The GAL22V10Cs I have are all second-hand chips that have been pulled from other systems so I concluded that the chip had suffered some sort of "incident" before it came to me.

Will
Re: New Board Development - SBC6120-RBC Edition [message #588 is a reply to message #587] Wed, 27 April 2016 12:47 Go to previous messageGo to next message
Andrew B is currently offline  Andrew B
Messages: 467
Registered: October 2015
Location: Near Redmond, WA
Senior Member
Administrator
The Lattice GAL16V8 and GAL22V10 parts Gary programmed for me work fine in my original STG board. So it looks like the .JED files can be used to program either GAL or ATF parts, and either part will work in the boards.

However, one thing to note is that the programming algorithm is different for the ATF and GAL parts, so you want to make sure that your programmer is setup for the correct parts.

When I get home tonight I plan to do some more probing with my logic analyzer and see if I can figure out what's up with the RAM test on my board. It writes 0's and -1s to the RAM and reads them back, should be pretty easy to see what's up.
Re: New Board Development - SBC6120-RBC Edition [message #589 is a reply to message #454] Thu, 28 April 2016 09:00 Go to previous messageGo to next message
Andrew B is currently offline  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 Go to previous messageGo to next message
Andrew B is currently offline  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:
index.php?t=getfile&id=51&private=0

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'Wink.

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:
index.php?t=getfile&id=52&private=0

But where does that LXMAR signal come from. On the CPU sheet, there is no output to a global net:
index.php?t=getfile&id=53&private=0

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:
index.php?t=getfile&id=54&private=0

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!! Surprised
  • Attachment: HANG.png
    (Size: 37.63KB, Downloaded 1226 times)
  • Attachment: LXMAR-RAM.png
    (Size: 11.08KB, Downloaded 1203 times)
  • Attachment: LXMAR-CPU.png
    (Size: 18.53KB, Downloaded 1168 times)
  • Attachment: Prototype-Fix.JPG
    (Size: 469.90KB, Downloaded 1214 times)
Re: New Board Development - SBC6120-RBC Edition [message #591 is a reply to message #590] Fri, 29 April 2016 01:49 Go to previous messageGo to next message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
Andrew -- good catch! Thank you for showing us how you figured out the problem, that logic analyser looks like a really useful tool to have.

I now have all the parts except for the PCB and the HD6120, both still somewhere in the postal system...
Re: New Board Development - SBC6120-RBC Edition [message #592 is a reply to message #591] Fri, 29 April 2016 03:38 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 276
Registered: October 2015
Senior Member
On the subject of GALs: they come in a B, C or D version. I've been looking through the Lattice datasheet, but aside from a marginal difference in max clock speed and maybe some packaging options I can't find a real difference. What am I missing?

RHK

[Updated on: Fri, 29 April 2016 09:31]

Report message to a moderator

Re: New Board Development - SBC6120-RBC Edition [message #593 is a reply to message #592] Fri, 29 April 2016 03:53 Go to previous messageGo to next message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
PCB has arrived! Only outstanding part is now the HD6120 IC, last seen three days ago in ShenZhen.
Re: New Board Development - SBC6120-RBC Edition [message #594 is a reply to message #593] Fri, 29 April 2016 05:33 Go to previous messageGo to next message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
I 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.
Re: New Board Development - SBC6120-RBC Edition [message #596 is a reply to message #594] Fri, 29 April 2016 08:15 Go to previous messageGo to next message
Andrew B is currently offline  Andrew B
Messages: 467
Registered: October 2015
Location: Near Redmond, WA
Senior Member
Administrator
will wrote on Fri, 29 April 2016 05:33
I 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 Go to previous messageGo to next message
Andrew B is currently offline  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

Re: New Board Development - SBC6120-RBC Edition [message #604 is a reply to message #596] Sun, 01 May 2016 08:55 Go to previous messageGo to next message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
Andrew

May I suggest another update for v1.0:
- Clearly mark the polarity of C29, C30, C31, C32, C37.

PS my board is now fully assembled and programmed including the fixes and IDE power PPTC; just waiting on the HD6120 CPU to arrive in the post.

[Updated on: Sun, 01 May 2016 10:23]

Report message to a moderator

Re: New Board Development - SBC6120-RBC Edition [message #605 is a reply to message #604] Sun, 01 May 2016 10:35 Go to previous messageGo to next message
jcoffman is currently offline  jcoffman
Messages: 332
Registered: October 2015
Senior Member
Will,

Polarity is clear. Square pad means pin 1, which is always the + lead. After your comment, I buzzed the board. It is correct.

Markings on small capacitors are sometimes hard to read. I like the convention on caps to have pin 1 the longer lead. Also true on many LEDs.

--John
Re: New Board Development - SBC6120-RBC Edition [message #606 is a reply to message #605] Sun, 01 May 2016 11:02 Go to previous messageGo to next message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
Thanks; I similarly buzzed it out with a printed copy of the MAX232CPE datasheet in hand just to be sure.
Re: New Board Development - SBC6120-RBC Edition [message #607 is a reply to message #606] Sun, 01 May 2016 17:29 Go to previous messageGo to next message
gkaufman is currently offline  gkaufman
Messages: 186
Registered: October 2015
Senior Member
Alive!

Built up the board tonight, with the scrambled .rom files and the jumper wire correction.

Booted right up into OS-8, played adventure.

Then swapped the 5mhz oscillator for an 8mhz oscillator without any problems (and a very noticeable boost in speed).

Kudo's to Andrew for getting the board designed and working (and to Will for scrambling the Roms).

One more suggestion, add a small connector in parallel with the reset switch, so a case mounted switch can also be used.

- Gary
Re: New Board Development - SBC6120-RBC Edition [message #608 is a reply to message #607] Mon, 02 May 2016 00:19 Go to previous messageGo to next message
rhkoolstar is currently offline  rhkoolstar
Messages: 276
Registered: October 2015
Senior Member
The manual warns about the speed of the 82c55:

"You must use at least the 5 MHz version of the 82C55 (as indicated by an A5, or -5 suffix); slower
parts will not work."

Will the IDE still work at 8MHz?

RHK
Re: New Board Development - SBC6120-RBC Edition [message #609 is a reply to message #608] Mon, 02 May 2016 04:02 Go to previous messageGo to previous message
will is currently offline  will
Messages: 213
Registered: October 2015
Senior Member
Gary - brilliant to hear that another board is up and running! Brings me hope that mine will work once the HD6120 arrives on the slow boat from China.

Quote:
One more suggestion, add a small connector in parallel with the reset switch


I believe this facility is provided for on the board already. One of the test points (TP3, from memory) can be pulled to ground through an external switch in order to reset the system. It could be improved by changing it from a single test point to 2-position header with the second position being wired to the ground net.

Quote:
Will the IDE still work at 8MHz?


The Intersil CP82C55AZ I have fitted on my (unproven) SBC6120-RBC board is rated at 8MHz. I have the same chip on my Zeta2 and KISS-68030 MF/PIC boards which all run significantly faster so I am expecting it will work fine.

Did anyone else get caught out by the 0.1" decoupling cap lead spacing? I am so used to using 0.2" lead spacing for these parts that I just assumed it would be 0.2" and I could use the huge stock of these I have already. Not a huge problem, just took 15 minutes with some flat nose pliers to reshape the leads appropriately.
Previous Topic: Tiny040
Next Topic: ALTERA MAX7000 adventure to program old CPLD's


Current Time: Mon Mar 17 11:40:29 PDT 2025

Total time taken to generate the page: 0.00952 seconds