Everything said below is a personal project. Nothing here should be read to imply this hardware will be finished, released or made. It exists in proto boards on my bench. Half the features have no driver or software support and may never have it. Have low expectations.
With that in mind, read on:
janbredenbeek wrote: Sat Sep 06, 2025 8:28 am
You can actually run any supported version of QDOS/Minerva by loading the images of the QDOS/Minerva + (S)GC 2.49 into RAM above $50000, doing a few POKEs and CALLing the (S)GC ROM, as described
here. Beware though that the first two vectors at $0 and $4 are immutable, even with RAM switched on, so if your custom ROM has a different boot address you will get into trouble with the various boot utilities.
This is something I need a clearer understanding of. It really forces me to show my hand to provide context to frame the intent of the question.
$050000 is on the 320K boundary. A system has 8MB of RAM ($800000) starting at $020000 so running from $020000 to $81FFFF. Does Minerva or SMSQ/E arbitrarily place itself at $050000 or at a position relative to ramtop or rambottom or....?
Current memory map:
$FFFFFF Top of addressable range
$E00000 Flash (2MB)
$C00000 Frame buffer (2MB)
$A00000 Frame buffer shadow RAM
$820000 16x expansion slots [1]
$020000 RAM start (8MB)
$018000 Internal IO (fully decoded, includes additional internal IO in fixed/standardized positions)
$000100 SRAM (used by Minerva
)
$000000 Vector table (Flash on init, swapped to RAM by trigger event)
The expandability is that I intend to support up to 1GB addressable range. The top two address lines on 32-bit address bus CPUs will not be used for compiler compatibility. In those machines the top of the addressable range is at $3FFFFFFF. I propose to relocate flash, the frame buffer and expansion slots up to the top, but have allocation for two 2MB frame buffers to leave open the option for dual screen support. [2]
As soon as I complete the 68SEC000 version of this board I will jump in with the 68020/030 versions. These are set to have the same size, positions of all connectors and share a common case/power supply/expansion system. To avoid problems with relocating expansion cards, I have designed the slots to have global card select signaling. The cards only see a very small segment of the address range. Address and data lines are isolated when no card is selected, though interrupts pass through regardless. The CPU/OS treats the cards as at their mapped location so the on-board ROMs' relative addressing works correctly. Extended cards can see the entire 32 bits of the used address bus. This is so future expansion options can exist, and because the board runs EmuTOS, which can use the full 4GB address range.
Some of these elements are interesting enough to place standalone on cards for BBQLs. Others really only suit higher powered compatible machines.
Address decoding for chip enables is handled by a large CPLD. This supports total reconfigurability. If I have made mapping errors a reprogram of the CPLD can change everything. As nothing is written in stone, I'm asking these very narrowly focused questions on the forum whenever a decision has long term consequences, may break something, or I have a hunch someone out there may know a very good reason it should be one way over another.
These answers are not just helpful to me. They encourage me to spend more time on it. This project has been on my bench in one form or another for 17 years now. The bench has changed and moved to a dedicated lab space in that time. My skills have increased manyfold. This is in part due to the ever patient Nasta. He has spent far more time with me, explaining arcane details, than ever seemed reasonable to me. I am so grateful to him. I'm also grateful to the various lecturers and TAs at Austin Community College and the University of Texas for formalising that education and pushing me towards new skills and areas of study that have made projects like this fit much more intuitively into my thought process. Community members out there who still answer random emailed and forum questions despite my shortcomings and sometimes impatient manner close out the triangle of gratitude. You have a depth and breadth of knowledge that is hard learned, valuable and very much appreciated. Even if I don't get along with your approach to things as individuals, I vastly respect the knowledge and work you've done and continue to do.
Dave
[1] 1.8MB space organized as 8 x 16K (128K total) with the rest freely accessible to any card on the "QL dynamic bus" which is a 32/16/8 bit dynamic bus sizing implementation of the QL standard extension bus. The 16K slots have 7.5 MHz timings. The dynamic bus can provide QL timings, 16 MHz timings, or CPU native timings, selected by card configuration. This is implemented via two capability signals F0 and F1. The dynamic bus can accept an adapter board that converts it into an additional standard extension bus slot. The bus supports card bus mastering and DMA. The DMA function allows a card to, for example, process data into the frame buffer without CPU intervention. The bus is segmented into two domains, so DMA between expansions, the frame buffer or flash do not have to stop the CPU. This is identical to the mechanism intended in QL Issue 6/7 boards, where the CPU can still access IO during video read-out.
Backplane intention:
4x standard or 8x standard, stackable
4x extended or 8x extended, stackable
The cards have a common through connector so can be placed on the system in any combination. Up to 16 standard or extended slots can be installed. The backplanes are buffered. Each card can draw up to 500mA 5V and 500mA 3.3V. This allows 3.3V cards to function with 5V IO. Maximum total load on the 3.3V or 5V rail is 2.5A sustained or 3.25A transitory up to 0.2 seconds, combined for all cards installed. The top card is active terminated. There are two versions of the termination board. One is vanilla. The other is a full blinkenlights board with LEDs for every pertinent signal. It's very pretty
It'll be an open spec, and any custom combination of slots can be used. It follows the Risc PC model of expansion. All that is left to do is recalculate the dimensions and socket positions as extended slots use a different connector that is card edge based. These sockets need to be at a different height from DIN connectors so the boards retain consistent position in relation to the guide slots in the case.
[2] My video system is very amenable to supporting multiple displays by duplicating the frame buffer. I suspect no mechanism exists currently to support two screens with channels mapped on a per screen basis. However, If multiple channels are opened overlapping each other and some are only used on Minerva's screen0 and others on screen1, it does work. I have written S*BASIC code that allows the hardware pointer to be mapped continuously across both screens. The possibility exists to extend this code into SMSQ/E. Potential future developments could support different resolutions and colour depths for each screen. This enables using one screen as the program windows and the other as the output windows.
At this time my card supports numerous Aurora modes, but does not fully support modes 4 or 8
yet. This is solved on paper but not in practice. A CPLD will duplicate the mode 4/8/other registers. If mode 4 or 8 are selected bit reordering will occur to the frame buffer. The original data will be written to shadow RAM during the same cycle. Frame buffer shadowing ensures the CPU
never has to wait for the video chip to respond while writing out display data to the digital video chip. If neither mode 4 or 8 are selected the data will be passed straight through. The flash on/off bit operates a flipflop that changes how the bits are reordered to create alternate colours. This can be used as an alternate palette, or by altering the palette LUT every 0.5 seconds to create the flash effect. Reads would be from shadow RAM, and would always contain the original data the OS thinks it is working with. This supports read/modify/write cycles too. All video accesses are 16 bit width. The frame buffer does not occupy CPU bandwidth.