Re: [Ql-Users] Graphics aspect ratio

[Wolf]

Hi,
sys_clnk is of course mentined in the 4.xx series of the QDOS/SMSQE 
manual. I'll add the keys for the format of pointer device driver 
definition block (not CON device) in the next revision of the manual.



Wolfgang
___
QL-Users Mailing List

Re: [Ql-Users] Graphics aspect ratio

[Jan Bredenbeek]

On 1 May 2017 at 15:04, Andrea Carpi  wrote:

>
> Il 28/04/2017 16.01, Marcel Kilgus ha scritto:
>
> > I added that
> feature at the request from Jens who paid for the development of the
> 8-bit driver. It was at a time when the SMSQ/E documentation was pretty
> much unmaintained...
>
>  Is there a complete list of system variables in
> SMSQ / E 3.xx?
>
> It's not a system variable but a variable in the CON device driver linkage
block. The list of variables is in the SMSQ/E source code tree (in the
keys/con file).

Jan.
___
QL-Users Mailing List

Re: [Ql-Users] Graphics aspect ratio

[Andrea Carpi]

  
Il 28/04/2017 16.01, Marcel Kilgus ha scritto: 

> I added that
feature at the request from Jens who paid for the development of the
8-bit driver. It was at a time when the SMSQ/E documentation was pretty
much unmaintained...

 Is there a complete list of system variables in
SMSQ / E 3.xx?

In the list of my own, the variable pt_asprt is not
there

This is the list I found:

$28000.W SV_IDENT Identification 


$d245 QL (QDOS) system variable identifier

 "S2AT" SMS Atari system
variable identifier

Pointers defining QDOS memory map: 

$28004.L
SV_CHEAP Base of common heap area 

$28008.L SV_CHPFR First free space
in common heap area 

$2800C.L SV_FREE Base of free area [+12 ]


$28010.L SV_BASIC Base of BASIC area [+16 ] 

$28014.L SV_TRNSP Base
of transient program area 

$28018.L SV_TRNFR First free space in TPA


$2801C.L SV_RESPR Base of resident procedure area 

$28020.L SV_RAMT
Top of RAM(+1) [+32 ] 

$28024.L SYS_MXFR Maximum return from free
memory call (SMS only)

$28028.L SYS_RTC Real time in seconds (SMS
only)

$2802C.W SYS_RTCF Real time fractional, countdown (SMS
only)

$2802E.W SV_RAND Random number(constantly changing) 

$28030.W
SV_POLLM Count of poll interrupts missed 

$28032.B SV_TVMOD 0 if not TV
display [+50 ] 

$28033.B SV_SCRST Screen status (0=active) 

$28034.B
SV_MCSTA Current value of MC status register 

$28035.B SV_PCINT Current
value of PC interrupt register 

$28036.B SV_USER User number in Toolkit
3 (Note:TK3 only!)

$28037.B SV_NETNR Network station number [+55 ]


Pointers to the list of tasks and drivers: 

$28038.L SV_I2LST Pointer
to list of interrupt 2 drivers 

$2803C.L SV_PLIST Pointer to list of
polled tasks 

$28040.L SV_SHLIST Pointer to list of scheduler tasks


$28044.L SV_DRLST Pointer to list of device drivers 

$28048.L
SV_DDLST Pointer to list of directory device drivers 

$2804C.L SV_KEYQ
Pointer to a keyboard queue 

$28050.L SV_TRAPV Pointer to trap
redirection table 

Pointers to resource management tables: 

$28054.L
SV_BTPNT Pointer to most recent slave block entry. Slave

 tables are of
8-byte entries, others are 4-byte. 

$28058.L SV_BTBAS Pointer to base
of slave block table 

$2805C.L SV_BTTOP Pointer to top of slave block
table 

Jobs table: The jobtable is a sequence of .Ls, each pointing
to

a job control block. LSW of a JobID is the position of that
job's

.L in the jobtable. 

$28060.W SV_JBTAG Current value of job tag


$28062.W SV_JBMAX Highest current job number 

$28064.L SV_JBPNT
Pointer to current job table entry 

$28068.L SV_JBBAS Pointer to base
of job table 

$2806C.L SV_JBTOP Pointer to top of job table 

Channel
table: 

$28070.W SV_CHTAG Current value of channel tag 

$28072.W
SV_CHMAX Highest current channel number 

$28074.L SV_CHPNT Pointer to
last channel checked 

$28078.L SV_CHBAS Pointer to base of channel
table 

$2807C.L SV_CHTOP Pointer to top of channel table 

MINERVA:


$2807C.L - pointer to new extensions, including default

 fonts,
cursor style, etc: see ASM.15-19 

$28080.L SYS_FRBL Free Block List, to
be returned to common heap

 (SMS only)

Keyboard [poke only those
marked with asterisk] 

$28088.W SV_CAPS *Caps lock: 0=normal,
-256.L=255.B=caps locked

 [+136] 

$2808A.W SV_ARBUF Auto repeat buffer


$2808C.W SV_ARDEL *Autorepeat delay: default=30 [+140 ] 

$2808E.W
SV_ARFRQ *Autorepeat 1/frequency: default=2 [+142 ] 

$28090.W SV_ARCNT
Autorepeat count 

$28092.W SV_CQCH Keyboard change queue character code
- default

 ctrl-C=$03 [+146 ] 

Misc 

$28094.W SV_WP Write protect


$28096.W SV_SOUND Sound status (BEEPING)

$28098.L SV_SER1C Receive
channel 1 queue address 

$2809C.L SV_SER2C Receive channel 2 queue
address 

$280A0.B SV_TMODE ZX8032 transmit mode 

$280A1.B SV.PRCS
Processor type, stored in top 4 bits, hex value

 of these 4 digits
denotes 68000 family processor

 type ($0x=68000/8, $1x=68010, $2x=68020
etc)

 Bottom 4 bits contains information about any

 Floating Point
Unit (FPU) available. 0=no FPU,

 1=internal MMU, 2=68851 MMU,
4=internal FPU,

 8=68881 or 68882 FPU.

 Note: not implemented on


original QLs, Gold Card onward only. Note: QPC

 emulates a 68000 but
identifies itself as a

 68010 processor

$280A2.L SV_CSUB *If non-zero,
is address of subroutine to jump

 to when CAPSLOCK is pressed: the
subroutine

 should spoil nothing. 

$280A6.W SV_TIMO Timeout for
switching transmit mode (QL)

$280A6.B DMA in use (SMS, ST)

$280A7.B
SV_MTYP Machine type value.

 bit 0=1 Hermes (QL) or blitter (Atari)
chip

 installed.

 bits 1 to 4 = machine type (0=ST, 2=Mega ST or

 ST
with RTC, 4=Stacy, 6=STE, 8=Mega STE, 10=Gold

 Card, 12=Super Gold
Card, 16=Falcon, 17=Q40/Q60,

 24=TT030, 28=QXL, 30=QPC, 31=QLay
emulator)

 bit 5 to 7 = display type. 0=QL/Futura,

 32=Monochrome
monitor, 64=Atari Ext.4, 128=Atari

 QVME, 192=QL mode LCD or VGA,
160=Aurora

$280A8.W SV_TIMOV Value of switching timeout (2 chars.)


$280AA.W SV_FSTAT Flashing cursor status 

$280AC.L SV_PROGD$ Pointer
to PROG_USE 

Re: [Ql-Users] Graphics aspect ratio

[Jan Bredenbeek]

On 1 May 2017 at 12:08, Tobias Fröschle 
wrote:

> Jan,
>
> SMSQ/E change log (http://www.wlenerz.com/smsqe/versions.html <
> http://www.wlenerz.com/smsqe/versions.html> , which comes in handy at
> times) says
> Implemented in 3.00
>

Thanks. I've taken a look at the changes.txt in the source and couldn't
find anything initially, however a search for 'aspect' revealed it was
implemented in 3.03.

Jan.
___
QL-Users Mailing List

Re: [Ql-Users] Graphics aspect ratio

[Tobias Fröschle]

Jan,

SMSQ/E change log (http://www.wlenerz.com/smsqe/versions.html 
 , which comes in handy at times) 
says
Implemented in 3.00 

Tobias

> Am 01.05.2017 um 12:00 schrieb Jan Bredenbeek :
> 
> On 28 April 2017 at 16:01, Marcel Kilgus  wrote:
> 
>>> Am 28.04.2017 um 15:30 schrieb Tobias Fröschle <
>> tobias.froesc...@t-online.de>:
>>> 
>>> Right. Somewhere there ;)
>>> 
>>> I seem to recall I saw that variable referenced somewhere in the
>> "official" documents - But when I looked for it, I couldn't find it either
>> and had to refer to the sources as well
>> 
>> I added that feature at the request from Jens who paid for the development
>> of the 8-bit driver. It was at a time when the SMSQ/E documentation was
>> pretty much unmaintained...
>> 
> 
> From the code of G-RATIO I gather that it only exists in v3.x versions of
> SMSQ/E (else it returns 'not implemented'). Can you confirm this?
> 
> Jan.
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Graphics aspect ratio

[Jan Bredenbeek]

On 28 April 2017 at 16:01, Marcel Kilgus  wrote:

> > Am 28.04.2017 um 15:30 schrieb Tobias Fröschle <
> tobias.froesc...@t-online.de>:
> >
> > Right. Somewhere there ;)
> >
> > I seem to recall I saw that variable referenced somewhere in the
> "official" documents - But when I looked for it, I couldn't find it either
> and had to refer to the sources as well
>
> I added that feature at the request from Jens who paid for the development
> of the 8-bit driver. It was at a time when the SMSQ/E documentation was
> pretty much unmaintained...
>

From the code of G-RATIO I gather that it only exists in v3.x versions of
SMSQ/E (else it returns 'not implemented'). Can you confirm this?

Jan.
___
QL-Users Mailing List

Re: [Ql-Users] Graphics aspect ratio

[Marcel Kilgus]

> Am 28.04.2017 um 15:30 schrieb Tobias Fröschle :
> 
> Right. Somewhere there ;)
> 
> I seem to recall I saw that variable referenced somewhere in the "official" 
> documents - But when I looked for it, I couldn't find it either and had to 
> refer to the sources as well

I added that feature at the request from Jens who paid for the development of 
the 8-bit driver. It was at a time when the SMSQ/E documentation was pretty 
much unmaintained...

Marcel
___
QL-Users Mailing List

Re: [Ql-Users] Graphics aspect ratio

[pgraf]

On 28 Apr 2017 at 15:30, Tobias Fröschle wrote:

> I seem to recall I saw that variable referenced somewhere in the
> "official" documents

Funny, I was looking for that yesterday also. While the Q68 
previously had only QL modes and upscaled modes with same ratio, I 
recently added 1024x768 and 512x384. Yesterday I tried CIRCLE in 
BASIC. Urghhh...

All the best
Peter

___
QL-Users Mailing List

Re: [Ql-Users] Graphics aspect ratio

[Tobias Fröschle]

Right. Somewhere there ;)

I seem to recall I saw that variable referenced somewhere in the "official" 
documents - But when I looked for it, I couldn't find it either and had to 
refer to the sources as well.

Tobias

> Am 28.04.2017 um 15:25 schrieb Jan Bredenbeek :
> 
> Thanks for the answers! The variable pt_asprt is actually in the CON device
> linkage block which is pointed to by the sys_clnk system variable (I
> couldn't find it in the QDOS/SMS Reference Manual, only in the SMSQ/E
> source code.
> 
> Jan.
> 
> -- 
> *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Graphics aspect ratio

[Jan Bredenbeek]

Thanks for the answers! The variable pt_asprt is actually in the CON device
linkage block which is pointed to by the sys_clnk system variable (I
couldn't find it in the QDOS/SMS Reference Manual, only in the SMSQ/E
source code.

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

Re: [Ql-Users] Graphics aspect ratio

[Giorgio Garabello]

Try this: (from Bob Spelten Jr. homepage)

G-RATIO.  Jens Wildgruber made a small extension which corrects the
original QL graphics commands. Strange circles in other resolutions than
the old 512x256? Not any longer with G-RATIO.
Click here  to
download the zip.

Unfortunately, it is not compatible with QDT

Giorgio Garabello

2017-04-28 13:52 GMT+02:00 Jan Bredenbeek :

> I'm sorry if this question has been answered before, but I've run into an
> issue with SMSQ/E's graphics system.
> When you use the CIRCLE command on a window with an aspect ratio of, say,
> 3:2 (on the screen, not in pixels since the graphics coordinate system is
> pixel-independent!) and type:
>
> CIRCLE 75,50,50
>
> you get a circle exactly in the centre of the window which exactly fits the
> window in vertical direction (assuming standard SCALE setting of 100,0,0).
> But when you enter this command on SMSQ/E, assuming a window with exactly
> the same aspect ratio, the circle becomes an ellipse which partly falls off
> the right edge of the window.
>
> I'm aware of the fact that the native QL screen has non-square pixels (the
> width/height ratio of a pixel is 0.738; combined with the 512x256
> resolution this yields an aspect ratio of about 3:2 or 1.476 to be exact).
> QDOS and Minerva compensate for this in the graphics routines so that the
> scale in horizontal direction is the same as in vertical direction (the
> Minerva source code is in fig.asm).
> However, on PC-emulated screens pixels have a different aspect ratio (I
> guess mostly 1:1). It appears that the graphics coordinate system on SMSQ/E
> still tries to adjust for the native QL pixel aspect ratio, leading to
> incorrect X/Y scale ratio on the graphics screen.
> AFAIK there is no way to adjust for this error, short of changing
> application programs. The SCALE command doesn't help, as there is only one
> SCALE parameter that sets the scale for both X and Y directions.
>
> Anyone got an idea?
>
> Jan.
>
> --
> *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
> ___
> QL-Users Mailing List
>
___
QL-Users Mailing List

Re: [Ql-Users] Graphics aspect ratio

[Tobias Fröschle]

Jan,

SMSQ/E uses the variable 

pt_asprt equ$14a   ; 6 bytes float pixel aspect ratio

in the extended channel definition block for exactly that purpose.

You can poke this address in order to change the pixel aspect ratio.

Tobias


> Am 28.04.2017 um 13:52 schrieb Jan Bredenbeek :
> 
> I'm sorry if this question has been answered before, but I've run into an
> issue with SMSQ/E's graphics system.
> When you use the CIRCLE command on a window with an aspect ratio of, say,
> 3:2 (on the screen, not in pixels since the graphics coordinate system is
> pixel-independent!) and type:
> 
> CIRCLE 75,50,50
> 
> you get a circle exactly in the centre of the window which exactly fits the
> window in vertical direction (assuming standard SCALE setting of 100,0,0).
> But when you enter this command on SMSQ/E, assuming a window with exactly
> the same aspect ratio, the circle becomes an ellipse which partly falls off
> the right edge of the window.
> 
> I'm aware of the fact that the native QL screen has non-square pixels (the
> width/height ratio of a pixel is 0.738; combined with the 512x256
> resolution this yields an aspect ratio of about 3:2 or 1.476 to be exact).
> QDOS and Minerva compensate for this in the graphics routines so that the
> scale in horizontal direction is the same as in vertical direction (the
> Minerva source code is in fig.asm).
> However, on PC-emulated screens pixels have a different aspect ratio (I
> guess mostly 1:1). It appears that the graphics coordinate system on SMSQ/E
> still tries to adjust for the native QL pixel aspect ratio, leading to
> incorrect X/Y scale ratio on the graphics screen.
> AFAIK there is no way to adjust for this error, short of changing
> application programs. The SCALE command doesn't help, as there is only one
> SCALE parameter that sets the scale for both X and Y directions.
> 
> Anyone got an idea?
> 
> Jan.
> 
> -- 
> *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

[Ql-Users] Graphics aspect ratio

[Jan Bredenbeek]

I'm sorry if this question has been answered before, but I've run into an
issue with SMSQ/E's graphics system.
When you use the CIRCLE command on a window with an aspect ratio of, say,
3:2 (on the screen, not in pixels since the graphics coordinate system is
pixel-independent!) and type:

CIRCLE 75,50,50

you get a circle exactly in the centre of the window which exactly fits the
window in vertical direction (assuming standard SCALE setting of 100,0,0).
But when you enter this command on SMSQ/E, assuming a window with exactly
the same aspect ratio, the circle becomes an ellipse which partly falls off
the right edge of the window.

I'm aware of the fact that the native QL screen has non-square pixels (the
width/height ratio of a pixel is 0.738; combined with the 512x256
resolution this yields an aspect ratio of about 3:2 or 1.476 to be exact).
QDOS and Minerva compensate for this in the graphics routines so that the
scale in horizontal direction is the same as in vertical direction (the
Minerva source code is in fig.asm).
However, on PC-emulated screens pixels have a different aspect ratio (I
guess mostly 1:1). It appears that the graphics coordinate system on SMSQ/E
still tries to adjust for the native QL pixel aspect ratio, leading to
incorrect X/Y scale ratio on the graphics screen.
AFAIK there is no way to adjust for this error, short of changing
application programs. The SCALE command doesn't help, as there is only one
SCALE parameter that sets the scale for both X and Y directions.

Anyone got an idea?

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List