Minerva change requests...

[Dave]

I had some problems with the batch of Minerva I made. However, quite a few people expressed interest and asked some quite good questions.

I thought it might be productive to have a discussion about a couple of the requests I received.

The first was the possibility of having a standard for the Euro symbol, to include it in the character set. This is easy to do, but has consequences for the replaced character. Anybody have any insightful thoughts on how it might be approached?

The second was the comment that now we're almost at 2015, do we need to reset the QL clock to start at a later arbitrary date? I personally think this is extremely problematic, as a date on one OS could mean a different date on another OS. I don't recall when the current clock loops around - is this an issue?

Any thoughts on the above, or other wishes?

[RWAP]

The QL date can work up to 2032 (?) I believe from memory - so I really doubt that there is any need to reset the start date - this would cause too many problems.

As for the euro symbol - there is one already in SMSQ/e - I thought it was also in Minerva?

[dilwyn]

SMSQ/E includes the Euro symbol at CHR$ 181, it would make sense for any Minerva changes to use the same character code.

On my website, fonts page, there is a replacement font for QDOS which has an Euro character at the same code. You are welcome to copy the Euro bit pattern out of that if you wish, I think it is exactly the same as the SMSQ/E version.

Regarding the clock, it varies from version to version of the OS, depending on whether the time system uses signed or unsigned values for the date. 0 corresponds to start of 1961 IIRC, so the point at which the clock stops working is a signed 32 bit value from the first possible time and date, whereas at some point Marcel ensured SMSQ/E used an unsigned 32 bit value for the clock, so it will carry on working twice as long. Either Simon Goodwin or Mark Knight (can't remember which) in their ROM bugs articles discussed this to explain how it works, although you can probably work it out by working out how many seconds in a year and working out the maximum value of signed and unsigned 32-bit values to work out where the clock reaches the limit. From memory, it might be 2030 and 2090, but don't quote me on that.

[tofro]

Dave,

Minerva 1.98 has exactly 331 bytes left before it spills over the 48kB barrier. There's not much hope that anything significant could still be squeezed in without removing something else.

With regards to the "€" character, I'd go with Dilwyn that it should use the same space as it does in SMSQ/E. This would replace a character which is not of much use anyways.

My assumption is, however, that there is something like "€" already - CHR$(229) looks suspiciously like one when looking at the sources... (Note, Minerva has its character set already extended beyond the QL's)

Tobias

[Dave]

The question becomes which clock format does Minerva use?

For the € character, I think it would be best to copy what SMSQ does. IMHO.

I don't see this as being a problem size-wise for Minerva. The Euro character is a straight byte substitution, and the clock issue may already be a non-issue.

Dave

[pjw]

On both QDOS JS and SMSQ/E the date ranges from 1961-01-01 to 2097-02-06, so we have a while to go yet..

What often causes confusion is that from SuperBASIC you cant pass unsigned longs to the DATE$ function. Once you get past DATE$(2^31 - 1) = 2029-01-19 03:14:07, you need to flip over to negative floats, ie DATE$(-2^31) = 2029-01-19 03:14:08. There seems to be a bug in QDOS (JS, at least) in that you cant pass the number 2^31 - 1 to the DATE$ function, but max 2^32 - 2.

Per

[pjw]

Re Minerva change requests, I once had a list somewhere.. but since I now mainly use smsq I guess its redundant anyway. However, cross-platform compatibility is in everyone's interest, and since I took a particular interest in some DATE issues Id like to mention them here. Im too lazy to explain so Ill just dump a blurb from my former website, knoware, below:

"These toolkits add the extended date functions found in Smsq/e to Qdos and Minerva, thus allowing programs that rely on this functionality to run under those operating systems. Minerva already has the extended DATE function built in (presumably this is why it was included in Smsq/e), therefore the toolkit comes in two versions; one with DATE and the other without. As pre-JS QL ROMs do not allow keywords in the system ROM to be overwritten by new definitions, the Minerva version could be used there too, saving a few bytes. (Ie, you cannot update the DATE function in AH to JM ROMs using these toolkits!)

The new keywords are as follows:
yr% = YEAR%[(datestamp)] Returns the year 1961..2097. If no datestamp is supplied the current year is returned
mn% = MONTH%[(datestamp)] Returns the month 1..12. If no datestamp is supplied the current month is returned
md% = DAY%[(datestamp)] Returns the day of month 1..31. If no datestamp is supplied the current day of month is returned
wd% = WEEKDAY%[(datestamp)] Returns the day of the week 0..6 (= Sunday..Saturday). If no datestamp is supplied the current day of the week is returned.
datestamp = DATE[(year, month, day, hour, minute, second)] Returns the number of seconds since January 1st 1961. If no parameters are supplied the current time in seconds is returned

The functional part of the code was pinched from the Minerva V1.98 sources, © Laurence Reeves, which are released under the GNU GENERAL PUBLIC LICENSE, Version 2, June 1991. The code was cobbled together by me, pjwitte. Any bugs found will in all likelyhood be mine.

The sources can be viewed by clicking on the links below. You can cut and paste them into an editor and alter them freely according to the license."

If theres any interest in these toolkits, let me know and Ill ax Dilwyn kindly to host them.

Per

[Dave]

Very informative posts. Thank you!

Our plan is that Minerva is used as a simple boot OS that people can use for basic QL functionality/maintenance. We suspect, however, that most people will just use it as a launcher for SMSQ/E.

Ideally, we'd like to have SMSQ/E in flash. That's an ultimate goal.

[Silvester]

There has been a long-standing problem with Minerva >v1.93 using FLP on non-Gold machines. The reintroduction of the IPC interrupt can add enough overhead to upset disk sector interleave. The solution was simple enough, use POKE!!53,128 in boot files to disable it (restored using POKE!!53,192 or upon reset). It can make a considerable difference to the time taken to load large files!

I have updated my Minerva by changing byte at EPROM offset 1301 from 192 to 128 (see details below). No need to erase EPROM, can be over-programmed (one bit changed from 1 to 0).

I suggest a change to this default action might be worth considering? Especially for new BBQL + FLP users (Gold systems are fast enough to avoid missing sector interleave). It can always be enabled with POKE!!53,192 when, if ever, it is needed.

updates_doc (minerva v1.98) extract:
---------------------------
From version 1.95, the IPC interrupt code has been re-instated
to keep awake to Hermes. This can sometimes cause slower input
especially when used with 14400bps modems. To remove this
use the basic command: POKE!!53,128.

Source file M/ss/init_asm extract:
-------------------------

move.b #pc.maskt!pc.maski,sv_pcint(a6) set mask for no gap

* The IPC interrupt was useless. The IPC code did not implement its use for
* signalling serial buffer full, as was intended. Up to 1.93, Minerva was
* totally ignoring it. now we have Hermes, it's back in 'cos the code works,
* signalling every eighth byte of serial input to keep us on our toes.

Suggest change line to : move.b #pc.maskt,sv_pcint(a6)

[Dave]

Anyone have any objections/comments about this change identified above? If nobody objects, I'll test and (re)incorporate it.