SCREEN1 = SYSVAR @ JSROM

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

SCREEN1 = SYSVAR @ JSROM

Postby tcat » Wed Apr 24, 2019 11:27 am

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

vram2.png
SCREEN1 @ SYSVARS
vram2.png (4.39 KiB) Viewed 1052 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
QL Wafer Drive
Posts: 1660
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: SCREEN1 = SYSVAR @ JSROM

Postby tofro » Wed Apr 24, 2019 2:25 pm

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
Gold Card
Posts: 334
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: SCREEN1 = SYSVAR @ JSROM

Postby janbredenbeek » Wed Apr 24, 2019 4:21 pm

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
Gold Card
Posts: 334
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: SCREEN1 = SYSVAR @ JSROM

Postby janbredenbeek » Wed Apr 24, 2019 4:24 pm

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
QL Wafer Drive
Posts: 1660
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: SCREEN1 = SYSVAR @ JSROM

Postby tofro » Wed Apr 24, 2019 4:40 pm

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: 558
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

Re: SCREEN1 = SYSVAR @ JSROM

Postby tcat » Wed Apr 24, 2019 7:26 pm

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: 558
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

Re: SCREEN1 = SYSVAR @ JSROM

Postby tcat » Thu Apr 25, 2019 7:39 am

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?

vram12.png
SCREEN0 - SCREEN1 - w/ SYSVARS
vram12.png (1.58 KiB) Viewed 952 times

Many thanks
Tomas


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

Re: SCREEN1 = SYSVAR @ JSROM

Postby tcat » Fri Apr 26, 2019 9:19 am

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.

screen01.png
SCREEN0-SCREEN1
screen01.png (8.69 KiB) Viewed 921 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
Trump Card
Posts: 209
Joined: Thu Dec 23, 2010 1:40 pm

Re: SCREEN1 = SYSVAR @ JSROM

Postby dex » Fri Apr 26, 2019 9:53 am

[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: 558
Joined: Fri Jan 18, 2013 5:27 pm
Location: Prague, Czech Republic

Re: SCREEN1 = SYSVAR @ JSROM

Postby tcat » Fri Apr 26, 2019 11:35 am

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



Who is online

Users browsing this forum: No registered users and 2 guests