Re: [ql-users] More about SMSQ/E v3.01 on SGC (and QXL)

[ZN]

On 8/8/2003 at 4:00 AM Thierry Godefroy wrote:

>I conclude from the above that it must be a problem in the
>initialization code of SMSQ/E v2.98+ as everything works just
>fine with v2.91. I had a quick look to the sources, and if looks
>like SMSQ/E v3.01 checks for ROMs at addresses $C000 (ROM slot)
>and $4C (inclusive) to $50 (exclusive) with $4000 bytes
>(16Kb) increments.
>
>Following the instructions in the Aurora manual, my Qubide is
>configured to show its ROM from the base address of $4FC000, so
>it -should- be detected, like should be the ROMdisq (address
>$C000).
>
>BUT: I seem to remember that SGC and Aurora are using shadowing
>mechanisms, so my question is: are those addresses valid at boot
>time ? (Nasta, are you with us ?  Three knocks for 'yes', two
>for 'no', please ! ;-)

OK, first the 3 knocks requested: knock, knock, knock!

SGC uses shadowing only in the screen areas, so that would be $2 to
$2, or $27FFF if screen 2 is disabled. Aurora basically follows what
the SGC does, but the old screen areas also appear in the new screen area,
that would be at $4C. It is worth noting that the Aurora actually has
256k of screen RAM, but normally only 240k is used - i.e. the block at
$4FC000 to $4F is not used to display an image, but is there and acts
as RAM, as long as nothing else is using those addresses.
Normally, those addresses would be used by a Qubide set to $FC000. Without
a Qubide there, one could actually load a 16k image of an EPROM and it
should get recognised as an EPROM when the OS is restarted (or an OS is
subsequently loaded and started as in the case of SMSQ/E).

This is the only hardware mechnism that I can think of that could prove to
be problematic, but I think it is highly unlikely. If a Qubide is
connected, it would be there from the start and should get recognised and
initialised.

That being said, the Qubide code first copies itself into RAM then
continues execution. This could potentially be a problem if the cache
settings are incorrect.

>Well, that's all for now... I was about to fiddle with the
>hard disk driver of SMSQ/E so to allow non-blocking ATAPI
>commands on my CD-ROM driver (there's a bug in SMSQ/E
>preventing to delay the ATAPI queue execution, for example
>when the CD-ROM spins up), but I'll wait until I find a way
>to have an homogoneous setting on at least both the Q60 and
>the SGC.

Thierry, I have a question - would it be possible to adapt the SMSQ/E hard
disk driver to the Qubide? This way there could be a standard of sorts,
especially since the Qubide driver is no longer maintained, and sources are
not available... The reason you are getting asked is of course being famous
for writing the CD ROM driver ;-)

N.

Re: [ql-users] More about SMSQ/E v3.01 on SGC (and QXL)

[Thierry Godefroy]

On Fri, 08 Aug 2003 05:44:57 -0500, ZN wrote:

> Thierry, I have a question - would it be possible to adapt the SMSQ/E hard
> disk driver to the Qubide? This way there could be a standard of sorts,
> especially since the Qubide driver is no longer maintained, and sources are
> not available... The reason you are getting asked is of course being famous
> for writing the CD ROM driver ;-)

It is definitely possible to modify slightly the Q60/Q40 sources of the hard
disk driver so to make them compatible with Qubide, then to compile and link
the corresponding module into the GoldCard version of SMSQ/E... The changes
would be very tiny (I/O addresses mainly, and probably the removal of some
Q40/Q60 hardware interrupt registers settings).

The problem is: how would you boot up SMSQ/E from the hard disk then, given
that Qubide and QXL.WIN partitions are not compatible ?... Of course, you
could boot it from a floppy or from a RomDisq.  As for porting the SMSQ/E
drivers so to make them ROMable and part of the Qubide board, it might be
possible, although probably not as easy. Another possibility would be to
make Qubide and SMSQ/E drivers to co-exist (with different device names,
of course, such as 'win' and 'hdd'), but it might be tricky to make them
recognize their own partitions on the same hard disk...

I could have a look into it, as soon as I get the proper sources for SMSQ/E
v3.01 (the ones I got for now fail to compile properly all but the Q40/Q60
version of SMSQ/E)...

QDOS/SMS forever !

Thierry ([EMAIL PROTECTED]).

Re: [ql-users] More about SMSQ/E v3.01 on SGC (and QXL)

[Roy wood]

In message <[EMAIL PROTECTED]>, Phoebus R. Dokos 
<[EMAIL PROTECTED]> writes
Thierry, Zeljko is asking about the second possibility (ie do away with 
the QubIDE format/ROM alltogether and have a new driver compatible with 
the QXL.WIN standard from SMSQ/E). A driver like that could be modified 
(whereas sources of QubIDE's driver do not exist) to support newer 
QubIDE developments like FLASH writing etc.
Hey, whoopee ! If you check back through my Byts of Wood some point in 
the last two years I suggested just this.!
--
Roy Wood
Q Branch. 20 Locks Hill, Portslade, Sussex.
Tel: +44 (0) 1273 386030fax: +44 (0) 1273 430501
web : www.qbranch.demon.co.uk

Re: [ql-users] More about SMSQ/E v3.01 on SGC (and QXL)

[Phoebus R. Dokos]

On Fri, 8 Aug 2003 16:29:41 +0200, Thierry Godefroy <[EMAIL PROTECTED]> 
wrote:


It is definitely possible to modify slightly the Q60/Q40 sources of the 
hard
disk driver so to make them compatible with Qubide, then to compile and 
link
the corresponding module into the GoldCard version of SMSQ/E... The 
changes
would be very tiny (I/O addresses mainly, and probably the removal of 
some
Q40/Q60 hardware interrupt registers settings).

The problem is: how would you boot up SMSQ/E from the hard disk then, 
given
that Qubide and QXL.WIN partitions are not compatible ?... Of course, you
could boot it from a floppy or from a RomDisq.  As for porting the SMSQ/E
drivers so to make them ROMable and part of the Qubide board, it might be
possible, although probably not as easy. Another possibility would be to
make Qubide and SMSQ/E drivers to co-exist (with different device names,
of course, such as 'win' and 'hdd'), but it might be tricky to make them
recognize their own partitions on the same hard disk...

Thierry, Zeljko is asking about the second possibility (ie do away with the 
QubIDE format/ROM alltogether and have a new driver compatible with the 
QXL.WIN standard from SMSQ/E). A driver like that could be modified 
(whereas sources of QubIDE's driver do not exist) to support newer QubIDE 
developments like FLASH writing etc.

Phoebus
--
Visit the QL-FAQ at:  (Still uploading 
stuff!)
Visit the uQLX-win32 at: