-
Notifications
You must be signed in to change notification settings - Fork 1
Home
This project is based on hardware and software developed here: https://github.com/EtchedPixels/Mini11 Overview
This is a 10cm * 10cm PCB with an MC68HC11A1 processor. It uses SMD PCB construction and MSI glue logic in the 74HC line. It does not have any programmable logic device other than the EEPROM built into the HC11. To interface with additional peripherals, the board follows M8 sytem outline and mounting hole dimensions, and is equipped with a full bus interface that will connect with the M8 series of peripheral expansion PCB's available on this repository.
The processor itself has a lot of built in features that make a self contained computer easier to make. The serial connection can connect to a host computer or some other device. The processor can support a TF memory card directly with software driving the built in SPI. That gives it a disk. To complement that there is 512kb of non volatile memory, battery backed up. Any 32k bank of this memory can be assigned to either the upper or lower 32k of the CPU memory map, by writing to the memory paging control latch. This essentially makes all the 512k memory selectively available to the CPU.
The main memory is made non-volatile using a DS1210 NVRAM controller IC. There is provision for either an on board or external battery, and also an auxiliary battery for additional protection or to allow hot swapping batteries.
A useful feature for many users, is that it requires no ROM/EPROM/EEPROM's or their associated programming devices. The MBUG or JBUG PC resident debug applications can access the HC11 directly via a serial port, and install the necessary boot and monitor software, or any other software.
0000-7FFF Bank 0 NVRAM
8000-EFFF Bank 1 NVRAM
F000-F03F CPU control registers
F040-F0FF Internal RAM
F100-F3FF Bank 1 NVRAM
F400-F7FF Expansion Bus Device Select
F800-FDFF Memory Paging Register (write only)
FC00-FFFF Bank 1 NVRAM
(not current - work in progress)
0000-EFFF dual bank general purpose memory
EF80 stack
EFC4-EFFF CPU vector jump table
FC00-FFFF Boot code
FF80 I/O vector table
FFD6-FFFF CPU vectors
Currently, the system boots from either the RAM or HC11 internal EEPROM, depending on the placement of jumper J2.
The CPU vectors in high RAM may be copied into a vector table in RAM so that they can be redirected. Unlike most other systems, you can also modify the actual CPU vectors in place (taking due caution).
Memory banking is simple. The upper 4 bits of the memory latch select one of sixteen 32kb blocs from the 512kb main memory, that will appear in the upper 32k of CPU memory. Similarly, the lower 4 bits of the memory latch select an independent 32k bank from main memory, which appears in the lower 32k of CPU memory.
The Mini11-M8E does not have any ROM in its memory map. So there are two ways to boot from a power down state.
- initiate HC11 special boot mode. Normally intended for debug access, this mode can also load and execute code resident in the EEPROM located at $B600 in the HC11. It is only 512 bytes, so the code there must load and run code from another source. Normally, the source would be a boot disk. So the boot disk also has boot code that will load the actual system core software. A serial loopback is required for the EEPROM boot mechanism to work, so it is enabled by PA5 during the boot sequence, and then disabled by boot code for normal use of the serial port.
- Code can be loaded directly into RAM, using Jbug, Mbug, or any other debug software for the HC11. This also uses special boot mode, but the debug software performs this transparently. Then, with J2 set to "RAM", the system will boot directly from the vectors stored in high RAM.
- once the boot firmware is installed, special boot mode is not needed, the monitor is active and can load S19 records from the serial port.
The HC11 SPI port is multiplexed to two devices on the board, a PCF2123 RTC, or a connector on which an SD memory card adapter can be placed. The device in use is selected in software by setting PA6.
The serial port connector is pinned and dimensioned to accept a common USB-serial adapter module based on the CH340E chip. This device can not achieve the arbitrary bit rates that are necessary for the HC11 debug mode to work. It is designed to be soldered to the board, so an alternate connector has been provided to plug in a compatible adapter, the FTDI FT232RL. Jumper J4 selects one of debug port, or on board USB adapter. Do not connect a USB cable to both ports at the same time, regardless of the jumper setting.
The serial loop back that starts an HC11 EEPROM boot, must be restored to a normal serial pass through after start up. Also, the SD interface and the RTC IC both share an MCU SPI port. So, it is required to switch two digital signals. This is done with a 74HCT153. The operation of the circuit is controlled by two GPIO signals and a jumper:
When set to "RAM", J2 passes serial input to the MCU. in the alternate position "EPR", it forces an EEPROM boot by echoing the character that the MCU sends at boot time. In the EPR position, the serial source can be restored to normal (external) by writing a "1" to GPIO PA5.
Secondly, the source of SPI bus source is chosen by GPIO PA6, a "0" selects the on board SPI port on J3, and a "1" selects the RTC IC.
The serial source is further chosen between the debug port, which is a FTDI, and the user port which is a CH340E module, with another jumper.
Set to "norm" for user serial port, alternate position to use debug port.
The 40 pin external bus interface is mapped by this board, as a set of standard and a set of equivalent signals. This board is an M8 bus controller. The interfaces form a matrix, which assigns individualistic signals from each different processor, to a single bus protocol. The highest and most complete bus model is the 6809, the bus is basically designed around it. But many signals can be omitted or repurposed, So in this case, the HC11 can not use the signals for the exact same purpose, it has some differences:
- Addresses and Data 16/8
- AS is used as a substitute for Q. Not quite the same timing but similar. So connected to Q on the M8 bus.
- E and R/W*
- IRQ
- NMI is routed to XIRQ on the M8 bus
- DIS common to all M8, in a memory cycle, commands the bus controller (CPU) to disable internal memory to allow external memory mapped devices to be enabled instead.
- BSEL0 common to all M8 controllers, addresses a segment of memory mapped I/O devices.
- RESET is now defined as a logic output on the M8 bus, a compatible device may use an open collector/ open drain arrangement as a source, if itself and all peripheral boards that are attached, are compatible with that method. A controller may use just an RC type reset circuit, and place it on the bus. But some devices need or prefer fast rise times and a simultaneous reset of many circuits. An RC is not well suited for this, so reset controller outputs connected to the M8 RESET line will be the norm. It means, an external device can not assert a reset, it can only be performed by the controller.
The DMA and timing signals of the M8 bus are not connected, because they aren't supported by the HC11. Those are BREQ, BA, HALT, and MR.
The KBUG monitor can be installed in RAM using MBUG or JBUG monitor software that uses the HC11 Special Boot Mode to access the memory or CPU. The current version is temporary, and only boots from RAM. It will be upgraded so that it will be loaded from a boot disk device, by a loader that boots from HC11 EEPROM.
To install the monitor, follow the JBUG or MBUG instructions to connect to the board. On this PCB, that means the MODA and MODB jumpers are installed and J4 set opposite to NORM. Once connected, install the monitor by uploading the S19 file. Note the following detail. When the board boots, the upper 32k actually points to block 0 in the RAM because of the paging system. So the boot process sets page 0 ($0000-$7FFF) to block 1 of the extended RAM. This enables contiguous main memory while not disturbing the monitor and vectors in high memory.
Additionally, note that in the case of an EEPROM boot, you must either host your entire code in EEPROM, or load it from disk or somewhere else (serial?). Booting from RAM allows the system to host up to the full 50k or so, of code, without any need for disk. A problem with a RAM boot is that the boot vectors and code are not write protected, so a system crash is fatal and requires a reload using the debug port.
The firmware really has two functions that are combined in one program now. In future these will be split.
- boot and system service (i.e. "kernel")
- boot and interrupt handling
- serial input/output
- mass storage access
- KBUG monitor
- read and patch memory locations
- load code from serial
- execute user programs
The firmware takes control when power is applied or when the system is reset by hardware. When the machine starts, the boot code performs the following steps:
- Relocate the MCU registers and internal memory to $F000
- Initialize the MCU hardware timer
- Enable the PA7 LED
- Set page 0 (low 32k memory) to extended memory bank 1.
- Initialize the UART
- Set up the indirect vector jump table
The KBUG monitor is very similar to MIKBUG in operation, it is derived from it. It resides in high memory, just below the CPU response vectors. After boot, it runs a memory test and displays the result. Then, it listens on the serial port and accepts commands from an input prompt. All the commands are a single letter. Due to the extreme simplicity of KBUG which is inherited from MIKBUG, the commands have some not so obvious features. The idea is to provide some way to do almost any utility task, with a minimum of commands and options. However this also makes the code very compact.
"M" - modify. After "M", enter a four digit hex address. The contents of that address will be displayed instantly in hex. If you press , control goes back to the monitor. Else, you can enter a new value in hex and it will be written to that address.
"W" - write. This is like "M" but is write only, it never performs a read of the memory specified. It is used to write values to write only memory locations like I/O latches that can be disturbed by reading them.
"P" - displays the contents of all CPU registers. Well, not really. Actually, it displays the contents of the stack pointer, along with the contents of a segment of memory that contains values that will be loaded into the CPU when the "G" command is executed. This is a little strange, but it's a clever way that the MIKBUG designers used to efficiently launch test code, with user specified register contents. You can edit those memory locations to fill them with any desired values, especially but not limited to, the program counter. This register variable storage area begins at the stack pointer location and consists of the 11 registers, in the order CC B A XH XL YH YL PH PL SH SL. So, if you read the values in SH and SL, it gives the address of the first cell, assigned to the condition code register CC. You can edit all those values and view them with the "P" command. Initially, the editable bytes that define the register contents begin right at the stack pointer location (the stack grows down from there). For example if SH=F0 and SL=B9, then the stack is pointing to $F0B9, and editing that location with "M" will modify the CC value.
"G" - go. This will begin program execution with the contents of the registers shown with the "P" command.
"X" - execute. This will begin program execution at a fixed location, currently $0000. It is a simpler version of the "G" command provided for convenience while testing.
"L" - load. Begin accepting S19 records to load a user program. Note that the CPU is not fast enough to keep up with a 115200 baud stream during loading, so your terminal software must be configured with 1ms delays with each byte that is sent during an S19 upload.
The M8E has an on board timekeeping IC, the Philips PCF2123. It is connected to the same circuit that battery backs up the 512k SRAM. So, it runs continuously whether the main board power is on or not. It is a calendar/clock and also can be set to cause periodic interrupts on command. The clock has a hardware output connected to one of the on board LEDs. It is programmable, so it can effectively be one of, lower intensity (PWM'd at high speed), blink at 2 Hz, or off.
There is a crystal frequency offset correction circuit in the PCF2123. Setting the correct offset will cause the system clock to add or omit 1/60th second timekeeping pulses, so as to compensate for crystal frequency error. Enabling and calibrating this system dramatically improves the clock accuracy since indoors at least, the crystals are designed to vary the least at room temperature. Normally it is possible to keep time to within a few seconds a week this way.
The hardware organization of the IC is as a BCD counter, so adjustments such as to or from UTC are not simple. On the other hand, it does make it easy to manage local time. With appropriate routines, it could be translated to and from "epoch" 32 bit times. Those make time calculations such as time zone adjustments much simpler.
The clock has a flag that can detect whether power has been lost. So if the time is then set correctly the flag will be clear and will run until long term correction is needed (or DST adjustments). The offset value that is used to correct for crystal frequency offset will be stored in the upper byte of on chip EEPROM.
The firmware includes a separate set of core functions, and those will include routines to get and set the time and calendar date, change modes and so on. In future, they will be combined with the other SPI device handlers, notably SD storage. It's important to coordinate these because they share a SPI port.