If I understand correctly - True Hires is either
- a memory expansion with Hires capability,
- a modified memory expansion, or
- an internal modification addition of RAM circuits.
Hires needs the amount of memory needed for the screen which sets the hires.
The size of the screen is adjustable, but most common is a screen of 32x192=6144 bytes with the displayroutine to it.
Where the needed memory is located is irrelevant for the computer, but the memory must be able to read the hiresdata.
This is indeed done with the above methods, although I wouldn't alter the internal memory of the machine.
In fact for the software it doesn't matter where/how the memory is arranged. It only needs to be accessible.
The ZX18 has 1K RAM and the TS1000 has 2K RAM inside, so on a TS1000 you could code games with larger hiresscreens without needing a memorypack.
My very first game in hires for the ZX81 used a 32x192 screen, but it worked a bit like a ZX Spectrum.
The game was originally written for the ZX Spectrum where all printing was done by RST 10 and the charactercode in A.
This register held the standard characterset or UDG.
For the game on the ZX81 I only altered the relevant parts of printing and reading the keyboard. Game itself remained as it was. The printing was simply altered in a routine that printed a character from the ROM (ASCII-code31 to 128) or a UDG (ASCII 144>) on the hiresscreen by calculating the startposition and then add 32 for the next line.
Unlike the ZX Spectrum all lines in hires are in order and not by a step 256.
So the game is true hires, although the display is done like UDG on PRINT AT positions.
Your 32x192 screen must start at a number of 32. The only reason for this is that during display the R-register won't go from 127 to 128, but back to 0 and thus displaying a false line of data. When your screen uses other dimensions yu must make sure that ANY line will end #7F or #FF. A screen 16x192 can start on any number of 16.
As for 1K Hires.
1K Hires is only possible with either a small sized screen or a displaymethod that unpacks a compressed screen during display. For each game you need to determine how you will store the screen and code a unpacking displayroutine.
It all started with a small sized screen that 'walked' over the screen and thus showing the parts of a maze where you were. After that all kinds of compression are worked out to make fullsized/halfsized/pixelmovement/charactermovement possible in games fitting 1K.
Best way to start (well that's what I did):
Use a method as described by the pages of Wilf Rigter. Even better, use the setting of IX. Other methods might have problems with modern interfaces (I had to alter my 1K games, now default set of IX).
Use the displayroutine mentioned there and code a simple display. I.e. a continuous counter from 0 to 255 on the first and last cell of the screen and let it run.
When running, you can alter as much as you like. Don't alter the hires screen display. Adding text is possible in lowres before or after the screen. On the screen you could use my PRINT AT from Shogun. Source can be shared.
With the PRINT AT you could also define your own characterset. Instead of pointing to ROM you could point to your own defined characterset.
As for 1K hires routines:
the games and sources can be found in the newgames-section.