SGC ROM position RFC

[Dave]

Hi folks.

Just want some feedback. I'm putting this in the Software section because it's about loading software in the memory map. The hardware behind it is secondary.

On a running Super Gold Card, there is an unused area from the top of the vector table ending at $3FF up to the bottom of the IO area at $18000. This is 96K that appears unused in the SGC memory map.

If I map SRAM into $00000 to hold the vector table, I could map SRAM up to the start of the internal IO area. Then, if users wish, they could copy ROM images into there arbitrarily and call them. This could free up as much as 95K in main memory. The internal IO notch is really very small. There is another 16K above that to the base of video RAM at $20000 that could be SRAM too.

I see people may like to have a boot script that copies ROMs into that extra space, calls them to link them in, then continues on.

Is that useful? Does it break anything? Would you use it? If you don't care, does it make any difference?

Feedback!

[swensont]

With the ZX81 and the T/S 2068, understanding the memory map is important, as there is little memory and you need to know how to use it best. On the QL, I've never really had to look at the memory map. When I had a BBQL, I just had to worry about the amount of memory, but not where things were stored. With emulators, and a ton of memory, I never have to worry about memory at all.

Tim

[Dave]

I feel this. I do.

If this idea would cost one penny I probably wouldn’t have mentioned it. It is cheaper. If it is unused it makes no difference.

Do you think it could break anything?

[janbredenbeek]

The area between $10000 and $17FFF is actually used to store half of the (S)GC ROM, which is copied to RAM on startup. The rest of the (S)GC ROM is copied to $1C200-$1CFFF (mainly for patches to the QDOS or Minerva ROM) or used to boot the system.

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.

[Dave]

This is very helpful. Thank you.

This makes the original question moot. I absolutely don’t want to break compatibility.

I need to ruminate some more because this may create another challenge.

[Dave]

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:

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.

[janbredenbeek]

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....?

The $50000 address is actually only used temporarily by the GC boot procedure. The whole boot process is described by Marcel here.

Under Minerva, the main OS occupies $00000-$0BFFF, with $0C000-$17FFF available for boot-time extensions and drivers (on the Q68, the ROM image may be up to 96K).

Everything up from $20000 is considered to be RAM (subject to RAM check on startup). But on Minerva, RAM support is limited to 16MB because everything not allocated to programs or data is considered to be slave blocks, and the table used to track these blocks uses word-size indexes.

On SMSQ/E, use of slave blocks is limited to the first 1MB (at least on platforms with much RAM available such as QPC or Q68) and the OS is loaded in parts (in low memory below $18000 and in high memory just below top of physical RAM).

[Pr0f]

The exact location of these parts loaded in the lower RAM areas - is this documented anywhere?

I understood that the lower 48K/64K of RAM would potentially be overwritten by SGC, but that it preserves it's only memory use between $10000 and $17FFF, then the QL internal I/O area between $18000 and $1BFFF is left untouched, and the SGC uses the next 16K area - $1C000-$1FFFF for it's own I/O and patches. Every address after that is RAM till the 4MB boundary.

But the boot process for SGC documented by Marcel is for QDOS / Minvera boot - SMSQ is booted from a disk image - I understood it was loaded at £30000, but it seems some updates are made in the lower RAM area?

[tofro]

But the boot process for SGC documented by Marcel is for QDOS / Minvera boot - SMSQ is booted from a disk image - I understood it was loaded at £30000, but it seems some updates are made in the lower RAM area?

The load address and run address of an SMSQ/E image is totally unrelated. SMSQ/E relocates its modules after loading on basically all platforms (except on some where it's in ROM).

[Pr0f]

Is the information about what it relocates on what platform documented somewhere - which was basically the question I was asking.