Re: [Ql-Users] UDP driver for Q68 and TFTP programs

2021-01-07 Thread pgraf--- via Ql-Users
Hi Wolfgang,

> I've written a UDP (only) ethernet driver for the Q68, and a TFTP
> file exchange programs (for the Q68, emulators and also some TFTP
> server/client software for PCs/Macs).

Many thanks! Love running your TFTP server on my Q68 for file 
exchange with the PC and my second Q68. Especially that executables 
can be easily transferred using the XTcc flag is very comfortable.

Saves a lot of SD card handling for file transfer. And although QL 
network for the Q68 is nice, ethernet feels like a different league 
in terms of speed.

Can your TFTP server theoretically also run on Martin's ethernet/UDP 
driver?

All the best
Peter

___
QL-Users Mailing List


Re: [Ql-Users] For Sale

2020-11-11 Thread pgraf--- via Ql-Users
On 11 Nov 2020 at 1:17, Steve C. via Ql-Users wrote:

> Aurura was not easy to Google, and I'm still not certain that it is
> a QL clone?

Not directly like Q40, Q60 or Q68. Aurora always is an add-on to 
GoldCard or SuperGoldCard. So you need one of these also.

Peter

___
QL-Users Mailing List


Re: [Ql-Users] MODPlay

2020-11-11 Thread pgraf--- via Ql-Users
On 10 Nov 2020 at 20:21, Marcel Kilgus via Ql-Users wrote:

> I wrote a music player for the old Amiga MOD file format. Head over
> to
> https://www.kilgus.net/smsqe/modplay/ for the details.

I forgot the exact percentage of CPU overhead by the 20 kHz 
interrupt of the Q40, but I tested it below 10% at design time. 
Otherwise I'd not have simplified the design that way. It's unlikely 
that Tony Tebby implemented sound less efficiently than myself, so 
probably the 68040 is simply too slow for Mr. Del Nero's routines. 
Didn't have time to really look, but if the rest of his code is 
similarly efficient as his memcopy, that's no surprise.

Qsplayer also was a C program using the sampled sound system.

Peter

___
QL-Users Mailing List


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

2020-03-10 Thread pgraf--- via Ql-Users
Hi Jan,

> > > 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.
> >
> 
> From what I can see I have to remove the capacitors(?) in the PCB tracks to
> the socket, which is quite a challenge given their small size, the crowded
> PCB area and my aging eyes :-(

I wouldn't recommend to use the sound connector anyway. 

> So I have mounted the resistors and diode
> in the area for the expansion connector and used the ground hole on the
> reset connector for ground (I did not dare to use the ground hole on the
> expansion connector as it's very close to the +3.3V and a short-circuit is
> easily made.

Nice idea. Another ground point is the singular pin above the SDRAM 
IC.

> Anyway, it's working now... got about 30Kbit throughput between the Q68 and
> a BBQL with GC, which is about the expected rate given the fact that QLnet
> is half-duplex. SERnet between Q68 and PC is about twice as fast at 115200
> baud, but as I said it's easier to do bulk transfers by swapping SDHC
> cards. At least my BBQLs now have easy access to real mass-storage :-).

Glad it works for you. Only 30 Kbit sounds a bit low, was that with 
mass storage or ramdisk?

Peter

___
QL-Users Mailing List


Re: [Ql-Users] Q60 + OSSC

2020-01-16 Thread pgraf--- via Ql-Users
On 16 Jan 2020 at 0:43, Thierry Godefroy via Ql-Users wrote:

> > Those are small PLDs, optimized almost to the last gate, not FPGAs,
> > and 800x600 is not doable.
> 
> Surprising, since it's "just" a change in divisors/counters/
> frequencies, but if you say so (I'm certainly no expert in PLD/FPGA
> programming).

Maybe you can look at it this way: The video controller of the Q60 
squeezes _more_ functionality than a contemporary Lattice reference 
design, into a PLD with less than _half_ the resources. This came 
not only from manual optimization using every possible trick, but 
also at the cost of flexibility. I had to exploit constraints that 
are not given at 800 x 600. I clearly remember that I tried hard to 
implement 800x600 some time after flatscreens came up, and came to 
the conclusion there is absolutely no chance.

> > I would find an answer to my original question interesting.
> 
> As I already explained, the OSSC has brought to me the solution for
> the Q60 (and since a 800x600 mode is ruled out, I don't see any
> point in modifying it now).

Thanks for clarification. If the OSSC wasn't such an expensive, 
clumsy setup, I would also just say: Issue solved. Period.

It's very good that you published your experience - I would never 
spend the money without knowing that it actually works with the Q60. 
For the BBQL, I have a better HDMI solution, so I have no other use 
for an OSSC. If it has not happened yet, I would encourage you to 
post your result on the QL forum also.

> But you'd have to ask other Q40/Q60 owners about what they would
> prefer (i.e. the use of a scan converter (*), or a heavy modification
> of their Qx0 to output a higher resolution compatible with modern
> monitors).

Or a different board that would run with the 68060 pulled out of the 
Q60, hence my original question.

> (*) In fact, a "cut-down" OSSC (that would only be able to deal with
> the Q40/Q60 and QL video modes, and with just the VGA input and no
> LCD display, no remote) could be a cheaper and easier solution.

Of course. And also smaller, nicer, decently cased. If not for time 
shortage _plus_ other priorities even for the QL hobby, that would 
be an intersting project.

___
QL-Users Mailing List


Re: [Ql-Users] QLTools - 2.15.5 available

2019-02-05 Thread pgraf--- via Ql-Users
Hi Norm,

> > 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.
> 
> What problems do you have with 16MB files? I presume you mean that the 
> qxl.win file is over 16Mb, and it's not a problem of writing something 
> that big into a qxl.win?

Yes, I mean QLWA image sizes over 16 MB, not file sizes.

> I don't see any weirdness on the command line output though. I'm mainly 
> on Linux which might be helping.

More on the Windoze side here.

> Can you give me an example of how to reproduce the problem(s) you are 
> seeing? I've just created a 20 MB qxl.win with no problems. (So far!)

Unfortunately not right now, and my memory is vague. I think that 
all issues were gone with 16 MB and less. My next image size step 
was probably 32 MB, not just 20 MB.

It could be, that just recompiling the latest qxltool source with an 
up-to-date compiler and library makes the issues disappear.

Peter

___
QL-Users Mailing List


Re: [Ql-Users] Stuart Honeyball

2018-03-29 Thread pgraf--- via Ql-Users
On 29 Mar 2018 at 14:19, Marcel Kilgus via Ql-Users wrote:

> > I remember how proud I felt when Stuart Honeyball lent me an ear
> > about the 68020 processor, while I was still a QL nodbody. At that 
> > time, he was reluctant about an upgrade to the GoldCard, because 
> > (coming from the 68000 and the QXL's 68040) Stuart was not aware the 
> > 68020 had dynamic databus sizing. I talked with him about my working 
> > '020 wirewrap board, and how I patched QDOS so most of it worked 
> > with the '020. In the end, I could convince him, and it felt like I 
> > had given the SuperGoldCard a kick-off :)
> 
> Interesting story. I'm still a huge fan of the SGC, but could never
> afford it at the time.

I had the luck to buy my SGC after the price fell, but before it 
became interesting for collectors. I find the SGC a masterpiece, the 
best thing that ever plugged into an original QL mainboard!

I still have the mentioned wirewrap 68020 board. In it's first 
revision, it worked even before I got hands on the GoldCard. It was 
plugged into the QL's 68008 socket via IDC cable. Lacking own RAM, 
speed came only from cache, higher clock and faster CPU. Of course, 
GoldCard was faster, which made me start to to add RAM. That 
revision was never finished, because the SGC came, and later on 
rumors of Goldfire made me think of 68040 upward ;-)

> > That's what inspired me, and what I later did my own way, with the
> > Q40, Q60 and Q68. Now I somehow feel like "the only one left". 
> > Stuart was no longer active... but still...
> 
> Well, there's Nasta, I've got the impression he knows the QL better
> than its original designers, though he seems to be impaired by his own
> perfectionism.

Also let's not forget that living in Eastern or Western Europe made 
a big difference at the time Nasta announced his GoldFire. 

But mentioning "announced designs" versus "materialized designs" 
takes my thoughts right back to Stuart Honeyball. 

I remember a funny moment, when there was chat about the QL Graphics 
Card that Stuart had announced, but kept delaying. Someone said, 
right in his presence: "Was there ever an *announced* design of 
Stuart which *materialized*?" Stuart grew very silent...

I don't know about Stuart Honeyball's early hardware, but indeed it 
seems that he hardly talked about his large projects until they were 
practically finished.

(By the way, I wish Stuart had finished his QL Graphics Card, 
because all the video converters I tried with my QLs suck.)

Peter

___
QL-Users Mailing List


Re: [Ql-Users] Stuart Honeyball

2018-03-29 Thread pgraf--- via Ql-Users
On 29 Mar 2018 at 10:40, Dilwyn Jones via Ql-Users wrote:

> I regret to have to report that I heard this morning of the
> death of Stuart Honeyball of Miracle Systems.

When I read the subject "Stuart Honeyball" I somehow expected he'd 
attend a QL meeting, publish his memoirs, or anything, but not that.

Every loss of a QL legend is tragic, but this one hurts me deeply. 
It was always the hardware that attracted me to the QL, and before I 
could afford my own printed circuit boards, Stuart Honeyball was 
like a hero for me. To own a legendary GoldCard was almost more 
desirable than the QL itself.

I remember how proud I felt when Stuart Honeyball lent me an ear 
about the 68020 processor, while I was still a QL nodbody. At that 
time, he was reluctant about an upgrade to the GoldCard, because 
(coming from the 68000 and the QXL's 68040) Stuart was not aware the 
68020 had dynamic databus sizing. I talked with him about my working 
'020 wirewrap board, and how I patched QDOS so most of it worked 
with the '020. In the end, I could convince him, and it felt like I 
had given the SuperGoldCard a kick-off :)

In my QL times, Stuart Honeyball was the only person who brought QL 
systems which contained the "heart" of a computer, the 
microprocessor and its surroundings. The GC, SGC and QXL were not 
just peripherals. They were computers, except graphics.

That's what inspired me, and what I later did my own way, with the 
Q40, Q60 and Q68. Now I somehow feel like "the only one left". 
Stuart was no longer active... but still...

Having good hardware ideas is one thing. Actually finishing a 
computer, so people can buy it, is a different thing. Especially as 
a single person in the small QL scene. Stuart Honeyball did both. He 
did it great. We will always remember him!

Peter

___
QL-Users Mailing List


Re: [Ql-Users] Sjef vd Molengraaf

2018-03-15 Thread pgraf--- via Ql-Users
On 15 Mar 2018 at 11:21, Marcel Kilgus via Ql-Users wrote:

> Last weekend I was at the German ZX81/Spektrum meeting and that was
> very well visited (50 people or so) and was a reminiscence of the
> bigger QL events like Eindhoven in the past. Unfortunatelly there were
> only 5 QLers in attendance, including me. I wish there was a similar
> QL meeting, but probably it wouldn't have the same attendance anyway.

Depends on which of the two figures (50 or 5) you mean with "same".

Peter

___
QL-Users Mailing List


Re: [Ql-Users] Wined

2018-02-09 Thread pgraf--- via Ql-Users
Thanks Wolfgang, very good!

On 9 Feb 2018 at 8:01, Wolf via Ql-Users wrote:

> Hi all,
> 
> I have uploaded WINED, a formely commercial win,flp and file editor as 
> freeware.
> 
> You can get if grom the usaul address (www.wlenerz.com/qlstuff).
> 
> Have fun.
> 
> Wolfgang
> ___
> QL-Users Mailing List


___
QL-Users Mailing List


Re: [Ql-Users] QL-SD new driver

2018-02-02 Thread pgraf--- via Ql-Users
On 2 Feb 2018 at 16:25, Marcel Kilgus via Ql-Users wrote:

> Well, I said I'd do it and apparently I did it:
> 
> https://www.kilgus.net/2018/02/02/clonetastic-ql-sd-clone-working-with-goldcard-clone/

What surprises me is this: "With the original Verilog code my clone 
didn't work at all, so it's definitely not just the different chip."

With a normal GC, the original QL-SD worked relatively well, 
compared to the SGC. On some GC systems it was even fully stable 
hardware-wise. So if we assume that the electrical characteristics 
of the XC9572 play a minor role, why did it not work _at_all_?

A significant difference between Original GC and Tetroid?

Peter

___
QL-Users Mailing List


Re: [Ql-Users] QL-SD new driver

2018-01-23 Thread pgraf--- via Ql-Users
On 23 Jan 2018 at 9:21, Graeme Gregory via Ql-Users wrote:

> > I've already started putting together a clone using an Xilinx
> > XC9572XL, which I have lying around. The Verilog file compiled from
> > the get-go, I just had to remove the additional SS lines because of
> > Pin restrictions in the small chip on my eval board. The long lines to
> > the board might not exactly help, though... might take a while, but I
> > will try to make a GoldCard compatible QL-SD one way or another, now
> > that I have your release to base it on :-)
> > 
> Doesnt gold card have a parralell port?
> 
> That should be enough IO pins to connect an SD card which just needs SPI.

I already designed an SD card device for SGC, Q40, Q60 parallel port 
many years ago. It even draws enough supply power by some tricks, no 
need for AC adaptor.

Due to the slow speed I did not release it. IIRC it was like floppy 
on Q40/Q60 and even slower on SGC. SGC data lines are 
unidirectional, allowing only bitbanging. No PAR on GC.

Peter

___
QL-Users Mailing List


Re: [Ql-Users] QL-SD new driver

2018-01-22 Thread pgraf--- via Ql-Users
On 22 Jan 2018 at 15:21, Wolf via Ql-Users wrote:

> > If only we could find another builder/supplier of the SD interface... :-)
> 
> Hopefully one that could work reliably with GC/SGC!

That would be nice. The QL-SD hardware is open source, everyone is 
invited to improve it toward GC/SGC tolerance.

Peter

___
QL-Users Mailing List


Re: [Ql-Users] QL-SD new driver

2018-01-22 Thread pgraf--- via Ql-Users
Marcel Kilgus via Ql-Users wrote:

> As I've understood your chip is 3.3V and the lines (or GND) is too
> noisy so that logic level 0 could be interpreted as 1 before the lines
> settle

Yes this is one of the aspects, but it's not a 3.3V versus 5V issue. 
(The relevant logic levels are the same.)

The rise and fall timings of the SGC (and to a smaller degree GC) 
are too fast for the QL mainboard, which creates too much crosstalk 
and ringing. Even without QL-SD, illegal levels occur and can be 
seen on oscilloscope. The QL itself only works because it's hardware 
is too slow to "see" these illegal levels.

> because the chip samples them faster as older chips would, is
> that about right?

Roughly. A 400 MHz chip inside an ancient 8 MHz design.

> Would it help to put a 74-style Schmitt-trigger in
> front of ROMOEH or something like that?

http://www.dilwyn.me.uk/qlsd/qlsd-hardware-src.zip
-> qlromext-sch.pdf, see U4 ;)

Unfortunately this was not good enough to get the SGC working.

I guess the best solution would be another QL-SD design with an old, 
slow PLD. Second best: Experimenting with serial resitors in all 
lines. A different place (e.g. external ROM port) might also help, 
but it is hard to predict.

Peter

___
QL-Users Mailing List


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

2017-11-13 Thread pgraf--- via Ql-Users
Hi Duncan,

thanks for trying.

> SMSQ/E 3.31 boots OK on my Q60. Just MenuConfiged keyboard language from
> english to german and still boots OK. Sorry can't reproduce the problem.

Did you only change the keyboard, or also general language?

Would be great if you can tell something about your MENUCONFIG 
version also. My version from Dilwyn Jones' site at

http://www.dilwyn.me.uk/config/index.html

seems from 1999. Not sure that is up to date.

Peter

___
QL-Users Mailing List


Re: [Ql-Users] Dock

2017-11-08 Thread pgraf--- via Ql-Users
On 8 Nov 2017 at 13:09, Fran├žois Van Emelen via Ql-Users wrote:

> Here "dock" does its job correctly with QPC2, SMSQmulator and Black Phoenix.

Tobias reported the same problem on QPC2. Maybe you don't use the 
latest version of SMSQ/E? That would make sense, because the "dock" 
must have worked earlier.

> Error in line 1020: could it be that you didn't load the correct extension?

I seldom use BASIC other than for trivial tasks, and was not 
prepared to debug the program. So I may do something stupid. But:

* There is no error, but a hang/crash! That should not happen when 
using a BASIC command.

* What is the "correct extension"? Even with plain SMSQ/E, RPTR 
seems there.
 
All the best
Peter

___
QL-Users Mailing List