Re: [Ql-Users] German Minerva ROM

[George Gwilt]

> On 8 Mar 2017, at 12:00, pg...@q40.de wrote:
> 
> 
> By now, SMSQ/E is also free software, Minerva offers no advantages 
> regarding licensing anymore. Native hardware interest moved from 
> targeting highspeed Motorola CPU to retrocomputing with FPGA. Which 
> is using plain 68000 at the moment, taking away most interest in 
> 68020+. Although I might change to 68020 later. And most developers 
> are gone, more work for less people, less playground for several 
> operating systems on one machine.

Any assembler program I write for my own use on QPC2 will certainly use the 
extremely useful 68020+ instructions.

George
___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[pgraf]

On 8 Mar 2017 at 11:24, George Gwilt wrote:

> > GWASS did not produce the same code as QMAC from Minerva source, and 
> > required various sourcecode changes, which now no longer allow to 
> > use QMAC. We did not hunt down all the subtle differences yet. I'm 
> > sure this could all be solved by more debugging and discussing the 
> > issues with you, and you would be more than willing to help. But 
> > this process would require a continuos period of time to concentrate 
> > on the topic, which neither Richard nor me found.
> 
> I remember spending much time altering the source code of SMSQ/E so
> that it could be assembled by GWASS. I think the reason for doing
> this this was that GWASS allows the 68020+ instructions to be
> used, which QPC2 allows, but QMAC doesn't. Otherwise, I agree that
> it is silly to go to the trouble of altering the Minerva code just
> so that you could use GWASS.

Yes, in today's view, it was a tragic decision to spend time 
altering Minerva for GWASS, not even with a full success.

When Minerva was first released as free software, things were 
different. Back then, there were more active developers and still 
moderate hope for a new hardware with something beyond 68060. 
Therefore, using a 68020+ assembler, which is free and actively 
maintained, could have meant a significant advantage in the future.

By now, SMSQ/E is also free software, Minerva offers no advantages 
regarding licensing anymore. Native hardware interest moved from 
targeting highspeed Motorola CPU to retrocomputing with FPGA. Which 
is using plain 68000 at the moment, taking away most interest in 
68020+. Although I might change to 68020 later. And most developers 
are gone, more work for less people, less playground for several 
operating systems on one machine.

All the best
Peter

___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[George Gwilt]

> On 7 Mar 2017, at 15:53, pg...@q40.de wrote:
> 
> 
> GWASS did not produce the same code as QMAC from Minerva source, and 
> required various sourcecode changes, which now no longer allow to 
> use QMAC. We did not hunt down all the subtle differences yet. I'm 
> sure this could all be solved by more debugging and discussing the 
> issues with you, and you would be more than willing to help. But 
> this process would require a continuos period of time to concentrate 
> on the topic, which neither Richard nor me found.

I remember spending much time altering the source code of SMSQ/E so that it 
could be assembled by GWASS. I think the reason for doing this this was that 
GWASS allows the 68020+ instructions to be used, which QPC2 allows, but QMAC 
doesn't. Otherwise, I agree that it is silly to go to the trouble of altering 
the Minerva code just so that you could use GWASS.

George
___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Marcel Kilgus]

Jan Bredenbeek wrote:
> Just a (maybe silly) question: Is there a way to execute an SBASIC job from
> another (non-SBASIC) job on SMSQ/E? I know it is possible on Minerva with a
> special vector call and in SBASIC you can simply EXEC another SBASIC
> program, but I couldn't find any info on how to do this from a non-SBASIC
> job...

Execute the SBASIC thing.

Marcel


___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Jan Bredenbeek]

Just a (maybe silly) question: Is there a way to execute an SBASIC job from
another (non-SBASIC) job on SMSQ/E? I know it is possible on Minerva with a
special vector call and in SBASIC you can simply EXEC another SBASIC
program, but I couldn't find any info on how to do this from a non-SBASIC
job...

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Jan Bredenbeek]

On 7 March 2017 at 21:29, Wolf  wrote:

I could be wrong, but AFAIK SBASIC doesn't put a MISTake keyword in front
>> of a 'bad line' which has been loaded from a file. Which makes it harder
>> to
>> debug...
>>
>>
>
> But it does.
> Try this nonsense "10 print print r=25" and load it.
>

I stand corrected, sorry. I got confused by the error messages displayed on
#0 when loading the file (which doesn't occur on JS or Minerva) but the
program indeed gets loaded with MISTakes.

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Wolf]

Hi,




The reason this springs to mind was that on the QL Forum online chat last
night, we were discussing Tim Swenson's SSB (Structured SuperBasic system).
While it's a nice, simple little development system for BASIC programmers,
one thing it doesn't do is check syntax.


You could always use the parser that comes with the Basic Linker.


I could be wrong, but AFAIK SBASIC doesn't put a MISTake keyword in front
of a 'bad line' which has been loaded from a file. Which makes it harder to
debug...




But it does.
Try this nonsense "10 print print r=25" and load it.



Wolfgang
___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Ralf Reköndt]

That's quite a historical thing. Jochen and Tony have always shared those 
things, a few or more others have never get any informations (maybe accept 
you) about those things. No wonder, Jochen was able to make his SBAS Thing. 
And...QD is still commercial after all those years, silly, isn't it?


- Original Message - 
From: "Marcel Kilgus"



On the other hand, SBAS/QD also shows how this could be done. It
actually fetches the program line by line from the QD editor and
manually builds the SBasic program with it. In case of an error QD is
instructed to jump to the offending line and show the appropriate
message.

I had a look at the code and it's pretty much intertwined with the QD
editor and probably not suitable for others, but in theory similar
interfaces could be implemented for other editors or purposes, I
personally just don't see the need. Plus I'd like to avoid the "oh,
why did you make it SMSQ/E only" complaints.


___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Dilwyn Jones]

Is there such a thing as an OS call of any description which when 
presented
with a line of BASIC as simple ascii will check the syntax so that a 
program
such as Tim's can check what is being entered without necessarily 
inserting

the line of BASIC into a program directly?


Well, there are the mentioned vectors (which I didn't know about until
today). Their usage is shown in sbsext_ed_basint_asm (albeit with
archaic names and thus difficult to find using a simple text search).
It look like they could do the job, but they need to be called from
within an S(uper)Basic job, just like ED. This makes things a bit more
complicated.

On the other hand, SBAS/QD also shows how this could be done. It
actually fetches the program line by line from the QD editor and
manually builds the SBasic program with it. In case of an error QD is
instructed to jump to the offending line and show the appropriate
message.

I had a look at the code and it's pretty much intertwined with the QD
editor and probably not suitable for others, but in theory similar
interfaces could be implemented for other editors or purposes, I
personally just don't see the need. Plus I'd like to avoid the "oh,
why did you make it SMSQ/E only" complaints.
Just to be clear, I don't have  a need for this myself, I just thought it'd 
be useful to document if viable.


Jan's comments coincided with the chat about SSB last night. I just thought 
if there was an "easy" way Tim could have integrated it into SSB, it would 
have added something to SSB.


Thank you for going to the trouble of looking at this.

Dilwyn 


___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Marcel Kilgus]

Dilwyn Jones wrote:
> Is there such a thing as an OS call of any description which when presented
> with a line of BASIC as simple ascii will check the syntax so that a program
> such as Tim's can check what is being entered without necessarily inserting
> the line of BASIC into a program directly?

Well, there are the mentioned vectors (which I didn't know about until
today). Their usage is shown in sbsext_ed_basint_asm (albeit with
archaic names and thus difficult to find using a simple text search).
It look like they could do the job, but they need to be called from
within an S(uper)Basic job, just like ED. This makes things a bit more
complicated.

On the other hand, SBAS/QD also shows how this could be done. It
actually fetches the program line by line from the QD editor and
manually builds the SBasic program with it. In case of an error QD is
instructed to jump to the offending line and show the appropriate
message.

I had a look at the code and it's pretty much intertwined with the QD
editor and probably not suitable for others, but in theory similar
interfaces could be implemented for other editors or purposes, I
personally just don't see the need. Plus I'd like to avoid the "oh,
why did you make it SMSQ/E only" complaints.

Marcel

___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Dilwyn Jones]

I could probably adapt QED if I'd had the time, but interfacing with
SBASIC will be difficult as that is a self-contained environment
(you cannot call the parser from another job, unless perhaps when
it's also an SBASIC job.


Have a look at SBAS/QD, it's part of SMSQ/E and does exactly this.

Let me put this in a different way, then.

Is there such a thing as an OS call of any description which when presented 
with a line of BASIC as simple ascii will check the syntax so that a program 
such as Tim's can check what is being entered without necessarily inserting 
the line of BASIC into a program directly? All that's required in this case 
is just to check individual lines of a text file. I hope you understand what 
I mean, imagine something corresponding to the very imaginary (and probably 
silly) extension LET a$ = "100 PRINT *{0}*":LET valid_or_not = 
SYNTAX_CHECK(a$)


(A very silly example, I know, but I hope it explains the kind of thing I 
mean)


Dilwyn 


___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Ralf Reköndt]

It should be possible, as there is another (earlier) full screen editor in 
GigaBasic with syntax check. Perhaps it is possible to contact the authors, 
maybe Rich has any addresses.


- Original Message - 
From: "Dilwyn Jones"
Apart from the obvious historical interest of BASICODE and the sofware you 
wrote, it would be useful to document vectors etc concerning editing basic 
programs and syntax checking. And if you have gone as far as to do a 
commented disassembly of the TK2 ED command, for example, that might be 
very useful too. For example, comparing the code in SMSQ/E might help show 
the differences and where common code could be used too if the structure 
of SuperBASIC and SBASIC is not too different.


___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Marcel Kilgus]

Dilwyn Jones wrote:
> Dare I say it (I can live in hope) that such documentation might one day
> help us get some form off IDE (a development environment) for better Basic
> program development. ED and even using a text editor is absolutely fine, but
> when it comes to developing the larger BASIC programs I do sometimes feel we
> are in need of some form of integrated development environment.

QD is probably best suited for Basic development on SMSQ/E as support
for it is integrated into the OS in form of the SBAS/QD thing. The
program can be started simply by pressing F10 and when there is an
error the editor directly jumps to the line.
Also it has features to add/remove and sort line numbers, but with QD
one usually simply doesn't use line numbers.

Of course a real IDE also has support for debugging, but debugging on
the QL is always a pain, no matter the language.

Marcel

___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Jan Bredenbeek]

On 7 March 2017 at 16:56, Dilwyn Jones  wrote:

Apart from the obvious historical interest of BASICODE and the sofware you
> wrote, it would be useful to document vectors etc concerning editing basic
> programs and syntax checking. And if you have gone as far as to do a
> commented disassembly of the TK2 ED command, for example, that might be
> very useful too. For example, comparing the code in SMSQ/E might help show
> the differences and where common code could be used too if the structure of
> SuperBASIC and SBASIC is not too different.
>

There is little documentation in the source I'm afraid, as I did little
commenting in those years :-(. However it should not be too difficult to
understand the working of these vectors from a JS or Minerva disassembly.
I'm also not sure whether the reason why it did not work on SBASIC is due
to the usage of these vectors or other hardware-dependent code (in fact I
got a nice lockup, probably due to corruption somewhere).


> The reason this springs to mind was that on the QL Forum online chat last
> night, we were discussing Tim Swenson's SSB (Structured SuperBasic system).
> While it's a nice, simple little development system for BASIC programmers,
> one thing it doesn't do is check syntax.
>

I could be wrong, but AFAIK SBASIC doesn't put a MISTake keyword in front
of a 'bad line' which has been loaded from a file. Which makes it harder to
debug...


> Dare I say it (I can live in hope) that such documentation might one day
> help us get some form off IDE (a development environment) for better Basic
> program development. ED and even using a text editor is absolutely fine,
> but when it comes to developing the larger BASIC programs I do sometimes
> feel we are in need of some form of integrated development environment. OK,
> I'll accept that probably if I'm talking in terms of such major programming
> effort, I'm probably using the wrong language in the first place, but hey,
> if the information is there, let's keep it and use it.


Yes an IDE would be great. It could probably be something in the form of a
shell like W*nd*ws Explorer or a 'Norton Commander' lookalike, which can
execute an editor or SBASIC job. I could probably adapt QED if I'd had the
time, but interfacing with SBASIC will be difficult as that is a
self-contained environment (you cannot call the parser from another job,
unless perhaps when it's also an SBASIC job.

Jan.


-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Dilwyn Jones]

Back in 1987 I wrote a BASICODE translator for the QL which included lots
of hardware-dependent code, including a cassette device driver for use 
with

the network ports. It had to be run from EPROM because of necessary exact
timing (after all the network port is an ordinary bit-banging interface).
Also, it used the SuperBASIC vectors $12C through $13A which are hardly
documented (I used the code for the TK2 'ed' command as documentation).
This software runs on Minerva but NOT on SMSQ/E.
I have plans to put it on GitHub as it might still be useful since a lot 
of

BASICODE programs have been put on GitHub recently. Moreover, I'm planning
a new release which doesn't depend on original QL hardware. There's no 
need

for using cassette interfaces now ;-) but you will still need to convert
the BASICODE programs in ASCII form to SuperBasic. The old code achieved
this by loading the program directly into SuperBASIC (using the
'undocumented' vectors) but this doesn't appear to work on SBASIC, so the
new code will write the translated BASICODE as an ordinary S*BASIC program
which you can LOAD or MERGE...
Apart from the obvious historical interest of BASICODE and the sofware you 
wrote, it would be useful to document vectors etc concerning editing basic 
programs and syntax checking. And if you have gone as far as to do a 
commented disassembly of the TK2 ED command, for example, that might be very 
useful too. For example, comparing the code in SMSQ/E might help show the 
differences and where common code could be used too if the structure of 
SuperBASIC and SBASIC is not too different.


The reason this springs to mind was that on the QL Forum online chat last 
night, we were discussing Tim Swenson's SSB (Structured SuperBasic system). 
While it's a nice, simple little development system for BASIC programmers, 
one thing it doesn't do is check syntax.


Dare I say it (I can live in hope) that such documentation might one day 
help us get some form off IDE (a development environment) for better Basic 
program development. ED and even using a text editor is absolutely fine, but 
when it comes to developing the larger BASIC programs I do sometimes feel we 
are in need of some form of integrated development environment. OK, I'll 
accept that probably if I'm talking in terms of such major programming 
effort, I'm probably using the wrong language in the first place, but hey, 
if the information is there, let's keep it and use it.


Dilwyn 


___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[pgraf]

Hi George,

> > We made the stategic mistake of first moving the code base to GWASS. 
> > Unfortunately the differences to QMAC continued to cost time and 
> > bugs. Still today it is not possible to _exactly_ reproduce the QL 
> > binary of Minerva, although the code seems to work. So if Minerva 
> > development should continue, I think this is what would be needed:
> 
> I'm sorry that GWASS causes trouble. Why is that?

It can not be said that GWASS causes trouble, it is just not QMAC, 
and we can not expect it to behave exactly the same. ANY change of 
toolchain on long and demanding assembler code would not have been 
easy.

GWASS did not produce the same code as QMAC from Minerva source, and 
required various sourcecode changes, which now no longer allow to 
use QMAC. We did not hunt down all the subtle differences yet. I'm 
sure this could all be solved by more debugging and discussing the 
issues with you, and you would be more than willing to help. But 
this process would require a continuos period of time to concentrate 
on the topic, which neither Richard nor me found.

All the best
Peter

___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[gdgqler]

> On 7 Mar 2017, at 11:42, pg...@q40.de wrote:
> 
> We made the stategic mistake of first moving the code base to GWASS. 
> Unfortunately the differences to QMAC continued to cost time and 
> bugs. Still today it is not possible to _exactly_ reproduce the QL 
> binary of Minerva, although the code seems to work. So if Minerva 
> development should continue, I think this is what would be needed:

I’m sorry that GWASS causes trouble. Why is that?

George
___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Jan Bredenbeek]

On 7 March 2017 at 10:36, Tobias Fröschle 
wrote:

> Peter, Marcel,
>
> I have yet to discover a program that doesn't run on SMSQ/E, provided it's
> set to mimic a QL memory map, and does on Minerva (but I'm open to
> suggestions). Weird programs are normally sooo weird that they won't run on
> either...
>

Back in 1987 I wrote a BASICODE translator for the QL which included lots
of hardware-dependent code, including a cassette device driver for use with
the network ports. It had to be run from EPROM because of necessary exact
timing (after all the network port is an ordinary bit-banging interface).
Also, it used the SuperBASIC vectors $12C through $13A which are hardly
documented (I used the code for the TK2 'ed' command as documentation).
This software runs on Minerva but NOT on SMSQ/E.
I have plans to put it on GitHub as it might still be useful since a lot of
BASICODE programs have been put on GitHub recently. Moreover, I'm planning
a new release which doesn't depend on original QL hardware. There's no need
for using cassette interfaces now ;-) but you will still need to convert
the BASICODE programs in ASCII form to SuperBasic. The old code achieved
this by loading the program directly into SuperBASIC (using the
'undocumented' vectors) but this doesn't appear to work on SBASIC, so the
new code will write the translated BASICODE as an ordinary S*BASIC program
which you can LOAD or MERGE...

Jan.
___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[pgraf]

On 7 Mar 2017 at 13:43, pg...@q40.de wrote:

> On 7 Mar 2017 at 13:15, Marcel Kilgus wrote:
> 
> > pg...@q40.de wrote:
> > > Also, the Minerva build system was completely lost when Lau released
> > > the code, and it has cost a lot of time to create a replacement.
> > 
> > Hm, took me at most 3 minutes to build Minerva using QMake. 100% bit
> > perfect, too. Seems a pity to me that so much time was lost on
> > trivialities.
> 
> It is often trivial things that suck time, and indeed a pity. No 
> idea how this comes, maybe the archive on which we first started was 
> less complete that what you have. Or it had to do with using GWASS. 
> I can not remember anymore, as that part of the work was more than a 
> decade ago.

IIRC the project was back then hosted on Savannah and they don't 
allow projects with non-free tools. It comes back to me that we 
probably wanted to avoid non-free tools, therefore no QMAKE... 

Peter

___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[pgraf]

On 7 Mar 2017 at 13:15, Marcel Kilgus wrote:

> pg...@q40.de wrote:
> > Also, the Minerva build system was completely lost when Lau released
> > the code, and it has cost a lot of time to create a replacement.
> 
> Hm, took me at most 3 minutes to build Minerva using QMake. 100% bit
> perfect, too. Seems a pity to me that so much time was lost on
> trivialities.

It is often trivial things that suck time, and indeed a pity. No 
idea how this comes, maybe the archive on which we first started was 
less complete that what you have. Or it had to do with using GWASS. 
I can not remember anymore, as that part of the work was more than a 
decade ago.

Peter

___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[pgraf]

On 7 Mar 2017 at 11:57, Dilwyn Jones wrote:

> > It looks like this is unrealistic to happen. There simply is not
> > enough time for the very (!) few remaining hardware-near QL
> > developers to deal with more than one free operating system. Unless
> > someone comes up with a strong reason.
> >
> > Still it makes me sad, because Minerva was not far from being
> > released again, and I liked the beauty of Minerva code.
> This is really sad, it would have been so good to have both QDOS (Minerva) 
> and SMSQ/E for Q68.

Minerva DOES work on the Q68, demonstrated in Edinburgh. Just 
yesterday I tried Minerva again with my latest FPGA. But there is a 
gap between private tinkering and making a public release.

The biggest issue here is that we have no QLWA driver independent 
from SMSQ/E, and I find the QL-SD driver (which I therefore use with 
Minerva) not very stable on the Q68.

> Perhaps you can keep the work you have done so far, in case anyone does 
> later step in to complete the work.

I don't plan to delete any sourcecode -
of which most credits should go to Richard Zidlicky ;-)

> After all, we saw this happen with uQLx when Graeme Gregory did a huge job 
> in updating the code base just when we all thought that uQLx was struggling 
> by now.

That's a point.

All the best
Peter

___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Marcel Kilgus]

pg...@q40.de wrote:
> Also, the Minerva build system was completely lost when Lau released
> the code, and it has cost a lot of time to create a replacement.

Hm, took me at most 3 minutes to build Minerva using QMake. 100% bit
perfect, too. Seems a pity to me that so much time was lost on
trivialities.

> Still it makes me sad, because Minerva was not far from being
> released again, and I liked the beauty of Minerva code.

It is a beauty. But it wasn't written for multiple hardware targets, I
can imagine it being very difficult to get a common build for multiple
targets and still have the QL version fit into 48k. SMSQ/E, on the
other hand, thrives on diversity.

Cheers, Marcel

___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Derek Stewart]

On 07/03/17 09:36, Tobias Fröschle wrote:

Peter, Marcel,

I have yet to discover a program that doesn't run on SMSQ/E, provided it's set 
to mimic a QL memory map, and does on Minerva (but I'm open to suggestions). 
Weird programs are normally sooo weird that they won't run on either...

Minerva is a miraculous thing in terms of code density and still a masterpiece. 
It's also, especially when things are getting close to the hardware, much 
better documented/commented (sorry, Marcel) than SMSQ/E. Whenever I try to 
understand something in terms of original QL HW, my first reference are the 
Minerva sources. But:

# of active code maintainers for Minerva: 0
# of active code maintainers for SMSQ/E: some :)

Writing software/drivers for Minerva - just like original QDOS - is also always 
a bit of a choice: You /can/ assume, for example (for whatever reasons), that 
you want the Thing extension to be loaded. You /can/ also assume, for example, 
the Extended Environment - All of this is available for Minerva, and even QDOS. 
But that means you build dependencies into the driver/software - On SMSQ/E, all 
of this can be taken as a given.

Minerva is also closely tailored to the original QL hardware, for example assuming a 
"compatible" memory map (at least in the lower 1M). Changes to that, like 
reserving specific areas for specific purposes, I'd assume to be nearly impossible. 
(hypothetical examples would be introducing DMA- and non-DMA capable areas, or the 
Atari's protected I/O ranges)

If the memory's there: I don't see any good reasons to port Minerva to new 
hardware. SMSQ/E is much better suited for both past and future.

Tobias



Am 07.03.2017 um 09:46 schrieb Marcel Kilgus :

pg...@q40.de wrote:

- no wait for F1/F2 (actually there will still be a tiny wait of 32ms,
 so keys can still be pressed)

Wow, 32 ms is a fast reaction from human ;-)


I guess you can already press the key while the ROMs are still being
scanned :)


As for Minerva in general, would you (or anyone else) see partial
advantages over SMSQ/E on the Q68 that make it worthwhile?


Minerva is a great ROM, it's so amazing what he managed to put into
48KB and anybody not using it on an original QL is certifiable crazy
in my eyes ;-)

But SMSQ/E is still the better OS. It's also much bigger of course,
but also still maintained and with new hardware it's the only way to
go IMHO.

Marcel

___
QL-Users Mailing List


___
QL-Users Mailing List



Hi,

Minerva is excellent for an expanded QL, but SMSQ/E is far better.

If the machine can run SMSQ/E thne I would use that by default, but 
anything else I use Minerva.


I never understand why people use JS, JM, AH roms.

The argument is that some software does not run on Minerva... Answer: 
must be badly written.


--
Regards,

Derek
___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Derek Stewart]

On 07/03/17 00:39, Alexandre Souza wrote:

Derek, Id be very interested in your old all 03a if you would part with
it...

Enviado do meu Tele-Movel



Hi Alexandre,

I do not think I would want to part with the ALL03a programmer, as it is 
a very versatile programmer, all the DOS based programming executes are 
written in C and allows easy addition of new components to the database. 
Also there is a good IC Tester function all written in C.


The programmer runs on a DOS machine with a dedicated ISA bus Parallel 
port. Though a Windows version has been produced.


I did think of trying to port over the C source to run a Q60, but never 
got around to it.


--
Regards,

Derek
___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Tobias Fröschle]

Peter, Marcel,

I have yet to discover a program that doesn't run on SMSQ/E, provided it's set 
to mimic a QL memory map, and does on Minerva (but I'm open to suggestions). 
Weird programs are normally sooo weird that they won't run on either...

Minerva is a miraculous thing in terms of code density and still a masterpiece. 
It's also, especially when things are getting close to the hardware, much 
better documented/commented (sorry, Marcel) than SMSQ/E. Whenever I try to 
understand something in terms of original QL HW, my first reference are the 
Minerva sources. But:

# of active code maintainers for Minerva: 0
# of active code maintainers for SMSQ/E: some :)

Writing software/drivers for Minerva - just like original QDOS - is also always 
a bit of a choice: You /can/ assume, for example (for whatever reasons), that 
you want the Thing extension to be loaded. You /can/ also assume, for example, 
the Extended Environment - All of this is available for Minerva, and even QDOS. 
But that means you build dependencies into the driver/software - On SMSQ/E, all 
of this can be taken as a given.

Minerva is also closely tailored to the original QL hardware, for example 
assuming a "compatible" memory map (at least in the lower 1M). Changes to that, 
like reserving specific areas for specific purposes, I'd assume to be nearly 
impossible. (hypothetical examples would be introducing DMA- and non-DMA 
capable areas, or the Atari's protected I/O ranges)

If the memory's there: I don't see any good reasons to port Minerva to new 
hardware. SMSQ/E is much better suited for both past and future.

Tobias


> Am 07.03.2017 um 09:46 schrieb Marcel Kilgus :
> 
> pg...@q40.de wrote:
>>> - no wait for F1/F2 (actually there will still be a tiny wait of 32ms,
>>>  so keys can still be pressed)
>> Wow, 32 ms is a fast reaction from human ;-)
> 
> I guess you can already press the key while the ROMs are still being
> scanned :)
> 
>> As for Minerva in general, would you (or anyone else) see partial
>> advantages over SMSQ/E on the Q68 that make it worthwhile?
> 
> Minerva is a great ROM, it's so amazing what he managed to put into
> 48KB and anybody not using it on an original QL is certifiable crazy
> in my eyes ;-)
> 
> But SMSQ/E is still the better OS. It's also much bigger of course,
> but also still maintained and with new hardware it's the only way to
> go IMHO.
> 
> Marcel
> 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Marcel Kilgus]

pg...@q40.de wrote:
>> - no wait for F1/F2 (actually there will still be a tiny wait of 32ms,
>>   so keys can still be pressed)
> Wow, 32 ms is a fast reaction from human ;-)

I guess you can already press the key while the ROMs are still being
scanned :)

> As for Minerva in general, would you (or anyone else) see partial
> advantages over SMSQ/E on the Q68 that make it worthwhile?

Minerva is a great ROM, it's so amazing what he managed to put into
48KB and anybody not using it on an original QL is certifiable crazy
in my eyes ;-)

But SMSQ/E is still the better OS. It's also much bigger of course,
but also still maintained and with new hardware it's the only way to
go IMHO.

Marcel

___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[pgraf]

On 7 Mar 2017 at 1:07, Marcel Kilgus wrote:

> One could for example patch a $11 into it to get
>
> [...]
>
> - no wait for F1/F2 (actually there will still be a tiny wait of 32ms,
>   so keys can still be pressed)

Wow, 32 ms is a fast reaction from human ;-)

Nice hack anyway.

As for Minerva in general, would you (or anyone else) see partial 
advantages over SMSQ/E on the Q68 that make it worthwhile?

Background:

We do have a basic working version, but I'm hesitating to complete 
and release it. Minerva suffers from not having a QLWA driver for 
the SDHC drives, and the QL-SD style driver still has bugs. For the 
Q68, having no floppy anymore, SDHC is crucial of course, so 
completing Minerva for Q68 would cost time to fix this issue (and 
some smaller issues as well).

Peter

___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Alexandre Souza]

Derek, Id be very interested in your old all 03a if you would part with
it...

Enviado do meu Tele-Movel

On Mar 6, 2017 10:20 AM, "Derek Stewart"  wrote:

> On 06/03/17 12:49, Marcel Kilgus wrote:
>
>> Hi all,
>>
>> I create a German version of the Minerva ROM, in case anybody is
>> interested:
>>
>> https://www.kilgus.net/2017/03/05/german-minerva-rom/
>>
>> I also briefly discuss a cheap EEPROM programmer that I ordered from
>> China. Suffice to say, I'm very satisfied.
>>
>> Cheers, Marcel
>>
>> ___
>> QL-Users Mailing List
>>
>> Hi Marcel,
>
> I have had a Minipro TL866CS for a long time and works very well.
>
> It does have problems with very old eproms, not being in the Eprom
> Programmer Database.
>
> But something like a Winbond W26C512 EEPROM, works very nicely.
>
> I might be retiring my Hilo Systems ALL03A MSDOS based programmer in the
> future.
>
> --
> Regards,
>
>
> Derek
> ___
> QL-Users Mailing List
>
___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Marcel Kilgus]

Ralf Reköndt wrote:
> Ah, a good idea. I have elsewhere on disk a Minerva (not the latest version)
> which was patched by Martin Berndt with german key layout (not so 
> important), with b/w colours of #1 and #2 (also not so important) but with
> autostart at F1, not F2 (a bit more important).

Ah right, that is annoying, too.

I haven't tried it yet, but looking at the source there is a byte at
address $042F in the ROM. Currently it's $08 and the meaning is
documented in the source:

*   bit(s)  value   meaning
*   0   0   do the full memory test
*   1   skip the memory test for a quick reset
*   1   0   scan rom slots
*   1   skip the rom slots, unexpand the m/c
*   2   0   normal establishment of memory size
*   1   take the upper memory limit below as gospel!
*   3   0   monitor mode
*   1   tv mode
*   4   0   wait for f1-f4 selection
*   1   skip the f1-f4 selection
*   5-6 0..3extend supervisor stack by 0K, 8K, 16K or 24K 
*   7   0   set single screen
*   1   set dual screens
*   8-130..63   extra blocks of 64k between last screen and system vars
*   14-31   upper limit on memory (0 = no limit)
* (Note that the top bits of d1 are unlikely to ever make sense as memory!)

One could for example patch a $11 into it to get
- skip memory test
- monitor mode
- no wait for F1/F2 (actually there will still be a tiny wait of 32ms,
  so keys can still be pressed)

Use any hex editor to change.

Marcel

___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Ralf Reköndt]

Ah, a good idea. I have elsewhere on disk a Minerva (not the latest version) 
which was patched by Martin Berndt with german key layout (not so 
important), with b/w colours of #1 and #2 (also not so important) but with 
autostart at F1, not F2 (a bit more important).


Cheers...Ralf

- Original Message - 
From: "Marcel Kilgus"



Hi all,

I create a German version of the Minerva ROM, in case anybody is
interested:

https://www.kilgus.net/2017/03/05/german-minerva-rom/

I also briefly discuss a cheap EEPROM programmer that I ordered from
China. Suffice to say, I'm very satisfied.

Cheers, Marcel


___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Norman Dunbar]

I'm rather fond of the AtTiny85 myself, I have to admit. :-)


Cheers,
Norm.

On 6 March 2017 13:26:59 GMT+00:00, Marcel Kilgus  
wrote:
>Derek Stewart wrote:
>> I have had a Minipro TL866CS for a long time and works very well.
>>
>> It does have problems with very old eproms, not being in the Eprom 
>> Programmer Database.
>
>Yes, I had to disable the "ID check" flag to read one of my old EPROMS
>and haven't tried to burn one yet. Might try this evening just for
>fun, but a 10-pack of EEPROMs is somewhere on its way between here and
>China, so I probably don't need those going forward anyway ;-)
>
>Read out the some GAL16V8s and burned some ATTINY chips so far, all
>worked flawlessly. So far I'm a really happy camper with this thing.
>
>Cheers, Marcel
>
>___
>QL-Users Mailing List

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Marcel Kilgus]

Derek Stewart wrote:
> I have had a Minipro TL866CS for a long time and works very well.
>
> It does have problems with very old eproms, not being in the Eprom 
> Programmer Database.

Yes, I had to disable the "ID check" flag to read one of my old EPROMS
and haven't tried to burn one yet. Might try this evening just for
fun, but a 10-pack of EEPROMs is somewhere on its way between here and
China, so I probably don't need those going forward anyway ;-)

Read out the some GAL16V8s and burned some ATTINY chips so far, all
worked flawlessly. So far I'm a really happy camper with this thing.

Cheers, Marcel

___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Derek Stewart]

On 06/03/17 12:49, Marcel Kilgus wrote:

Hi all,

I create a German version of the Minerva ROM, in case anybody is
interested:

https://www.kilgus.net/2017/03/05/german-minerva-rom/

I also briefly discuss a cheap EEPROM programmer that I ordered from
China. Suffice to say, I'm very satisfied.

Cheers, Marcel

___
QL-Users Mailing List


Hi Marcel,

I have had a Minipro TL866CS for a long time and works very well.

It does have problems with very old eproms, not being in the Eprom 
Programmer Database.


But something like a Winbond W26C512 EEPROM, works very nicely.

I might be retiring my Hilo Systems ALL03A MSDOS based programmer in the 
future.


--
Regards,


Derek
___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[pgraf]

Hi Marcel,

> I create a German version of the Minerva ROM, in case anybody is
> interested:
> 
> https://www.kilgus.net/2017/03/05/german-minerva-rom/

Thanks! Very good idea!
Peter


___
QL-Users Mailing List

Re: [Ql-Users] German Minerva ROM

[Graeme Gregory]

On Mon, 6 Mar 2017, at 12:49 PM, Marcel Kilgus wrote:
> Hi all,
> 
> I create a German version of the Minerva ROM, in case anybody is
> interested:
> 
> https://www.kilgus.net/2017/03/05/german-minerva-rom/
> 
> I also briefly discuss a cheap EEPROM programmer that I ordered from
> China. Suffice to say, I'm very satisfied.
> 
> Cheers, Marcel
> 
Nice, using in German might force me to improve my knowledge :-)

Graeme
___
QL-Users Mailing List