Re: [Ql-Users] SMSQ/E boot sequence
On 17/03/16 11:11, Marcel Kilgus wrote: Actually I can tell a lot about programmers through the way they structure and indent their code. Except the missing spaces in the for loop in line 428 this is as spotless as I've ever seen it ;) Are you sure you were looking at my code? ;-) (But thanks!) I'll get 428 sorted next time I have a change to make. Someone once said the same about my SupeBasic code too, I think it was my QSAVE'd file decoder, but I might be wrong. I think it's on Dilwyn's site somewhere. Can't even scold you for the use of strncpy as you've properly documented it! It's a well known feature/bug! strcpy() terminates, strncpy() might terminate! There's nothing like consistency. Of course if C is the right language for parsing and emitting text is another discussion ;) In this case the utility was for an AIX Unix system with a pretty much brain dead C compiler and nothing else, so it had to be C. Normally for parsing, I'd use ANTRL4, build a grammar and have it generate a lexer and parser then inherit the parser and build by "compiler" or whatever from that, in Java. Which I absolutely hate! I'm waiting for the C/C++ lexer/parser versions to come out, at the moment it's Java, Javascript or Python only. See https://github.com/NormanDunbar/Tnsnames_checker for an even less interesting example! I'm definitely not learning Perl, no way, not now, not ever! :-) Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E boot sequence
On 17 Mar 2016 at 11:33, Marcel Kilgus wrote: > pg...@q40.de wrote: > > Thanks for the nice essay. A few remarks: > > > > The "LOWRAM" mode of the Q40/Q60, where read access at $0 to $17FFF > > is mapped to shadow RAM, was mostly used for ROM emulation in the > > early days. The Q60 had to use two 16 bit EPROMs, because the design > > rule was strictly without SMD components. No space saving solution > > with Flash was possible at the time, since the 68060 needs memory > > always 32 bit wide physically, unlike a 68020. The ROM emulation > > saved me from having to UV-erase the EPROMs too often. > > I thought it was a handy tool and could maybe utilized more to > write-protect critical OS code, but so far it isn't and I'm not sure > why. Perhaps for debugging reasons, although I'm pretty sure QMON > actually makes use of sms_wbase to be able to write to low RAM. > > I guess there is no speed difference between this part of RAM and > the rest? Yes, there's no difference. Only video RAM and non-volatile RAM differ in speed. By the way, on the Q68, FPGA-internal RAM is faster than SDRAM. So if SMSQ/E has a fixed area where speed matters, I could try to map internal RAM there. Peter ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E boot sequence
pg...@q40.de wrote: > Thanks for the nice essay. A few remarks: > > The "LOWRAM" mode of the Q40/Q60, where read access at $0 to $17FFF > is mapped to shadow RAM, was mostly used for ROM emulation in the > early days. The Q60 had to use two 16 bit EPROMs, because the design > rule was strictly without SMD components. No space saving solution > with Flash was possible at the time, since the 68060 needs memory > always 32 bit wide physically, unlike a 68020. The ROM emulation > saved me from having to UV-erase the EPROMs too often. I thought it was a handy tool and could maybe utilized more to write-protect critical OS code, but so far it isn't and I'm not sure why. Perhaps for debugging reasons, although I'm pretty sure QMON actually makes use of sms_wbase to be able to write to low RAM. I guess there is no speed difference between this part of RAM and the rest? > On a hardware level, write operations in this mode do not actually > fail, and the mainboard does not generate a bus error exception. > They take place, but are ignored. Ah ok, I'll update that to be more precise. > The CPU does not get its initial instruction pointer from address > $8, as mentioned in the blog, but from $4. (The vector at $8 is > assigned to the bus error exception.) Of course, right. It's just that I've done so much 64-bit development the last week that the second entry for me was naturally at offset 8 :-) Damn. > Funny that an LRESPRed Q40/Q60 SMSQ/E copies itself to $28480, and > not to the more rounded $3 like QPC. And I did not yet know, > that Q40/Q60 SMSQ/E copies itself twice, not just once. In this case it has to as the host OS might have loaded the file at a location where it would be overwritten by the main SMSQ loader (near RAMTOP). > I think I can guess the reason why SMSQ/E cleared the first 256 > bytes of legacy screen RAM at $0002: Debugging! Yes, I think so, too. But no reason was given in the code :-) But you're right, it's probably s posh version of "make the LED blink so I know something is running" I usually have to do when programming by Atmels ;-) > After reading the essay, I will add a little new feature to the Q68 > bootloader. It will not just load "ROM" binaries at $0 (used for > QDOS and Minerva), but also "RAM" binaries to $3. This shall > save SMSQ/E one self-copy ;) I think that makes sense, yes. Thinking about it, it might also make sense to start execution at offset $30004 in this case so LRESPR and "ROM boot" could easily be distinguished. QPC doesn't have this feature and actually crashes if you try LRESPR SMSQ/E, but as this is a new thing anyway... Cheers, Marcel ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E boot sequence
Someone once said the same about my SupeBasic code too, I think it was my QSAVE'd file decoder, but I might be wrong. I think it's on Dilwyn's site somewhere. It's at http://www.dilwyn.me.uk/docs/formats/index.html under 'SAV file format' but it's not Norman's original. It was slightly hacked by me to add one or two SBASIC extras such as binary and hex constants, so it might not be up to Norman's usual standards (I can't remember exactly how many changes I made...) 8-| Note: anyone who tries to use the listing in the article, it uses some DJToolkit extensions. Dilwyn - No virus found in this message. Checked by AVG - www.avg.com Version: 2016.0.7497 / Virus Database: 4542/11829 - Release Date: 03/17/16 ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E boot sequence
Marcel Kilgus wrote: > For anybody interested: I've just written a short essay about the low > level boot process of SMSQ/E for anybody daring enough to try to > understand it: > > http://www.kilgus.net/2016/03/17/smsqe-boot-sequence/ > > Cheers, Marcel Thanks for the nice essay. A few remarks: The "LOWRAM" mode of the Q40/Q60, where read access at $0 to $17FFF is mapped to shadow RAM, was mostly used for ROM emulation in the early days. The Q60 had to use two 16 bit EPROMs, because the design rule was strictly without SMD components. No space saving solution with Flash was possible at the time, since the 68060 needs memory always 32 bit wide physically, unlike a 68020. The ROM emulation saved me from having to UV-erase the EPROMs too often. On a hardware level, write operations in this mode do not actually fail, and the mainboard does not generate a bus error exception. They take place, but are ignored. The CPU does not get its initial instruction pointer from address $8, as mentioned in the blog, but from $4. (The vector at $8 is assigned to the bus error exception.) Funny that an LRESPRed Q40/Q60 SMSQ/E copies itself to $28480, and not to the more rounded $3 like QPC. And I did not yet know, that Q40/Q60 SMSQ/E copies itself twice, not just once. I think I can guess the reason why SMSQ/E cleared the first 256 bytes of legacy screen RAM at $0002: Debugging! At very early stage of firmware development, one usually has no working serial driver, nor character output on the screen. The easiest thing to generate some debug output is to "poke" to the screen, when the code reaches certain locations. At least that's how I worked myself ;-) Of course one needs to clear that area first, because reset or power-off does not reset video memory contents. After reading the essay, I will add a little new feature to the Q68 bootloader. It will not just load "ROM" binaries at $0 (used for QDOS and Minerva), but also "RAM" binaries to $3. This shall save SMSQ/E one self-copy ;) Peter ___ QL-Users Mailing List
Re: [Ql-Users] WIN drive gone missing
Bob Spelten wrote: > Yesterday I had a similar freeze/crash but I put that down to a fault in > the program I am updating. > No QPAC2 File access at that moment. > So today's QPC2 session started OK but at the time of the crash I was > using Files (?). There are about a billion ways to crash SMSQ/E, so I wouldn't count on your problems being the same. Personally I never had Files crash on me and even then it's more likely that the device driver is at fault, but if somebody can reproduce it I can have a look. Cheers, Marcel ___ QL-Users Mailing List
Re: [Ql-Users] Sqlite C library
Hi, The amalgamated file is too large for C68 in QL environment, you need to cross compile in Linux or Windows. But there preprocessed file with all the C files in separated. This is more suited to QL C68, just need to write the makefile. I am looking at this, Sqlite is supposed to be ANSI C so should no problem for C68. Would the Dbas extensions to Superbasic not do the same thing. Like write SQL statement using Superbasic. Regards Derek Original message From: Norman DunbarDate: 19/03/2016 18:15 (GMT+00:00) To: ql-us...@q-v-d.com, Massimino Boccardi Subject: Re: [Ql-Users] Sqlite C library Hi Massimino, I looked at this some time back and found that the "all in one" file was far too big for C68 to compile so it needed to be split back into its separate parts sign and a make file created for it. And that's before looking in the code to find out if there's anything that might need some assembly conversions etc. Also, sqlite itself is in two parts, the sqlite utility which allows you to create and interrogate databases fom a command line, and the main library which allows you to do the same, but from inside your own application. I haven't looked at it for a while I'm afraid. Have fun. Cheers, Norm. On 18 March 2016 16:26:00 GMT+00:00, Massimino Boccardi wrote: >Hi. >Is it possible to recompile the Sqlite 3 library on the QL !? > >www.sqlite.org > >Regards, >Massimino >___ >QL-Users Mailing List -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] Sqlite C library
Now that I didn't try! :-) Cheers, Norm. On 19 March 2016 18:22:16 GMT+00:00, Giorgio Garabellowrote: >and using the gcc cross compiler? > >2016-03-19 19:15 GMT+01:00 Norman Dunbar : > >> Hi Massimino, >> >> I looked at this some time back and found that the "all in one" file >was >> far too big for C68 to compile so it needed to be split back into its >> separate parts sign and a make file created for it. And that's before >> looking in the code to find out if there's anything that might need >some >> assembly conversions etc. >> >> Also, sqlite itself is in two parts, the sqlite utility which allows >you >> to create and interrogate databases fom a command line, and the main >> library which allows you to do the same, but from inside your own >> application. >> >> I haven't looked at it for a while I'm afraid. >> >> Have fun. >> >> >> Cheers, >> Norm. >> >> On 18 March 2016 16:26:00 GMT+00:00, Massimino Boccardi < >> massimi...@hotmail.com> wrote: >> >Hi. >> >Is it possible to recompile the Sqlite 3 library on the QL !? >> > >> >www.sqlite.org >> > >> >Regards, >> >Massimino >> >___ >> >QL-Users Mailing List >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> ___ >> QL-Users Mailing List >> >___ >QL-Users Mailing List -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ QL-Users Mailing List
Re: [Ql-Users] Sqlite C library
and using the gcc cross compiler? 2016-03-19 19:15 GMT+01:00 Norman Dunbar: > Hi Massimino, > > I looked at this some time back and found that the "all in one" file was > far too big for C68 to compile so it needed to be split back into its > separate parts sign and a make file created for it. And that's before > looking in the code to find out if there's anything that might need some > assembly conversions etc. > > Also, sqlite itself is in two parts, the sqlite utility which allows you > to create and interrogate databases fom a command line, and the main > library which allows you to do the same, but from inside your own > application. > > I haven't looked at it for a while I'm afraid. > > Have fun. > > > Cheers, > Norm. > > On 18 March 2016 16:26:00 GMT+00:00, Massimino Boccardi < > massimi...@hotmail.com> wrote: > >Hi. > >Is it possible to recompile the Sqlite 3 library on the QL !? > > > >www.sqlite.org > > > >Regards, > >Massimino > >___ > >QL-Users Mailing List > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > ___ > QL-Users Mailing List > ___ QL-Users Mailing List
Re: [Ql-Users] Sqlite C library
Hi Massimino, I looked at this some time back and found that the "all in one" file was far too big for C68 to compile so it needed to be split back into its separate parts sign and a make file created for it. And that's before looking in the code to find out if there's anything that might need some assembly conversions etc. Also, sqlite itself is in two parts, the sqlite utility which allows you to create and interrogate databases fom a command line, and the main library which allows you to do the same, but from inside your own application. I haven't looked at it for a while I'm afraid. Have fun. Cheers, Norm. On 18 March 2016 16:26:00 GMT+00:00, Massimino Boccardiwrote: >Hi. >Is it possible to recompile the Sqlite 3 library on the QL !? > >www.sqlite.org > >Regards, >Massimino >___ >QL-Users Mailing List -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E boot sequence
I won't pretend I understood all of it by any means, but interesting to read all the same. And congratulations on the new look website - very nice. Dilwyn -Original Message- From: Marcel Kilgus Sent: Thursday, March 17, 2016 12:00 AM To: ql-us...@q-v-d.com Subject: [Ql-Users] SMSQ/E boot sequence For anybody interested: I've just written a short essay about the low level boot process of SMSQ/E for anybody daring enough to try to understand it: http://www.kilgus.net/2016/03/17/smsqe-boot-sequence/ Cheers, Marcel ___ QL-Users Mailing List - No virus found in this message. Checked by AVG - www.avg.com Version: 2016.0.7497 / Virus Database: 4542/11825 - Release Date: 03/16/16 - No virus found in this message. Checked by AVG - www.avg.com Version: 2016.0.7497 / Virus Database: 4542/11825 - Release Date: 03/16/16 ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E boot sequence
On 17/03/16 12:09, Dilwyn Jones wrote: It was slightly hacked by me to add one or two SBASIC extras such as binary and hex constants, so it might not be up to Norman's usual standards (I can't remember exactly how many changes I made...) 8-| I think, if I remember, that you fixed it for SBASIC's new hexadecimal and binary floating point values. Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 ___ QL-Users Mailing List
[Ql-Users] SMSQ/E boot sequence
For anybody interested: I've just written a short essay about the low level boot process of SMSQ/E for anybody daring enough to try to understand it: http://www.kilgus.net/2016/03/17/smsqe-boot-sequence/ Cheers, Marcel ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E boot sequence
What I miss in TT's rewritten QSAVE/QLOAD things is the message "xxx xxx xxx Extensions missing" as it was with the original QSAVE/QLOAD, if extensions used in the _sav were not pre-loaded. This was always very helpful. Cheers...Ralf - Original Message - From: "Norman Dunbar" On 17/03/16 12:09, Dilwyn Jones wrote: It was slightly hacked by me to add one or two SBASIC extras such as binary and hex constants, so it might not be up to Norman's usual standards (I can't remember exactly how many changes I made...) 8-| I think, if I remember, that you fixed it for SBASIC's new hexadecimal and binary floating point values. Cheers, Norm. ___ QL-Users Mailing List
Re: [Ql-Users] WIN drive gone missing
Op Fri, 18 Mar 2016 21:17:33 +0100 schreef pjwitte: Sorry Urs, Bob, I cannot confirm this. To my mind the Qpac2 "apps" are some of the most stable programs written for QDOS and SMSQ/E ;) Sometimes stuff just happens, but if it happens a lot Id look elsewhere.. Per Two crashes in two days is uncommon. As I said, the first could be my own programming error but has not been investigated further. For the second it may have been a coincidence that QPAC2 was involved and I only mentioned this because of Urs's suggestion. I just hope it's not the start of a pattern. Bob -- The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/ ___ QL-Users Mailing List
Re: [Ql-Users] WIN drive gone missing
Op Fri, 18 Mar 2016 16:29:03 +0100 schreef ql: Just days ago I experienced the same. In my case QPC2 was still in the Windows Task Manager. I killed it there and then a fresh start opened the QXL.win and properly booted up. In my case I got the same problem day by day. After investigating it looks like there's a bug in QPAC2 Files which causes SMSQ/E to freeze. Urs Thanks all for the quick response. There were no zombies found in Task Manager. With Total Commander I could copy the .WIN without errors. Restarting W$7 did restore my .WIN to normal and QPC2 booted as before. Also the _dbs was accessible again. Lucky me. Yesterday I had a similar freeze/crash but I put that down to a fault in the program I am updating. No QPAC2 File access at that moment. So today's QPC2 session started OK but at the time of the crash I was using Files (?). Bob -- The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/ ___ QL-Users Mailing List
Re: [Ql-Users] WIN drive gone missing
On 03/18/2016 04:12 PM, Bob Spelten wrote:Hi, the first thing to do with windowsin these cases is to reboot windows It sounds as if the file was still marked as opened by another program. Try copying it to another directory. HTH Wolfgang Hi All, Today, while working in QPC2 on my W$7 system, SMSQ/E suddenly froze. No mouse movement, no keys and Sysmon had stopped. I could kill the QPC2 task with the [x] button but it would not restart my boot. QPC2 & SMSQ/E do start but WIN1_ cannot be mounted anymore ("not found"). I then checked this with another QPC2 but the QXL.WIN could not be mounted with WIN_DRIVE there too. SMSQmulator however, where it's normally mounted as WIN7_, reports it as "read only" but I can list the files and view their contents. In W$7 I can View the .WIN file (Total Commander /View) but when mounting that directory with DOS_DRIVE in QPC2, viewing the .WIN file from QPAC2/Files gave an "in use" error. My other .WIN drives there are OK. Does anyone know what happened here and how I can fix this? There was a channel to a BDAS file open on WIN1_ at the time but this has never been a problem when SuQcess2 crashed in the past. Never lost a _dbs that way. Bob ___ QL-Users Mailing List
Re: [Ql-Users] SMSQ/E boot sequence
On 17/03/16 10:47, Marcel Kilgus wrote: Not sure how much I'll really use the blog, but it might come handy now and then, like it has now. I use mine to make up for a deficiency in remembering stuff. I keep trying to learn new stuff, so the older stuff "ages out of the cache"! I had to do some C programming recently, and I was completely unable to get started after "int main(int argc, char *argv[]) {" - I simply couldn't remember! I got there in the end - https://github.com/NormanDunbar/TraceMiner - but the C quality is probably dubious! The link about will be of interest to even less people here than your SMSQ/E Boot Sequence post! It's handy for me to have a blog as I can (usually) access it from whichever contract I'm working on at the time, so I have my notes with me. As ever though, you end up using it for many things other than work. Enjoy. Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 ___ QL-Users Mailing List