jfoucher on Sun 27 Dec 2020 wrote:
I've been lurking on this forum for a few years
If you've been lurking for more than three years then you might hold the record.
jfoucher on Sun 27 Dec 2020 wrote:
RC2014
People have put 6502 on RC2014 bus. However, the memory maps don't match. So, unless 6502 is used with incompatible RAM/ROM, some of the upper address lines must be inverted. Also, I presume that full peripheral compatibility requires a 6502 I/O hole to be mapped to Z80's IOREQ using 74x688. This chip is notoriously slow and may be incompatible with your target of 10MHz. Indeed, if you can sidestep this, 14MHz should be attainable.
Anyhow, I have some advice. Feel free to apply pieces of it according to your preferences and judgement.
Firstly,
I've already stated that I'd like an ITX board with 65SIB. This also applies to Mini-ITX or smaller, such as 100mm*100mm. Therefore, whatever you devise, I'd like to make an initial purchase of two units and more to follow. I trust your instincts with design choices.
Secondly, now that you've de-lurked, you'll have to ignore the whingers. For every permutation of hardware or software, someone will disagree. A minority of them will have the decency to publish an outline specification prior to disagreement but I suspect that some of them contrarians or wish to impede the progress of others. If they don't like your design decisions, they are free to make their own variants.
Thirdly, I totally get the hard limit of a 100mm*100mm board. Prototyping board exceeding 300mm*100mm used to be commonplace. However, with increased scale of integration, it is now common to obtain a microcontroller with serial ROM and WiFi or an accelerometer which is 40mm*30 or significantly smaller. With competitive pressure on circuit board prototyping services, a credit card circuit board gets expensive and the smallest 160mm*100mm EuroCard prohibitively so. I also wonder about the budget of some hobbyists given that 1/3 of people in US cannot raise USD400 in an emergency. In other countries, USD50 is a significant commitment.
Fourthly, you have conflicting constraints, and especially so when you have a hard limit on board size (and the helpful contributions of the peanut gallery). However, I strongly suggest placing speed ahead of need. Specifically, all high speed, parallel hardware should be adjacent to the processor. That's ROM, RAM and video. All else is secondary. Indeed, I may persuade you that a bus expansion connector may not be required or that it is relegated to a miscellaneous, we-hadn't-thought-of-it connector likely to be used by zero or one cards.
You may have seen recent discussion regarding
processor stacking and
RAM stacking. While I am a keen advocate of processor stacking, a design with FPGA may benefit more from using the alternate clock phase for video, DMA and/or a soft-core with custom instructions, such as hardware multiply. Other uses may include
decompression hardware, a polygon engine or an alternate processor architecture, such as 6809 or Z80. Anyhow, I strongly recommend against DIP 65C02 and instead use a smaller package. This should save about 1/16 of the board area.
74x138 allows eight RAM to be stacked. If 74x138 is itself stacked, it is quite easy to make a stack of 24 (or more) RAM chips. Therefore, using 128KB static RAM, it is possible to place 2MB or more in one socket directly adjacent to the processor. Given that ROM and RAM (of different form factors) often have similar pin-out, it is possible to place one surface mount EEPROM at the bottom of one optional ROM socket/RAM stack and place one surface mount RAM at the bottom of another optional stack. Fly leads determine address decode and read/write functionality. A further tip that I've seen (from BigDumbDinosaur or drogon?) is to never solder a relatively expensive ZIF socket. Instead, it is possible to insert a ZIF socket into a DIP socket during development and then remove the unsoldered ZIF socket when complete. This elevated arrangement may also require less space around a ROM socket for ZIF handle. Anyhow, this requires approximately 1/4 of your board but it practically eliminates the requirement for a RAM expansion card.
A video connector of any type plus FPGA, power regulation, boot ROM and boot ROM programming socket requires a minimum of 3/16 of the board area. Optional video DRAM may require another 3/16. Therefore, it may be highly preferable to omit video DRAM restrict display to character tile data sourced from static RAM. Regardless, FPGA is likely to perform unrelated functions. The standard technique for FPGA systems is to hold the processor in a reset state until the FPGA configuration is loaded from serial ROM and initialization is complete. During this period, an FPGA may populate static RAM with debug software. FPGA can also be used for clock division and address decode. Some FPGA provide PCI Express. I am not suggesting that you choose such a unit but your design is likely to be upward compatible with PCI Express and therefore a future iteration may have a bridge to SCSI, SATA and Ethernet. Dual port RAM in FPGA is suitable to implement a
cell network hardware suitable for a near universal
tape/disk/keyboard/mouse/PAN/LAN/WAN interface. In the trivial case, eight bi-directional FPGA UARTs (without hardware handshake) can be wired to four PS/2 connectors which may also provide power to peripherals. Four PS/2 connectors require approximately 1/16 of your board area.
To aid bootstrap, it may be preferable to connect keyboard in a manner which bypasses FPGA. (
I've previously suggested this with W65C265 microcontroller.) While a dual 6522 configuration would obtain much goodwill, this may not be compatible with your desire to avoid clock stretching and similar techniques. Instead, it is possible to use one or more 74x574 latches and one or more 74x244 (or 74x245) buffers to obtain a switch matrix interface up to 16*16. This can be connected to any cheap keyboard after its PS/2 or USB controller is removed. After further development, the interface may be re-purposed as GPIO. Indeed, I suggest that the parallel port approximates the conventions of 26 pin or 40 pin Raspberry Pi connector. This would provide compatibility with a subset of existing peripherals.
65SIB is quite obviously intended to use 74x138 for decode. In a minor case of chip stacking, it is possible to obtain 16 or more multiplexed channels. Seven of these may be allocated to a primary 65SIB connector. Another seven may be allocated to an optional secondary 65SIB connector. The remainder may be allocated to internal use (RTC, config EEPROM, thermometer, status lights) or the Raspberry Pi connector.
With VGA, ROM socket, RAM stack, eight unclocked serial channels, 24 clocked serial channels, Raspberry Pi GPIO connector and possible future expansion with PCI Express, I am not sure that a dedicated bus expansion connector is the best use of space. Indeed, such expansion can be bodged from RAM socket. The missing signal lines can be provided from an adjacent socket with known placement and configuration. Without loss of generality, this uses considerably less space on the main board and you do not have to worry about the reliability of this bodge. I believe that BigDumbDinosaur implemented an expansion board in a similar manner prior to the probable world record for 65816 + SCSI uptime exceeding 300 days.
Regarding clock speed, 80MHz oscillator provides a suitable video dot clock for 1280*720 and FPGA can divide by 5-20 for 65C02. Future iterations of the design could use 150MHz oscillator suitable for
2K video (1920*1080) although, without space for video DRAM, this may be
limited to tiles of some description. In all cases, FPGA for video is a hedged bet which allows you to follow any advances made by ElEctric_EyE, Radical Brad or others. I am not fussed by the details of FPGA. I believe that anything with 10000 LUTs would be more than sufficient to implement a
VIPER and a VIC-II. Prior to a self-hosted system, the least constrained development environment may be an advantage. In particular, any FPGA partially supported by open source tools may draw more interest. However, the preferences of idiots like me with full stack of vaporware are secondary to people making practical advances with FPGA video.
At the risk of minor blasphemy, it is possible to save approximately 1/16 of the board area by eliminating 65C02 and rely upon one or more soft-cores.
I have been recently alerted to
BigEd's work in this field.
Here's a quick board area budget where the limit is approximately 16 square inches:
- 1 square inch for board fixing holes.
- 1 square inch for four pin Molex power connector and power regulation.
- 0.5 square inches for oscillator.
- 1 square inch for 65C02.
- 3-8 square inches for ROM/RAM/expansion.
- 3-6 square inches for video and miscellaneous tasks.
- 4 square inches for parallel port.
- 1 square inch for UART/cell networking.
- 1 square inch for 65SIB.
To minimize cost, I believe that a two layer board is possible. If you are lucky, you might get three ROM/RAM sockets on the first iteration but this may not continue to future iterations. Indeed, pressure of space allocation may reduce sockets to a boot ROM hidden under one RAM stack.
Anyhow, pick through my message for useful ideas. In the case that you reject all of them, I still wish to purchase multiple units from you because it is preferable for us to have economies of scale and a common development platform.