SCREEN1 = SYSVAR @ JSROM

Anything QL Software or Programming Related.
tcat
Super Gold Card
Posts: 633
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

SCREEN1 = SYSVAR @ JSROM

Post by tcat »

Hi,

I have visualised 2nd vram (SCREEN-1) on JSROM, that maps over system variables. JSROM machines seem closest to Minerva.

Code: Select all

10 REMark HEX(20000)=131072 .. SCREEN0, HEX(28000)=163840 .. SCREEN1
20 FOR s=0 TO 32764 STEP 4: POKE_L s+131072, PEEK_L(s+163840)
30 PAUSE
SCREEN1 @ SYSVARS
SCREEN1 @ SYSVARS
vram2.png (4.39 KiB) Viewed 5375 times
Bottom half seems almost writable by a program, I wish to decompose the rest. At the top I can most likely see system variables, there comes somewhere superbasic area, QDOS stack. I wonder what is that piano keyaboard pattern, that looks very regular?

Can anyone help please, I wish to make --SAFE-- use of the second VRAM (SCREEN1), if possible. Also some of QDOS routines take SCREEN{0,1} as their parameter.

Many thanks.
Tomas


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: SCREEN1 = SYSVAR @ JSROM

Post by tofro »

Typical non-Minerva applications that make use of the second screen need do the following:
  1. Allocate any needed memory from the system
  2. Go into supervisor mode and never leave it again while the second screen is in use. Note that implies that your program will take over the machine entirely.
  3. Save the system variables and supervisor stack to some safe place (allocated in step 1)
  4. Never call QDOS while system variables are moved, except for MT.IPCOM traps (that one seems to be safe)
  5. Run the application, which can now use the second screen freely
  6. de-activate second screen
  7. Restore system variables and supervisor stack
  8. leave supervisor mode.
The above attack plan makes it clear that while the second screen is active, QDOS (and any other job) cannot be active. The system variables and supervisor stack are for the most part hard-coded into the OS. If you don't want any (surely catastrophic) collision, you need to make sure everything else but your program is inactive.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: SCREEN1 = SYSVAR @ JSROM

Post by janbredenbeek »

tcat wrote: Bottom half seems almost writable by a program, I wish to decompose the rest. At the top I can most likely see system variables, there comes somewhere superbasic area, QDOS stack. I wonder what is that piano keyaboard pattern, that looks very regular?
The thin lines are the slave block table (8-byte entries, most contain only one byte $01), the blocked pattern is the job table and channel table (4-byte entries, $FF000000 means unused). These tables follow the system variables and supervisor stack (from $28480 onwards). The slave block table's size depends on the amount of RAM, there are two slave blocks for every K RAM above $28000.
Below the tables are the common heap which extends downwards (upwards in terms of memory addresses).
Further down (out of screen memory) you would see SuperBasic, TRNSP and RESPR areas which expand downwards in memory. You won't normally see them on second screen memory unless you're almost out of memory...

Jan.


User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: SCREEN1 = SYSVAR @ JSROM

Post by janbredenbeek »

tofro wrote:Typical non-Minerva applications that make use of the second screen need do the following:
  1. Allocate any needed memory from the system
  2. Go into supervisor mode and never leave it again while the second screen is in use. Note that implies that your program will take over the machine entirely.
... and don't forget to disable interrupts! ;)

Jan.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: SCREEN1 = SYSVAR @ JSROM

Post by tofro »

janbredenbeek wrote:
tofro wrote:Typical non-Minerva applications that make use of the second screen need do the following:
  1. Allocate any needed memory from the system
  2. Go into supervisor mode and never leave it again while the second screen is in use. Note that implies that your program will take over the machine entirely.
... and don't forget to disable interrupts! ;)

Jan.
Jan,

Right, forgot that - The point is, the list of ISRs is rooted in system variables - Once these are overwritten, the system might go haywire once an interrupt is serviced.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
tcat
Super Gold Card
Posts: 633
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

Re: SCREEN1 = SYSVAR @ JSROM

Post by tcat »

Hi Tobias, Jan,

Thank you, that explains that nicely, but also makes me ask further. How about If
slave blocks, channel tables, and heap blocks moved away from the screen1, appropriate system vars updated to point to a new home of tables concerned.

Then at the screen top, remains a few lines ($144 bytes ~ cca 5 lines), that may have to be also copied to screen0. Any chance it worked, as long as we just preserve top few lines in both screens{0,1}?

P.S. I am aware of the exercise of stopping QDOS, and ISR, we toyed with in `dithvide' dual screen driver, remember?

Many thanks.
Tomas


tcat
Super Gold Card
Posts: 633
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

Re: SCREEN1 = SYSVAR @ JSROM

Post by tcat »

Hi,

In other words, looking for a way, both screens{0,1} look like this, with all the tables moved to their new home, with sysvars updated appropriately.

If possible, then we could use QDOS as usuall, as long as we do not write to top 5 lines, where sysvars would now live?
SCREEN0 - SCREEN1 - w/ SYSVARS
SCREEN0 - SCREEN1 - w/ SYSVARS
vram12.png (1.58 KiB) Viewed 5275 times
Many thanks
Tomas


tcat
Super Gold Card
Posts: 633
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

Re: SCREEN1 = SYSVAR @ JSROM

Post by tcat »

Hi,

Doing some tests, in SuperBASIC so far.

[1] Resized WINDOWs #1,2 to fit bottom half of the screen.
[2] Copied sysvars, and system tables to screen0, as shown earlier.

Now I can switch to screen1, and back to screen0.

Code: Select all

10 REMark HEX(18023) = 98403, master chip (ZX8301) display control 
15 REMark bit-7 (1)-screen1, (0)-screen0 
20 POKE 98403,128: PAUSE: POKE 98403,0
JS-ROM Basic routines are tied to screen0 only, so when switching to screen1 WINDOWS #1,2 disappear altogether, but after pressing a key, appear again.
SCREEN0-SCREEN1
SCREEN0-SCREEN1
screen01.png (8.69 KiB) Viewed 5244 times
I am surprised to see some visual activity at the top 5-10 lines after switch to screen1, while when at screen0 these lines hold still???

Tomas


User avatar
dex
Gold Card
Posts: 286
Joined: Thu Dec 23, 2010 1:40 pm

Re: SCREEN1 = SYSVAR @ JSROM

Post by dex »

[2] Copied sysvars, and system tables to screen0, as shown earlier.
Not necessary.
VideoRAM is not bank switched.
Pointer to start of video memory swaps between two various addresses.
I am surprised to see some visual activity at the top 5-10 lines after switch to screen1, while when at screen0 these lines hold still???
Correct.
Sysvars are in the fixed address (beginning od screen 1), and never in screen 0 area.


tcat
Super Gold Card
Posts: 633
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

Re: SCREEN1 = SYSVAR @ JSROM

Post by tcat »

Hi,

I now realise, thank you. But anyway, top 5-10 line flicker at screen1, makes me think of some QDOS or SuperBASIC intepreter activity?

I was hoping to divert some of the QDOS drawing routines to screen1 from within machine code.
As I read somewhere, long word channel ID encodes screen{0,1}, possible?

If not, I am thinking of how to code simple drawing primitives, including putting char to screen, dot, line, block, etc.

Reading A.Pennel's book, gives some QDOS routines as safe to call, when the intepreter is stopped.

These include IPC, clock, heap, queues, lists, strings, maths, mdv sectors r/w verify, and date.

Many thanks
Tomas


Post Reply