Is there an extended mode 4 emulator without the PE? I never had one, but I don't think so.RalfR wrote:How was this checked with the Extended Mode 4 emulator on Atari? I can't remember as I have never used without PE.
SCR_YLIM
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: SCR_YLIM
- NormanDunbar
- Forum Moderator
- Posts: 2274
- Joined: Tue Dec 14, 2010 9:04 am
- Location: Leeds, West Yorkshire, UK
- Contact:
Re: SCR_YLIM
mk79 wrote:Othwerise: https://xkcd.com/927/
Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
-
- Font of All Knowledge
- Posts: 3971
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: SCR_YLIM
What is QDOS Classic mode?tofro wrote:Well, neither Q40/Q60 in QDOS Classic mode Aurora seem to support IOP.FLIM (is that BTW documented for uqlx somewhere? Calling IOP.FLIM without PE loaded might as well lead to a crash or bogus answers on other machines).
Regards,
Derek
Derek
Re: SCR_YLIM
Well, running QDOS Classic, the "pack-port" of original QDOS instead of SMSQ/E on the Q40.Derek_Stewart wrote:What is QDOS Classic mode?tofro wrote:Well, neither Q40/Q60 in QDOS Classic mode Aurora seem to support IOP.FLIM (is that BTW documented for uqlx somewhere? Calling IOP.FLIM without PE loaded might as well lead to a crash or bogus answers on other machines).
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: SCR_YLIM
So anyone enterprising enough to make Qdos display at other screenmk79 wrote:Sure. I'd call this new standard "PE" and have these variables available at address $f2 and $f4 of the CON driver definition block... I guarantee all new platforms will conform to it!pjw wrote:Cant we decide on a standard and see it implemented in future iterations of updates? Some system variable, or some under-used Channel Definition Block location to contain the at all times prevalent screen limits?
resolutions than 512x256, should also manage to set those metrics in
these locations. And no shame should devolve on a programmer who used
something like the following code - and then produced the wrong
answer! Right?
Code: Select all
... get sys vars
move.l sys_clnk(a0),d0
bne.s pi_ok have we PI compliance?
move.l #$02000100,d1 ..no, must be BBQL 512x256
bra.s ret
pi_ok
movea.l d0,a4 ptr to CON linkage
move.l pt_xscrs(a4),d1 get scr x/y
ret ...
mk79 wrote:Othwerise: https://xkcd.com/927/
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: SCR_YLIM
Well, I think sys_clnk is only set by SMSQ/E and my versions of the PE (>=v2), the original TT QDOS versions don't set it. That's why the original SCR_YLIM uses iop.slnk to get the linkage block. But if you can live with that I don't think any shame should be put upon youpjw wrote:So anyone enterprising enough to make Qdos display at other screen resolutions than 512x256, should also manage to set those metrics in these locations. And no shame should devolve on a programmer who used something like the following code - and then produced the wrong answer! Right?
Re: SCR_YLIM
No, I dont think I could live down the shame, so I'll do the honourable thing and use iop.slnk where dinosaurs are likely to be met with. Thanks to you (and others) for your help!mk79 wrote:Well, I think sys_clnk is only set by SMSQ/E and my versions of the PE (>=v2), the original TT QDOS versions don't set it. That's why the original SCR_YLIM uses iop.slnk to get the linkage block. But if you can live with that I don't think any shame should be put upon youpjw wrote:So anyone enterprising enough to make Qdos display at other screen resolutions than 512x256, should also manage to set those metrics in these locations. And no shame should devolve on a programmer who used something like the following code - and then produced the wrong answer! Right?
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
-
- Font of All Knowledge
- Posts: 3971
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: SCR_YLIM
I have 2 x Extended 4, Mode 8 emulator boards, the SMSQ/E software supplied all had the Pointer Environment built in.mk79 wrote:Is there an extended mode 4 emulator without the PE? I never had one, but I don't think so.RalfR wrote:How was this checked with the Extended Mode 4 emulator on Atari? I can't remember as I have never used without PE.
However, SMSQ for the QXL can change the screen resolution to: 640x350, 640x480, 800x600 and does not have the Pointer Environment built in it has to be loaded in in separate files: PTR_GEN, WMAN, HOT_REXT.
This was added in SMSQ/E which adds an extra screen mode.
Regards,
Derek
Derek
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: SCR_YLIM
Ah, yes, that is true. I don't think anybody still has the source code to SMSQ and I'm too lazy to boot up a real machine, so no idea on what that screen driver is based on and what interfaces/variables it provides. But it, too, is a very esoteric platform.Derek_Stewart wrote:However, SMSQ for the QXL can change the screen resolution to: 640x350, 640x480, 800x600 and does not have the Pointer Environment built in it has to be loaded in in separate files: PTR_GEN, WMAN, HOT_REXT.
Re: SCR_YLIM
When I have got my Extended Mode 4 emulator, there was just Level-C driver, later came Level-D driver and then I have got an alpha/beta Level-E disk from TT, which was the first Level with an inbuilt PE, but I do not think, that it was SMSQ/E, perhaps a pre-SMSQ/E.Derek_Stewart wrote:I have 2 x Extended 4, Mode 8 emulator boards, the SMSQ/E software supplied all had the Pointer Environment built in.
The first SMSQ/E came, when I bought the QVME in Eindhoven.
4E75 7000