Talk:Sinclair QDOS

I've removed this article from the "DOS" Category as Qdos is neither related to MS-DOS etc, nor is it a "DOS" in the generic sense, as in its standard form, it didn't support any kind of "disk" storage medium — Letdorf 12:40, 6 December 2005 (UTC)

Timeline

Most references for the QDOS timeline are based on supposition based on misinformation. I note the date given for JM version as late 1984. In the summer of 1984, QJUMP released its toolkit which had to allow for non-released versions AH and earlier as well as the released JM ROM which was shipping at that time.

Fact 1

I assembled the JM ROM and handed it over to production while I was working for Sinclair.

Fact 2

I had already given notice and I walked out of Sinclair the day the first QL was shipped. This was at least two weeks later.

Therefore it follows that

JM was "released" before the first QL was shipped.

However, ancient test ROMs were fitted to many early QLs, as part of a deliberate policy.

The Story

After the launch of the QL the "software development team" moved out of Sinclair Research's main building into a building site owned by the company to try to decide what sort of system software the QL should have, based on the expectations raised by the launch. The result was the first test version for sending to an evaluation panel: FB (named after Francis Burdett? the Sinclair driver who drove me back from my meeting with Sir Clive at which I resigned). Versions PM, AH, followed at about weekly intervals. These test versions included early versions of a rapidly evolving SuperBASIC.

3 bugs were found in the operating system in test version AH. The next version JM had what was the final version of QDOS (final, because no bugs were or ever have, as far as I am aware, been found in this version of QDOS) this was also sent to testers bundled with SuperBASIC in ROM (the microdrives still did not work reliably enough to ship software on). This version of SuperBASIC differed from some earlier versions in that the parameter order for one of the graphics commands was changed and there was a change in the SuperBASIC procedure initialisation to accommodate the permanent inclusion of SuperBASIC in the ROM. No problem showed up in testing this version.

So you can ignore all the rubbish that has been written about it: JM was actually released before any QLs, flaky or or not, were shipped. The rest is chaff. Sinclair shipped flaky QLs with ancient development versions of the operating system, graphics and SuperBASIC in a dongle hanging out the back either because 1) (the "official internal" version) buggy software was more acceptable to the press than faulty hardware 2) those who had developed the software had left the company in disgust over the premature launch - slandering them seemed a good way out a deep hole. "Les absents ont toujours tort" - always blame those who are not there.

Tony (its all my fault) Tebby —Preceding unsigned comment added by TonyTebby (talk • contribs) 15:24, 15 February 2009 (UTC)

Hi Tony - it's fascinating to hear the inside story on this, but unfortunately personal accounts are considered "original research" by Wikipedia, which is frowned upon. So, to summarise, you had handed over the JS ROMs two weeks before the first QL shipped, but SRL chose to ship large numbers of QLs with earlier test versions for less than honourable reasons?

It is curious that you say the JS ROMs were shipping in 1984, as Simon Goodwin's article in Sinclair QL World August 1987 claims JS was released by SRL in "early 1985", and the JS ROMs were reported as "on the way" in the May 1985 issue of Sinclair User. In any case, the release dates given in the article are intended to indicate when the version was released by SRL in customer shipments.

While it's fair to say most of the bugs in the QL firmware (from AH onwards) were in the SuperBASIC interpreter and not Qdos itself, I think there were a few issues documented in books and magazine articles that could possibly be described as bugs (or at least, "quirks") in Qdos v1.03 (JM):

• Using mdv8 confused the system
• If there was less than 1k free RAM, Microdrive I/O could deadlock
• Attempting to close ser2 would close ser1 instead (maybe a SuperBASIC bug?)
• MT.RERES didn't work reliably
• Some minor TRAP #3 SD.* function quirks
• Only the first peripheral ROM found was initialised - not sure if this was the responsibility of Qdos or SuperBASIC.

Letdorf (talk) 21:39, 17 February 2009 (UTC).

Hi - I hope you don't mind if I call you Letdorf

I screwed up, and not for the first time. I got JM confused with JS! It was 25 years ago and I only started checking my sources after I committed the article. I have corrected this. With the 25 year "celebration" coming up I am getting a lot of hassle and I am afraid that I "lost my cool" when your (reasonably accurate from an outsider's point of view) account hit my fan and brought back memories of when I was ------ by a bunch of --------s.

I do know that personal accounts are not a Good Idea, not just in Wikipedia but elsewhere. Which is one of the reasons I have kept quiet for 25 years! That is why this is in Talk and not in the article itself.

"So, to summarise, you had handed over the JS [JM - my mistake] ROMs two weeks before the first QL shipped, but SRL chose to ship large numbers of QLs with earlier test versions for less than honourable reasons?"

You can find plenty of references to the fact that Jan Jones and myself left Sinclair as soon as QLs started shipping. There was no-one else to do any bug fixes or developments. QED: there were no bug fixes. Well not quite. I did in fact keep in contact with Sinclair (I am not totally irresponsible) and I provided them with fixes to the two problems I found (see below). These fixes found their way into the JS ROM. But they could easily have been made available earlier.

The mind does play tricks, but if you are going to be strict about it, none of the "bugs" mentioned in your list actually involve the operating system directly, just the device drivers and SuperBASIC (does that make a difference to a user?). And to put it into perspective, did any of the first release versions of MSDOS, LINUX, WINDOWS, MAC-OS, AMIGADOS have fewer than a hundred bugs?

So JM ROM Bugs

MDV8 causing a problem? I seem to remember something about MDV8, but I cannot find any references to it on the net. Maybe you can enlighten me. I think NET8 worked fine, so this might have been a peripheral chip or MDV driver problem.

"If there was less than 1k free RAM, Microdrive I/O could deadlock". That was a real screw up on my part. I think the same problem will be found in test version AH. A couple of weeks before the JM version (February 1984?), the Microdrive behaviour was changed radically in an unsuccessful attempt to make it more reliable. Despite not improving the reliability at all, while slowing serial access by more than 5 times, the change became permanent. I implemented single sector prefetch to claw back some performance, but I forgot to check whether there was a spare slave block for the prefetch. As a result, if there was only one slave block, as soon as a sector was read in, the slave block was marked "waiting for read" again. Patched by me by returning "out of memory" earlier!

"Attempting to close ser2 would close ser1 instead". This was a peripheral chip bug.

"MT.RERES didn't work reliably". MT.RERES existed only for "completeness". It was always a null operation: releasing resident area makes no sense - after all, the resident area was a sort of soft ROM. Software in the resident area was linked permanently to the operating system and did not have to allow for being removed. One of the non-errors fed to the press to show how "open and honest" Sinclair was being about the firmware problems that were holding up QL deliveries.

"Some minor TRAP #3 SD.* function quirks" This could refer to two things. 1) The first versions of the curve drawing routines had the interesting property of not terminating if you tried to draw an ellipse that was very long and only one pixel wide. I am not sure whether these problems persisted in release ROMs. The problems certainly did not exist in the versions written by Jonathan Oakley [Tony's mistake, actually Laurence Reeves did most of the Minerva code] in the Minerva ROM, nor in my versions in SMSQ. 2) Simon Goodwin wrote a replacement console driver which had a number of behavioral discrepancies, which, with his usual modesty, he ascribed to errors in the QL ROM versions rather than bugs in his own.

"Only the first peripheral ROM found was initialised". Ah yes, this was an error. It was my error, even though, for some strange reason, it was in the SuperBASIC initialisation. It was not a problem for users as the documentation for peripheral suppliers gave them the workaround. In any case, I supplied the firmware for all the first generation of peripherals. Fixed by me.

Any way, thank you for putting me straight on one or two things.

Tony (it's all my fault) Tebby —Preceding unsigned comment added by 90.20.22.79 (talk) 10:04, 18 February 2009 (UTC)

Yes, I am just "Letdorf" as far as Wikipedia is concerned :-). It is sometimes difficult to differentiate between the different components of the QL firmware, but I think it's reasonable to consider the device drivers to be part of Qdos. I agree the above list of possible bugs isn't a long one for a moderately sophisticated OS. To expand on my list:

• mdv8: Simon Goodwin claims in his SQLW article that until version MG, accessing mdv8 would prevent further access to mdv2. If this problem existed, I doubt it affected many users!

• Closing ser2: this could well be an IPC bug, but I've just perused disassemblies of both the JM ROM and the 8049, and I can't identify where the problem lay. Again, Goodwin claims it was fixed in MG.

• MT.RERES: hmmm, it seems curious to document a OS call that wouldn't make sense!

• Minor SD.* quirks: I was referring to things like the SuperBASIC FILL command sometimes drawing a raster line twice, or a 512-pixel-wide BLOCK not drawing anything - again these are from Goodwin's list. I'm assuming the corresponding SD function was to blame here, and not SuperBASIC.

Thanks again for your comments, and apologies for the impudence of pointing out some of your 25-year-old bugs :-) Letdorf (talk) 23:14, 18 February 2009 (UTC).

Hi Letdorf - no apologies required, we must stop meeting like this. So I have set up a temporary mailbox allmy.fault(AT)yahoo.co.uk if you are prepared to leave me your e-mail address.

You are making me work - I have tracked down a "bug" list of which is compilation of various other lists, such as Simon Goodwin's. Going through this, I have been able to identify two kernel bugs in JM, one of which persisted through MG. I have also just perused a disassembly of the JM ROM and found the 1 bit error that caused one of the bugs that I have just vehemently denied above.

Tony (it's all my fault) Tebby —Preceding unsigned comment added by 90.20.134.171 (talk) 21:25, 20 February 2009 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Sinclair QDOS. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20040414144453/http://www.scp-paulet-lenerz.com/smsqe/ to http://www.scp-paulet-lenerz.com/smsqe/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 01:57, 14 December 2017 (UTC)