Re: [Ql-Users] Q40i/Q60 board availability

2020-06-12 Thread Peter Graf via Ql-Users
Hi Jason,

> I realize I'm 19 years late to the party, but does these boards exist
> anymore?

Nice to hear that my good old design is still of interest. The Q60 still
exists and has a die-hard user base, but is no longer officially
manufactured. The Q40/Q60 version of the SMSQ/E operating system is
still maintained.

It appears that your interest is not QL related, but more driven by the
68060 CPU as such. Can you tell us a little more about it? Would you
want a QL operating system at all, or is 68K Linux preferred?

> How hard would it be to get them made again?

There is a slow-going effort to build a few more boards from leftover
parts, on a hobbyist basis. The outcome is hard to predict.

>From time to time, I vaguely consider designing a completely new 68060
mainboard with modern HDMI video output, and SDHC cards instead of
floppy and IDE harddisk. Would such a machine come close to what you like?

All the best
Peter
___
QL-Users Mailing List


Re: [Ql-Users] Memory cards and the Q60 (was Re: SMSQE 3.36)

2020-05-12 Thread Peter Graf via Ql-Users
> If it is the drives, well, that's the problem Thierry has mentioned.

By the way I doubt the ISA bus reset is required, which is adding to the
delay. Neither QDOS Classic nor my own Utility ROMs use it. Never seen
any issue.
___
QL-Users Mailing List


Re: [Ql-Users] Memory cards and the Q60 (was Re: SMSQE 3.36)

2020-05-12 Thread Peter Graf via Ql-Users
Ralf Reköndt via Ql-Users wrote:
> Hmm, so why use it in an EPROM?

You need some kind of ROM to boot the machine and load the OS.

This can be a separate loader, like inside the Q68, but then it needs to
access mass storage to load the OS.

In case of the Q40 and Q60, the OS can boot completely without any mass
storage, which is faster.
___
QL-Users Mailing List

Re: [Ql-Users] Memory cards and the Q60 (was Re: SMSQE 3.36)

2020-05-12 Thread Peter Graf via Ql-Users
 Marcel Kilgus via Ql-Users wrote:
> Fabrizio Diversi via Ql-Users wrote:
>> This issue seems to address newer SMSQ/E in Eprom, I used second
>> hand ST M27C1024 eprom 120ns. I ordered completely new eprom from
>> China the same Brand but with 100ns.not sure where is the
>> problem.
> 
> SMSQ/E never executes from EPROM, it is always copied to RAM first. So
> any problem with the EPROM would certainly result in an instant crash.

Since the Q60 has no separate loader like the Q68, SMSQ/E has to execute
from EPROM at first, to do the copying.

If the EPROM has a timing problem on the borderline, it is possible that
only very little data is corrupted during the copying process from ROM
to RAM. Which could result in something that is not an immediate crash.

(I'm not saying it is a timing problem.)
___
QL-Users Mailing List


Re: [Ql-Users] SMSQE 3.36

2020-04-23 Thread Peter Graf via Ql-Users
Fabrizio Diversi via Ql-Users wrote:
> -    As a slave I have a 4 GB Toshiba SD HC with a CF adapter Type II. 

Ah! Very good idea! With the right passive CF-IDE adapters, those might
not suffer the same problem as the SD-IDE converters, which allow no
slave. Also they are quite compact.

Thanks for pointing to that!

Peter
___
QL-Users Mailing List

Re: [Ql-Users] SMSQE 3.36

2020-04-23 Thread Peter Graf via Ql-Users
Fabrizio Diversi via Ql-Users wrote:
> it is more easy to find on the market CF to IDE adapter, only for my Q40 
> I ordered recently from Amazon (should be here next week) an SD/IDE 
> adapter: Kalea Informatique - Adaptateur Convertisseur IDE 3.5" 40Pin 
> vers SD Card. I let you know .

They work, but have the problem of not allowing a slave device on the
same connector.

Peter
___
QL-Users Mailing List


Re: [Ql-Users] SMSQE 3.36

2020-04-23 Thread Peter Graf via Ql-Users
Thierry Godefroy via Ql-Users wrote:
> Sadly, I did not find a single SD card to IDE adapter that could be
> configured on a master/slave IDE port, i.e. they all grab the "stand
> alone" role and forbid using a second IDE drive as a slave (or master).

Same here, unfortunately. Except that, it seems a nice alternative with
the full possible speed.

Peter
___
QL-Users Mailing List


Re: [Ql-Users] SMSQE 3.36

2020-04-23 Thread Peter Graf via Ql-Users
Wolfgang Lenerz via Ql-Users wrote:
> The Qx0 uses the UV erasable 27c1024.
> I don't remember whether other types of EPROM, especially EE ones will fit.

The 27C4096 fits. Nowadays, most of them are OTP though.

Peter
___
QL-Users Mailing List


Re: [Ql-Users] SMSQE 3.36

2020-04-23 Thread Peter Graf via Ql-Users
Fabrizio Diversi via Ql-Users wrote:
> New configuration I am approaching is to burn new ROM able to load 
> SMSQ/E 3.36 directly without need of at least one atari partition and 
> then have a single CF/SD (1 or 2 partition, doesn't care) to be able to 
> load until 8 QXL.WIN and to have the freedom to share them with Q68.

Especially for sharing with the Q68, the new feature is useless, as it
does not exist there.

Peter
___
QL-Users Mailing List


Re: [Ql-Users] SMSQE 3.36

2020-04-23 Thread Peter Graf via Ql-Users
Thierry Godefroy via Ql-Users wrote:
> On Thu, 23 Apr 2020 09:16:36 +0200, Wolfgang Lenerz via Ql-Users wrote:
> 
>>> Sadly, this change totally broke secondary partitions support for Atari
>>> partitioned hard disks.
>>
>> Just to make sure, this change broke things in 3.36 only, not in 3.35?
> 
> Yep. v3.35 works like a charm in this respect, and I actually reverted to
> it for now...

For me the question is: Where is even the slightest practical benefit of
the new feature? Up to eight QLWA containers can be used without it.

I know it is hard to abandon code, after time was already invested, but
in this case I'd vote for it.

All the best
Peter
___
QL-Users Mailing List


Re: [Ql-Users] SMSQE 3.36

2020-04-19 Thread Peter Graf via Ql-Users
Hi Wolfgang,

> SMSQE 3.36 is out. You can get it as usual on wlenerz.com/smsqe

Many thanks for your maintainance work, covering so many different machines.

Not that I actually use the Q68 FAT driver, but by chance I noticed a
configration issue. The "Fat1_ is on card =>" entry exists, but can not
be selected. ("Fat2_ is on card =>" and higher numbers work.)

> For the Q68, cards need not be initialized for normal access (a
> CARD_INIT might still be necessary for the CARD_xx commands).

I have not enough evidence to actually blame this feature, but would
recommend a little caution. I had strange issues two times, since I
tried it instead of just rebooting. In both cases, problems appeared in
connection with overwriting existing files. I had to concentrate on
other stuff, so I didn't actually investigate. Reverting to a backup
image cured it. Could be just coincidence with something else.

> The
> keyboard may be handled via interrupts, which may help with certain
> USB-PS/2 adapters (this needs your FPGA to be updated, though). SER
> works again correctly.

Please note that the mentioned FPGA update not just adds keyboard
interrupt support, but also lowers the rate in which the PS/2 ports are
sampled. At the moment we wait on more testing. Since the Q68 has no
field update for the FPGA, persons who have those (not fully PS/2
standard conforming) adapters should ask Derek.

All the best
Peter
___
QL-Users Mailing List


Re: [Ql-Users] QL User grapic competition from 1985: Tree

2020-04-16 Thread Peter Graf via Ql-Users
Michael Berger wrote:

> I have a 1985 issue of 'QL User', where the results of a graphics 
> competition were posted. Basic programs of limited length, to produce 
> some image. The contribution that impressed me most (by far!) was 'Tree' 
> by A. Pritchard. That was a random image with a tree in the foreground, 
> an island in the background. With the tree being painted by recursion. 

Very cool indeed, thanks for sharing!
___
QL-Users Mailing List


Re: [Ql-Users] QBOX BBS for TCP/IP released!

2020-03-04 Thread Peter Graf via Ql-Users
Am 04.03.2020 um 17:26 schrieb Jan Bredenbeek via Ql-Users:
> I've just ordered Schottky diodes for the operation 'Q68-net'.
> I followed the discussion on the QL forum about fitting network sockets to
> the Q68 case. This doesn't look very straightforward. I think removing the
> on/off switch and mounting the network socket there will be the best
> solution with minimal impact (I only need one network socket).

If you have no problem with network plugs on the front side, then I'd
recommend drilling a hole to the front panel.

> Or is there a simple way to convert the sound output socket to a network
> socket with minimal damage?

It is even possible without *any* damage, but you would lose sound. Some
tinkering would be involved, drilling a hole is definitely easier.

Peter
___
QL-Users Mailing List


Re: [Ql-Users] QBOX BBS for TCP/IP released!

2020-03-02 Thread Peter Graf via Ql-Users
Hi Jan,

> I personally use a Linux machine or Raspberry Pi with tcpser and a> 
> USB-to-serial converter to exchange files to my BBQL.
How about using a Q68 as bridge from Linux (SER) to QLNET (BBQL)?

This way you could use higher baudrates. And network is much faster on
the BBQL than SER.

Peter

___
QL-Users Mailing List


Re: [Ql-Users] Q60 + OSSC

2020-01-15 Thread Peter Graf via Ql-Users
Thierry Godefroy wrote:
>> Besides lack of time and the BGA soldering issue, I remain unsure if
>> such a massive board modification is appropriate for a historic computer.
>>
>> A lot depends on the question, what do we actually prefer today: Keeping
>> the historic machine alive, or any 68060 machine that has decent video
>> and runs SMSQ/E?
> 
> That's why I always suggested a 800x600 SVGA mode to replace the 1024x512
> one... Granted, you loose 44288 pixels, but 800x600 is totally decent and
> workable (under both SMSQ/E and Linux), and won't require any additional
> VRAM, "just" needing a reprogramming of the FPGA(s) (or so is my wild
> guess).

Those are small PLDs, optimized almost to the last gate, not FPGAs, and
800x600 is not doable.

I would find an answer to my original question interesting.
___
QL-Users Mailing List


Re: [Ql-Users] Q60 + OSSC

2020-01-15 Thread Peter Graf via Ql-Users
Thierry Godefroy wrote:
> In fact, I found out today that by increasing the sample rate to 1260 (from
> the 1200 I used so far) on the OSSC, I could get it to output a 1024x512
> (without scan doubling) or 2048x1024 (with it) resolution in the 480p HDMI
> signal format... and the good news is that the monitor accepts it !

What does the OSSC do then...

a) scale 512 to 480 vertical pixels?
b) somehow make the monitor display a 512 pixel signal?
c) just output 480 pixels, and 32 lines are lost?

>> I have been generating 1024x768 @ 60 Hz DVI/HDMI directly from $5 FPGA
>> with only moderate overclocking, maybe that leads to a better Q60
>> solution one day.
> 
> Very interesting, since the best solution would indeed be to gain a
> standard resolution output on the Q60.

My personal preference would be a solution that includes more VRAM, so
it is not interpolated, but an actually usable resolution.

Besides lack of time and the BGA soldering issue, I remain unsure if
such a massive board modification is appropriate for a historic computer.

A lot depends on the question, what do we actually prefer today: Keeping
the historic machine alive, or any 68060 machine that has decent video
and runs SMSQ/E?

>> At the moment I still struggle with manual BGA soldering.
> 
> I never tried that myself... There are a few interesting videos on
> Youtube about it, in particular this one:
> https://www.youtube.com/watch?v=L8EWqWj2srg

Using a hot air gun like in that video looks even more difficult than
the IR lamp I'm experimenting with.

All the best
Peter
___
QL-Users Mailing List


[Ql-Users] Q60 + OSSC

2020-01-13 Thread Peter Graf via Ql-Users
Thierry Godefroy wrote:

> Here are two new photos (full resolution, untouched: 30Mb each !) in DNG
> format, with and without scan lines doubling:
> http://qdos.free.fr/images/Q60-1960x1024.dng

Many thanks for taking a highres picture. It is nice to get the screen
filled, still single pixels can not be distinguished in every area. The
picture is significantly clearer on my 1024x768 monitor using the "black
bar" CPLD workaround. Hard to tell what I'd actually prefer, unless I try.

I have been generating 1024x768 @ 60 Hz DVI/HDMI directly from $5 FPGA
with only moderate overclocking, maybe that leads to a better Q60
solution one day. At the moment I still struggle with manual BGA soldering.
___
QL-Users Mailing List


Re: [Ql-Users] FGPA Anyone (Mister)

2020-01-13 Thread Peter Graf via Ql-Users
Marcel Kilgus wrote:
> Daniel Baum via Ql-Users wrote:
>> I'm afraid your core doesn't seem to work on my Mister (or I've messed up
>> somehow). I get a black screen with a white Minerva logo in the bottom
>> right corner, which appears to be gradually overwritten with more blackness.
>> I wonder if it's the problem that some cores have with 128MB SDRAM cards?
> 
> When I did this thing there were no 128MB cards, so this could very
> well be it, yes. Will have to see what's different with them.

Maybe just an extra address or chip select line that needs a fixed level?
___
QL-Users Mailing List


Re: [Ql-Users] FGPA Anyone (Mister)

2020-01-13 Thread Peter Graf via Ql-Users
Thierry Godefroy wrote:
> I don't want to undermine your (nifty) project or discourage you to
> pursue it, but I recently found a solution for hooking my QL and
> compatible computers (including the Thor XVI and the Q60), to a LCD
> monitor (as long as it got an HDMI input).
> 
> See it here:
> http://qdos.free.fr/monitors.html

Thanks for trying it with the Q60. If it nicely converts the Q60 signal,
that would be a big point despite the very high price.

Is the native resolution of your monitor 1920x1080?

The published Q60 screen appears a little blurred, but that might be a
matter of taking the photo. A close-up would be interesting.
___
QL-Users Mailing List


Re: [Ql-Users] QL-VGA

2020-01-09 Thread Peter Graf via Ql-Users
Norman Dunbar via Ql-Users wrote:
> I get that it's a software description of some hardware.

Not software. It is simply a hardware description, and the result is
pure hardware, i.e. flipflops, gates, wires. You can as well describe he
same hardware in a schematic rather than text.

It is important to understand that no emulation is involved and there is
no difference to other logic chips, except that an FPGA can be
re-configured. Like GALs, just more complex.

>From the same hardware description, is is also possible to manufacture
customized chips, called ASICs, which have a fixed logic.
___
QL-Users Mailing List


[Ql-Users] The Pawn adventure with graphics on the Q68

2019-11-17 Thread Peter Graf via Ql-Users
Hi,

just in case not everyone is on the QL forum, there is an exciting new
software development underway. "The Pawn"  and other "Magnetic Scroll"
games are back. And this time not just text but with graphics! The first
supported machine is the Q68, executables are already downloadable, on
page 3:

https://qlforum.co.uk/viewtopic.php?f=3=3033

Work for other platforms, even the BBQL, is ongoing. Definitely worth a
look, impressive!

Peter
___
QL-Users Mailing List


Re: [Ql-Users] QLTools - 2.15.5 available

2019-02-04 Thread Peter Graf via Ql-Users
Hi Norm,

> One of the reasons I did some work was a recent almost total loss of over 300 
> floppies going back many years.

Oh my. That sounds similiar to my Q60 harddisk loss long ago.

> I have qxltools on my laptop but haven't looked at it for ages, I think I had 
> problems compiling it - but I can't remember. It might well be in line for 
> some tittivation!

Sounds good. I could compile qxltools, but that was long ago. My concern
are image sizes over 16 MB and some strange characters in the
commandline output.

All the best
Peter
___
QL-Users Mailing List


Re: [Ql-Users] QLTools - 2.15.5 available

2019-02-02 Thread Peter Graf via Ql-Users
Norman Dunbar via Ql-Users wrote:
> Revision 2.15.5
> 
> [...]
> 
> If you enjoy using this half as much as I've enjoyed amending it, then 
> I've had twice as much fun as you! :o)

That's great work! But like many, I went from floppy images to harddisk
images to be honest. Most native machines now support SD cards as
removable media.

So what I have to use for the commandline is "qxltool" rather than
"qltools". Is there any chance that "qxltool" also receives some
maintainance?

All the best
Peter
___
QL-Users Mailing List


Re: [Ql-Users] OT new 68k Core

2018-11-12 Thread Peter Graf via Ql-Users
desin via Ql-Users wrote:
> 
> FX CAST cycle accurate Atari ST FPGA core
> 
> http://www.atari-forum.com/viewtopic.php?f=117=34555
> and
> http://atari-forum.com/viewtopic.php?f=28=34554

I don't find this off-topic at all. The logic seems to include a new
68000 CPU core, which is relevant for QL hardware.

The core seems to be a cycle-accurate 68000 CPU, which could allow to
implement a GoldCard on FPGA without repeating the difficult software
timing adjustments for QL network and Microdrives.

The 68000 CPU core used inside the Q68 is not cycle-accurate. For speed
reasons this can be nice, like the single-cycle multiplier. But whenever
there are timing loops, a cycle-accurate implementation helps a lot.

All the best
Peter
___
QL-Users Mailing List


Re: [Ql-Users] QED v2.01 released!

2018-09-25 Thread Peter Graf via Ql-Users
Jan Bredenbeek via Ql-Users wrote:
>  I'm very pleased to present you release 2.01 of QED, my ever popular text
> editor!
> 
> This release comes exactly 30 years after version 1.01, which has been
> included in many QL software distributions.

Awesome! Many thanks, Jan!
___
QL-Users Mailing List


Re: [Ql-Users] BouQLder Qlash source code

2018-05-26 Thread Peter Graf via Ql-Users
Hi Wolfgang,

> the source code for BouQLder Qlash is now available from my site.

Amazing work. And a lot of comments. I like this one:

"Normally, a sound is only played if the previous one is finished.
An explosion, though, is always played" :-D

Thank you very much
Peter
___
QL-Users Mailing List


Re: [Ql-Users] BouQLder Qlash

2018-05-06 Thread Peter Graf via Ql-Users
Wolf via Ql-Users wrote:

> thereTs a new game on my site called BouQLder Qlash.
> It's an an arcade game inspired by an old 8 bit game called Boulderdash.
> I programmed it initially to showase some of the capabilities of the Q68.

Awesome!!! Looks like the first QL arcade game of this century! You make
the impossible possible ;)

Many thanks, great work!
Peter
___
QL-Users Mailing List


Re: [Ql-Users] Q40 and Q60 video controller for flatscreen monitors

2018-05-01 Thread Peter Graf via Ql-Users
Am 01.05.2018 um 20:55 schrieb Thierry Godefroy via Ql-Users:
> On Tue, 1 May 2018 19:26:56 +0200, Peter Graf via Ql-Users wrote:
> 
>> Most flatscreens misunderstand the signal as 800x600, leading to bad
>> interpolation.
> 
> Among the 3 LCD monitors I own, only the latest is able to (badly) sync
> the Q60 video signal and it does as if it would be a 640x480 VGA mode
> with 38.3KHz horizontal and 71.4Hz vertical frequencies, so the sampling
> of the pixels is extremely bad, and it fails to display the last 32
> lines...
> 
> Interestingly, my last functionning CRT monitor, that displays the Q60
> mode just fine (thanks to the 100% analogous processing of the signal),
> also reports a 640x480 38KHz/71Hz mode.

Sorry I wasn't precise. I was not referring to the original signal, but
the general issue with 1024x512, after improving timings for flatscreen
already. I generated more suitable 1024x512 signals (with relaxed
front/back porch timings) that are accepted but misunderstood.

Peter
___
QL-Users Mailing List


Re: [Ql-Users] Q40 and Q60 video controller for flatscreen monitors

2018-05-01 Thread Peter Graf via Ql-Users
Dave Park via Ql-Users wrote:

> What are the frames per second and number of lines in the image?

Originally 72 Hz, 512 visible lines.

> What 'legal' signal is it most similar to?

At design time it was fine to use any legal resoltion of a multisync CRT
monitor. The idea was to stay at the QL-style 2:1 ratio on 4:3 screen,
epscially for the QL modes 4 and 8.

Most flatscreens misunderstand the signal as 800x600, leading to bad
interpolation.

> Is it possible to alter the frame rate

Yes I did that, as I wrote.

> and/or to supply a pixel clock signal?

Yes, but it is at the very maximum. Otherwise I would of course have
increased it already.

> This could open up the option of DVI conversion. (I have never
> owned a QX0 and don't know if it uses a card or custom logic.)

There is a slight chance to generate a pseudo FullHD signal, but only at
unusually low frame rate. I keep looking at that, but it is difficult,
logic was already optimized extremely to fit the chip. And not all
monitors would accept it.

> I'm just trying to understand the problem and why the LCD monitor won't
> sync the nonstandard signal.

Some do sync, but usually blur the picture by sampling 800 points on a
1024 horizontal line.

> If it's just one aspect of the signal it may
> be easily fixable and retain full screen display.

Not easily fixable, I would have done so.

Peter
___
QL-Users Mailing List


[Ql-Users] Q40 and Q60 video controller for flatscreen monitors

2018-05-01 Thread Peter Graf via Ql-Users
Hello,

I have developed an alternative video controller for Q40 and Q60:

http://qlforum.co.uk/viewtopic.php?f=2=2434

All the best
Peter
___
QL-Users Mailing List


Re: [Ql-Users] SMSQ/E 3.33

2018-04-30 Thread Peter Graf via Ql-Users
Hi,

> But there are some confusing aspects about the Q68 files.
> Both count 350.000 bytes, one .SYS and one .WIN.
> When Viewed they look the same. Should the .WIN not be a valid QLWA file  
> containing the .sys?

Both are wrong and can not be used by the Q68 Loader without changes.

There should only be the .WIN Container and it should be 1 MB in size.
(The .SYS File should be *inside* that container.)

Peter
___
QL-Users Mailing List

Re: [Ql-Users] Probleme mit smsq_q40_boot_make_bas

2018-04-30 Thread Peter Graf via Ql-Users
Sorry that message was supposed to be private.
___
QL-Users Mailing List


[Ql-Users] Probleme mit smsq_q40_boot_make_bas

2018-04-30 Thread Peter Graf via Ql-Users
Hi Wolfgang,

ich benutze das .WIN Archiv der SMSQ/E Sourcen.

1. smsq_q40_boot_make_bas führt menuconfig nicht sichtbar aus, ziemlich
verwirrend, da man nicht weiss ob und woher er die Konfiguration dann nimmt.

2. Zeile 760 gibt ein "not found", weil komischerweise ofile$ seinen
Wert verloren hat.

Könnte man gzip, menu_rext und menuconfig nicht in das WIN File legen?

LG Peter
___
QL-Users Mailing List

Re: [Ql-Users] SMSQ/E 3.33

2018-04-29 Thread Peter Graf via Ql-Users
Hi Wolfgang,

fantastic work, many thanks!

Now all QL hardware platforms QL, GC, SGC, Q40, Q60 and Q68 share the
same, stable filesystem on SDHC cards. And they can exchange it with
emulators on the same medium.

This was my original hope and vision, when I first started with SD cards
on the SGC parallel port and Qx0, first based on mtools, later adapting
the Steinkopf drivers, later the QL-SD interface with Qubide format,
which then again was used for the first steps on the Q68, leading to
QLWA support for all hardware in the end.

I could only pioneer FAT32 and the basics of such drivers, and I'm glad
that I did. But Wolfgang made everything so much more complete and well
integrated. The QL world owes him a big thanks!

All the best
Peter



Am 29.04.2018 um 11:40 schrieb Wolf via Ql-Users:
> Hi all,
> 
> SMSQ/E 3.33 is out, get it as usual from
> www.wlenerz.com/smsqe
> 
> What's new in this version :
> 
> Final bugfix for LRESPR in procedures (means everybody should upgrade)
> Better QL networking.
> Gold card is configured not to use ABC keyboard.
> Improvements in standard QL EE.
> Q68 & SMSQmulator better  handling.
> 
> The sources for the stand-alone TK II are included in the SMSQ/E sources.
> Moreover, whilst they aren't really part of SMSQE, the new QL-SD drivers 
> are built on the basis of the SMSQ/E "dv3" driver acihtecture, so their 
> sources are also included in the SMSQ/E sources (remember, the compiled 
> drivers are at wlenerz.com/qlsd).
> 
> If you have a Qx0 machine and access to an EPROM burner, this may be of 
> interest to you : The Qx0 may now have a compressed SMSQ/E so newer 
> versions thereof fit in the standard EPROMs. There is a certain process 
> involved in making these EPROMs - but it is clealy described in the 
> "smsq_q40_boot_doc" or "smsq_q40_boot_txt" files in the SMSQ/E sources.
> 
> Finally, Q68 has better handling of some slower SDHC cards. Also, and 
> that is an officially unofficial and undocumented feature, the Q68 may 
> also be able to read most older SD (not SDHC) cards. However, make sure 
> that this actually works with your cards before using them in earnest. 
> Offficially, the Q68 still only supports SDHC cards.
> 
> Have fun!
> ___
> QL-Users Mailing List
___
QL-Users Mailing List


[Ql-Users] QL Video Card?

2018-03-29 Thread Peter Graf via Ql-Users
Am 29.03.2018 um 22:59 schrieb Marcel Kilgus via Ql-Users:
>> (By the way, I wish Stuart had finished his QL Graphics Card, 
>> because all the video converters I tried with my QLs suck.)
> 
> Yes, this is true. That's the reason I have built a prototype of a
> bus-snooper that mirrors the QL screen on an HDMI monitor, but... damn
> it, now that you know I will never finish it :-)

Believe it or not, but when I wrote my remark this noon, I was actually
thinking "that could be something for Marcel Kilgus" now that he started
playing with FPGA. Really.

My guess is that you'd use an FPGA with >=32 KB RAM, so why bus-snooping
and not fully replace the video area? Just to keep the original video
output alive?

How would you work around the HDMI licensing costs issue?

Personally, I still prefer VGA, because I also have some older monitors
and converting VGA to HDMI can be done by small cheap dongles.

Peter
___
QL-Users Mailing List


Re: [Ql-Users] QL-SD news

2018-03-29 Thread Peter Graf via Ql-Users
Am 30.03.2018 um 00:47 schrieb Marcel Kilgus via Ql-Users:
> Peter Graf via Ql-Users wrote:
>> Did you test your logic changes with a non-Tetroid GC inside a QL where
>> the original logic did *not* work reliably?
>>
>> I'm asking, because IIRC you reported total failure of the original
>> logic with the Tetroid GC, while my experience was, that non-Tetroid GC
>> always basically worked, just not reliably in some QLs.
> 
> As far as I could gather in my limited tests, INGOT 5 never worked
> (which includes the Tetroid) and INGOT 6 worked or at least mostly
> worked.

That makes me a little sceptic, because I have one labelled "INGOT 5"
which worked (with the original driver and not fully reliable).

>> As for the daughter board, why do you want to re-design it?
> 
> Using the push-to-eject style daughter boards is a lot cheaper and
> easier to do than your original design. 

The card socket I used was around 2 € the last time I looked - no idea
why it should be hard to solder. Well, matter of taste.

> Besides, I don't have your original designs ;)

There is also the option to ask ;)

All the best
Peter
___
QL-Users Mailing List

Re: [Ql-Users] QL-SD news

2018-03-29 Thread Peter Graf via Ql-Users
Am 29.03.2018 um 23:29 schrieb Marcel Kilgus via Ql-Users:
> Speaking of only announcing stuff that basically already works, I have
> made huge progress regarding my work on QL-SD that I was going to
> write about today anyway:
> 
> https://www.kilgus.net/2018/03/29/ql-sd-news/

Must have been a lot of work. Let's hope there will be no further
issues, as there is quite a number of combinations to test. By the way,
interesting to hear that you prefer my original idea of an internal
version.

Did you test your logic changes with a non-Tetroid GC inside a QL where
the original logic did *not* work reliably?

I'm asking, because IIRC you reported total failure of the original
logic with the Tetroid GC, while my experience was, that non-Tetroid GC
always basically worked, just not reliably in some QLs. That would mean
conclusions from Tetroid to non-Tetroid is not possible.

As for the daughter board, why do you want to re-design it?

Will you upload your logic changes to the QL-SD section of Dilwyn's site?

Good luck,
Peter
___
QL-Users Mailing List


Re: [Ql-Users] Stuart Honeyball

2018-03-29 Thread Peter Graf via Ql-Users
Am 29.03.2018 um 20:13 schrieb Darren Branagh via Ql-Users:
> Dont forget he also designed the ZX Spectrum issue 1 PCB by hand.

And approximately 16000 of these machines were produced!

Does anyone know how many GoldCards were sold?

Peter
___
QL-Users Mailing List


Re: [Ql-Users] Quanta eMag

2018-03-15 Thread Peter Graf via Ql-Users
The printed QUANTA magazine for December/January arrived here today.

Derek Stewart via Ql-Users wrote:
> Hi,
> 
> Has anyone received the recent Quanta eMags, the last one I received in 
> October/November 2017. My subscription is in date.
> 
> I tried to email John Southern, but no reply, where he asked me to do an 
> article on the Q68.
> 
> Is Quanta still running?
___
QL-Users Mailing List


Re: [Ql-Users] Sjef vd Molengraaf

2018-03-09 Thread Peter Graf via Ql-Users
This is very sad news indeed. At Eindhoven I also showed the first Q40
before it had any operating system, and later the first public
appearance with QDOS Classic. It was there where Tony Tebby approved my
machine and agreed to port SMSQ/E. The Eindhoven meetings in the middle
between England and Germany were classic events that will long be
remembered. Thank you Sjef van de Molengraaf!


Bob Spelten via Ql-Users wrote:
> 
> I am sad to inform you all that Sjef van de Molengraaf passed away earlier  
> this week at the age of 73.
> As long time secretary of the Dutch SIN_QL_AIR foundation he will be  
> remembered by many international QL'ers. He was the driving force behind  
> many great Eindhoven meetings during the 90's and later, until they ended  
> in October 2008.
> He seldom posted on this list but it kept him informed of what was going  
> on in the QL community.
> 
> Our thoughts are with his family.
> 
> Bob
___
QL-Users Mailing List


Re: [Ql-Users] Quanta eMag

2018-03-09 Thread Peter Graf via Ql-Users
Hi Derek,

I have the same problem with the magazines. I thought it was because I
could not pay QUANTA subscription for some time. QUANTA had difficulties
to tell their bank account information. I paid in January.

Maybe it is because of Lee Privett passing, which we all understand.

All the best
Peter



Am 09.03.2018 um 10:23 schrieb Derek Stewart via Ql-Users:
> Hi,
> 
> Has anyone received the recent Quanta eMags, the last one I received in 
> October/November 2017. My subscription is in date.
> 
> I tried to email John Southern, but no reply, where he asked me to do an 
> article on the Q68.
> 
> Is Quanta still running?
___
QL-Users Mailing List


Re: [Ql-Users] Q68 Baud

2018-01-21 Thread Peter Graf via Ql-Users
Hi Fabrizio,

> I have done a sufficient number of experiment in copying and executing 
> files over the sernet@230400 to say that it is working.

I'm glad it does, although SERNET alone can not prove the SER-USB
adaptor handles 230 kBaud reliably in general. The problems usually pop
up when you have no protocol splitting long transfers it into smaller
chunks.

> I copied also some files over the net, bigger than 1Mb, and then 
> compared byte by byte. I would like to say that @230400 sernet should 
> work:-).

Thank you for testing and reporting.

> The cable I used is coming originally from Laplink package and it is 
> clearly visible that the cable construction quality is excellent, the 
> usb/ser adapter is a Digitus one, the "PC" is a Mac Book pro using Win10 
> with Parallels...and finally QPC.

When I was testing USB-SER adaptors, it was PC to PC. It could be that
not having USB-SER adaptors on _both_ sides improves chances. Also I
seem to remeber that the "good" one I found back then was also Digitus.

By the way, did anyone have success with SERNET on Qemulator?

Peter
___
QL-Users Mailing List


Re: [Ql-Users] Q68 Baud

2018-01-20 Thread Peter Graf via Ql-Users
My experience is that internal SER cards for PC tend to work reliably at
up to 230 kBaud without handshake, while most USB-SER coverters don't.

Usually you notice it only during long file transfers.

Am 21.01.2018 um 00:11 schrieb Dave Park via Ql-Users:
> Once you're up into 230k territory, the quality of the cable starts making
> an extraordinary difference, even if there is UART support for that speed.
> 
> On Sat, Jan 20, 2018 at 3:25 PM, Peter Graf via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
> 
>> Hi Fabrizio,
>>
>>> configuring the driver in Win10 there are available different predefined
>>> speeds, including 460800, so I assume it should work at least from PC
>> side.
>>
>> I know, but that tells nothing about what the adaptor can physically
>> hanlde. I have a lot of experience with that, unfortunately. Nine out of
>> ten adaptors which allow to select such high speeds, can't even handle
>> 230 kBaud PC to PC reliably.
>>
>> Peter
>> ___
>> QL-Users Mailing List
___
QL-Users Mailing List


Re: [Ql-Users] Q68 Baud

2018-01-20 Thread Peter Graf via Ql-Users
Hi Fabrizio,

> configuring the driver in Win10 there are available different predefined 
> speeds, including 460800, so I assume it should work at least from PC side.

I know, but that tells nothing about what the adaptor can physically
hanlde. I have a lot of experience with that, unfortunately. Nine out of
ten adaptors which allow to select such high speeds, can't even handle
230 kBaud PC to PC reliably.

Peter
___
QL-Users Mailing List


Re: [Ql-Users] Q68 Baud

2018-01-20 Thread Peter Graf via Ql-Users
Hi Fabrizio,

> Now playing with SMSQ/E sources, according Wolfgang suggestion (Thanks)

How do you come to the idea your SER-USB adaptor supports 460 kBaud,
even PC to PC?

The required RS-232 line drivers are very seldom!
Peter

___
QL-Users Mailing List


Re: [Ql-Users] Q68 Baud

2018-01-20 Thread Peter Graf via Ql-Users
Hi Fabrizio,

> Finally what is the theoretically max ser speed of the Q68 is?

460 kBaud for the hardware itself (UART and RS-232 driver). But for the
overall system, max. 115 kBaud is specified in the Manual. Beyond that
it has not been sufficiently tested.

Please note that many USB-SER converters for PC start getting unreliable
at 230 kBaud already.

Peter
___
QL-Users Mailing List


Re: [Ql-Users] Some QL Newbie Questions: Modern video and storage upgrades for QL

2018-01-06 Thread Peter Graf via Ql-Users
Hi Michael,

> What is the easiest way to connect a QL to a modern VGA or HDMI monitor?  

The only converters which work for me at all, are the GBS-8220 and
similar. These are VGA converters. I find picture quality poor compared
to a suitable CRT monitor, but at least I can work.

All my attempts with HDMI converters failed on my three QLs, although I
tried several SCART cable wirings. The best I could get was picture
going on and off all the time. Others have reported success.

> Are there any servers that run on a PC that act as a file server to the QL 
> over the serial port that could be used in place of floppy/CF/SD hardware?

In theory, you could run a PC emulator which accesses those media and
connect your QL via a nullmodem cable and the SERNET software.

Be aware the QL serial port is extremely slow. For example reading a
complete floppy disk would take half an hour this way (if you have luck
and there is no reliability problem).

Peter
___
QL-Users Mailing List


Re: [Ql-Users] New document on DV3 drivers

2017-12-29 Thread Peter Graf via Ql-Users
Wolf via Ql-Users wrote:
> I've added a small technical explanation of DV3 drivers for SMSQE to the 
> additional info and data section on the SMSQE site.

Which is here:

http://www.wlenerz.com/smsqe/DV3_Device_Drivers.zip

Good stuff, thanks Wolfgang!

Peter

___
QL-Users Mailing List


Re: [Ql-Users] How to reach QUANTA membership secretary?

2017-12-28 Thread Peter Graf via Ql-Users
Hi John,

did you find the bank account information? What shall I do?

All the best
Peter

Am 28.11.2017 um 15:58 schrieb John Southern via Ql-Users:
> Hi Peter,
> 
> I will dig out the details of the bank account and forward them on to you.
> 
> Regards
> John
> 
> On 26 Nov 2017 1:54 p.m., "Peter Graf via Ql-Users" <
> ql-users@lists.q-v-d.com> wrote:
> 
>> Hi,
>>
>> I'm trying to pay my QUANTA subscription without Paypal. In the papers I
>> received, bank transfer to QUANTA is offered, but the required account
>> information was not included.
>>
>> I found no email address of the QUANTA membership secretary, neither in
>> the papers, nor on the website. And using the form on the QUANTA website
>> did not result in a response.
>>
>> What shall I do, write a postal letter, asking for the required
>> information? Or is there an easier way?
>>
>> All the best
>> Peter
>> ___
>> QL-Users Mailing List
>>
> ___
> QL-Users Mailing List
___
QL-Users Mailing List


Re: [Ql-Users] Mode 33 to 32

2017-12-16 Thread Peter Graf via Ql-Users
The least significant of the 6 green bits.

Am 16.12.2017 um 19:12 schrieb pjwitte via Ql-Users:
> Sorry for yanking your chain again so soon but, on going the other 
> way, ie from mode 32 to 33, what is the best value for W? g6, 0, 1..?
> 
> Per
> 
> On 16/12/2017 18:13, pjwitte via Ql-Users wrote:
>> Aah! Perfect! Thanks Marcel, youre a star!
>>
>> So in fact I interpreted the input wrong. It should have been:
>>
>> GGGggRRR rrBBBbbW <- input
>>
>> and
>> ggWBBBbb RRRrrGGG -> output
>>
>> Seems so obvious now ;)
>>
>> Per
>>
>> On 16/12/2017 15:30, Marcel Kilgus via Ql-Users wrote:
>>> 320 c$ = c$(4 to 5) & c$(16) & c$(11 to 15) & c$(6 to 10) & c$(1 to 3)
>>
>>
>> ___
>> QL-Users Mailing List
>>
>>
>>
> 
> ___
> QL-Users Mailing List
___
QL-Users Mailing List


Re: [Ql-Users] Mode 33 to 32

2017-12-16 Thread Peter Graf via Ql-Users
pjwitte via Ql-Users wrote:
> I havent tested your suggestion yet, Wolfgang, but what I found so far 
> was that gggbrgg0 appears (to my eye) to look cleaner than 
> gggbrggW. Is that so wrong? ;)

It is right, because gggbrggW has the W at the wrong bit. It
must be the least significant green, which is what Wolfgang an me wrote.

___
QL-Users Mailing List


Re: [Ql-Users] Mode 33 to 32

2017-12-16 Thread Peter Graf via Ql-Users
But the same as my proposal :)

Wolf via Ql-Users wrote:
> No, not the same as %gggbrggW, as suggested in the original post.
> 
> Wolfgang
> 
> On 16/12/2017 10:18, Peter Graf via Ql-Users wrote:
>> Wolfgang Lenerz via Ql-Users wrote:
>>> I'd do it this way
>>>
>>> %ggWbrggg
>>
>> Which is the same :)

___
QL-Users Mailing List


Re: [Ql-Users] Mode 33 to 32

2017-12-16 Thread Peter Graf via Ql-Users
Wolfgang Lenerz via Ql-Users wrote:
> I'd do it this way
> 
> %ggWbrggg

Which is the same :)
___
QL-Users Mailing List


Re: [Ql-Users] Mode 33 to 32

2017-12-15 Thread Peter Graf via Ql-Users
> What do I do with 'w' in either case for best results?

I would just use the RGB0 bit of mode 33 as G0 Bit of mode 32, which is
what you probably do already.

There is no perfect translation, since mode 33 has 64 clean grey levels,
while mode 32 has only 32. There will be a minimal green tint in mode 32
where RGB0 of mode 33 was set, but almost not noticeable.

___
QL-Users Mailing List


Re: [Ql-Users] SMSQE 3.32

2017-12-10 Thread Peter Graf via Ql-Users
Tobias Fröschle via Ql-Users wrote:
> That’s really great. Eager to try an IDE-to-SD Adapter and see how direct 
> data exchange will work.

The adaptor I use is called "Kalea Informatique Adapter IDE 3,5 Zoll 40
Pins auf SD-Card", available off the shelf from from amazon.

I could directly use a card from the Q68. The new DISP_MODE command for
Qx0 made it even easier, because the first 4 modes are the same. But
don't forget a backup of your card, like I did :(

Let us know your experience!
Peter


___
QL-Users Mailing List

Re: [Ql-Users] SMSQE 3.32

2017-12-10 Thread Peter Graf via Ql-Users
Wolf via Ql-Users wrote:
> - Filesystem for QUBide drives.

This is a very nice feature especially for native hardware, allowing
direct data exchange between Q68 and QL with QL-SD.

> - Q40/Q60:
> It is now possible to use IDE hard disks formatted with FAT32 and contining
> QXL.WIN "drives"

A little background info: I was originally planning to design a Q68
compatible SDHC card interface for the Q40/Q60. But driver and hardware
use SPI mode, which limits theoretical speed to 3 MB/s. On a Q60 that
would not be optimal - even practical speed of a tradititional harddisk
via the ISA bus was higher.

It turned out that IDE-SD Adapters worked relatively well with SDHC
cards, so I asked Wolfgang, why not use IDE instead. Saving the time and
cost for hardware development and getting better performance.

However these adaptors should be used with caution. Firstly, I could
only find adaptors which expect to be IDE "master" and are not
jumperable to "slave". This can be an ugly limitation, if you only have
one ISA I/O card and it is only for two IDE drives. Personally, I have
an ISA card for 4 IDE drives, but these days not easy to find anymore.

Secondly, I have experienced severe problems installing "ShoeString"
Linux. The original Q60 Linux installed, but did not "like" a "slave"
present on the same IDE bus as the IDE-SD adaptor (similar issue with
compact flash). It could be that Linux tries to use advanced ATA
commands which are well supported by harddisks, but maybe not on those
adaptors.

If only SMSQ/E is used, I did not notice problems with a slave present
on the same bus. However, testing was only minimal.

Important: You can not use Tony Tebby's mkpart program to partition
FAT32 IDE drives. Two major reasons:

1. The standard partition table was Atari style, but is DOS style for
FAT32.

2. In order to make a card readable on x86 PC, the Q40/Q60 must swap all
bytes on the ISA bus for DOS style IDE devices. This is because of the
ugly little-endian number representation on x86 PCs. 68K represents
numbers as they are normally read, and so does the traditional IDE
driver of the Q40/Q60.

Great job, Wolfgang!!!

Peter
___
QL-Users Mailing List


[Ql-Users] How to reach QUANTA membership secretary?

2017-11-26 Thread Peter Graf via Ql-Users
Hi,

I'm trying to pay my QUANTA subscription without Paypal. In the papers I
received, bank transfer to QUANTA is offered, but the required account
information was not included.

I found no email address of the QUANTA membership secretary, neither in
the papers, nor on the website. And using the form on the QUANTA website
did not result in a response.

What shall I do, write a postal letter, asking for the required
information? Or is there an easier way?

All the best
Peter
___
QL-Users Mailing List


Re: [Ql-Users] SMSQ/E 3.31 Q40 no boot after configure

2017-11-13 Thread Peter Graf via Ql-Users
Hi Duncan,

> the version of menuconfig I have is 3.36 and is dated 2003.

Thank you. That's it! :) With menuconfig 3.36 it worked.

> The version of menuconfig on Dilwyn's site is 3.34

Found even 3.36 when I searched again. Maybe it is stored at more than
one location.

All the best
Peter
___
QL-Users Mailing List


[Ql-Users] SMSQ/E 3.31 Q40 no boot after configure

2017-11-12 Thread Peter Graf via Ql-Users
Hi,

the original SMSQ/E 3.31 Q40 boots here on my Q60/80 with LRESPR.

But if I do even the slightest configuration with MENUCONFIG, it crashes
on boot. Just language settings, nothing else.

Can anyone with Q60 reproduce this problem?

All the best
Peter
___
QL-Users Mailing List


Re: [Ql-Users] Q40 display mode

2017-11-11 Thread Peter Graf via Ql-Users
Am 11.11.2017 um 22:06 schrieb Derek via Ql-Users:
> I will check on my Q60 the DISP_TYPE values and report back tomorrow.

I looked already. Seems always 33.

Peter
___
QL-Users Mailing List


Re: [Ql-Users] Q40 display mode

2017-11-11 Thread Peter Graf via Ql-Users
Am 11.11.2017 um 17:58 schrieb Giorgio Garabello via Ql-Users:
> 64 – 24-bit colour mode (no hardware supports this at the time of writing)

Hmmm... was there _software_ support at the time of writing?

> DISP_TYPE
> The DISP_TYPE function is used to find the type of display. For the Q40,
> there are two values that may be returned.
> 0 Original ST QL emulator (this value is returned on QL based hardware).
> *1 16 bit colour mode.*

The Q40 supports both original QL hardware modes and 16 bit highcolour.
It depends on what you select.

Peter



___
QL-Users Mailing List

Re: [Ql-Users] Dock

2017-11-10 Thread Peter Graf via Ql-Users
Hi Wolfgang,

> Concerning dock, this is supposed to be a program run in the background.

I figured that, but started a second SBASIC and used LRUN from there -
which didn't work.

> Start with EX, not LRUN

That, plus QPRT v0.14 does the trick.

However, I'm still puzzled that the missing keyword from QPTR didn't
return an error, and that a BASIC program can crash the machine.

Thanks, really great idea. At least for my favorite 512x384 mode on the
Q68 it runs smoothly. Just need to create smaller icons...

Thanks,
Peter
___
QL-Users Mailing List


Re: [Ql-Users] Dock

2017-11-08 Thread Peter Graf via Ql-Users
François Van Emelen via Ql-Users wrote:
> RPTR is part of the pointer toolkit ‘qptr_rext’. Once loaded Dock does 
> what it is supposed to do.

Not here, same hang/crash. At least with the 'qptr_english_bin' from
Wolfgang's site.

Not sure it really is because of RPTR, but in one of my debug attempts
yesterday, the program seemed to get short before it, but never behind it.

Peter
___
QL-Users Mailing List

Re: [Ql-Users] Dock

2017-11-07 Thread Peter Graf via Ql-Users
Peter via Ql-Users: wrote:
>> I would have a look at the OUTLN and WINDOW commands a bit up from there
>> [...]
> 
> Wow, you are really an ace! Setting OUTLN to 1 pixel cures the RPTR
> crash. WINDOW can remain unchanged.

Not under all circumstances... something is definitly buggy.

And there seemed a difference between QPTR loaded or not loaded, but I
can't reproduce at the moment.

Peter
___
QL-Users Mailing List


Re: [Ql-Users] Dock

2017-11-07 Thread Peter Graf via Ql-Users
Hi Tobias,

> I would have a look at the OUTLN and WINDOW commands a bit up from there
> [...]

Wow, you are really an ace! Setting OUTLN to 1 pixel cures the RPTR
crash. WINDOW can remain unchanged.

However, an SBASIC command should not crash the machine by a wrong
parameter.

> Doesn't work here as well in QPC2 and SMSQ/E 3.30

Good to hear the Q68 is not at fault :)

Thanks!
Peter
___
QL-Users Mailing List


Re: [Ql-Users] Dock

2017-11-07 Thread Peter Graf via Ql-Users
Hi Fabrizio,

RPTR  does not seem to need QPTR, otherwise the keyword wouldn't exist.

Anyway if I load QPTR, "dock" hangs/crashes the same.

More ideas? Thanks,
Peter



Am 07.11.2017 um 21:35 schrieb Fabrizio Diversi via Ql-Users:
> Peter ,
> 
> dock is a nice program that use QPTR toolkit (RPTR), you can find the 
> toolkit manual on Dilwyn web site. It work nicely on SMSQmulator, QPC 
> and Q60.
> 
> Ciao
> 
> 
> Fabrizio
> 
> 
> On 07/11/2017 19:28, Peter Graf via Ql-Users wrote:
>> Hi,
>>
>> I try to run this nice looking "dock" for SMSQ/E:
>>
>> http://www.wlenerz.com/qlstuff/dock_bas.zip
>>
>> It seems to crash or hang at the RPTR command in line 1020, which I can
>> not find in the SMSQ/E Manual on Dilwyn's Website.
>>
>> Does anyone else use this program and can give me a hint?
>>
>> All the best
>> Peter
___
QL-Users Mailing List


[Ql-Users] Dock

2017-11-07 Thread Peter Graf via Ql-Users
Hi,

I try to run this nice looking "dock" for SMSQ/E:

http://www.wlenerz.com/qlstuff/dock_bas.zip

It seems to crash or hang at the RPTR command in line 1020, which I can
not find in the SMSQ/E Manual on Dilwyn's Website.

Does anyone else use this program and can give me a hint?

All the best
Peter
___
QL-Users Mailing List


Re: [Ql-Users] Possible bug in the (experimental) QubIDE feature of QXLWinReader

2017-10-31 Thread Peter Graf via Ql-Users
Hi Wolfgang,

> the new version of QxlwinReader is on my website.

Many thanks! If I had to vote for the "tool of the year", QxlwinReader
would be it! :)

Extraordinary useful for the development of the Q68! Without
QxlwinReader, there was always an emulator or Wxqt2/qltools involved
when transferring files to the Q68 over the internet.

QxlwinReader proofed much easier to use for me and saved lots of time.

Great work!
Peter
___
QL-Users Mailing List


Re: [Ql-Users] QL MODE 8 Flash Bit

2017-10-27 Thread Peter Graf via Ql-Users
Hi Jan,

> The flashing is up to and including the pixel which has the flash bit on
> to turn flash off.

Thanks for this precise info!

> I've tested this on a real QL and it looks like the blink frequency is
> 16/50th of a second which is a bit slower than the software-generated
> blinking of the window's cursor (12/50th second). So a complete blink
> cycle will be 32/50th second.

Thanks. I just measured exactly the same with a stop watch.

I alread have a hardware implementation now. Not just as easy when a
pixel really consists of 12 pixels...

I just noticed the work was in vain, because SMSQ/E does not seem to
support FLASH in MODE 8. At least not if I test with SBASIC.

All the best
Peter
___
QL-Users Mailing List


Re: [Ql-Users] QL MODE 8 Flash Bit

2017-10-27 Thread Peter Graf via Ql-Users
Hi Jan,

> It works in a serial fashion, much like the old Videotex/Prestel standard.
> When you set the flash bit on a pixel, the colour of that pixel is used
> as background flash colour for the rest of the line until another flash
> bit on the same line is encountered.
> E.g. when a pixel has red colour with flash on, the rest of the pixels
> on the line will flash between the original pixel colour and red until
> the next set flash bit.

The "until" is ambiguous. When that next pixel occurs, does it still use
the background colour of the previous pixels, or already the colour in
it's own colour bits?

Also, is there any exact info about the blink frequency?

> Hope you'll find this useful.

It is useful, thanks! But not yet sufficient for the implementation.

Peter
___
QL-Users Mailing List


[Ql-Users] QL MODE 8 Flash Bit

2017-10-27 Thread Peter Graf via Ql-Users
Hi,

today I noticed that my MODE 8 Flash Bit implementation in the Q68 was
never completed. It is 11 years ago that I designed the video
controller, and now I don't even remember how exactly the QL hardware
used that bit at all. Especially, I don't know how the background colour
for the flashing area is determined!

Could anyone enlighten me? Quick reply would be nice, release date
nearing quickly...

All the best, Peter
___
QL-Users Mailing List


Re: [Ql-Users] Stupid AND

2017-09-19 Thread Peter Graf via Ql-Users
Wolfgang Lenerz via Ql-Users wrote:
> Just a rant about the SBasic AND operator.
> 
> Suppose this:
> 
> 10 a=0
> 20 b=10
> 30 if (a<>0 AND b/a=5)
> 40   do_something
> 50 end if
> 
> Run it and what happens?
> 
> You get an "overflow" error at line 30.
> You get this error because it is trying to evaluate the second condition 
> (b/a) and failing as a=0 and you can't divide by 0.
> 
> BUT WHY IS IT TRYING TO EVALUATE THE SECOND CONDITION IN THE FIRST PLACE?

Maybe this wise language includes Chinese or Persian philosophy?

> The first condition (a<>0) is NOT met and so, in any other programming 
> language I use, the second condition isn't even tested, as the result 
> will be "false" anyway because of this.

IIRC other languages also do not _guarantee_ to stop evaluation after a
lefthand AND condition failed.

Peter
___
QL-Users Mailing List


Re: [Ql-Users] Q68 Advance Notice 2 - Pricing

2017-09-09 Thread Peter Graf via Ql-Users
Hi Gerhard,

>> 3. There can be no promise of ethernet software drivers, although
>>I would like them for myself, building upon my QLwIP project.
> 
> Tell me(us) more about your QLwIP project (no need of inventing diversity of 
> projects)

QLwIP is a combination of

- A QDOS native TCP/IP Stack
- QDOS native drivers for SER (SLIP) and ethernet (Q40 & Q60)
- Text mode Webbrowser
- Mail client (SMTP & POP3)
- Webserver

I did most of the work about 15 years ago and have publicly demonstrated
that QLwIP works, but never finished it to public release for various
reasons. If I find the time someday, I could adapt it to Q68 and SMSQ/E.
Since the Q68 ethernet hardware differs a lot from the Q40/Q60, this
driver part must be rewritten.

Also there are new difficulties, like the fact that most email providers
no longer offer unencrypted SMTP & POP3 access.

So, no promise.

Peter
___
QL-Users Mailing List


Re: [Ql-Users] Q68 Advance Notice 2 - Pricing

2017-09-09 Thread Peter Graf via Ql-Users
Hi all,

before placing orders, please take this into consideration:

1. The Q68 is not a high-end machine like the Q60 in terms of speed.
   If in doubt, please wait for benchmarks.

2. I developed the Q68 strictly as a hobby project, absolutely for free,
   and support will be only by communitly forum or mailing list.

3. There can be no promise of ethernet software drivers, although
   I would like them for myself, building upon my QLwIP project.

4. Documentation may come delayed, or in limited fashion.

All the best
Peter


Derek Stewart via Ql-Users wrote:
> Q68 Price List - Batch 1
> ---
> 
> Q68 board, 4Gb SDHC Card, SMSQ/E: £150.00
> Black Case: £20
> Belkin Black PS/2 spliter: £2.00
> 
> General Release date: 09/10/2017
> 
> 20 completed and tested Q68 boards, available.
> 
> Once this quantity is exceeded, I will order more Q68 PCBs to be 
> manufactured.
___
QL-Users Mailing List

Re: [Ql-Users] Q68 Advanced Notice

2017-09-02 Thread Peter Graf via Ql-Users
Derek Stewart via Ql-Users wrote:

> Q68 Advanced Notice
> ---
> [snip]

I hope to be able to comment more about the Q68 at a later time, right
now let me say thanks to...

... Laurence Reeves and Tony Firshman for releasing Minerva as free QL
operating system, motivating me to develop the Q68 at all

... Richard Zidlicky for bringing Minerva plus PS/2 driver to the Q68
and his great help debugging CPU cores

... Mark Swift for QDOS Classic, structured so nicely that even I could
port it to the Q68 in a single day

... Tobias Gubener for the CPU core the Q68 finally uses

... Adrian Ives for the QL-SD driver, initially used for Q68 mass storage

... Tony Tebby for relasing SMSQ/E as free software after all

... Wolfgang Lenerz for his outstanding achievement of porting SMSQ/E to
the Q68

... Wolfgang Lenerz again for very helpful tools, extra drivers and docs

... Derek Stewart for his courage and lots of work manufacturing the Q68
hardware and making it available for the public

All the best
Peter

___
QL-Users Mailing List


Re: [Ql-Users] QL-SD interface and SGC

2017-06-23 Thread Peter Graf via Ql-Users
Hi Andrea,

>> My guess is that replacing the QL motherboard could fix this issue.
>> Unfortunately, I have no Aurora system to try.
> 
> Is it possible to install QL-SD on Aurora?
> Although the ROM socket is different from that of the QL?

The Aurora has a jumper setting for standard QL ROMs. In that setting
QL-SD should work.

Peter
___
QL-Users Mailing List


Re: [Ql-Users] R: R: QxlwinReader

2017-06-17 Thread Peter Graf via Ql-Users
Davide wrote:

> Having had to transfer a full QL system based on SGC/Qubide to .win with 150
> Mb, using DD would have been quite a nightmare. 

Why should dd be a nightmare? Are you aware that dd means a utility
program, not floppies?

> [...]

> I understand the effort to write such sw might not be negligible, but a
> utility which could manage to read native Qubide hard disks on a PC and
> transfer files to a .win file (and maybe vicecersa) I think would be very
> useful.

If you have a PC with IDE port anyway, then where is the problem to use
dd to get the image?

Peter

___
QL-Users Mailing List


Re: [Ql-Users] QxlwinReader

2017-06-16 Thread Peter Graf via Ql-Users
Wolf wrote:
> A new version of QxlwinReader is available on my site, better handling 
> of Qubide image files.

For those like me who didn't find it quickly:

http://www.wlenerz.com/QLstuff/#qxlwinr

___
QL-Users Mailing List


Re: [Ql-Users] QxlwinReader

2017-06-10 Thread Peter Graf via Ql-Users
Wolf wrote:

> I've released QxlwinReader, a small java program that allows you to 
> read/write qxl.win type container files directly.
> 
> There is also experimental support for Qubide formatted ("BDI") 
> container files.

Excellent!

BTW it can delete subdirectrory trees in one go, which is very useful.

Peter

___
QL-Users Mailing List