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: 

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

[Thierry Godefroy]

Hi again !

Well, I did more testing based on the feedback I received
from you all (thanks !  That's what I like in the QL world:
you always find an helpful hand and often many hands actually).

Well, I did the following:

- booting SMSQ/E v3.01 from a working v2.91 session: no ROM
  (Qubide, ROMdisq) intitialization, crash at the first keypress
  on the PC AT kbd (I guess it's because the interrupts are
  enabled at the hardware level on SH but that no driver is
  installed to process those interrupts).

- unplugging the IDE cable from the CD-ROM drive (I got a hard
  disk as the master and the CD-ROM drive as the slave): no joy,
  SMSQ/E v3.01 crashing at load time (the screen stays in QL
  MODE 4 with flickering pixels at the bottom, denoting an
  activity of the OS (system variables updated at each polled
  interrupt).

- unplugging the IDE cable from Qubide and booting from ROMdisq:
  SMSQ/E boots but here again, no ROM is initialized (i.e., after
  loaded from the ROMdisq under Minerva v1.92, SMSQ/E doesn't
  initialize the ROMdisq).

- plugging back the IDE cable into Qubide and unplugging ROMdisq:
  Same as above: SMSQ/E boots but doesn't initialize the Qubide
  ROM once loaded.

For info, I don't have the 'special GAL2' on Qubide (it is said
in the ROMdisq manual that it won't work with a Qubide and a
GoldCard if Qubide is not fitted with that special GAL, but I
don't know if it extends to Super GoldCards as well).
Also that system uses no backplane (Qubide is plugged into
the Aurora and the SGC is plugged into the Qubide throug-
connector). The power supply is a PC one, (200W, i.e. about
10 times what the system needs) and the +9V is derivated from
the +12V via a LM317K regulator (with proper decoupling) so
that Qubide and SGC are supplied via their own 7805 regulators
(I found it the best solution to minimize the noise on
power supply lines and the tension dropout from one card
to another). The Qubide chimic capacitors were all replaced
with tantalum ones (for a better filtering of high frequency
noise) and the 74HC688 was replaced with a 74ALS688 (better
rejection of noise too than it's CMOS equivalent). The
resulting Qubide is rock solid and I never got a single
hard disk corruption in 6 years of 24/7 functionning (this
system was used for QLCF BBS), i.e. since the Aurora was
installed (I did get problems with Qubide when the MB was
still a QL one). I can't shorten the IDE cables (but it
won't make a difference here, obviously).

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 ! ;-)

Another question is: what changed in the initialization routines
(including cache handling ones) between v2.91 and v2.98 ?  Using
the v2.91 routines should allow to make SMSQ/E to work again (I
don't beleive it's a hardware problem)... Tony (Tebby), are you
around ?... :-)

Another sad piece of news: while v2.98 works just fine on my
QXLs, v3.01 don't and crashes after the boot process, apparently
when a 'MODE' command is executed in my boot program... Marcel,
was there a bug left in the display drivers when you sent the
sources to Wolfgang ?

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.

QDOS/SMS forever !

Thierry.