QIMSI

[Derek_Stewart]

Hi,

I do not know where this reference to WIN_USE comes from, as this command just renames the WIN device driver name.

On power up there each storage device has a default device driver, in the ROM of the interface:

Microdrive: MDV
Floppy Disk: FLP
QIMSI: WIN

The QL boots up looks at the ROM Port, then the next interface setup in hardware (just guessing here, as I am not a hardware developer).

If no ROM device and attached interface, like Floppy Disk Interface boot up the FLP1_boot, then the QL ROM tries MDV1_boot, if that fails due to no media, drop into Superbasic.

Now it maybe that the QIMSI boots up after the Floppy Disk Interface, so if a Disk is in the Floppy Drive the boot system is aborted, so remove the Floppy Disk and let QIMSI boot up using the defined QLWA.WIN container file on the FAT32 partition of the SD Card.

WIN_USE does not have be used.

There are no Formatting utilities for the QIMSI builtin to the QIMSI system.

The QIMSI is similiar to the Q68, in the way it sores the data on the SD Card, but the Q68 uses SMSQ/E which has SD Card formatting commands built into the SMSQ/E operating system, please see Q68 SMSQ/E manual.

Whereas QIMSI uses QDOS (Minerva or JS, JM...) has no SD Card formatting extensions and there are only minimal QWA container handing commands included.

[lliont]

I think that because QLSD driver (rom version) initially boots as MDV to be able to automatically run boot file and then it becomes WIN,
the existence of another driver that boots has the effect to keep QLSD stay as MDV, maybe.

[Derek_Stewart]

Hi,

I seem to guessing at the way the QL starts up.

Referring to the QL Technical Manual by Tony Tebby, in Section 2.4, page 15:

2.4 Start-up
The first thing that Qdos does when the system is reset is to execute a RAM test. This test determines the amount of contiguous RAM present, and if there is any RAM failure, hangs up the machine.

Qdos then initialises the system variables, the system management tables, and the SuperBASIC area.

The address $COOO is then checked by Qdos for the characteristic longword $4AFB0001: if this is found, Qdos links in the SuperBASIC procedures contained in the ROM, prints out the name of the ROM, and performs a JSR to its initialisation point (details of the correct format of the ROM are found in section 8.0 on ROM device drivers). It is perfectly in order for the code in this ROM to take over the machine completely and never return to the system, for example if another operating system were being booted.

Qdos then does the same for the other ROMs in the expansion slots.

If all of these ROMs return control to Qdos, the next action is to try to open a device driver "BOOT": if this is found, its contents are loaded as a SuperBASIC program and executed. If no device driver "BOOT" has been linked in, Qdos attempts to find a file "MDV1_BOOT" and load and execute its contents as a SuperBASIC program. If both of these attempts fail, Qdos starts up the SuperBASIC interpreter with an empty program memory

Which is what I meant, each attached ROM to the QL handles the boot process.

[Maskenlos]

Hi Derek,

I do not know where this reference to WIN_USE comes from, as this command just renames the WIN device driver name.

Dilwyn gave the explanation already, quote from him take from other QIMSI thread:

3. If the QL has a floppy disk drive and you boot from a floppy disc for any reason, the magic of the startup sequences leaves the WIN device of the QIMSI named as MDV. It's a side-effect of the way interfaces boot up by changing their names as they boot up. I only found out because I left a floppy with a BOOT program on it in the drive overnight by mistake. After the floppy BOOT program ran, the device called WIN didn't exist - DIR WIN1_ failed. DIR MDV1_ gave a listing of the SD-card! So I had to use a WIN_USE "win" command to manually change the SD-card device name from MDV to WIN if the QL had booted from floppy disk on the Gold Card.

I would not say this is a QIMSI bug. This behaviour has been already described in the old hard disc documentations and solutions like MFM interface from Dirk Steinkopf (Steinberg??) around 1992.

I somehow like the idea from Chris_68

What I would like to say with this is, QIMSI and a lot of other projects are great designs and it doesnt have to be the developer that writes the instructions/manuals.

There are so many ways to contribute without getting into contact with Peter or me, just some examples:

- Write a beginners guide and publish here. Like "QIMSI for QL beginners"
- Improve the sound player and share some sample files
- Program an auto sound conversion program for PC
- Just simple report working mice that we can further fill the list
- Make a QIMSI section on your personal web page with the content
- Translate the manual into your native language to help others not so familiar with English

Best,

Stephan

[stephen_usher]

Peter, I'll write something up for you a bit later and PM it.

[stephen_usher]

First of all, thank-you Peter for replying.

I've got more time to reply to you post now so...

P.P.S. The manual should be explicit that if you boot from another device then you HAVE to use WIN_USE every time, not often, always.

The manual can not state that in general, as the behaviour depends on the the other device. Depending on the timing of the "MDV renaming magic" of the other device, the issue might not occur. It is an interaction issue, not a QIMSI bug as such. On the other hand, I don't want a listing of all affected devices in the QIMSI manual.

If you like, you can PM me a short text passage how you prefer this documented in the manual.

Fair enough. And a fuller explanation was given later in the thread which explains this more fully.

It may be useful to merely say in the documentation that because there's a quite a high chance that the system will be in a state after booting from another device where it's forgotten the WIN device name that it should be reset using the WIN_USE command (it works without giving a parameter by the way) as a failsafe.

As for "format", indeed there is no mention in the manual, which means that users will assume that it would work as it would with any other device. I think again the manual should explicitly state that the device doesn't support formatting of a drive image but instead (I guess) that you need to create one using an emulator of some kind.

You are right, the creation of the container files should be explicitely documented. After ten years of QL-SD, it probably seemed too obvious to me. I'm sorry, but writing documentation already took so much time that I sometimes regret the public release of QIMSI. Writing docs is not my hobby at all.

It's a trap we all fall into. Something we do all the time becomes the default that we think is natural to assume. I've had to train myself to avoid these things when writing user documentation at work and try to word things so that they make no assumptions about the reader's knowledge but tries also not to speak down to them. It's sometimes hard to do.

I wonder if someone's written a stand-alone program to generate a WIN image file, rather than having to require people to get an emulator working. That would be far easier to explain too.

[Peter]

I wonder if someone's written a stand-alone program to generate a WIN image file, rather than having to require people to get an emulator working. That would be far easier to explain too.

I don't know. Maybe as part of the QXL software?
Since empty images are short when zipped, the easiest way is probably to offer a variety of sizes for download.
Once the sucession of updates has slowed down, I'd like to ask Dilwyn for a QIMSI section in his QL website.
The images could be played there.

[XorA]

I wonder if someone's written a stand-alone program to generate a WIN image file, rather than having to require people to get an emulator working. That would be far easier to explain too.

isnt that qxltool?

[Peter]

isnt that qxltool?

Of course. Thanks. I often use qxltools, but forgot about this feature!

[stephen_usher]

For those who have Trump Cards and need proper directories now that you have a large storage device, I can confirm that the version 2.19 ROM image on the Dilwyn archive works on the original hardware and gives you them.