I don't use KiCAD, but I have use many of the China PCB shop for Four layer board prototype with excellent results. I use Altium for my CAD tools. (It's auto router is terrible) ~~ _/) ~~~~ _/) ~~~~ _/) ~~~~ _/) ~~ It was nearly 10 years ago, John. I had never heard of KiCAD and since I could not afford a commercial product, I was using the free software from one of the PCB houses at the time. But even the $5000 products I used in the 80’s and 90’s could not auto-route very well. I have designed and laid out probably well over 100 boards earlier in my career, and this board was packed tighter than any other I had ever done. It is the original version of the board I am currently re-designing. The motivation for this board design was primarily to replace my 64K dynamic RAM board as it was starting to have problems, and I had no knowledge of this awesome group of S-100 enthusiasts to help me locate a replacement. Called the MemPlus, it had (has) the following features all on one S-100 board: · 8-bit IEEE-696 compliant slave · Two sockets for 32K x 8 static RAM chips · Optional battery-backup for the RAM · Two sockets for up to 64K ROM that overlays the RAM if/when addressed · Flexible ROM addressing – any size for either socket on any 256-byte start address boundary · Optional wait-state generator for ROM addresses · Optional 24-bit extended addressing · Test Input port and test output port at FF. Input port used a set of switches. Output port displayed on LEDs or hex displays. · A hardware monitor with these capabilities: o Display 16 or 24-bit address bus o Display Data Out bus (or test output port, switch-selectable) o Display Data In bus o Display the important status and control signals on the bus o A Run/Stop switch to stop the CPU freezing the displays o A single-step switch that can step one M1 cycle or one any cycle at a time, switch selectable o A hardware breakpoint that can trigger on address only, set on switches · Since the TIL311 displays are rather expensive, the board exists with the option to use LEDs instead of hex displays · The breakpoint address and test data input switches can use either hex rotary switches, which are very convenient, or regular dip switches. · The Run/Stop, Step Type, Step One Sycle, Breakpoint Arm and Output display switches are brought out to a convenient pod for ease of use. · The display portion of the board is initially attached to the main S-100 board. In this configuration, the board is 2.7” taller than a standard board. However, it can be snapped off and mounted anywhere desired. Then two inexpensive 40 pin ribbon cables (like standard PATA disk drive cables) are used to connect the two. I counted the pins for this board as a rough idea of density, and in the 77 sq. inches of real-estate there are 1925 pins. That’s 25 pins per square inch. Given that there are two regulators and heat sinks, two 2032-style coin cell holders, and explanatory silk-screening all over the board, I think this is a very dense board. Hence my inquiry about a four or maybe a six layer board. The update I describe below is about 30 or 31 pins per square inch. The version two of this board has been in “spare-time” design now since December 2014. It, too had some significant motivation. Last summer I bought a version 2 of the IDE/CF board and built it hoping to augment my 8” disks. Although it worked using the utility programs to write sectors and such, I could not get it to work through CP/M 2.2. My BIOS is a mashed-up mess of what used to be the California Computer Systems (CCS) CBIOS, which has worked very well for me up till the IDE/CF board came along. After hours of troubleshooting, I learned that it should be significantly easier to get it working in a CP/M 3 system. So, I began research on how to upgrade my system to CP/M 3. I learned a lot, and as a side-project, I built a second S-100 system for testing and development (I announced on the list that it was fully operational back a number of months ago.) One of the biggest things I learned was that CP/M 3 runs a whole lot better in its banked arrangement. But I only had 64K, and although I built a second 64K board so I had 128K, I had no memory manager, and my CPU, the CCS 2810 Z80 board, is a straight Z80, with no memory management either. So, the motivation was that I needed CP/M 3 to make using the IDE/CF board easier, and I needed more than 64K of RAM to make a go with CP/M 3, and I needed a memory manager to move up from 64K. Necessity is the mother of invention, so I set out in late December to invent an upgrade to my MemPlus board with the following goals in mind: · Retain the 8-bit slave flavor. I see lots of work being done with 4M and 16M boards, all in support of 16 and 32 bit processors. This is great and I enjoy reading about the trials and the successes. However, I don’t see myself going there with my S-100 machines. (I have MS-DOS on several machines built for it, including about 15 vintage PC’s from the early to late 80’s.) Instead, I am happy with trying to do as much as I possibly can with my Z80. I would entertain the idea of moving up to, say, a Z180, but that’s a whole other story. · Increase RAM beyond 64K. With 512K static chips readily available, two sockets would get me up to 1M. Plenty for any 8-bit machine. This gives me enough RAM to run CP/M 3 in banked mode, with several banks for disk buffers, etc. This RAM can be addressed linearly if desired by any bus master. Include the ability to use 32K, 128K or 512K chips. · Build a memory manager to handle the RAM on the board for 8-bit bus masters that have only a 64K address space, like Z80. With this, I can make use of the RAM above 64K. · Retain the battery-backed RAM option and provide an easy way to bypass it if not being used. · Drop one ROM socket – the second was never used on the original board, and I don’t see much utility in it. The ROM can be 2K, 4K, 8K or 16K in size, set by a dip switch. Oh, and I got rid of all the ROM configuration jumpers. When the ROM size is set by the dip switch, it automatically configures the socket. (This method is employed for the RAM too.) · The ability to address the ROM on any 256 byte boundary was extreme as were the switches and logic to implement it. I dropped that addressing in favor of a much simplified scheme that permits placement of the ROM in 16 different locations above 8000H. Locations not supported can be accommodated by re-programming the control logic (discussed later.) · Improve the wait-state generator to the circuit everyone uses now to make up to 8 wait-states for the ROM. Modern static RAM is sufficiently fast and I don’t believe wait state will be needed, even with 8 and 10MHz CPUs. (Note: my CPU is only 4MHz. I may be looking for a way to test this design at 6, 8 or 10MHz.) · Retain the test ports, but permit their address to be any I/O port from 00H to FFH. · Retain the heart of the hardware monitor, as described above, and make the following enhancements: o Add a slow-stepper mode of operation that will automatically step the computer by anywhere from about 1 cycle per second up to about 1000 cycles per second. o Improve the breakpoint system so breaks can be triggered on nearly any bus cycle (memory read, I/O write, Interrupt Acknowledge, etc.), any memory address (including 24-bit addresses) and any data bus content. Also, include a means of adding “don’t care” bits, so, for example, a range of memory addresses could be selected and any of them hit would cause a break. o Add front-panel-like memory operations: Examine, Examine Next, Deposit and Deposit Next. · Retain the flexible display options. · Retain the flexible dip switch or hex switch input options, and add the ability to use off-board switches. · Expand on the control pod for the main operational switches, plus add on-board switches to mimic all functional operation, so the control pod can be optional or disconnected and all the hardware monitoring and front-panel operations can be done directly on the S-100 board. · Wrap up as much of the logic as possible into GALs to save space. At this point in the design, there are 12 GALs on this board, a mix of 16V8 and 22V10. There is a GAL for nearly every function on the board, such as RAM addressing, MMU control, front-panel logic, etc. I have bread-boarded about half of this now, and hope to breadboard and test the remaining in a couple of weeks. The only part of the design that I believe is outstanding right now is the power supply. You probably remember how I switched my machines over to a 5 volt buss running off a switching power supply. Thus all the 5Vregulators on my boards are bypassed. But for the sake of most others, I have to figure out the power needs of this board and determine how I’m going to do the voltage regulation. I like what several have done lately with the on-board switching regulator, and if no one has a problem, I’m probably going to copy it. I just got my v3 IDE/CF card today, so I’ll be looking into that soon. Now that I have left the cat out of the bag on this project, I welcome any and all feedback. It is probably a good point to hear if anyone has any suggestions for additional improvement or notices that I have gone off the deep end somewhere. I have enjoyed using KiCAD to work up the schematics. It pretty much matches the power of the old stand-alone systems I used before. The biggest gripe I have right now is that it is very cumbersome to copy blocks from one sheet to another. (This design exists on 5 custom-sized sheets that are nearly C size.) I am also wrestling with the fact that I built the whole design using local names for the nets. In systems I had used in the past, all nets were global. A net named GND on one sheet was automatically connected to any nets with the same name on any other sheets in the project. I got a tip from another group member the other day that I ought to be able to change all local net names to global with a text editor. I’ll be checking this out very soon. I will also be very interested to see how the board layout tools work. As I mentioned earlier, the system I used a lot years ago had an awful auto-router and I hand-routed most boards in less time, plus I always got it 100% routed, but not the auto-router. I would really like to post my KiCAD schematics, but I’m unsure how. If you have stuck with me through this whole email and you got here, and you know how to post files like the KiCAD files, please reply and let me know. Bob Bell From: n8vem...@googlegroups.com [mailto:n8vem...@googlegroups.com] On Behalf Of John Monahan Bob what is the circuit, I’m really surprised freerouter could not do a two layer board. I have done 80486 boards where literally finding spaces for the chips became the issue yet freerouter resolved in 2-3 days. The initial placement of chips is most critical. Try and avoid as much as possible the net wires crossing over each other. Another trick is to let it run say 2 or three days. Save the file, and in KiCAD see what is not connected. Start again, but first link up by hand the previously unconnected wires. Most companies these days will do multilayer boards including PCBCart. However > 2 layers are more than 2X more expensive. Have not done > 2 layers John From: n8vem...@googlegroups.com [mailto:n8vem...@googlegroups.com] On Behalf Of Bob Bell I am working on a board design (details to appear later - it's getting close) and I am concerned about component density and the ability to route the board. A previous version of the board pretty much maxed out component count and took several weeks (albeit rare spare time) to hand route (the autorouter I was using at the time just utterly gave up.) This new design, even with all the random logic and some of the higher-level logic crammed into 12 GALs, exceeds the pin count, my measure of board density, of the previous version by nearly 30%. So, it is looking quite likely that I'll need to go to at least a 4-layer board to be sure it can be routed with the chips as close to each other as I believe they will need to be. -- -- You received this message because you are subscribed to the Google Groups "N8VEM-S100" group. To unsubscribe from this group and stop receiving emails from it, send an email to n8vem-s100+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. |