Re: [ql-users] SMSQ-E Development
On 14 Nov 2002, at 1:39, P Witte wrote: (...) Quite some work has already been done by various people, such as tidying up the code to make it suitable for general distribution, adding various tools and help utilities, and Marcel has added some significant improvements to the code base which were previously only available to SMSQ-E for QPC. All well and good so far :) Yes, and until now my job consisted more or less to play catchup with the code supplied by Marcel (and Fabrizio). (...development being people driven) There is, of course, no way that I, nor anyone else, can force anybody a) to contribute b) to contribute in any given direction. I DO try to nudge people in the right direction, by asking whether they couldn't do some development in such and such area. As an example, I have asked one person whether he couldn't make the necessary developments for the home directory to be used by jobs. (You do remember that, don't you? :- I am in the process, however, of trying to collect the different ideas different people have given me at different times to have an overview of what should be done. In my opinion, there are, basically, three kinds of projects: 1 - Small improvements (e.g. Fabrizio's italian language support). By small I DO NOT mean unimportant - but they are improvements that can be handled by a single developper in not too much time. 2 - Important changes - the new WMAN and, possibly, rewriting the mass strorage device drivers for more/better/different/true etc directory support and longer filenames, come to mind. 3 - Adaptions to various machines. It is probable that many a development will need to be adapted to some machines more that to others. I had already mentioned the idea of a key developper for each machine, but that hasn't really been taken up. So how do we go about this? We can have a general scatter load approach, everybody doing something in the corner, alone - as you pointed out, this will peter out pretty quickly. Or, as you rightly suggest, we can have some form of centralisation, where, at the least, track is kept of the progress in different areas. The best way, IMHO, would be to have somebody to parcel out the work. However, in view of the fact that the QL scene is pretty individualistic, and that my perceived authority seems to be on the low side, I think this is rather irrealistic... So, your idea of a website could be a pretty good one. The thing that is stoppping me for the time being, is the feable number of developpers. Again, the question is whether it is worth it to go through all of that, just for four or five people. Ok, so the argument will be that if we don't do it that way, nobody else will participate etc I don't believe that for a second, I also don't believe that doing it this way will bring back the Q60 crowd into the fold. But - why not, if there is a sufficiently strong demand for it. (the website could): Hold general information about the project yes. List the sub-projects yes List planned developments yes List the developers and their areas yes - if the developers want. List progress information yes List the resellers and registrar yes Allow downloading of components to registered developers This is the area where I balk the most. By making the sources available to everyone, I still hope to draw people into development, who whould not, normally, have done so. Making a distinction between registered developers and those who are not (and don't have accessto everything) makes me pretty uneasy. As an example, I do not know whether Fabrizio would have become a registered developer? The fact is, that it was decided to keep destribution of the sources in a certain way. Doing it on a website means either detroying this way of duistributing the sources, or introducing a difference between normal QLer and registered developers. If there really is a majority opinion to do it that way (and I would like EVERYONE'S opinion on this) I'll bow to it, though. BTW, what do you mean by component? Moreover, one of the disadvantages of the website will, of course, be that some control is removed from me (at least that is a disadvantage in my eyes :-)). For the time being, most of the developers speak to me, and, as said above, I try to nudge them in a general direction. If we set up a website, the developers will speak to each other. I'm NOT saying that this is a bad thing but it will mean that development will be made on a more ad hoc basis. As the software registrar, with a mission to try to keep unified versions where possible (and thus, trying to steer the thing a bit), that must leave me with fixed feelings, of course since my power to influence things will be diminished (if it ever existed). But again, if this serves the community, I have no problems with it Allow downloading of the latest binaries to registered users That would be a definite no. The users should get
Re: [ql-users] ADSL
??? 13/11/2002 5:14:46 ??, ?/? Tony Firshman [EMAIL PROTECTED] ??: I am looking forward to being able to write scripts, and do anything I want (8-)# If you just wanted that I could have given you space a long time ago... ask Rich :-) Phoebus
Re: [ql-users] ADSL
??? 13/11/2002 5:43:34 ??, ?/? Fabrizio Diversi [EMAIL PROTECTED] ??: Tony , I have the same configuration as you for my personal web pages : - ADSL via a TCP/IP Router with Firewall - Dynamic Ip and DNS provided by www.dyndns.org - Shoestring Linux with Apache Web server but everything run on my Q60 !! I plan on doing the same but with my Q40... let's see how that will fare :-) Better , don't you think? Nahhh better would be if everything ran under SMSQ/E but this is an imperfect world... We have to wait to see who's going to finish their stack first... then we can write a small webserver :-)
Re: [ql-users] New WMAN (was: GD2)
??? 14/11/2002 1:12:14 ??, ?/? Wolfgang Lenerz [EMAIL PROTECTED] ??: Are the sources available? BTW, QPTR pratically doesn't need to be updated - I've done some work on that, and, provided one or two new functions are used, to reduce 24 bit colours to 16 bit and set the correct MS bit, you can use it to produce high colour PE windows from Basic. There is a distinctive problem there provided you've used just what I call bit cropping... ie removing by brute-force the highest order bits from each colour... The problem (on which I ran into while developing my all around Windoze bmp converter is that once you start chopping bits left and right you are killing the displayed picture... that's not important for sprites for example (well for me it is) as for artificial images you can have the colours pre-arranged so they won't use the whole 32 or 24 bit gamut, but nonetheless I think that we should come to an agreement on how this function should be performed... there are plenty of algorithms to go around, but the fastest (albeit not the most correct ;-) is to scan your bitmap and statistically adjust it... this can be done extremely fast if using the FPU (anybody use S.G and G.G's FPUFNs ? ) but for slow QL systems (ie Aurora - which hopefully will have it's rendition of the GD2 once I get a: The SGC and b: The sources) this is impossible to make at a decent speed :-(... Maybe we should restrict colour rounding to high colour systems only (All High-Colour systems, including QPC do have FPU support or they are sufficiently fast to perform this)... I'm trying to finish an article for QL Today for that We're all waiting :-) Just a couple of questions here: 1 - Does button mean the buttons in the button frame, or also (other) loose items? I call a button every loose item. My 2 (euro) cents (pennies) regarding WMAN/PE in general. With the major updates that happened to the PE, using a different Window Manager should become redundant I would think It would be a good idea on restructuring it a bit (without losing compatibility) to accept add-ons... Since the PE in general provides a good enough (and known enough most important) framework a new gui (for which I strive for so long) will be a lot easier to construct. AFAIK, attaching bitmaps (ie skins) and high-colour (or should I say multi-colour) icons (sprites) is already possible so by polishing it up a bit every one could build his own window manager in a sense... As for my GuiDemo (Norman, Wolfgang and others have seen it so far), once I started using FPU-Presence benefiting instructions the whole thing is flying! (and on high-resolution, high-colour as well). Even interpreted S*Basic is burning rubber... (Generated some 5 Hi colour, 3D shaded Windows in about 15 minutes which is NOT BAD at all)... (Regular speed without FPU is about 2 windows on a Q40) Now if mine can do this, imagine how fast the really optimised (and written in assembly) PE can go Phoebus
Re: [ql-users] Q40 and Linux
??? 13/11/2002 5:41:15 ??, ?/? Phoebus Dokos [EMAIL PROTECTED] ??: ??? 13/11/2002 5:17:02 ??, ?/? Fabrizio Diversi [EMAIL PROTECTED] ??: Thanks, Tony and Fabrizio :-) Hi Fabrizio One thing I didn't figure out yet is how to boot the cd in the first place (ie where I can find the boot disks). I can download the CD no problem (it's approx a 10 min. download for me) but there are no instructions on how to re-attach the parts... Forget what I said... I did it :-) A plain Copy /b cd-aa. + cd-ab. + cdQL.iso /b did the trick ) I managed to boot Linux but as I have no CD (or Ethernet) card attached yet, I will forget it for a couple of days BTW: the vmlinux included with the ISO (the q40 one) did not start fast at all, I downloaded vmlinux-2.26-2 and it flies (Maybe things were removed from the kernel?) Any help will be appreciated. Anyway pay attention that you need a second HD or you have to repartition the main HD using MKpart to create a LNX and Swp partitions, so do not start to fill your main HD before prepare it for Linux. A note on Mkpart though... I have the one that came with 2.91 and it is despicable :-) No help file of any kind you need to guess what you're doing all the time... Atari-Fdisk didn't see it coming ;-) Told me the disk was $#$#@#@#@#'d :-) Anyway I decided to backup the few things I managed to put in (All graphics and sounds dammit... huge files) and I will start fresh tomorrow I left most of my HDD unpartitioned for this reason :-) Didn't do me any good of course as I realized that the numbers I was giving to MKPART were totally put aside... ckkk.. even DOS Fdisk seemed nice at that point! :-D If it's not updated, we will probably have to do something about it. Also regarding SMSQ/E and the Italian version you made, I am sure you didn't had any reason to (as Italian doesn't require the upper 128 chars like Greek of the ASCII) but did you by any chance looked at the keyboard driver and if it's possible easily to convert it to a switching one? (Instead of going through less-than-perfect solutions with buttons etc?) Regards, Phoebus
Re: [ql-users] New WMAN (was: GD2)
On Wednesday, November 13, 2002, at 11:50 PM, Phoebus Dokos wrote: My 2 (euro) cents (pennies) regarding WMAN/PE in general. With the major updates that happened to the PE, using a different Window Manager should become redundant I would think It would be a good idea on restructuring it a bit (without losing compatibility) to accept add-ons... Interesting idea, to allow for add-ons. Would it be possible to make it so that not only would it allow add-ons but also allow 'replacement' functions, just like S-Basic replaces old with like named pieces? That would allow updates or modified window routines to be written that a user could choose - talk about custimization. Also, would it be easy to add additional structures/objects within PE. I am using several custom pieces in QDT that I wrote. It would be nice to eventually make them part of the standard PE setup (I said eventually - QDT comes first!). Jim Hunkins
Re: [ql-users] Memory
On Thu, 14 Nov 2002 at 10:10:14, Duncan Neithercut wrote: (ref: [EMAIL PROTECTED]) -Original Message- From: [EMAIL PROTECTED] [mailto:editor;quanta.org.uk]On Behalf Of Tony Firshman Sent: 13 November 2002 20:38 To: [EMAIL PROTECTED] Subject: Re: [ql-users] Memory On Wed, 13 Nov 2002 at 18:45:47, Duncan Neithercut wrote: (ref: [EMAIL PROTECTED]) Does anyone know of an extension that allows the RAM seen by SMSQ/E to be altered. I want to play around with different memory sizes for SMSQ/E on a Q60. Why not use the Tony Tebby idea of ALCHP eg: 10 new_size = 20:REMark memory size required 20 a=ALCHP(FREE_MEM - new_size) Don't lose the value of a, as one can then do 'RECHP a' to restore without reboot. Thanks but its not quite what I am looking for, I would like to be able to softreset with an altered total memory seen by SMSQ/E. The gold card and superGold card had a keyword that did something like that. Indeed, and so does Minerva (8-)# When one does a reboot with SMSQ/E image file (using LRESPR), I wonder whether the following might work: new_size = 20 a= ALCHP(enough for SMSQ/E) LBYTES smsq/e,a b=ALCHP(FREE_MEM - new_size) CALL a (or wherever I very much doubt it though. I think it is a clean boot from then. -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@surname.co.uk http://www.firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
Re: [ql-users] SMSQ-E Development
Wolfgang Lenerz writes: There is, of course, no way that I, nor anyone else, can force anybody a) to contribute b) to contribute in any given direction. I DO try to nudge people in the right direction, by asking whether they couldn't do some development in such and such area. As an example, I have asked one person whether he couldn't make the necessary developments for the home directory to be used by jobs. (You do remember that, don't you? :- Yeah, Ive got this guy in my cellar with the thumbscrews on. I think he'll soon crack ;) Per
Re: [ql-users] SMSQ-E Development
Wolfgang Lenerz writes: (...development being people driven) I am in the process, however, of trying to collect the different ideas different people have given me at different times to have an overview of what should be done. In my opinion, there are, basically, three kinds of projects: 1 - Small improvements (e.g. Fabrizio's italian language support). 2 - Important changes - the new WMAN and, possibly, rewriting the 3 - Adaptions to various machines. It is probable that many a You might add: 4 - Documentation (including design specs and structures) 5 - Support functions (eg the project web) So how do we go about this? We can have a general scatter load approach, everybody doing something in the corner, alone - as you pointed out, this will peter out pretty quickly. And could lead to political problems due to information black spots and a perceived lack of openness. (the website could): Allow downloading of components to registered developers This is the area where I balk the most. By making the sources available to everyone, I still hope to draw people into development, who whould not, normally, have done so. Making a distinction between registered developers and those who are not (and don't have accessto everything) makes me pretty uneasy. As an example, I do not know whether Fabrizio would have become a registered developer? Both modes of distribution could exist in parallel. There should be no need for immediate access to the latest sources for those who only have a casual interest, whilst for an active developer this is quite essential. The fact is, that it was decided to keep destribution of the sources in a certain way. Doing it on a website means either detroying this way of duistributing the sources, or introducing a difference between normal QLer and registered developers. If there really is a majority opinion to do it that way (and I would like EVERYONE'S opinion on this) I'll bow to it, though. BTW, what do you mean by component? See * below. Moreover, one of the disadvantages of the website will, of course, be that some control is removed from me (at least that is a disadvantage in my eyes :-)). No. You would be in control of all relevant UPloads to the site. For the time being, most of the developers speak to me, and, as said above, I try to nudge them in a general direction. If we set up a website, the developers will speak to each other. I'm They will anyway. But with a central, open site at least we'll all have the chance to see what the results of those discussions are as soon as the outcomes have been agreed. NOT saying that this is a bad thing but it will mean that development will be made on a more ad hoc basis. As the software registrar, with a mission to try to keep unified versions where possible (and thus, trying to steer the thing a bit), that must leave me with fixed feelings, of course since my power to influence things will be diminished (if it ever existed). But again, if this serves the community, I have no problems with it I think the best you can ever hope for is to have some control over the integrity of the sources. What facilities and improvements will be developed will be entirely up to the interests and abilities of the people involved. Allow downloading of the latest binaries to registered users That would be a definite no. The users should get their updates from the resellers. The developers don't need to download the binaries - recompiling everything is a five minutes process! At present there is virtually no control over who legal users are. If a reseller went down, or if there was a corrupt reseller (God forbid!) there is currently no way of knowing. My proposal is that each user license would come with its own serial number that the customer could use to register with the database to allow free upgrade downloads or support entitlement. Registration on the project web by users would, of course, be entirely voluntary. There is no privacy issue involved here, as the serial number only pertains to the user license. Obviously, if someone tried to register an invalid serial number, or one that is already in use, that would need to be investigated. Moreover, some kind of validation process must take place, to make sure that new versions are stable, before they are passed on to the user. Absolutely. This is your domain ;) Hold a support database (a la M$'s Knowledgebase) THAT is a LOT of work! ALL of this is a LOT of work. So is upgrading Wman and GD2! But this would be ideal for someone who would love to contribute and support, but is not able/willing to program in m68. A knowledgebase utility is an interesting programming project in itself. It neednt be created by the webmaster himself. Once up and running it could save resellers as well as punters a lot of hassle. It neednt all be done at once: in the mean time we have this list! * Components: My not too deep musings so far
Re: [ql-users] New WMAN (was: GD2)
Wolfgang Lenerz wrote: I hope so. I want to tie up some lose ends like this WMAN thing before concentrating on the university project. After that I hope others are sufficiently familiar with the code to start contributing, too (it's BTW not only SMSQ/E. EasyPtr should be updated as well, for example. Any volunteers?). Are the sources available? IIRC somebody asked Albin and he said that he would give them away. BTW, QPTR pratically doesn't need to be updated - I've done some work on that, and, provided one or two new functions are used, to reduce 24 bit colours to 16 bit and set the correct MS bit, you can use it to produce high colour PE windows from Basic. Good. I've never used the QPtr BASIC interface, so I've no idea when it comes to that. Just a couple of questions here: 1 - Does button mean the buttons in the button frame, or also (other) loose items? Loose items. But another entry for the button frame thingies is a good suggestion. 2 - I often give my application subwindows different colours to my info subwindows. Ok. How would you call the entries? Marcel
[ql-users] Fw: QL games
A help request from a user trying to run an old game on QemuLator. Anyone able to help - in the hope he might register his copy if he gets it to work! (I had a brief look and couldn't solve it) Dilwyn Jones - Original Message - From: John Leifer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 13, 2002 7:04 AM Subject: QL games Dilwyn Years ago I used to own 2 Sinclair QL's and like a fool I parted with them. My wife used to love playing the Breakout game that was included in the supplied microdrive cartridge. As a gift for her I am trying to set up on my PC a QL emulator running Breakout. I am using the QEmuLator package (currently unregistered until I am sure that it will work). Having downloaded the games (both in the microdrive and floppy version) via your web site I find that when I run Pirate, Gun or Breakout the game crashes out with the following error messages: Pirate At line 400;2 Bad parameter Gun At line 410;2 Bad parameter Breakout At line 130;2 Not found I have no programming skills and therefore am unable even to begin to resolve the problem. Can you help? Regards John Leifer
Re: [ql-users] SMSQ/E
available from (um Dilwyn's web site ?) Ummm, no, but I think I have the sources of some of Chas's programs, which he sent me when re released his ex-DP programs. Not sure if that includes compare...must have a browse. -- Dilwyn Jones I have the source for Compare, but can't remember at all where I got it from. Wolfgang Ah, found it. It's on the QL Emulators CD, in the Zips directory, the sub-directory called CHASDILN. Along with his other programs Better Basic, Cash Trader, Compare, Editor Printer, Media Manager SE, Payroll and XREF. -- Dilwyn Jones
Re: [ql-users] New WMAN (was: GD2)
??? 14/11/2002 3:46:51 ??, ?/? James Hunkins [EMAIL PROTECTED] ??: Interesting idea, to allow for add-ons. Would it be possible to make it so that not only would it allow add-ons but also allow 'replacement' functions, just like S-Basic replaces old with like named pieces? That would allow updates or modified window routines to be written that a user could choose - talk about custimization. I can't see why not :-) Then again, I've yet to see the sources :-) Nonetheless first: all guesswork from Desktop developers (HIIN) would be eliminated and second: Why re-invent the wheel? Also, would it be easy to add additional structures/objects within PE. I am using several custom pieces in QDT that I wrote. It would be nice to eventually make them part of the standard PE setup (I said eventually - QDT comes first!). That would be possible if using the add-on idea... Maybe it's already possible... I can't tell (yet). and not only that, that would shorten your QDT development by months :-)! Phoebus
Re: [ql-users] Memory
On 14/11/02 at 11:42 Tony Firshman wrote: When one does a reboot with SMSQ/E image file (using LRESPR), I wonder whether the following might work: No it wouldn't. SMSQ/E takes over and reinitializes everything from scratch. Nasta
Re: [ql-users] New WMAN (was: GD2)
On 14 Nov 2002, at 2:50, Phoebus Dokos wrote: There is a distinctive problem there provided you've used just what I call bit cropping... ie removing by brute-force the highest order bits from each colour... err no, the lowest oder bits of course... Anyway, the problem you describe is, IMHO, irrelevant here, since you are designinbg a wiondow, and can thus choose any colour scheme you like. It's not a question of displaying a bitmap in this respect... I'm trying to finish an article for QL Today for that We're all waiting :-) You mean, you are all programming with QPTR...? With the major updates that happened to the PE, using a different Window Manager should become redundant I would think It would be a good idea on restructuring it a bit (without losing compatibility) to accept add-ons... Since the PE in general provides a good enough (and known enough most important) framework a new gui (for which I strive for so long) will be a lot easier to construct. AFAIK, attaching bitmaps (ie skins) and high-colour (or should I say multi-colour) icons (sprites) is already possible so by polishing it up a bit every one could build his own window manager in a sense... Actually, it is pretty easy to do so, within some limits. I have here a small progs I use for keeping my dvd colection. This displays the dvds (I scanned the sleeves) and uses, for example, a green triangle as a button (that lights up when the pointer is over it). this was done entirely in Basic - only, it uses RPTR instead of RD_PTR(T) and thus is responsible itself for handling things like pointer in/out of the window/loose item etc... I was able to display higher colours even before Marcel changed WMAN (it also works on the Q60, for example) since it doesn't use WMAN, just the Pointer interface... Wolfgang - www.wlenerz.com
Re: [ql-users] New WMAN (was: GD2)
On 14 Nov 2002, at 13:54, Marcel Kilgus wrote: 2 - I often give my application subwindows different colours to my info subwindows. Ok. How would you call the entries? Info window colours... Appsub window colours... Wolfgang - www.wlenerz.com
Re: [ql-users] Memory
On 14 Nov 2002, at 11:42, Tony Firshman wrote: When one does a reboot with SMSQ/E image file (using LRESPR), I wonder whether the following might work: No, that won't work. SMSQ/E checks the available memory. However, it might be possible to poke a value somewhere before doing the cCALL - I'll have to check that (this weekend). Wolfgang - www.wlenerz.com
[ql-users] Ken Brickwood
Sorry for sending this to the list but... ..I need to contact Ken Brickwood and don't have his email address on file. I know he reads this list. Ken, I need to send you something you asked for at the London show - can you email me your postal address? Cheers, Darren Branagh Director, Wicklow Web Centre Limited Computer Training, Web Design, Repairs sales Upgrades. Email : [EMAIL PROTECTED] Web: http://www.wwc.ie
[ql-users] SMSQ/E Soft reset and RAMTOP
Since V2.98, all versions have the same soft reset - jump to sms.base ($900) in supervisor mode with interrupts disabled. To set the top of RAM you set sms.usetop ($404) to the new top before a soft reset. Note that most of the operating system is usually loaded above sms.usetop, you can reduce it, but do not increase it. For the Q40, low RAM is either read only or write only and it is normally read only. To write to low RAM you must poke a byte address (I think any value will do, but I use $FF). Interrupts must be disabled while doing this. Why? There's a prize for the first person who posts the correct answer to the list. moveq #sms.xtop,d0 trap #1 move.w #$2700,sr st q40_lowrom ($FF01) move.l ramtop,sms.usetop ($404) st q40_lowram ($FF018000) jmp sms.base ($900) Tony Tebby
Re: [ql-users] Fw: QL games
Dilwyn Jones wrote: A help request from a user trying to run an old game on QemuLator. Anyone able to help - in the hope he might register his copy if he gets it to work! (I had a brief look and couldn't solve it) Dilwyn Jones - Original Message - From: John Leifer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 13, 2002 7:04 AM Subject: QL games Dilwyn Years ago I used to own 2 Sinclair QL's and like a fool I parted with them. My wife used to love playing the Breakout game that was included in the supplied microdrive cartridge. As a gift for her I am trying to set up on my PC a QL emulator running Breakout. I am using the QEmuLator package (currently unregistered until I am surethat it will work). Having downloaded the games (both in the microdrive and floppy version) via your web site I find that when I run Pirate, Gun or Breakout the game crashes out with the following error messages: Pirate At line 400;2 Bad parameter 400 If n=1 THEN EXEC_W mdv1_tre1 Gun At line 410;2 Bad parameter 410 If n=3 THEN EXEC_W mdv1_gun1 Breakout At line 130;2 Not found 130 v=RESPR(6144):LBYTES mdv1_mc,v I have no programming skills and therefore am unable even to begin to resolve the problem. Can you help? Regards John Leifer Looks to me like it can't find 'mdv1_'. I haven't used QEmuLator so can give no help in configuring this...anyone know how to configure where to locate 'mdv1_'?
Re: [ql-users] SMSQ/E Soft reset and RAMTOP
For the Q40, low RAM is either read only or write only and it is normally read only. To write to low RAM you must poke a byte address (I think any value will do, but I use $FF). Interrupts must be disabled while doing this. Why? Don't know anything about the Q40 hardware. My guess: Interrupt vector is located in the low ram ... and if next access between the st to set the RAM access to WRITE, and the interrupt occurs just after this instructions - who knows which vector (value) is fetched on the access to read instead of write? Jochen
Re: [ql-users] New WMAN (was: GD2)
In message [EMAIL PROTECTED], Marcel Kilgus [EMAIL PROTECTED] writes Wolfgang Lenerz wrote: I hope so. I want to tie up some lose ends like this WMAN thing before concentrating on the university project. After that I hope others are sufficiently familiar with the code to start contributing, too (it's BTW not only SMSQ/E. EasyPtr should be updated as well, for example. Any volunteers?). Are the sources available? IIRC somebody asked Albin and he said that he would give them away. I would like to suggest that the sources be given to Rich Mellor who could work on them and maintain a cheap commercial release for them. -- Roy Wood Q Branch, 20 Locks Hill Portslade. Sussex. BN41 2LB. UK Tel : +44 (0)1273 386030 Fax : +44 (0)1273 430501 (New number!) Mobile +44(0)7836 745501 Web : www.qbranch.demon.co.uk
RE: [ql-users] Fw: QL games
The games Pirate and Gun fail because John must have unzipped them with the Windows version of unzip instead of unzip for the QL. This causes the executables' QDOS headers to be lost. Breakout fails because it tries to load a file named 'mc', but there is no file with such a name in the mgames.zip archive on Dilwyn's web site. Dilwyn, is one or more of the original files missing from mgames.zip? John, I can send you by email a version of mgames.zip correctly unzipped for the QL. (But breakout seems to be missing.) Daniele
