You seem to have quite a penchant for sockets oriented on the board at integer multiples of 90° ...
have you considered the possibility of other angles, like 45°?

Enso's Chochi is an example of what I'm suggesting.

Mike

There are a few situations where 45° makes it easier to route an IC with lots of pins; but usually it just takes more space that way. My own CAD will only do multiples of 90°. What I have done, on very few occasions, is to make a separate component like a thru-hole resistor or diode in 45°. I do not limit my trace angles though. They can be anything, not just multiples of 45°.

BDD, some of your vias appear to be too close to other traces, like near the middle of U4. Do they actually meet your design rules?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I actually did a layout with the CPLD (ATF1504AS) mounted that way. The problem was that now the effective north-south footprint of that device was much larger, and that impinged on space needed to route traces in the vicinity of the SRAM. It just didn't fly. In this application I haven't seen where 45 degree placement is of value. I will look at doing so with the CPLD in POC V3, as that device will be a PLCC84 package.


Yes they do. The via diameter is 0.026 inches, I'm using 0.006 inch wide traces and the layout is on a 0.025 inch grid. Therefore, the clearance between the via in question and the nearest trace is .025 - (.026 / 2 + .006 / 2), which is 0.009 inches. EPCB requires that a minimum of 0.007 inches clearance be maintained between traces and other objects, so that location meets that rule with 0.002 inches to spare. When I transfer the layout to an image file the via always seem to look bigger than they actually are.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I've tinkered some more with POC V2's design and think I've got it to the point where it can be built. Pages one through five of the schematic are attached to this message, with page six of the schematic and the PCB layout attached to the next message. The next message will have some explanatory comments.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Here's page six of the schematic, and the PCB layout:



Just to recapitulate, POC V2's principal differences compared to POC V1 are:

• 512KB of RAM, all of it potentially addressable.
  
  
• Atmel ATF1504AS CPLD for glue logic.
  
  
• Four high speed TIA-232 ports.
  
  
• Support for 20 MHz operation.

There are some changes from the previous design I posted:

• I decided to use a MAX-248 transceiver instead of a pair of MAX-238s. Although a single MAX-248 is more costly than two MAX-238s, its overall footprint is smaller and it requires only one set of charge pump capacitors to power all four serial channels. Also, the MAX-248 is in a PLCC-44 package, which relieves me of the chore of soldering 48 pins on two SOIC packages.
  
  
• I relocated the EPROM (U4) to make it possible to use a ZIF socket. POC V1.1's ROM socket has taken quite a beating with constant ROM replacement as I tinker with the firmware code. As POC V2's firmware will be more complicated, I expect that I will be popping ROMs in and out of that socket quite often. This change required enlargement of the PCB from 19.5 square inches to 21 square inches, which is the maximum size allowed with ExpressPCB's Proto-Pro service.
  
  
• I added circuitry to make it possible to connect either a dumb serial terminal or a SECONS µVGA terminal device to the console port (port A). The µVGA is a TTL device, so there are two jumper blocks in the circuit (JP3 and JP4) to configure the console port to operate at either TIA-232 or TTL signal levels. When configured for TTL, the DTR signal becomes Vcc to power the µVGA device.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Just out of curiosity, does anything exist that plugs into the ROM socket and connects to a PC over USB so that it can quickly be reprogrammed without removing it?

There does, but such devices are expensive. That's why I rearranged the board to make room for a ZIF socket.

Much of POC V2's firmware will be copied from POC V1's, as the I/O hardware will mostly be the same. So I don't expect a huge development curve. However, I am planning on integrating an "HMU" (hardware management unit) into the CPLD, so some supporting code will be required over and above the BIOS and interrupt handlers. I'll work on the HMU after I get past the initial hurdle of making the unit work.

I should note that I can send S-records to POC via TIA-232 from my UNIX box, so I can test code before burning it into the ROM.
—————————————————————————————————————————————————————————————
EDIT: Evidently, as reported below, EPROM emulators do exist that can be driven from USB. Learn something new every day.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yes. USB connected EPROM emulators exist.

https://www.eetools.com/index.cfm/product/314/eprom-emulator.cfm
http://www.batronix.com/shop/epromemulator/emulator.html

But are a little pricey

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

A *little* pricey? I think I'll stick with real EPROMs for now.

BTW, I didn't know such devices were available.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I'm curious why you can't send the whole image over the UART?

My 6809 is updated using the following workflow:

Change code
"make"
Hit reset button on SBC, or enter "q" command at monitor prompt
"make upload"
6809 resets into new monitor

"make upload" is a program I wrote for my dev system which sends the image, a 64byte EEPROM page at a time, to the SBC. The SBC in turn is running code which:

Copies the entire EEPROM 16KByte image into RAM
A jump point into the relocated flash routine is calculated
Flash routine is entered. At this point nothing is reading the EEPROM which would very much cause problems
64byte pages are received and written into EEPROM
Between each page the necessary timing constraints are honoured using a trivial delay loop
After each page a "#" is sent back on the serial port when the delay has completed, so the sender knows to send the next page
At the end of the write operation, the entire new content of EEPROM is echoed back so the sender can check the content
Nothing can be done if the transfer failed. It very rarely does, and when it does I pry out the IC and program it using my AVR programmer
In any case, the new reset vector is jumped through

My processing is not perfect. With bank switching, I could write the new image to a bank and check it there, before writing it to the EEPROM. Or I could use retry logic to resend the 64byte pages. But hey ho. I'm very pleased with this and it took minimal effort.

BTW, I'm using Atmlel 28C256 EEPROMs.

So is there any reason why your SBC couldn't implement something like this, and save you from using the ZIF socket? The big advantage of EEPROMs vs other ROMs is they can be programmed with ordinary voltages which means they have the potential to be in-situ reprogrammed.

_________________
8 bit fun and games: https://www.aslak.net/

The code that handles the S-record input is part of the ROM.


The big disadvantage of EEPROMs is that they are slow. The ROMs I use (AMD) are 55ns parts.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Obviously, but who said you must execute it from ROM? Just copy the download routine to RAM and execute it from there. Also when having a self-updating system, you always inlcude a "save boot" section into the ROM that normally is not update (unless your S-record input routine is not working). And todays ROM are large enough, so you can afford to have more than one jumper selectable region.

The S-record functions are dependent upon serial I/O primitives in the ROM, as well as other functions that process the incoming ASCII byte representations and convert them into binary form. Plus all I/O is interrupt-driven, which means that to do what you suggest would mean shadowing much of the ROM into RAM. It could be done but I am not seeing any advantages to doing so. I don't want the persistent performance penalty that would be imposed by the relatively slow EEPROM. I chose to use a fast EPROM so as to avoid wait-stating ROM accesses at the clock speeds that I have been running (usually 12.5 MHz).

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Okay, I've run into a problem. I have here the Atmel programming/test rig for their CPLDs, as well as the PLCC-84 adapter so I can play around with the ATF1508AS CPLD. POC V2 is going to use the smaller 1504AS, which is in a PLCC-44 package. So a while back, I ordered the PLCC-44 adapter and waited for it to ship. And waited and waited and waited and...

Anyhow there's a snag at Atmel and it doesn't look like I'm going to get this adapter anytime soon. If I could, I'd reverse-engineer and make my own. However, Atmel is careful about covering their tracks with this stuff, and I'm reluctant to invest the necessary time when so many other things are tugging at my sleeve.

I can't use ISP via JTAG with the 1504AS because the four JTAG pins are being used as I/O connections—every pin on the device is spoken for in this design. Otherwise, I'd just add the necessary JTAG circuitry to POC V2.

As I said, a snag.

I have two possible remedies:

1. Wait until Atmel produces and ships the adapter or,
   
2. Figure out how to shoehorn the much larger 1508AS—who resources I don't need with this design—on to the PCB.

I really don't want to wait too much longer to get this thing built, so I may attempt B. It's going to be tight...

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That seems to be the most sparsely populated area of your board, so it looks like you should be able to do it, at the expense of some bill-boarding and jumper-map real estate.

Mike