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

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

For anyone interested, yes, a '138 could have been put onboard, but part of the idea was, as stated in the data sheet:

• eight separate CE\ pins, so you can get faster selects by
  handling the computer's entire address-decoding scheme with
  a CPLD if desired than you would get from adding a 74xx138
  to this plus the computer's other address-decoding logic

_________________
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?

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

Here it is early 2014, some three years after I started this topic and POC V2 remains a paper computer. Part of the reason has to do with many other things vying for my attention. So I have had a hard time doing the long "burn" needed to fully think this thing through and get some hardware built. Not helping matters is that POC V2 is a pretty ambitious design.

Work has let up a bit in the last week or two, giving me some time to focus on where V2 is or should be headed. After this period of intense (?) cogitation, I have decided that V2's current design represents too big a leap from V1. So, while V2 will be built with programmable logic and more RAM as originally planned, it will be reduced to a more modest design that will enable me to get real warm and fuzzy with a CPLD and making the banking function in the 65C816 work. Also, I want to stay within the Express PCB Proto-Pro 4-layer design limits for this next version (maximum board area of 21 square inches and a maximum of 650 holes). Therefore, V2 as described up to this point will become V3 and will now be the new resident of the back burner.

This more modest V2's memory map will be as follows:

The I/O hardware will map in as follows:

Principle hardware changes over V1 are:

• Atmel 1504as CPLD glue logic
• 512KB RAM
• 32KB EPROM split into two blocks (LOROM and HIROM
• NXP 28C94 quad UART (QUART)

V2 will continue to use the piggy-back SCSI host adapter that I developed for V1.

Aside from the use of the CPLD, the most significant hardware change from V1 will be the use of the 28C94 QUART in place of the 26C92 DUART. This will add two more TIA-232 ports, giving me a total of four: one for the console, one for file transfer from my UNIX software development system and two to connect to other peripherals, e.g., a serial printer or maybe another terminal.

Although LOROM, I/O and HIROM are shown as "hard wired" into the memory map, this aspect of V2 isn't cast in concrete. At this point, I don't know how much of the CPLD's resources will be consumed in implementing the essential logic, which will include wait-stating ROM and I/O accesses and with any luck, prioritized interrupt encoding. If sufficient logic resources remain, I may try to implement some of the theories I presented in the past on memory management. The first thing to try would be to see if I can arrange the logic so that I can map out LOROM and/or HIROM and make RAM appear instead. It'll come down to available product terms and I/O pins.

The 1504as CPLD is the most capable one in the Atmel lineup that is available in a PLCC-44 package. It will replace six of the seven separate discrete logic devices used in V1's design, reducing the PCB's hole count and taking up less board space than the discrete hardware. The 1504as has 64 macrocells and 25 uncommitted I/O pins, plus several dual purpose pins that could be pressed into service as I/O pins if needed. Although I haven't started work on the logic as yet, I'm reasonably certain that this CPLD will be more than adequate for what I want to do.

Schematic and PCB layout will soon follow.

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

Prioritized interrupt encoding is out. There aren't enough pins on the 1504AS to connect each interrupt source to an input. So I'll have to continue to poll IRQ sources as I am doing with POC V1's firmware.


Actually no pins over and above what are needed to wire /CS and /OE connections to the ROM would be used. It will be dependent on available product terms only. If the 1504AS has the resources to do this, an "HMU" (hardware management unit) would be added to the memory map at $00DF00:


One byte in a read/write "register," which would default at reset to %00000000, exposing ROM at $00E000 and RAM at $00C000. Not much to it, but it's a start.

If enough P-terms remain after the above is working, I'll try arranging the logic so that a write to a ROM address always bleeds through to RAM. This would make it possible for the BIOS and interrupt handlers to be shadowed in RAM, thus avoiding the use of wait-states for accessing those routines.

After all that, I might look at making the I/O block mappable as well, so the RAM underneath can be exposed. Of course, the HMU itself can never be mapped out...but perhaps I could assign it to a shadow address at the very top of the memory map, say at $07FF00 or thereabouts. Then the entire $00D000 range can be mapped out, exposing RAM all the way up to $07FEFF, for a total of 524,032 contiguous bytes. $07FF01 to $07FFFF will be wasted (maybe), but such is life...

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

Here are pages 1 through 5 of the schematic. Page 6 and pictorials of the PCB layout are in the next post.

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

Here they are.

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

I tinkered slightly with the circuit, added an EWS (Extra Wait-State) input to the CPLD, and squeezed down the PCB layout a little more. Page 6 of the revised schematic and the PCB layout will appear in the next post.

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

Page 6 of the schematic and the PCB layout.

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

Hi BDD.

I've never laid out a PCB before, so my question may have an obvious answer, but I'll ask it anyway. Please don't take offense ... I'm just trying to understand and learn.

Could your overall average trace length benefit from more carefully-considered placement of the components, especially the CPLD and the right-most MAX?

Thanks,

Mike

Possibly. The constraints of working within the 21 square inch/650 hole limit of ExpressPCB's Proto-Pro service make it difficult to optimize connections to all devices. When a board is at that size connectors can eat up a disproportionate amount of real esate, the 4-port TIA-232 connector being one such culprit.

What you see is the result of several trial layouts, in which I tried to keep routing as point-to-point as possible. However, the present design is not cast in concrete until I actually order PCBs. So I may well play with it some more.

The CPLD tends to be problematic, as it is connected into the rest of the circuit in disparate places. Also, PLCC packages tend to work better with radial connections, which arrangement doesn't fit very well on a narrow board like what you see in the illustration (n.b., DIP packages are actually worse). If I position the CPLD to favor short connections to the MPU, the connections to the expansion port and QUART get longer. If I position it to favor the latter items, then the MPU connections get longer. It's all about compromise, and in this case, I decided to more-or-less centrally locate the CPLD to keep all traces as short as practical.

A possibly idealized layout would have the CPLD in between the MPU and the rest of the address and data bus end points (EPROM, RAM, etc.). There isn't enough space on the board to allow such a layout. Another possibility is for the CPLD to be angularly displaced relative to the MPU. The attached illustration, which is a work in progress, has such a layout.


This layout, which is on a truncated micro-ATX PCB, includes Garth's 4MB DIMM, which is to the left of the CPLD, which in turn, is at the top left corner of the MPU. Also, bus drivers/transceivers are part of the design, as the potential bus loading is much higher than my earlier efforts. They are located around the MPU to keep the latter's connections reasonably short.

As for the MAX-238s, their connections operate at the relatively low speed of the TIA-232 signaling rate, no more than 230.4 Kbps in my application. Positioning is non-critical. An alternative that I have considered in place of the two MAX-238s is a single MAX-248, which is essentially four MAX-232s in a PLCC-44 package. However, the single-piece price of the MAX-248 is some 23 USD, versus 15 USD for two MAX-238s. Paying an extra 8 USD to slightly compact the layout seems counterproductive for a hobby computer, no?

I'm always amenable to suggestions, which is why I post this stuff for commentary. Sometimes I don't always see the forest, only a bunch of trees.

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

I figure that if I'm only making one, my value of time in design and assembly is well beyond that of the parts, which is why I have a bunch of WW PLCC sockets here which I paid about $10 each for. The price of multilayer PCBs OTOH is intimidating. I design them frequently for work, but we never order less than a hundred at a time, so the set-up charges (some amortized and some not) become quite acceptable.

_________________
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?

In the case of POC V2, the theoretically more compact layout that would be achieved with the MAX-248 is not of any particular value. The PCB cost is fixed regardless of size and number of holes, assuming the 21 square inch/650 hole limit of ExpressPCB's Proto-Pro service is not exceeded. On the other hand, if I were going to build one hundred copies of this unit, I'd be using a production PCB service, and board size and hole count would become important.

My general approach has been to concentrate time on compacting areas where compaction will achieve something of value. As I mentioned, the MAX-238 connections are relatively low speed. So issues that would arise with, say, overly-long address connections aren't likely to occur.

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

Just for grins, I decided to take another look at using the MAX248 in place of two MAX238s. Attached are the revised schematic (pages 4, 5 and 6) and the revised PCB layout. Compare this new PCB layout with the one above and you will see that the MAX248, along with its charge pump capacitors, takes up less space than the two MAX238s, even though the latter are SOIC devices. Dunno if I'm convinced, though, to spend the extra money just so I have more unused board space.

On the plus side, soldering a PLCC44 socket into the board is easier than soldering two 24 pin SOIC devices. Hmm...

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