SGC ROM position RFC

[janbredenbeek]

You have to delve into the source code for that. So far, I've seen it relocating to two or three areas:

- 00000-0BFFF
- 10000-17FFF (not on GC/SGC)
- top of physical ram (RAMTOP is lowered)

[tofro]

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

For some of the modules, it is obvious (like that the vector table needs to go to $0), for most, the only (and best) documentation is the source code. (Have a look at the module headers)

[Pr0f]

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

For some of the modules, it is obvious (like that the vector table needs to go to $0), for most, the only (and best) documentation is the source code. (Have a look at the module headers)

Many thanks,

Looks like I have some reading to do

[Peter]

The expandability is that I intend to support up to 1GB addressable range.

Not possible due to QLiberator abusing the upper three address lines. 512 MB is maximum.

[Pr0f]

The expandability is that I intend to support up to 1GB addressable range.

Not possible due to QLiberator abusing the upper three address lines. 512 MB is maximum.

Yes - 1GB would be possible if only the top 2 lines had been clobbered / usurped - but 3 address lines leaves you with 2^29 - so 512Mb maximum

I am guessing modifying Qiberator, as we have source for that - to change the way these lines are used or even not using them is quite a piece of work.

The other approach would be to allow 4Gb space, but have some sort of VM type architecture - and run individual address spaces within a restricted memory map.

[Dave]

The expandability is that I intend to support up to 1GB addressable range.

Not possible due to QLiberator abusing the upper three address lines. 512 MB is maximum.

Thanks for the correction. I thought it was two. An incredibly short-sighted decision by the author in hindsight, but at the time who ever thought it would still be in use 40 years later?

While there are ways that could be implemented to bypass this limitation, Any amount past about 32 MB really makes no practical difference except for new code. I've never run out of memory on my Q68 even once.

I'll temper my ambitions on RAM size.

I am providing 2MB of flash, which operates at CPU speed and bus width. It is a suitable location to directly run SMSQ/E from. I do wonder if there are any versions of SMSQ/E for any machines that run in place, with the OS image and vector table already fixed in their final running position at power-up? If so and if that version is relocatable, it might be a better SMSQ/E version to start compatibility efforts on than the SGC version I have been considering. I have Minerva booting (though I don't go much past there as I am still working out some basic issues) but I think it would be nice to have SMSQ/E native as the default OS with Minerva as a PRAM selectable alternative.

Which reminds me. I have been thinking about start-up behaviour. It crossed my mind that it might be interesting to have the user hold down 1, 2 or space on startup/reset to select mode 4/8/other to force a particular mode. That selection would be stored in PRAM. If a key isn't pressed, on startup/reset the PRAM would indicate the previously selected mode and take that as a default. If the mode is not 4/8 but a GD2 mode, the mode number would be saved in the byte. Users can create custom mode definitions for the video subsystem which can be applied using MODE NN in the usual manner. User created modes are saved as mode definition files in a system folder, exactly like on the Risc PC. The only work remaining there is to convert the BASIC program to assembly and link it into the OS as a new BASIC keyword.

The F1/F2 selection is a QL emblem so I considered that having $00 stored in the PRAM byte would display the original selection screen for those that wish to retain the original functionality.