Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
|
Twelve years ago, I made my first post here about my POC (Proof of Concept) design I had started, a basic 65C816 circuit that...well...was meant to prove that my concept of how to build a small computer was sound. POC V1.0 worked well after some patches were made to the original design. Those patches were eventually rolled into POC V1.1, which had the same memory map, RAM, ROM and I/O as V1.0, but incorporated some additional features to support using the real-time clock socket as an expansion socket. V1.1 was stable to 14 MHz and by the time I was ready to move on from it, it had SCSI and thus could work with mass storage.
Following the construction of POC V1.1, I started thinking about building something more elaborate, a unit that would have more serial ports, more RAM and programmable logic, which I was going to call POC V2. Several designs came out of that project, but all had problems that I ultimately decided were due to me leaping ahead too quickly and introducing too many new features at once. That epiphany prompted me to return to the V1 series and build V1.2, still an all-discrete design.
V1.2 was meant to be a test-bed on which to work out how to get four-channel serial communication working, which was accomplished. V1.2 was also a test-bed for wait-stating via clock-stretching, a feature that made it possible to run the unit at 20 MHz. V1.2 led V1.3, which, still all-discrete, is able to use almost the entire address space in the 128KB RAM with which it is fitted. A planned successor to V1.3, which would have had 512KB of RAM, was on the drawing board, but I decided not to proceed with it, mostly due to the large amount of glue logic that would be required to make it work using discrete gates. I decided that V1.3 was as far as I would go with a discrete logic system and that it was time to return to programmable logic.
Now I am on to POC V2, but in a new direction, as the original POC V2 project is dead. This new incarnation will proceed more incrementally than the original V2, which I hope will minimize the difficulty of making it work. As I have developed a functional "virtual QUART" (vQUART), suitable driver software for it, and wait-stating via clock-stretching—all tested on POC V1.3—the task of designing this new POC V2 series would be less onerous.
V2.0 may be best described as V1.3, but with a CPLD replacing almost all of the glue logic. This new unit's main purpose will be to refine the use of the CPLD, as well as to experiment with various memory map configurations and make circuit operation observations with the 'scope and logic analyzer. The knowledge thus gleaned will—I hope—lead to building a system with much more RAM and other features.
Anyhow, here's the schematic for V2.0:
Attachment:
File comment: POC V2.0 Schematic
poc_v2.0.pdf [366.51 KiB]
Downloaded 160 times
...and here's the PCB layout I developed:
Attachment:
File comment: POC V2.0 Printed Circuit Board
v2_pcb.gif [ 108.74 KiB | Viewed 2725 times ]
New to V2.0 are:
- CPLD in place of discrete glue logic. The CPLD will generate extended addressing (A16 only, since the RAM is 128KB), chip selects, qualified /RD and /WD control signals and a wait-state-enable (/WSE) signal to control the clock generator. I will be using the Microchip (Atmel) ATF1504AS in PLCC44, which has 64 macrocells and 32 uncommitted I/O pins—all but one of those I/O pins will be used. V2.0 will include a JTAG port for in-system programming of the CPLD.
- Data bus transceiver. Observation of POC V1.3's behavior has led me to conclude use of a transceiver to isolate the data bus from the MPU while the latter is emitting the bank bits during Ø2 low will be beneficial. The transceiver will mitigate the potential for bus contention, and will also act as a level converter to "boost" the TTL-level outputs of the SRAM and ROM during a data fetch cycle.
- A card-edge socket for expansion. Interfacing an expansion card to the unit will be easier, as I don't have to deal with long extender pins going into a DIP socket, as was the case with the V1 series. Also, the card-edge socket has more pins (36 total), which allow me to bring more signals to it, as well as provide more Vcc and ground connections.
- More test point headers. These will make hooking up my test gear more convenient, which may prove to be very useful in the event the unit is DOA or unstable on the first power-up.
V2.0's memory map initially will be the same as V1.3's, which means I can actually use V1.3's firmware for initial testing (initial testing of V1.3 was done using V1.2's firmware—in fact, I "stole" the ROM from V1.2 and plugged it into V1.3 for that first go). That memory map decodes the I/O block into pages, which requires the glue logic only be aware of the MSB of the address bus, that is, A8-A15.
The observant reader of the schematic will note I've also connected A6 and A7 to the CPLD. Doing so allows me to make the I/O block decoding more granular, effectively reducing the size of the I/O block by quite a bit. As the CPLD logic assumes that anything that isn't a ROM or I/O access is a RAM access, shrinking the I/O block frees up RAM that would otherwise be inaccessible. This RAM will be reserved for use by the firmware: direct page and circular queues for serial I/O (SIO). The latter use bears some explaining.
Since there are four UARTs, and since each UART needs two queues—received and transmit, a total of eight queues must be provided. The typical arrangement with a 65xx MPU is to use a page of RAM per queue, which is very convenient from an indexing perspective. Eight pages is 2KB total. In the V1 units, the limitations of discrete glue logic restricts bank $00 to 48KB of contiguous RAM, from which direct page, the hardware stack and the SIO queues have to be allocated.
2KB for the SIO queues was more contiguous RAM than I was willing to sacrifice, so I developed queue management code that would allow me to make the queues as small as 64 bytes each. The management code adds processing time to interrupts, as well as the SIO foreground functions, slowing them down. Also, a small queue causes frequent blocking if a large stream of data, such as a full console screen repaint, is transmitted. A small receive queue makes reception more prone to dropped datums should the foreground not retrieve them often enough.
With that in mind, and given the greater address decoding granularity that is possible in a CPLD, I connected A6 and A7 so I can ultimately parcel out the I/O block in smaller chunks. I/O starts at $00C000 and with it decoded into pages, the address range would be $00C000-$00C6FF, as there are seven I/O devices. The space from $00C700 to $00CFFF would be seen as RAM, which would amount to 2304 bytes. I could cram the eight SIO queues in there at 256 bytes each, with one page of RAM left that could be the firmware's direct page, thus making that address range a "reserved" or "system" area. Doing so would leave almost all of bank $00 RAM from $000000-$00BFFF (48 KB) for user code and data, user direct page and the hardware stack. I say "almost" because there are firmware vectors that have to be in RAM somewhere, as well as workspace for buffers and such.
Thinking about that for a while, I decided that if I added A6 and A7 to the CPLD's decoding menu I could reduce the size of each I/O slot to 64 bytes, with a corresponding increase in the "reserved" RAM that is above the I/O block. The new effective address range for the I/O block would become $00C000-$00C1CF. I'd want to reserve an extra I/O slot...just in case, as well as make sure the system area starts on an even page boundary so direct page accesses don't get penalized.
Accordingly, I'd start the system area at $00C300, extending to $00CFFF, for a total of 3328 bytes. Subtracting out the space needed for eight 256 byte SIO queues (2048 bytes total) and 256 bytes for system direct page, I'd have 1280 bytes left over. If I place the top of the stack at $00CFFF and not have it expand more than two pages (which would be a big stack), I'd have 768 bytes left over for vectors, buffers, and other firmware workspace, e.g., the SCSI device table. All RAM below the I/O block, as well as all RAM at $010000 and beyond would be unencumbered.
So I've got some work to do to build the unit and see if it goes or blows.
———————————————————————————————————
EDIT: Replaced the schematic PDF with a corrected version. The original had an error in the expansion connector pin-out table.
_________________ x86? We ain't got no x86. We don't NEED no stinking x86!
Last edited by BigDumbDinosaur on Fri Mar 22, 2024 9:44 pm, edited 5 times in total.
|
|
Login
Register
FAQ
Search
