Dilwyn Jones wrote:
>>> Does it contain this feature (background drawing), too?
>> Yes, it does. Can't say whether it fully works, however, I normally use
>> SMSQ/E instead of the plain QL stuff.
> Remember, though, that this version doesn't work across all QL ROM
> versions - Minerva being requi
Marcel Kilgus wrote:
> The commercial phase of SMSQ/E is pretty much over, I'm hoping to
> organize free downloads sooner or later. Which release do you need?
>
> The feature you requested (background update) was by the way done by
> me ;-)
Well, that was meant to be private
Jiri Dolezal wrote:
> Perfect!
> My (old) SMSQ was not able to do this, l and I was really hesitating
> to buy the latest one.
> Now I have one more reason to spent 90 EUR for it.
The commercial phase of SMSQ/E is pretty much over, I'm hoping to
organize free downloads sooner or later. Which rel
Tobias Fröschle wrote:
> - the 020 has an instruction cache - but that should not lead to
> problems with code run from ROM, as that cannot be very self-modifying ;)
The problem is not the OS but application programs doing this. In the
patched ROM the cache is cleared on every TRAP or exception, f
Thierry Godefroy wrote:
Wow, hello again :-)
> For all 680x0 CPUs above the 68000/8 (ie. for 68010/012/020/030/040/060s),
> the MOVE from SR instruction is priviledged while it is not for the
> 68000/8. This is the usual cause of incompatibilities for software
> written for the 68000 and ran on a
Dave Park wrote:
> It's been mentioned that vanilla QDOS/Minerva doesn't run happily on
> 68EC020 due to CPU differences. The GC/SGC copies and patches the OS to
> work with the EC020 CPU, and to relocate certain resources.
>
> My questions are: what are the differences? How does the GC/SGC boot th
Daniele Terdina wrote:
> here are the details of how Q-emuLator stores files on the native file system:
>
> QL files have a special piece of information associated with them, called the
> ‘QDOS file header’.
> The header stores such information as the file name and whether the file is
> an execut
Wolfgang Lenerz wrote:
>> QPAC2
>> channels window has the same problem, it will show "WIN1_whatever"
>> even if I have renamed WIN to XYZ.
>>
> ?
> WIN_USE PPP
> open_in#3,ppp1_boot
>
> Call up channels menu , here it shows "ppp1_boot".
Okay, this is because SMSQ/E actually provides an official w
Wolfgang Lenerz wrote:
> What the prowess loader does is the following : it opens the startup
> file from where it is indicated in its command line (eg. ex
> win1_proweess_prg_loader;"win1_prowess_startup". So far so good.
>
> Once that file is open, the loader then uses that for a special trap#3
Wolfgang Lenerz wrote:
> Thanks, but I'm not sure I understand - the loader program works from a
> ram disk? It doesn't here.
Here it does. Unlike WIN, where nothing seems to happen, it starts up
fine when everything is copied to ram1_
Marcel
___
QL-Us
Wolfgang Lenerz wrote:
> The fact that the prowess loader program doesn't work seems to indicate
> an error in the emulation core itself somewhere.
>
> As this loader program seems to be a C program, finding the error will
> not be trivial. Since I can load Prowess "my" way, this is not so high
> o
Bryan Horstmann wrote:
>>> * When I select Xchange, I cannot find out how to bring it up to
>>> screen size; I've already set the screen size correctly
>> Simple : you can't Xhange has a fiwed screen size which you can't
>> change (unless you poke around somewhere in the program's code, I thi
Tobias Fröschle wrote:
>> 3 - I'm by far not the programmer Marcel is.
> Considering your day job and judging by the results, you're very,
> very good for a non-professional ;)
Outstanding even. SMSQmulator is a great piece of work.
Marcel
___
QL-Users
Tony Firshman wrote:
>> QPC of course has the same problem. I solve this by using a queue that
>> buffers display accesses and only apply the changes to the screen
>> image 62,5 times per seconds.
> Is there anything to be gained from the (very) old trick of storing the
> previous screen content an
Wolfgang Lenerz wrote:
> Well, drawing to the screen is heavy on the resources, ESPECIALLY when
> one is in QL compatible mode. Basically, I redraw the ENTIRE screen once
> for every pixel changed (or every 2 or 4 fixels in QL mode).
> If anyone could point me to a way to change a wingle pixel in a
Dilwyn Jones wrote:
>> I'm sorry, due to the recent loss of my father I was not in the mood
>> to participate in any discussions. Just a short answer:
> I'm very sorry to hear of your loss, Marcel. Please accept my condolences.
Thank you all. In the end he was responsible for introducing me to his
Norman Dunbar wrote:
> In QPC, version 3.33, the above works without any exceptions. PRINT
> PROCESSOR gives 20, I must assume that either a 68020 doesn't barf at a
> long word access to an odd address or something is not working correctly
> any more!
Only 68000 and 68008 had this limitation.
Mar
I'm sorry, due to the recent loss of my father I was not in the mood
to participate in any discussions. Just a short answer:
SMSQE wrote:
> The keyboard functions correctly in absolutely every piece of software I
> have, except QPC2.
This is probably because you do not play any games, as many of
Norman Dunbar wrote:
> I wonder why, when I reply fro my phone, I seem to start a new thread,
> even thoigh I'm replying and not manually, starting a new thread.
Probably because your phone doesn't seem to generate the
"In-Reply-To:" header.
Marcel
___
tobias.froesc...@t-online.de wrote:
> The address of the keyboard input buffer seems to be private to the
> console channel - There's no variable in the channel table for that.
> I could even imagine that all console channels share the same
> keyboard queue - As there can always be only one channel
Norman Dunbar wrote:
> Ok, given that the above is true, I assume that when the scheduler
> reschedules a task, then the above system variable will be loaded with
> the keyboard queue for the (now) current job?
You're already off path here. The queue is not the one of the
currently executing job (
George Gwilt wrote:
> Although I put the program in an existing obscure directory (called
> "Tobias") it ran without configuratrion. But there was no sound. Perhaps I
> should read the manual.
You need to load Simon's sound_cde extension, which was already in my
boot, so it did work from the get-
Dilwyn Jones wrote:
> Download it free of charge from:
> http://www.dilwyn.me.uk/games/index.html#qjewels
> (173kilobyte download)
That thing is very cool, well done Tobias (and I thought so even
before I read the nice shout out ;) ).
Funny thing is, I unpacked it and thought "Oh god, this being
John Gilpin wrote:
> Thanks for checking on me, well the message is from me and not a hoax.
That is about as likely as me winning the lottery... and I never buy
tickets. Whoever you are, you truly have no shame.
Marcel
___
QL-Users Mailing List
http://
tobias.froesc...@t-online.de wrote:
> No wonder it doesn't work, then ;)
Yeah, I had to look it up, too, but the source code was pretty
definite on that point ;-)
pt_spray
moveq #err.ipar,d0
rts
end
Marcel
___
QL-Users Mailin
tobias.froesc...@t-online.de wrote:
> does anyone know how "spraying" sprites with the Easyptr 4.01 BLOBW
> procedure is supposed to work in mode 32?
TT never implemented spraying for GD2, sorry. Wasn't exactly a much
sought of feature.
Marcel
___
QL-U
Dave Park wrote:
> (reposted from wrong list address - apologies if dupe)
Don't worry, wasn't a list address but my personal one. Thanks for the
heads-up, pity I don't have a gold card ;)
Marcel
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/sm
Marcel Kilgus wrote:
> It was always possible to implement different file systems, SMSQ/E
> itself comes with FAT12 support built-in for example. A layered
> approach would just ensure that the file system could easily be shared
> between hardware drivers. But with the state t
Miguel Angel Rodriguez Jodar wrote:
>> Unfortunately yes. There is no abstraction layer between hardware and
>> file system.
> Well... that's not necessarily bad news. That means that I can implement FAT
> and
> thus, easing file sharing between PC and QL :)
It was always possible to implement di
Miguel Angel Rodriguez Jodar wrote:
> A proper QDOS driver is still needed. That remainds me of a thing I'd like to
> know and it's not very clear in the documentation I've read: for a directory
> device driver, I see that I have to implement high level file routines (OPEN,
> CLOSE, READ, WRITE, FO
Adrian Ives wrote:
> It's a bit of an over-simplification to lay the reasoning for my
> decision to withdraw solely on the lack of interest. It has more to do
> with simple economics. It costs money to buy the stock to build the
> units. As I have said before about the Ser-USB, unless the stock can
Dave Park wrote:
>> Of course, no idea if any hardware development for the QL could ever
>> be commercially successfully nowadays, but it might have made for a
>> nice KickStarter project to gauge real interest.
>
> Having worked it out myself for my own projects, I know they'd never
> be "commerci
Dave Park wrote:
> That being said, it's still a "wrong behavior" in the sense that
> INKEY$ is not like INPUT but is more like KEYROW - both should
> instantaneously check if a key is pressed and report if so.
Unlike KEYROW INKEY$ does NOT check the current keyboard status, it
just gets the next
Adrian Ives wrote:
> I have sent the most recent sources to Peter Graf just a few minutes ago.
>
> The code may be placed in the public domain, but it is up to Peter how
> he wishes to move forward with it. I regret that I cannot offer any
> support with the drivers as I am moving on to other proje
Dilwyn Jones wrote:
> Before I reinvent the wheel and OCR my Easyptr manual to use on my
> eBook reader, has anyone else already done this?
>
> The Easyptr commands are the hardest syntax to remember of all the
> BASIC extensions, I think!
After reading this I checked in my usual directories and f
Dilwyn Jones wrote:
>> Now we just need a nice 'icon' to go with name ... :-)
>>
> Well, I worry that the smiley reveals what icon was probably going through
> your mind, Malcolm 8-/
Well, this here of course:
http://lh5.googleusercontent.com/public/8SgPf-WayiR39OVsi6q0EKXxHrT5GO2YBKzZzTg25x8XWU
Wolfgang Lenerz wrote:
> Much is now working correctly.
> Basic works.
> PE & WMAN work.
> It's now possible to have a bigger screen (I normally use 1024x512) but
> screen access remains slow.
Congrats. I remember it to be pretty satisfying once things start to
work ;) I probably never forget the
Bob Spelten wrote:
>> Nothing to do with BPUT here. The problem is that you're using an
>> array expression x(0,1) with more than one dimension in the FOR loop.
>> SBASIC got a bug there.
> Thanks for the insight.
> I was puzzled because it had worked before.
> But I did at one point replace the si
Bob Spelten wrote:
> Can anyone explain this?
> I found another UPUT/BPUT related strange bug.
>
> I have the following lines in my program:
>FOR i%= 0 TO x(0,1) -1 : BPUT #c3%,aa$
Nothing to do with BPUT here. The problem is that you're using an
array expression x(0,1) with more than one dime
Dilwyn Jones wrote:
> Can anyone help with the query below?
> I think it refers to the Maths Toolkit now available on my website
> http://www.dilwyn.me.uk/tk/maths.zip
> (the toolkit includes the assembler source if anyone wishes to investigate).
The MATREAD command is for example completely inco
Norman Dunbar wrote:
> Mind you, it shows how well Marcel has done with QPC when it just works
> and just works in a manner that makes me think it's still QDOS. Ditto
> for SMSQ/e of course!
Actually I hope it works much better than QDOS ;) The SBASIC command
line history in SMSQ/E is something I
Lee Privett wrote:
> Not the same for OPC2 unfortunately , I am running this Windows
> program under WINE (through Play on MAC), when the initial
> configuration window comes up if I select devices and obtain a text
> box the ALT 3 works a charm producing # characters, however when
> getting past
Lee Privett wrote:
> I have this experience on a toshiba laptop making its use
> impossible, one of the keys to go somewhere else is the underscore _
> and you know how often that gets used :(
While in QPC, press all the modifier keys once one after the other
(Ctrl, Alt, Fn, Shift, left and right
Gerhard Plavec wrote:
> I mean QL-networking of course: one QL running with 68K/OS another one
> with QDOS - may be they are compatible in this way - if not, have a try
> with a SER-connection (68KQL to QDOSQL or 68KQL to some computer with a
> RS232)
68K/OS is weird and in any case has no Basic o
George Gwilt wrote:
> On 18 Feb 2012, at 11:13, Tony Firshman wrote:
>> I will design a tool to add the extra 1/4" diameter (8-)#
> Can you do it in millimetres?
He has to, because unlike a 5 1/2" disc, which really has that size, a
3,5" disc is in reality a 90mm disc. This is only roughly 3,5 in
Ralf Reköndt wrote:
> Hmm, how do TK2 check this?
Address check < $C000.
Marcel
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Tony Firshman wrote:
>>> Pedant (8-)#
>>> (Pot calling the kettle black).
>>> Tony
>>
>> Why the sudden outbreak of "testy" emails ;-)?
>>
> Not at all - didn't you see the smile. It was a J O K E.
> and the 'pot' comment was against *me* (8-)#
WSH!
That's the sound of Geoff's joke go
Marcos Cruz wrote:
> I see a contradiction here, Marcel:
>
> George's proposal sounds reasonable to me too, but you say probably there
> won't be any more paid upgrades, what means the actual end of QPC2's
> commercial life. If there's no comercial life left for QPC2, then I think
> there's no reas
Geoff Wicks wrote:
> I would guess that not many copies, if any, of QPC2 will be sold in
> the future. That being so, it might be worth while offering Marcel a
> sum of money in place of these. This could be attractive to Marcel
> if he reckoned that it was worth more than he would get from the
> f
pjwitte wrote:
> I need to print from QPC2 via QPCPrint using a QL program that doesnt
> have any configurable way to translate characters. The text to be
> outputted contains "foreign" characters in QL format that dont match
> up with the printer's character set.
Have a look at the TRA command,
Bob Spelten wrote:
> Does anyone have experience in using Extended Sprites as an EasyPTR AW
> menu item?
> The sprite should change to the "current" status when I move the mouse
> over it but it doesn't.
Wolfgang did that stuff, but I think this is implemented for loose
items only.
Marcel
__
Computer Research Centrum, Ltd wrote:
>>in QDisk.c for the lines (around line 295) containing 'WA', 'A5' & 'B5'
>>as part of a switch statement. If your processor is a big endian one,
>>the code should work; however, if it is little endian (like the x86
>>processors), then the tests will definit
Dilwyn Jones wrote:
> BEWARE: the ptr_gen2.02/wman205 combination gives problems on some
> systems (e.g. my MinisQL Aurora) and I had to resort to the ptr_gen
> v2.01/wman 2.01. I have no idea if this is a general issue, or
> confined purely to that one system of mine. Symptons include pointer
> ap
Dilwyn Jones wrote:
> Now what did Marcel once say about being "unable to resist a
> challenge..." :-)
I've grown up since then ;-)
Marcel
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Norman Dunbar wrote:
> Well, I suspect that QPC will run under WINE on any flavour of Linux,
> and not necessarily one that has an Intel Processor of x86 fame beneath
> it.
Hmm, where to begin... The very name of WINE itself stands for "Wine
Is Not an Emulator". It does not do ANY CPU emulation. S
Norman Dunbar wrote:
> * He kept saying "Windows client running on ARM (natively)" I
> wonder if that is some sort of Citrix type thing rather than proper windows?
No, it's a proper, native port. Notice how he says that they've
re-compiled office for the ARM architecture. Windows NT used to be
ava
Lee Privett wrote:
> Using Win7 on a new Toshiba laptop running QPCII now throws up this
> problem, which works perfectly well under Windows and also in
> Q-emulator
They use different mechanisms to read the keyboard. Unfortunately some
notebook manufacturers mess up the keyboard scan codes... you
Norman Dunbar wrote:
> prog_use win1_c68_
> ex cc;'-c -v -tmp ram1_ win3_source_test_c'
Try
ex cc;'-c -v -tmpram1_ win3_source_test_c'
Notice the lack of a space between tmp and ram1_...
Marcel
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/s
Rich Mellor wrote:
> I think this is a problem with Q-emulator (maybe others) - I wonder if it is
> linked to MOVE.W / MOVE.L trying to use an odd address (which was supposedly
> not valid on the 68008, but somehow works on the standard QL!)
Hm? I'm pretty sure this has never worked on a standard
Lee Privett wrote:
> Yes that is looking good will try tonight, also the suspend in Turbo
> may work too.
By the way, I do read your blog as an RSS feed, but have never given
feedback because I have none of the accounts needed to post comments.
Marcel
Lee Privett wrote:
> Yes that is looking good will try tonight, also the suspend in Turbo
> may work too.
SUSPEND has the problem that a) no user input can be processed in the
meantime and b) the runtime of the code that actually does something
cannot be taken into account, so depending on how muc
Wolfgang Lenerz wrote:
> have a look at
> www.scp-paulet-lenerz.com/14mljkl24/Wolf/Download
>
> You can download a timer thing from there, usable from basic.
Ah, that's perfect. I'd go with something like Wolfgang's extension.
Marcel
___
QL-Users Maili
Lee Privett wrote:
> Something like
>
> 10 FOR F = 1 TO 25
> 20 PRINT CHR$(31);
> 25 A$ = INKEY$ : do something else with this (stops me
> using the Pause command so
)
> 30 DELAY (100)
> 40 END FOR F
>
> DELAY 100 gives
Martyn Hill wrote:
> My questions arose from my attempts to 'find' the SBASIC variables (and
> thus the internal SB tables) by peeking directly around memory and
> comparing to the results of the SB peek (\\xxx) commands. The SYSVAR
> "sys_sbab" no longer appears to point to a 'real' Job0 - it do
Lee Privett wrote:
> Weird it may be but unless there is some other sprite software I am not
> aware of (DPs I am having problems with), I do not know how to detect
> graphic collision without looking at the screen directly, unless there is
> another way?
Um, you control where the sprites are draw
Martyn Hill wrote:
> How is it that some of these areas lie well outside of the traditional
> SBASIC job area?
>
> I have my own ideas, but hoped someone here (Marcel?) might be able to
> shed some light on how and where SBASIC is laid-out in SMSQ/E.
Frankly for me it's all pretty hazy what you're
Miguel Angel Rodriguez Jodar wrote:
> Until now, I present to you a demo of the read speed achieved with a
> white-brand
> SD card, and a 640KB (should work on an unexpanded too) QL with Minerva 1.98 .
>
> http://www.youtube.com/watch?v=78xtsEKW4Lw
That is frigging cool, congratulations!
Marcel
George Gwilt wrote:
> 100 DEFine PROCedure Sloop
> 110 TYPE_IN "exep button_sleep"&CHR$(10)
> 120 END DEFine
>
> Now the procedure Sloop will put that program to a button.
Why do you use "TYPE_IN" for this?
By the way, Button_Sleep of course puts the CURRENT job into the
button frame, not the on
Tobias Fröschle wrote:
> I have not seen a command though that would shrink S*Basic to a button
> which would be quite nice,
EXEP "Button_sleep"
("Button_Schlaf" for German QPAC2. Unfortunately this one is not
language agnostic).
Marcel
___
QL-Users M
thorsten herbert wrote:
> @Urs,Just saw the piture and noted, that in the same folder there
> is a screen showing a game called WERNER. I'm sure that I had this
> game but can't remember what it was about. Any other screenshots?
That was a Boulder Dash clone. Quite a nice game, actually, played it
Dave Park wrote:
> The catch is that the QL is much lower powered in terms of heat and current
> demands, and these PC-type boards do not fit that power envelope - therefore
> they can't be used embedded very easily.
This board uses less than 20 Watts when idle (still less than 40 Watts
in worst c
Dave Park wrote:
> Indeed an FPGA implementation of an m68k chip, or emulation of an n68k on
> some other lightweight chip are the only two economically sensible
> solutions.
Actually, the cheapest solution would be to buy something like this
http://mini-box.de/fr/catalog/il/1261
and use a thin
While looking for something else I actually found the old QL hardware
schematics on my hard drive. Considering that the files are 20 years
old that's quite a feat, I think ;) Problem was, the current Windows
version of the layout software couldn't read this old file format...
BUT I actually manage
Phill Harvey-Smith wrote:
>> And of course the SMSQ/E sources are available, which can be downloaded
>> in whole or part from http://www.scp-paulet-lenerz.com/smsqe/
>
> Yeah I found the SMSQ/E sources later on, problem is they use DMA which
> of course the original QL does not use.
Erm, no, while
Bob Spelten wrote:
> So this brings back another Sprite question, what is the current limit for
> pointer sprites?
> The maximum I could make was a line of 64 characters or 384x10 (or 12?)
> pixels.
The maximum for pointer sprites is I think 64x64 = 4096 pixels.
> Any more and SMSQ/E crashed, the
Tobias Fröschle wrote:
> I can very well live with no background window update (Although I very
> much appreciate you made it working on SMSQ/E that I use on QPC and QLX-
> It looks like it has been considerable work),
And you're right with your assessment ;)
> but not quite with having an unreli
gdgqler wrote:
> I cannot find INCBIN among the QMAC assembler directives. I presume
> that if it were there it would cause the inclusion of a binary file,
> already assembled. GWASS allows the inclusion of such files by LIB.
Then your QMAC might be too old, at least 1.06 has INCBIN. But reading
y
Bob Spelten wrote:
> My question remains, why or when should I use Bitmask?
Rules of thumb:
- If the sprite is a complete solid rectangle, don't use any mask.
- If the sprite is QL mode and has a shape, use a bitmask
- If the sprite is high colour, use alpha mask
> I have just produced my firs
tobias.froesc...@t-online.de wrote:
> never tried it on the real black box, but I'm successfully running
> ptr_gen 2.0.1 against wman 2.05 in uqlx and Minerva. The trick is -
> don't use the newest ptr_gen, 2.02 and 2.03 proved largely too
> un-stable to me (at least on that platform) to be really
Bob Spelten wrote:
> This probably means that somewhere in RAM an unpacked version is held and
> copied to the screen.
> Is there any way to peek the location of this from SBasic?
Nope.
>> - For solid sprites, the mask can be omitted entirely
> Your PNGCVT program can also make sprites with Bitm
Bob Spelten wrote:
> WMAN2 provides support for up to 32K colours for PE window elements,
> direct or through the use of 1 to 4 System Palettes or a User Palette set
> up in RAM.
True. This was the main reason for WMAN2.
> It also supports sprites in 8, 16 or 24 bit modes with Alpha masks or no
>
Dilwyn Jones wrote:
> I forgot to ask in the original question if the Atari ST_QL emulator
> ever supported high colour modes? Or was it just larger screen
> resolutions with no increase in number of colours?
Just higher resolution.
Marcel
___
QL-User
Dilwyn Jones wrote:
> Ah - might not be possible to use SMSQ/E on Trump Card at all,
> perhaps? This was at crux of question.
No, some gold is required for SMSQ/E ;)
Marcel
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
tobias.froesc...@t-online.de wrote:
> Marcel,
> sorry to contradict again ;-) :
> uqlx can run a JS ROM in 800x600 without PE quite well.
This is right out of the uQLx source code:
if (isMinerva) {
[...]
else /* JS doesn't handle big screen */
{
bsfb:
qlscreen.linel=128;
ql
tobias.froesc...@t-online.de wrote:
> Marcel, George,
> my QXL originally came with "SMS" (neither "2" nor "Q" attached to it).
> This definitely had no PE. (Today it's on newest SMSQ/E, naturally)
I'm pretty sure that version was called SMSQ (it's the only version
that was called SMSQ, actually).
tobias.froesc...@t-online.de wrote:
> Yes, I'm sure ;-)
> Mostly because I have to re-install PE from Dilwyn's site whenever I set up a
> new Linux box
Yes, you're right. I already had the suspicion that Minerva was
written cleanly enough to support different screen layouts (had to
really, be
gdgqler wrote:
> There must have been some, otherwise I would certainly not have
> gone to the trouble of testing different sizes! Nor, i suspect, would Mark
> Knight.
I'm genuinely curious and don't pretend that I know the whole truth.
But except the "SMSQ for QXL" fringe case I cannot currently
tobias.froesc...@t-online.de wrote:
> -- I think the PE was necessary for higher resolutions, so you can test
> -- for that first. Afterwards IOP.FLIM should be able to find the screen
> -- limits.
> Not quite.
> UQLX does offer higher resolutions without PE (sure you can run PE
> on top of it.)
>
gdgqler wrote:
> IOP.FLIM is a good way of finding screen limits. It is slightly
> annoying if it is not available. I have programs which find the
> maximum size by trial and error if IOP.FLIM is not there.
In which cases is IOP.FLIM not available and the resolution not
512x256?
Marcel
_
gdgqler wrote:
>> I'm looking for a function to use in S*BASIC that will tell me if the
>> display driver is capable of providing resolutions greater than the QL's
>> mode 4 & 8 defaults - it would be enough just to know if the display driver
>> is GD2 or not. It has to run on any QL system, inclu
Phill Harvey-Smith wrote:
> K, I've applied to join that group, though last message seems to have
> been posted to it in 2008, and the group requires approval to join, so I
> guess it depends if the admin is still around :(
The admin is Nasta. I hope that he's still around somewhere...
It's so da
Phill Harvey-Smith wrote:
> I have here a Sandy SuperDisk interface which works fine. The board
> however has several (3) missing chips and a missing 9 pin socket, I know
> from the manual, that this can be upgraded to a SuperQBoard, by fitting
> the missing chips and the 9 pin mouse socket.
All m
Adrian Ives wrote:
> It's easier said than done, though. You can't exactly whip the JS ROMs out
> of a QL and slap in SMSQ.
SMSQ? I'm talking Minerva here... and you certainly can whip out a JS
ROM and put Minerva in there ;) I've never owned a machine capable of
running SMSQ/E before creating QPC
Dilwyn Jones wrote:
> Authors of QL software like me use JM and JS ROMs to test software for
> compatibility. Probably the only thing I use them for, though.
Yeah, but that's something you didn't have to do if people would at
least be willing to enter the 90s, QL wise ;) I had Minerva in all my
QL
Dave Park wrote:
> I just need to check out the chip select lines on the two ROM sockets to see
> how they operate - someone has said that in the $8000 socket, CS asserts for
> the entire 32K block, but to me that suggests a conflict with the ROM port.
>
> I'll want to check it out, unless someone
Dave Park wrote:
> I have been talking to Tony (Lau is AWOL) about Minerva 2. I would really
> like to do a Minerva ROM board that allows you to choose to boot either
> Minerva 1.98 or JS ROMs, since it's always handy to have both. If I can get
> permission and licenses, I'll be doing that.
Minerv
Adrian Ives wrote:
> But what I would really like is some kind of document that sets out a list
> of things that fall in the category: "This should work under QDOS, it says
> it should, but it doesn't
but we went ahead and fixed it in SMSQ"
Where does it say it should work under QDOS? I guess th
Lee Privett wrote:
> Thanks, I think it is reporting sectors rather than memory as I
> seem to get twice as much, however it is telling me what I want to know.
No, it's RAMTOP, i.e. the highest RAM address, but below the RAM are
the ROMs etc. On a QL you will probably have to subtract 131072 to
de
Phill Harvey-Smith wrote:
> Indeed, I have worked out this much, however I think the RAM test takes
> place before this point so will hit the mirrored rom and only see 640K
> :( So there must be something else afoot :)
RAM test is pretty much the first thing the OS does, long before
initializing t
Tony Firshman wrote:
> Not only did he get the code working but he also made some improvements
> to the sound. I almost said 'sound improvements' which is also true but
> not the same thing (8-)#
I did analyze the original 8049 code to implement the QPC sound
emulation. I dimly remember it being
401 - 500 of 933 matches
Mail list logo
