[Ql-Users] Open source Floppy controller and Eprom programmer

2020-09-05 Thread Marcel Kilgus via Ql-Users
I have written a bit about my old (and very customized) QL and only 30
years later I also open sourced two pieces of the hardware:

1. a Sandy SuperQBoard clone called the "Herbert card", named after my
late father. It features a floppy controller, parallel port and mouse
adapter. Unlike the SuperQBoard the Herbert card is HD compatible!

2. Jochen Hassler's Eprommer-II board that can burn EPROMs and even
program old GAL chips. That was pretty advanced for its time

I included current KiCAD schematics, layouts, ROMs and even source
code, so everything is there to built it, enjoy!

I've linked to the individual articles here:
https://www.kilgus.net/2020/09/05/hardware-from-my-past/

___
QL-Users Mailing List


[Ql-Users] QD vB.07

2020-08-05 Thread Marcel Kilgus via Ql-Users
I uploaded a new QD version to https://www.kilgus.net/smsqe/qd/.

It finally seems to fix the crashes Per experienced with it (thanks
for isolating the problem!). Basically it could corrupt memory if you
give it an editor height on the command line (e.g. "\n200") that does
not fit on the screen. I introduced the bug in B.05 while implementing
the per-extension file usage feature, a very unfortunate and
unexpected side-effect.

Cheers, Marcel

___
QL-Users Mailing List


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

2020-06-12 Thread Marcel Kilgus via Ql-Users
Wolfgang Lenerz via Ql-Users wrote:
> AFAIK, no new boards are being built.

There was talk about some unbuilt boards on the forum, but I think
because of the problems with the uncommon video resolutions they
hesitated to actually building more.

Cheers, Marcel

___
QL-Users Mailing List


[Ql-Users] QL-SD driver v1.09

2020-05-16 Thread Marcel Kilgus via Ql-Users
I've released a new QL-SD driver for anybody fortunate enough to possess one ;)
You can read the details here: 
https://www.kilgus.net/2020/05/17/ql-sd-driver-v1-09/

Downloads for the impatient are here https://www.kilgus.net/ql/ql-sd/

___
QL-Users Mailing List


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

2020-05-13 Thread Marcel Kilgus via Ql-Users
Ralf Reköndt via Ql-Users wrote:
> A simple bootstrap loader would do the trick, right? Why a complete 
> SMSQ/E in EPROM? As far as I remind, TT has written such one, having it
> it one of my TT disks (for Atari).

What advantage would that have compared to the full SMSQ/E? None.

Marcel

___
QL-Users Mailing List

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

2020-05-12 Thread Marcel Kilgus via Ql-Users
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.
But once it boots the EPROM is not used again anyway.

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] SMSQE 3.36

2020-04-23 Thread Marcel Kilgus via Ql-Users
Thierry Godefroy via Ql-Users wrote:
> Attaching the "quick and dirty" patch again to this message.

FYI, the list doesn't allow attachments, so they are filtered out.

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] 15th Sinclair QL Italian meeting goes virtual

2020-04-05 Thread Marcel Kilgus via Ql-Users
Davide Santachiara via Ql-Users wrote:
> Anybody who would like to join us can just type on any browser (Chrome
> preferred):
>
>   https://meet.jit.si/sinclairql

I'll be there, at least for the first hour or so.

Cheers, Marcel

___
QL-Users Mailing List


[Ql-Users] QL-SD ROM

2020-03-28 Thread Marcel Kilgus via Ql-Users
I've developed a new prototype for a QL-SD style adapter, enjoy:

https://www.kilgus.net/2020/03/28/ql-sd-rom-the-early-days/

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] IOB.FLIN strips CR from lines ending in CR/LF

2020-03-24 Thread Marcel Kilgus via Ql-Users
Jan Bredenbeek via Ql-Users wrote:
>> Hi Jan,
>>
>> On what machine?
>>
> It does occur on QPC2 too and appears to be connected to WIN-devices
> (doesn't occur on ram and dos, only win).

Yes, seems to be a hard-coded feature of the DV3 drivers.

Marcel



___
QL-Users Mailing List


Re: [Ql-Users] Website move

2020-03-09 Thread Marcel Kilgus via Ql-Users
Badaman - sinclairql.es via Ql-Users wrote:
> It is a pity. I hope that the contents may be available on another site,
> as well as a copy of the page with its current aesthetic.

I guess you mail client doesn't show the signature or you'd have seen
his new URL http://home.hccnet.nl/b.spelten/ql/ ;)

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] RE QDT Running with 240 MB of RAM

2020-03-03 Thread Marcel Kilgus via Ql-Users
Wolfgang Lenerz via Ql-Users wrote:
> Wow, what ever do you use 240 MB for??

Why is it 240 with SMSQmulator and not 256? Technical problem or just
being on the save side?

Marcel

___
QL-Users Mailing List


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

2020-03-02 Thread Marcel Kilgus via Ql-Users
Jan Bredenbeek via Ql-Users wrote:
> On this (Quantum) Leap day, I proudly present the re-release of QBOX. And
> not just the version that's been laying around for years in scattered
> files, but a complete ready-to-run WIN container that works over TCP/IP on
> QPC2, SMSQmulator and UQLX! It also contains the complete QL file archive
> of my BBS from 1987 to 2003, which is about 48MB.

Oh my good, this is pretty cool. The only thing that's missing for the
complete retro experience is the anxiousness over the accumulate phone
bill and the haste to get things done as quickly as possible! :)

I often chatted to Jochen through his BBS and we exchanged SMSQ/E
sources and stuff this way as sending floppy discs quickly became too
annoying ;) Good times.

Cheers, Marcel

___
QL-Users Mailing List


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

2020-01-21 Thread Marcel Kilgus via Ql-Users
desin via Ql-Users wrote:
> win_check 1

I have just one comment, WIN_CHECK does not work (and doesn't make any
sense anyway) if you mount a .WIN file through the menu. WIN_CHECK
checks if the file on the underlying FAT32 partition is continuous.
When mounted through the menu there is no underlying file system.

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] QL-VGA

2020-01-17 Thread Marcel Kilgus via Ql-Users
Wolf via Ql-Users wrote:
> I'd like that too, since I'm on no social media nor the forum.

I try to inform all 4 major venues (this list, the English forum, the
German forum and Facebook), which is a bit of a pain but they all have
distinct groups of users.

But while I do get the rejection of Facebook I encourage joining at
least the English forum, it is a very lively place (between 5 to 30
posts a day I would guess. If that is too much, the forum is split
into hardware/software/etc. so easy to filter for one's taste) and
unlike Facebook it is exclusively operated by QL enthusiasts.

I uses an RSS reader to read the forum, so I get to see new posts when
they arrive, just like in an eMail list, and can then decide to chime
in or not. This way reading it is very comfortable without having to
manually poll the site for changes, which in the past was my biggest
grievance with web forums.

Marcel

___
QL-Users Mailing List


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

2020-01-16 Thread Marcel Kilgus via Ql-Users
Daniel Baum via Ql-Users wrote:
> You seem to have done an outstanding job with the Mister core. It runs very
> nicely, and ,at least under SMSQ/E at full speed and 4MB of memory, seems
> very stable.

Thanks, good to hear!

> I have one tiny niggle - on the keyboard, + and = are where the \ should
> be, and KBD_TABLE appears to do nothing, but seriously, this is literally a
> Quantum Leap for the Mister.

I feared that this is a problem, I changed a few keys for my German
keyboard but was not sure if this breaks other layouts or if the
layout was broken anyway.

For people not following the forum, I just released another core that
can mount .WIN files directly without a need for a second SD card.
This needed a new QL-SD driver v1.08, but the change has not impact
whatsoever on real QL-SD devices, so there is no need to update.

Cheers, Marcel

___
QL-Users Mailing List


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

2020-01-13 Thread Marcel Kilgus via Ql-Users
Peter Graf via Ql-Users wrote:
>> 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?

Unfortunately nothing this easy, took me ages to understand what he
did. A12/A11 are now multiplexed and also act as DQMH/DQML. These are
never used at the same time, so he can do that, but it's weird to
understand as of course there are no comments... and the SDRAM code is
100% mine, so I couldn't just take his changes to the original core.

Anyway, I think I fixed it, new core is on the page. Of course I can
only tell that it still works with the 32MB board ;)

Marcel

___
QL-Users Mailing List


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

2020-01-13 Thread Marcel Kilgus via Ql-Users
Thierry Godefroy via Ql-Users 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).

I'm aware of it and it's of course quite a beast, but it's also more
expensive and, this might be the camera, monitor or non-optimal
settings, but on your QL example I see that you got Moiré effect in
the stippled pixels. Anyway, sure, that is a pretty versatile option
at least.

Marcel

___
QL-Users Mailing List

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

2020-01-13 Thread Marcel Kilgus via Ql-Users
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.

Marcel

___
QL-Users Mailing List


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

2020-01-13 Thread Marcel Kilgus via Ql-Users
Daniel Baum via Ql-Users wrote:
> I'm looking forward to testing this.
>
> Are you going to send it to the main Mister repository?

That's the plan.

Marcel

___
QL-Users Mailing List


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

2020-01-12 Thread Marcel Kilgus via Ql-Users
I did a lot of work on the MiSTer core a year ago. Because of some
Greek guy I happen to know :-P I resurrected it a week or two ago and
a few minutes ago I finally put the stuff online:

https://www.kilgus.net/ql/mister/

I don't have time to test everything but I'm pretty sure I uploaded
the right files. Enjoy.

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] QL-VGA

2020-01-10 Thread Marcel Kilgus via Ql-Users
John Southern via Ql-Users wrote:
> I have two questions
> 1) When can I buy one?

I don't know yet. Maybe in a few months if all goes well.

> 2) What are the advantages over an RGB/CGA/EGA to HDMI converter?

That is was designed exclusively with the QL in mind and it just
works. If you already have a converter that works for you, you
probably don't need QL-VGA.

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] QL-VGA

2020-01-09 Thread Marcel Kilgus via Ql-Users
Norman Dunbar via Ql-Users wrote:
> I've read your article. It looks interesting. I'm not clued up on
> FPGAs - although I know what the initials stand for - so, I would be
> interested in knowing a bit more about how you did the converter. If
> you have time and inclination of course.

Well, it's a bit like programming, the difference is just that
basically all lines execute at the same time! If you want something to
execute sequentially you have to implement a state machine.

That's the gist of it. If you have a base clock and base everything
off of that things are pretty clean and work nicely. But if you have
different clocks things get weird very quickly. For example I tried
implementing an Aurora card for the MiSTer FPGA board, but I couldn't
get the pixel clock to change reliably, it only worked like 50% of the
time.

For QL-VGA I use a base clock of 130Mhz, which divides nicely into the
10Mhz QL pixel clock and the 65Mhz VGA pixel clock, so nice and clean.

Debugging is either done by simulating your code on the PC or by
actually compiling a complete logic analyzer INTO your design so it
runs on the same chip next to your own logic :-o You can then read out
your signal data using the JTAG interface. That is pretty cool.

For a pretty simple example the QL-SD code is open source if you want to
see how this looks like: https://www.kilgus.net/soft/qlromext_spi.v
This is so small it compiles to a CPLD chip, which is basically a GAL
on drugs. But the way to code is exactly the same.

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] QL-VGA

2020-01-09 Thread Marcel Kilgus via Ql-Users
Urs Koenig (QL) via Ql-Users wrote:
>> I'll never have a facebook account. But I do use the Forum.
> Same as me.

Yes, it's a bit of a pity that the discussions tend to get split up
nowadays. The most active thread for QL-VGA is actually the Facebook
one this time, with currently 474 members the QL group there has a
different (more wide spread) audience than even the forum.

Cheers, Marcel

___
QL-Users Mailing List


[Ql-Users] QL-VGA

2020-01-08 Thread Marcel Kilgus via Ql-Users
In case anybody is still lurking here and has not jumped ship to
Facebook or the forum, I made a new post about my QL-VGA hardware. You
can read about it here:

https://www.kilgus.net/2020/01/08/ql-vga-the-second/

All the best, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] Assembly language eComic, issue 7, out now!

2019-10-02 Thread Marcel Kilgus via Ql-Users
Norman Dunbar via Ql-Users wrote:
> In this issue there is an article by Tobias on the Q68, plus
> exciting stuff about the UTF8 character set encoding and how it can
> be used on the QL - or at least, how I can use it! Two world class
> (ahem!) utilities are supplied to enable conversion from the QL to
> UTF8 and back again. There's even, wait for it, a table of contents! ;)

As a pedantic ass I have to object so sentences like these:

"• The UK Pound symbol is character 96 ($60) on the QL, but in ASCII
it is character 163 ($A3)" (etc.)"

ASCII is, by definition, 7-bit, so it cannot contain a character with
the number 163. The tale of characters 128-255 is one fought in many
battles. Linux tended to be "ISO 8859-1" and later "ISO 8859-15"
before they adopted UTF-8, on Windows you will mostly find the
"Windows-1252" encoding. These are very similar, but differ when it
comes to the Euro sign for example (ISO 8859-1 is too old to have a
Euro sign and the others have adopted it in different places).

But, and that is the important thing, Unicode was made to unify them
all. And UTF-8 is a pretty darn cool invention, unfortunately it came
too late for Windows, which was a very early adopter of Unicode at a
time when everybody thought "65536 characters ought to be enough for
everyone!". So Windows started to used 16-bits for every character
("UCS-2" encoding), which makes coding somewhat weird, and then they
found out that 65536 characters are not enough after all, so now
Windows uses UTF-16, which is UTF-8's big brother, with sometimes 2
bytes per character and sometimes 4. What a mess. But when it comes to
data storage UTF-8 is the way to go these days, always!

For QPC I already implemented these translations 20 years ago when
copying text to/from the clipboard. But well done for bringing UTF-8
to the QL :-)

Cheers, Marcel

___
QL-Users Mailing List

Re: [Ql-Users] Just a small

2019-09-23 Thread Marcel Kilgus via Ql-Users
paul via Ql-Users wrote:
> test to see if this still comes my way.

It came my way at least ;) These days the QL-forum seems to have taken
over all talks about the QL.

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] New QPC release ?

2019-04-08 Thread Marcel Kilgus via Ql-Users
pjwitte via Ql-Users wrote:
> DMEDIUM_TYPE returns -1 on DOS devices (the underlying iof.xinf call
> suggests: IOI_FTYP $2C Byte Format type (1=qdos, 2=msdos etc) but -1 
> is arguable..)

Oh, that actually is a bug. It's supposed to be 2 of course. I have
translated the code into C last weekend and thus already fixed it
without even knowing that it was broken.

> The other relates to iof.xinf directly, but that is not wired up to 
> any DMEDIUM_ command, namely:
> IOI_HDRL $28 Long File header length (per file storage overhead) - 
> which returns 512b on DOS, while all other devices return 64b. The 
> inconsistency here is that 512b doesnt relate to the actual file 
> header size, as I always assumed was the intention..

Looks like the structure is somehow offset by some bytes, as that is
also supposed to be 64.

I was thinking more about the line of DMEDIUM_RDONLY and
DMEDIUM_REMOVE. This is a bit more difficult to check but I think I
got the most common cases now at least.

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] New QPC release ?

2019-04-07 Thread Marcel Kilgus via Ql-Users
François Van Emelen via Ql-Users wrote:
> There seems to be a new release of QPC2 in the pipeline.

It has been in the pipeline for the last 2 years... but yeah, it's
much further along now.

> It would be very useful if someone would/could debug the 'DMEDIUM_XXX'
> functions.

If you refer to the DOS device then someone must be me then. But this
is not a bug. It's maybe a missing feature, but one that is amazingly
difficult to pull off correctly for very little gain. I might try
halve-assing it though.

Marcel


___
QL-Users Mailing List

Re: [Ql-Users] EasyMenu

2019-04-03 Thread Marcel Kilgus via Ql-Users
Derek wrote:
> EasyMenu has always been slow to startup on all QL platforms.

It takes about 2 seconds on an unexpanded Minerva QL, so I wouldn't
say this was generally the case.

It took 20 seconds or so on a Q68, which was not the Q68's fault at
all but a mere coincidence.

All the best, Marcel

___
QL-Users Mailing List


[Ql-Users] EasyMenu

2019-04-03 Thread Marcel Kilgus via Ql-Users
During the German ZX meeting that has become some sort of last refuge
for us QL fans, too, a new EasyMenu was created, fixing a small bug
that resulted in long startup time on the Q68. I don't think the bug
has other ill effects, but updating certainly will not do any harm:

https://www.kilgus.net/smsqe/easyptr/

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] Wallpaper program

2019-02-20 Thread Marcel Kilgus via Ql-Users
Dilwyn Jones via Ql-Users wrote:
> Recent versions of SMSQ/E from about version 3.00 feature high colour and
> high resolution screens along with the new Window Manager.

So "recent" being within the last 16 years ;-)

> The downside of using wallpaper on a high-colour system is the amount of
> memory it takes. On a 16-bit colour system such as QPC2 each pixel needs two
> bytes of memory, so a 1024×768 pixel display in mode 32 or 33 could need up
> to 1,572,864 bytes just to hold the uncompressed wallpaper – at the time of
> writing SMSQ/E does not support compressed wallpaper screen images.

Technically SMSQ/E never had the concept of a background, the
wallpaper is just a window that cannot be brought to the front. And as
such it needs the same amount of memory every full-screen window needs
for its save-area. This was even true if you set the background to a
plain colour!

For v3.00 I at least implemented true plain-coloured backgrounds so
that they do not need any additional memory but are drawn on-the-fly.

> Download the Wallpaper software and a few example graphic files from
> http://www.dilwyn.me.uk/graphics/index.html

Nice one, thanks.

Cheers, Marcel


___
QL-Users Mailing List

[Ql-Users] Kilgus.net update roundup

2018-12-16 Thread Marcel Kilgus via Ql-Users
For those that don't monitor my blog or the QL-Forums, here are a few
updates that happened the last few weeks:

I've decoded the GoldCard boot/patch ROM code
https://www.kilgus.net/2018/11/14/supergoldcard-boot-sequence/

I've hunted down a crash in Minerva
https://www.kilgus.net/2018/11/16/microdrive-mystery/
(includes comments by the man Lau Reeves himself!)
and released a new version "1.98a1" accordingly
https://www.kilgus.net/ql/minerva/

I've released QMON/JMON for free
https://www.kilgus.net/smsqe/qmon/

I've released a picture of the QMON successor SMON that was unfortunately
never finished
https://www.qlforum.co.uk/viewtopic.php?f=3=1392=60#p25802

I've released a new QL-SD demo disc that now includes many QL games,
some for free for the first time
https://www.kilgus.net/2018/12/17/ql-sd-demo-update/

I've uploaded an update to my PNGConv tool as the 13 year old binary
exhibited some problems:
https://www.kilgus.net/smsqe/sprite-converter/

I think that was it for now... have fun.

___
QL-Users Mailing List


Re: [Ql-Users] QMac source code

2018-12-14 Thread Marcel Kilgus via Ql-Users
Jan Bredenbeek via Ql-Users wrote:
> QLINK has some serious issues compared to the GST version. The symbol table
> dump in the _MAP file looks strange and the generated binary output file is
> not executable.

I've used QLink 1.03 for years on many many projects including SMSQ/E
without any problems. You need to supply the FILETYPE option on the
command line or linker file if you want the result to be executable.

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] QMac source code

2018-12-14 Thread Marcel Kilgus via Ql-Users
Urs Koenig (QL) via Ql-Users wrote:
> I was trying to find the sources of all the GST software, updated QUANTA
> editions of QMAC and QLINK in specific. All my tries (through QUANTA,
> sending emails to all documented addresses of Phil) failed and I stopped
> seeking exactly 5 years ago.

I've last had contact with him in the year 2000, but the adress is not
valid anymore (I guess he let it lapse and some domain hoarder picked
it up as the current one was registered in 2003).

According to a 2013 freedom of information request he's still
registered with this address as a dentist with the Department of Health
https://www.whatdotheyknow.com/request/gp_and_dental_practices_2

I found an eMail adress for the practice, but I didn't try contacting
it.

In the meantime I've disassembled QMac into a state where it can be
altered without messing up any pointers and data structures.

Cheers, Marcel


___
QL-Users Mailing List


[Ql-Users] QMac source code

2018-12-10 Thread Marcel Kilgus via Ql-Users
Hi everyone.

Does anybody know who has the source code to QMac? The Quanta version
doesn't look like simple patches to the GST binary, so I guess
somebody must have had it at some point. I'd like to make a few small
updates myself.

All the best, Marcel

___
QL-Users Mailing List


[Ql-Users] QMON manual

2018-11-21 Thread Marcel Kilgus via Ql-Users
Yesterday I asked on the QL Forum if somebody could maybe supply a PC
editable version of the QMON manual for me to work on. Many people
came forward and tried to help, thanks a lot! But Per mentioned that
he already has a well formatted PDF of it but doesn't remember where
he got it from. I was wondering if the author is maybe lurking here?

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] QL and 3D printing

2018-11-21 Thread Marcel Kilgus via Ql-Users
Giorgio Garabello via Ql-Users wrote:
> http://www.hunggartorino.it/ql/ql-parts-thanks-to-3d-printing/

Interessting, thanks. 3D CAD and printing is one thing that I'd like
to be able to do but better not try because I cannot do everything I
want to do as it is...

On the other hand we have some pretty cool machines at work that can
even print metal parts :-D

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] About OQTopus network manager.

2018-11-05 Thread Marcel Kilgus via Ql-Users
Giorgio Garabello via Ql-Users wrote:
> An introductory article on OQTopus, the new network manager for Black
> Phoenix
> Enjoy the reading. Giorgio
>
> http://www.hunggartorino.it/ql/discovering-oqtopus-the-new-network-manager-for-black-phoenix/

Unfortunately I currently don't have much time to do anything QL wise,
but I must say the screenshots look pretty amazing! :-)

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] File header info

2018-09-28 Thread Marcel Kilgus via Ql-Users
> on dbas manual i've found an alternative description of the header..
>
>    Type  Length   Name  Contents
>    2 -    LENGTH    File Length
>    1 -    TYPE  File access *256+ file type
>    2 -    DATA  Dataspace size - EXECutable type
>    2 -    OFFSET    GST Linker "OFFSET" value
>    0 36 char  NAME$ File name
>    2 -    UPDATE    Update date
>    1 -    VERSION%  Version number
>    1 -    FILE% File number
>    2 -    BACKUP    Backup date (not used)
>
> I'm more and more confused…. :-(

This is the definite version from the SMSQ/E source code:

* file header structure

hdr_flen equ$00 ; longFile LENgth
hdr_accs equ$04 ; byteaccess control byte
hdr_type equ$05 ; bytefile TYPE
hdrt.exe equ  1   ; executable
hdrt.rel equ  2   ; relocatable
hdrt.ldr equ  3   ; loader re-locatable file
hdrt.pfm equ  7   ; proforma/prowess types
hdrt.dir equ  $ff ; directory
hdr_info equ$06 ; 8*bytes additional information
hdr_data equ$06 ; longprogram DATA space
hdr_xtra equ$0a ; longextra info
hdr_name equ$0e ; string  file name (up to 36 characters long)
hdr.nmln equ  36
hdr_date equ$34 ; longupdate date
hdr_vers equ$38 ; wordversion number
hdr_flid equ$3a ; wordFile ID
hdr_bkup equ$3c ; longbackup date
hdr_end  equ$40 ; end of header

Contrary to my previous mail hdr_accs is defined by SMSQ/E as the DOS
attributes for the file. My DOS device also uses it this way.

dos.ro   equ  $01   ;   read only
dos.hidf equ  $02   ;   hidden file
dos.sysf equ  $04   ;   system file
dos.vol  equ  $08   ;   volume label
dos.subd equ  $10   ;   subdirectory
dos.updt equ  $20   ;   file is updated

I don't think these attributes (like read-only) are actively enforced
for QL devices, however.

The only known use for hdr_xtra is on SMSQ/E files that can be
LRESPRed, in this case it holds the SMSQ/E version (hdr_data is 4 for
these files)

Marcel

___
QL-Users Mailing List

Re: [Ql-Users] File header info

2018-09-28 Thread Marcel Kilgus via Ql-Users
Giorgio Garabello via Ql-Users wrote:
>> File access key: Don't know of any software that uses this.
> OK. let's see if anyone knows more ...

I think the largely unknown TK3 used that byte. Not really important.

>> "backup date" can be used by backup programs to store the date and time of
>> the last backup. It is not used by the system.
>>
>> "reserved" is, well, reserved, and not used for anything.
> ok, but…….why?

Why space is reserved? For future use that never happened, probably.

Marcel

___
QL-Users Mailing List

[Ql-Users] QD 2018

2018-09-15 Thread Marcel Kilgus via Ql-Users
I have just updated QD 2018 to version B.05:

; B.05  Implemented per-extension editor-usage (configurable) (MK)
;   Fixed BASIC usage for DEFine FuNction (MK)
;   Fixed colours in replacement confirmation dialog (MK)
;   Fixed DO on resize to keep the x window size (MK)
;   Bottom right corner stays where it is on normal resize (MK)
;   Allow CTRL+Z (mark current line) in read-only mode (MK)

As previously with the tab settings the editor-usage can now be
configured per extension, so you can say all "_bas" (or "_bsl" ;) )
files automatically invoke the "BASIC" editor usage, for example.

The rest is the stuff we've already talked about here.

https://www.kilgus.net/smsqe/qd/

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] Summer is over, QL time approaching...

2018-09-01 Thread Marcel Kilgus via Ql-Users
Urs Koenig (QL) via Ql-Users wrote:
> last day of summer 2018, a summer where I experienced so much. One if not
> the greatest summer I ever had.

:-)

> Normally summertime is a QL free time for me and many other QL folks. But
> this summer was different.

In my case it was quite the opposite, too :-)

> Before the trip I edited and published the story of MIRACLE SYSTEMS/Stuart
> Honeyball based on video material of the Italian QL enthusiasts (YouTube),

Still haven't watched it fully, unfortunately. So much material.

> After the trip I was telling the story of the last remaining early D03 build
> standard QL with PM (EP)ROM as an unboxing video (YouTube).

That was quite interesting.

> Finally I was able to spend a full day plus some extra hours here and there
> on QL/E and was able to release v3.18 (Edition 1808, Codename "Eternity",
> last updated 12.08.2018) on the very same day Linus Torvalds released Linux
> kernel v4.18. It is pure coincidence that both software reached sub-version
> 18 the same day.

I have looked a little bit closer at QL/E recently and was quite
impressed by the way the boot process tries to adapt to the machine
and configuration at hand.

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] QL-SD order page

2018-09-01 Thread Marcel Kilgus via Ql-Users
Thanks everybody, it will take me a while to process all the orders
that came in so far! :-o

Fairly recently I have decided that I will populate the upper SPI port
to allow to connect possible future expansions without any additional
soldering. Problem is, I've run out of connectors... so I've ordered
more, but they will take two or three work days to get here from the
US, which means the next boards will probably ship Thursday at the
earliest.

All boards also now come with a free plastic chip prying tool to
prevent the QL from taking some screw-driver related damage.

Thanks to Tobias for testing the new version and the subsequent
glowing review :-) I have invested a LOT of time into making this
thing as perfect as possible and I'm glad that it shows.

And yes, also thanks to Wolfgang for writing the first driver! Without
it I would probably not have done what I did.

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] QL-SD order page

2018-08-31 Thread Marcel Kilgus via Ql-Users
RWAP Software via Ql-Users wrote:
> Thanks Marcel - it will also be worth listing some on sellmyretro - as
> there are a few people who have been looking for these to go with their
> Gold Card clones :)

Judging from all the reactions I got so far I expect demand to surpass
supply anyway, but if not I will certainly do that.

Cheers, Marcel

___
QL-Users Mailing List


[Ql-Users] QL-SD order page

2018-08-31 Thread Marcel Kilgus via Ql-Users
Hi everyone.

I decided ql-users as the long-time home of most long-time users get
the link to the QL-SD order page first:

https://www.kilgus.net/ql/order/

Soon I will also publish it in QL Forum and Facebook.

Cheers, Marcel


___
QL-Users Mailing List


Re: [Ql-Users] QD 2018 colours

2018-08-28 Thread Marcel Kilgus via Ql-Users
pjwitte via Ql-Users wrote:
> So that wouldnt help you, Bob. In VB0.3 the behaviour
> changed again. Now DOing the resize button annoyingly resets the width
> to 80 coloumns for some reason as well as maxing the hight.

It has never worked for me before, but I fixed it anyway,

> There is one serious bug though, that I hope will one day be tackled
> by some brave and patient soul.

Tried. Failed. Not happening, sorry.

> Its hard to demonstrate and almost impossible to catch in the act.

That's basically the problem. That and that the editor core is
thousands of lines of hard to read code. But if you can ever repro
it...

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] QD 2018 colours

2018-08-28 Thread Marcel Kilgus via Ql-Users
Bob Spelten via Ql-Users wrote:
> But setting a custom width, moving the "size" to the left, is where the
> right side also moves left.

OK, now I see what you mean.

The size is incremented in 20 character steps. There is no explanation
in the code why that is, but as this is the same amount that is used
when the edit window is panned I guess that this is the reason. I
tried removing the restriction and most things seemed to work, but I
found at least a minor bug, so I'm not comfortable lifting that
restriction.

I can make the bottom right corner stay in place, though. The downside
is that now when you resize less than 20 characters more basically
nothing happens at all, this might be confusing for some users.

> Jochen once explained that size grows in
> discrete steps but I would expect the right side to be anchored, now full
> screen can never be reached.

Ususally it cannot be reached because the maximum line length is
exhausted before the maximum screen width.

> My numberless Basic is named xxx_bsl so would not benefit.
> Usually I start QD through FI2 where the right command flag is added to
> take care of this.

I start 100 QDs when working on stuff like this, 10% by hotkey and 90%
by FiFi ;)

> Just one more. It sometimes happens when a line is longer than the window
> and I use ALT-right to jump to the end of the line, the text pans less
> than needed but the cursor/arrow lands on the right spot, outside the
> window.
> This seems more likely to happen when the cursor is already at position
> 80+.

Can't reproduce right now. And in any case, this is a problem with the
editor core, which I'm not touching with a 10 feet pole.

> Last one? Opening QD in read-only mode (\P) lets me pick a block for the
> scrap but using ^Z to hot-buffer one line is not working. A bug or a  
> missed feature?

Apparently you have to thank me that CTRL+X works in this mode:
cmp.b   #24,d1  ; CTRL X => Quit
beq.s   not_protected   ; yes, so do it (Marcel wants it !!)

I added
cmp.b   #26,d1  ; CTRL Z => Mark current line
beq.s   not_protected   ; yes, so do it (Bob wants it !!)

Cheers, Marcel


___
QL-Users Mailing List


Re: [Ql-Users] QD 2018 colours

2018-08-28 Thread Marcel Kilgus via Ql-Users
Bob Spelten via Ql-Users wrote:
> Per already mentions the jumpy resize behaviour.

I frankly don't quite see what's jumpy about it?

> One point I would like to add now, as a Basic programmer, is the DEFine
> highlight that is not working for FN or FuNction sections.

Again a feature I didn't even know about. And quite obviously this has
never worked but is not too difficult to fix.

I'd prefer if the editor usage would switch automatically to BASIC if
a file with the extension "_bas" wa loaded (correspondingly for
"_asm"), but I must check how difficult that would be.

> For other points I need to check my notes and test them against this  
> version.

Can do, but as a general matter I must stress that me releasing some
software does not mean that all outstanding 20 years old bugs will get
fixed :-o

Marcel


___
QL-Users Mailing List


Re: [Ql-Users] QD 2018 colours

2018-08-28 Thread Marcel Kilgus via Ql-Users
pjwitte via Ql-Users wrote:
> Im having a problem with the latest QD (2018). The 'Replace 
> confirmation sub menu' seems to have its colours mixed up. I cant read
> that menu in any palette!

I've never used or seen this menu, but yes, it's broken. Jochen was
being clever here, unfortunately without explaining comments in the
menu/code what he did! Bad Jochen! The window actually has a "hole" in
it that let the original text shine through. Apparently Bernd, who did
the colour conversion, gave up understanding it. Took me halve an hour
to get it, too.

Unlike the last official release my sources are based on Bernd's
version, so you got a confused and bugged halve-finished version of
the window. The last official release just didn't colour the window at
all.

> If "someone" ;) is going to delve into the innards of QD again to sort
> this out, could they also tweak the 'resize to full screen' option (DO
> resize icon) to perhaps leave the current x-size of the window 
> unchanged (as it was in the earlier version)?

I don't think there ever was a version that left the x-size alone? As
far as I can tell all previous versions just made the window a LOT
wider, to the maximum allowed size. I much prefer the current
behaviour.

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] colour confusion

2018-08-24 Thread Marcel Kilgus via Ql-Users
OK, I have a little bit more time and net here now. When I defined the colours 
15 or so years ago I was asking the community for feedback, but I think most 
people didn‘t even quite understand the purpose yet, so there weren‘t really 
any changes to it.

I defined the colours based on three things, the Windows 95 colour palette, the 
WMAN window structures and the colours needed to successfully port QPAC2 to 
them. Only one or two additions were made for other software like QD (which 
still has the editor colours in its own config block as I felt these were not 
generic enough in usage). 

With QPAC2 it was necessary to have a foreground colour and one other font 
colour, for which I created the name „middle ground“. This was part joke and 
part lack of a better name. Plus, nobody complained ;)

I never realized this could be interpreted as STRIP colour, especially as I 
actually defined one „STRIP“ colour, too: „Title text background“. I don‘t have 
my laptop with me, but I don‘t think there is the concept of a „STRIP“ colour 
in the data structures, so I probably never really considered it. Sorry for the 
confusion!

I was hoping that some day there would be a style guide, but adoption of the 
system palette was slow and finally I forgot about it. Still, many applications 
these days use them, so I consider them a success nonetheless.

One more thing: they are defined somewhat conservatively because if you give 
too many options thing get even more messy. I know Per was always on the rather 
bleeding edge of WMAN UI development so probably struggled a lot more with them 
than anybody who simply duplicated the QJump style.

Cheers, Marcel

> Am 24.08.2018 um 14:45 schrieb pjwitte via Ql-Users 
> :
> 
> There appears to be some inconsistency in the application of colour 
> components of palettes by different software authors. Im referring in 
> particular to the use of "middle ground". Correct me if Im wrong, but I 
> assumed this option was reserved for use as the strip colour, ie the colour 
> of the text background. Some authors do it this way, while others use the 
> background (ie normally the paper colour) as text background. This can make 
> texts like titles, info texts, and error messages unreadable, depending on 
> the palettes used.
> 
> While it is possible to devise palettes that will work in either case, it 
> sort of cramps one's style a bit. And the whole motivation for going to the 
> trouble of devising palettes and systems, one presumes, is to make things 
> simpler, more consistent - less mickymouse.
> 
> Unless it is already too late (ie the bug has become convention) it would be 
> great if the next iteration of relevant documentation could firm up the 
> convention that:
> 
> background is equivalent to PAPER colour,
> middle ground is equivalent to STRIP colour, and
> foreground is equivalent to INK colour,
> 
> if that is indeed the intention.
> 
> Perhaps authors too, would try keep this in mind when releasing updates?
> 
> Per
> 
> 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] colour confusion

2018-08-24 Thread Marcel Kilgus via Ql-Users
No, „middle ground“ is supposed to be an alternative INK colour.

Still on holiday, hope this works.

Marcel

> Am 24.08.2018 um 14:45 schrieb pjwitte via Ql-Users 
> :
> 
> There appears to be some inconsistency in the application of colour 
> components of palettes by different software authors. Im referring in 
> particular to the use of "middle ground". Correct me if Im wrong, but I 
> assumed this option was reserved for use as the strip colour, ie the colour 
> of the text background. Some authors do it this way, while others use the 
> background (ie normally the paper colour) as text background. This can make 
> texts like titles, info texts, and error messages unreadable, depending on 
> the palettes used.
> 
> While it is possible to devise palettes that will work in either case, it 
> sort of cramps one's style a bit. And the whole motivation for going to the 
> trouble of devising palettes and systems, one presumes, is to make things 
> simpler, more consistent - less mickymouse.
> 
> Unless it is already too late (ie the bug has become convention) it would be 
> great if the next iteration of relevant documentation could firm up the 
> convention that:
> 
> background is equivalent to PAPER colour,
> middle ground is equivalent to STRIP colour, and
> foreground is equivalent to INK colour,
> 
> if that is indeed the intention.
> 
> Perhaps authors too, would try keep this in mind when releasing updates?
> 
> Per
> 
> 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] QD 2018

2018-08-15 Thread Marcel Kilgus via Ql-Users
Jochen Merz via Ql-Users wrote:
> 1988 + 20 = ???  ;-)

Erm, calling it 20 makes me feel younger :-o

Marcel

___
QL-Users Mailing List


[Ql-Users] QD 2018

2018-08-15 Thread Marcel Kilgus via Ql-Users
To celebrate QD's 20th anniversary Jochen Merz gave me the premission
to release the fabulous QD text editor for free. Enjoy:

https://www.kilgus.net/smsqe/qd/

Cheers, Marcel

___
QL-Users Mailing List


[Ql-Users] QL-SD progress

2018-08-09 Thread Marcel Kilgus via Ql-Users
Work on QL-SD is still moving along, the driver has reached version
1.07 and seems pretty stable now:

https://www.kilgus.net/soft/qlsd107_bin.zip

There is also a new version of the loadable DEV device (or actually
it's the version that already comes with SMSQ/E, compiled for QDOS):

https://www.kilgus.net/soft/dev205.zip

Note that the QL-SD driver is not compatible with the DEV device built
into the GC or SGC ROM. I might provide an updated ROM image in the
future, but until then just load the driver above.

Note that it still does not work with the MiST emulator, but at this
point I'm not yet convinced it's actually a problem with the driver.
I've compiled a new FPGA core with a slightly updated 68k
implementation and wait for feedback, maybe it helps.

I've also soldered a bit of hardware in my free time in the evenings:

https://www.kilgus.net/2018/08/09/ql-sd-teaser/

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] return values QPC2 <>SMSQMULATOR

2018-08-05 Thread Marcel Kilgus via Ql-Users
Wolf via Ql-Users wrote:
> does your comment mean the question is solved?

Not sure if intentional or not, but OPEN_OVER with NFS device
overwrites any file, even if it's marked as read-only. And according
to François it returns "not found" if the file really is on a
read-only drive like a CD-ROM, haven't tested this myself, though.

Cheers, Marcel

___
QL-Users Mailing List

Re: [Ql-Users] return values QPC2 <>SMSQMULATOR

2018-08-05 Thread Marcel Kilgus via Ql-Users
Wolf via Ql-Users wrote:
> I didn't get the original question, for a few days I seem to have had
> some email trouble...

This was the complete code:

100 OPEN_OVER#3,'ram2_rdonly_txt'
110  REMark Why does 'dmedium_rdonly(\dev$) return 0 instead of 1
120  REMark Why does 'dmedium_type(\dev$) return -1 instead of 3
130  REMark Why does 'line 240  return  -23  WITH qpc2 (which seems 
correc)t BUT -7 with SMSQMULATOR
140  dev$='dos3_' :d$=DATE$  :datad_temp$=DATAD$
150 REMark DOS3_   is an external USB CD DRIVE
160 DATA_USE 'dos3_'
170  fichier$=dev$$
180 WHEN ERRor
190 IF  ERNUM:PRINT#3,ERLIN,ERNUM:END IF
200 END WHEN
210 d= FTEST(dev$)
220 IF d<0:CLOSE#3:DELETE 'ram2_rdonly_txt' :DATA_USE 
datad_temp$:STOP:END IF
230 f=FOP_NEW(fichier$):
240  PRINT#3,240,' f=fop_new(fichier$) = ',f
250  PRINT#3,250,'dmedium_rdonly(\dev$) = '; DMEDIUM_RDONLY(\dev$),'rdonly'
260  PRINT#3,260,'dmedium_type(\dev$) = ', DMEDIUM_TYPE(\dev$),'type'
270  PRINT#3,270,'dmedium_name$(\dev$) = ', DMEDIUM_NAME$(\dev$) ,'name'
280   CLOSE#3
290 DATA_USE datad_temp$  :PAUSE

Marcel

___
QL-Users Mailing List

Re: [Ql-Users] return values QPC2 <>SMSQMULATOR

2018-08-04 Thread Marcel Kilgus via Ql-Users
François Van Emelen via Ql-Users wrote:
> 110  REMark Why does 'dmedium_rdonly(\dev$) return 0 instead of 1
> 120  REMark Why does 'dmedium_type(\dev$) return -1 instead of 3

Because I didn't implement special support for this.

The DOS device generally doesn't care if the directory you point it to
is on a CD or on a network share on the other side of the planet, it's
just some directory.

Native QDOS driver usually must know the medium type or read-only
state anyway, so they can just fill that in. For virtual devices like
DOS additional efforts are needed and even then the data is hard to
come by.

> 130  REMark Why does 'line 240  return  -23  WITH qpc2 (which seems 
> correc)t BUT -7 with SMSQMULATOR

Probably Wolfgang just didn't write special code for this error case.
This could be considered a minor bug.

Cheers, Marcel

___
QL-Users Mailing List

Re: [Ql-Users] Odd behavour of the DIR command?

2018-07-26 Thread Marcel Kilgus via Ql-Users
Jan Bredenbeek via Ql-Users wrote:
> This has always been the problem with substitution devices. One solution
> would be to rewrite the io.fstrg/fs.headr/etc code to substitute the
> filenames read as well (essentially chop off the directory path
> substituted). In case of io.fstrg this means checking if the channel is
> opened for directory access, then check if the data read would be a file
> header (length=64), then change the filename read accordingly. In your own
> example when using INKEY$ from BASIC this would fail because INKEY$ reads
> one byte at a time (using io.fbyte).

Has anybody got the source code to the SUB device? It does this kind
of substitutions.

> Another solution would be to make the DIR command 'substitution-aware' so
> it would recognise a substituted device and act accordingly.

But then you have to do the same for QPAC2, QMenu, ...

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] Odd behavour of the DIR command?

2018-07-26 Thread Marcel Kilgus via Ql-Users
Giorgio Garabello via Ql-Users wrote:
> From the QL Forum:

Copy of my answer:

The problem is that QL filenames always include the directory paths
and the usual substitution devices like DEV only redirect the OPEN
call, after that the channel is maintained by the other driver, so the
result of DIR calls are not translated. This means that the DIR
shd1_fifi here actually returns filenames as "prg_fifi", which the DIR
then filters for names starting with "fifi" but they actually start
with "prg", which in the end results in no files being listed.

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] QLSD tester sought

2018-07-06 Thread Marcel Kilgus via Ql-Users
desin via Ql-Users wrote:
>> I'm mainly interested in making sure it still works as stable as
>> before.
> Hello Marcel
>
> works ok on the MiSTER
>
> but no luck on the MiST

Hi Markus.

What happens on the MiST? In principle the hardware access is the same
as before.

Cheers, Marcel

___
QL-Users Mailing List


[Ql-Users] QLSD tester sought

2018-07-05 Thread Marcel Kilgus via Ql-Users
I've got a new QLSD driver release which needs some testing, so if
anybody is willing to help there is a ROM and RAM version at

https://www.kilgus.net/soft/qlsd105_bin.zip

I'm mainly interested in making sure it still works as stable as
before.

There are 4 changes:

1. It solves a small problem with the card auto-detection when more
than one card is used at the same time. Probably few people run into
this with existing single slot QLSD hardware ;)

2. It adds some sort of API so 3rd party software can call into the
driver to have raw access to the card sectors. In case anybody is
interested there is some demo code at

https://www.kilgus.net/soft/qlsd_demo.zip

3. The "QLSD is busy" flag moved into the system variables so several
drivers or other software can share QLSD more easily.

4. It checks the version of the hardware and outputs it on startup.
For this to work I added a new register to my hardware that encodes
the version and variant. The original hardware is detected simply by
not having this register.

When the feedback is good I can go forward with releasing the new
hardware.

All the best, Marcel



___
QL-Users Mailing List


Re: [Ql-Users] SMSQ/E 3.33

2018-05-16 Thread Marcel Kilgus via Ql-Users
Thierry Godefroy via Ql-Users wrote:
> I am faced with a problem in v3.33: the "WMAN system colours" config block
> is gone (!) and as a result, most of PE programs (especially old ones) are
> affected and only display in the ugly (and CRT screen killing) white
> background/green borders/black text default.

Oh, somebody actually uses the config block, interesting ;-) Even
though I have written it I have never used it myself, I just set the
colours during boot.

> Is that a bug, or (I barely even dare making such a silly supposition)
> something that was done on purpose ?

Not silly, I have removed it for QDOS WMAN to get the size of the
binary down again, but it's supposed to be included in SMSQ/E. Looks
like it somehow got lost between me and Wolfgang. Wolfgang, please
check that the second input line in smsq_smsq_wman_link reads

input dev8_ee_wman_config_rel

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] GDPR and 25th May

2018-05-04 Thread Marcel Kilgus via Ql-Users
Rich Mellor via Ql-Users wrote:
> With the new GDPR legislation coming in on 25th May - how will the
> mailing list cope with this?

Article 30, section 5:

"5. The obligations referred to in paragraphs 1 and 2 shall not apply
to an enterprise or an organisation employing fewer than 250 persons
unless the processing it carries out is likely to result in a risk to
the rights and freedoms of data subjects, the processing is not
occasional, or the processing includes special categories of data as
referred to in Article 9(1) or personal data relating to criminal
convictions and offences referred to in Article 10."

I think this makes the mailing list excempt from the need to keep
detailed records. Under the presumption that less than 250 people
manage the mailing list, of course.

Marcel

___
QL-Users Mailing List


[Ql-Users] QL-SD progress

2018-04-28 Thread Marcel Kilgus via Ql-Users
For anybody following my struggle to produce actual hardware, there is
a slight update on the progress:

https://www.kilgus.net/2018/04/29/ql-sd-update/

Good night ;) Marcel

___
QL-Users Mailing List


Re: [Ql-Users] QLSD Drivers

2018-04-17 Thread Marcel Kilgus via Ql-Users
Wolfgang Lenerz via Ql-Users wrote:
> new QL-SD drivers for QXL.WIN style container files are on my site
> (wlenerz.com/qlsd).
> These are much improved versions by Marcel Kilgus.
> They should work with later QDOS versions (e.g. JS, MG), Minerva, SMSQ/E.

Thanks Wolfgang. Perhaps a short Whats-New is in order:

- The driver version (currently 1.04) is shown in the ROM message plus a
  message if slot 1 could be initialised or not
- Minerva/QDOS: If a card is found on boot then the device name will be
  briefly changed to MDV so that MDV1_boot can be found and immediately
  renamed back to WIN afterwards
- There was a bug when reading and writing data at the same time. This
  alone should be enough reason to update the driver as it can corrupt
  the image
- Added SGC support code and auto-detection of CPU speed. As said, a
  hardware mod is still needed for full GC/SGC compatibility. But if
  your card worked before it might work even better with this ROM
- CARD_INIT defaults to slot 1 when no parameter is given
- Card changes are detected automatically, so CARD_INIT is basically
  not needed anymore ;)
- WIN2 defaults to QXL.WIN in slot 2, WIN3 defaults to QXL.WIN in slot
  3 (if anybody ever had a slot 3 in the history of QL-SD ;) ). Except
  me and probably Peter, of course
- Added command WIN_CHECK (same as on the Q68) that checks if the image
  file is continuous
- Added SMSQ/E and QDOS compatibility. Only MGG and JS was tested,
  because these were already enough of a pain that I was afraid to
  check out anything older
- Support for multi-block reads, so it should execute your boot file a
  tiny little bit faster

GC only: to get another speed bump load the _BIN driver again in your
boot file, running the driver code from GC-RAM can up the speed
noticably. You can probably run DEL_DEFB afterwards to release the
memory that the ROM driver still held onto (not tested). Or LBYTES the
driver code and issue CARD_INIT before the CALL to the new driver to
release the memory of the ROM driver.

SGC and original QLs do not profit from this, so this is not needed.

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] Graphic objects and padding

2018-04-14 Thread Marcel Kilgus via Ql-Users
pjwitte via Ql-Users wrote:
> If those who "wrote the book" on these matters arent able/willing to
> pipe up, then we'll have to waste some time R-ingTFBs and doing the 
> tests ourselves. I'll be back.

"The books" were written so long ago, even the people who wrote them
must usually spend some serious time to answer questions like yours.

Regarding your question in the forum, the internal save area format
always has a "spare" long-word after each line, fuck knows why. So
that is why every line is 4 bytes longer, because it just writes out
the internal format. But it doesn't matter really, the "increment"
field in the file header is what's important, for all it's worth it
can be one 65kb per line and should still work, the field must just
match the data. If you construct a file yourself, use whatever line
increment pleases you.

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] SerMouse

2018-04-14 Thread Marcel Kilgus via Ql-Users
Dilwyn Jones via Ql-Users wrote:
> SERMouse is a software driver from Albin Hessler to connect a serial PC
> mouse to one of the serial ports SER1 or SER2 of a QL. A specially wired
> adaptor cable is necessary between the mouse connector and the QL serial
> port.

Only for those weird English QLs I think ;)

> Albin Hessler gave Marcel Kilgus permission to release the SerMouse software
> as freeware, so version 3.04 of the software is currently available. I’ve
> added it to the Pointer Environment page on my website to download free of
> charge.

Thanks Dilwyn!

Cheers, Marcel

___
QL-Users Mailing List

[Ql-Users] Cueshell

2018-03-31 Thread Marcel Kilgus via Ql-Users
Happy Eastern everyone,

today I'm proud to present to you Albin Hessler's Cueshell, in my eyes
the best file manager ever written for the QL:

https://www.kilgus.net/2018/03/31/cueshell-the-definitive-file-manager-for-the-ql/

All the best, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] FiFi

2018-03-30 Thread Marcel Kilgus via Ql-Users
> Am 30.03.2018 um 14:18 schrieb François Van Emelen via Ql-Users 
> :
> Thank you. I suppose it is the same version as the one I bought many year ago 
> from Jochen Merz.

Actually I know one user who has bugged Wolfgang so much that he did a few 
updates recently ;) No, it's not me!

Fifi is such an essential tool for me, I've used it at least a million times to 
search through the vast sources that are SMSQ/E.

Thanks! Marcel
___
QL-Users Mailing List

Re: [Ql-Users] QL-SD news

2018-03-29 Thread Marcel Kilgus via Ql-Users
Dave Park via Ql-Users wrote:
> This is amazing work!

Thanks.

> It also means I can stop my occasional work on my QL-SD version. I have no
> desire to sell a QL-SD into a crowded marketplace.
>
> Instead, I'd like to buy one for compatibility testing on Issue 8.

We can certainly arrange something :-)

> This lets me focus on other projects that I have been neglecting this last
> month, due to life events.

Good to hear, frankly it seemed to me like you have too many irons in
the fire at once again anyway. That's the recipe for never finishing
anything. I know because I tend to do that, too... :(

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] QL Video Card?

2018-03-29 Thread Marcel Kilgus via Ql-Users
Peter Graf via Ql-Users wrote:
>> 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?

I've been thinking about this but I'm still probably not good enough
to to pull this off using pure hardware, especially as my goal was
HDMI which makes the task pretty much out of my league especially as
not every FPGA can do the necessary TDMS signals (bought a Spartan
board nonetheless if I ever wanted to try it ;) )

This was supposed to be a pure fun project for 2 or 3 evenings, so I
got a GAL and a bunch of level shifter to connect a Raspberry Pi to
the QL bus and did the rest in software. This is still not trivial as
sampling the bus in the neccesary frequency can only be achieved bare
metal, i.e. without any operating system running. But the video
processor at least handles the whole HDMI stuff, which is neat.

It almost worked before I stopped tinkering with it, it just showed
ALL memory accesses, not just the ones to the screen memory ;-) Some
problem with the address decoding in the GAL. Looked funny, but one
could see the blinking cursor etc.

Then the idea was to use an XC9572XL chip to do both level shifting
and address decoding. After that I had the idea that instead of level
shifting all the signals the CPLD could output them using a very fast
SPI line instead as this would save a lot of lines. The Raspberry
actually has a SPI slave function block, unfortunately nobody ever
used it and therefore it seems to be pretty buggy. That's when time
ran out around Christmas.

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] QL-SD news

2018-03-29 Thread Marcel Kilgus via Ql-Users
Peter Graf via Ql-Users wrote:
>> 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).

There are possibly other factors as well, but it doesn't really
matter. The key here is to only sample the lines at a point in time
when you know they must be valid because otherwise the QL would not
work at all.

>>> 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.

That is indeed cheaper than I expected, Reichelt was at 5€ IIRC. The
whole daugther board including SD socket, voltage regulator and
resistors however costs 1,50€ when bought from a reseller in Germany
or 50ct when bought directly in China... so it's not only cheaper but
saves time in manufacturing.

>> Besides, I don't have your original designs ;)
> There is also the option to ask ;)

I'm a naturally shy guy ;-)

Cheers, Marcel

___
QL-Users Mailing List

Re: [Ql-Users] QL-SD news

2018-03-29 Thread 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. Difficult to tell because the software had a few remaining
issues, too, but I haven't been able to crash it or corrupt any data
for a few days so I consider it stable now.

> That would mean conclusions from Tetroid to non-Tetroid is not
> possible.

Original INGOT 5 GCs were tested and started to work, too. Not with
the latest logic that includes the SGC fix, but the GC fix alone
already worked for them and if anything the latest version should make
it even more stable.

> 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. Besides, I don't have your
original designs ;) Only problem is that the card cannot be centered
in the MDV drive with them, which bothers me a bit but is difficult to
change due to the positions of the screws. Also, dual-slot would be
cool.

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

Eventually, sure.

All the best, Marcel

___
QL-Users Mailing List


[Ql-Users] QL-SD news

2018-03-29 Thread 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/

Hope this is interesting to you all.

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] Stuart Honeyball

2018-03-29 Thread Marcel Kilgus via Ql-Users
pgraf--- via Ql-Users wrote:
> When I read the subject "Stuart Honeyball" I somehow expected he'd
> attend a QL meeting, publish his memoirs, or anything, but not that.

Yes, that would have been preferable.

> 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.

> 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.

> Having good hardware ideas is one thing. Actually finishing a 
> computer, so people can buy it, is a different thing.

True dat.

Marcel


___
QL-Users Mailing List


Re: [Ql-Users] Stuart Honeyball

2018-03-29 Thread Marcel Kilgus via Ql-Users
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.
>
> He passed away peacefully last night (28th March) at 23:45 of
> cancer, according to his wife, Karin.

Oh my! He wasn't that old, was he?

One more true hero of the QL world gone, my condolences :-(

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] Sjef vd Molengraaf

2018-03-15 Thread Marcel Kilgus via Ql-Users
pgraf--- 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".

I guess we can still do 5...

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] Sjef vd Molengraaf

2018-03-15 Thread Marcel Kilgus via Ql-Users
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.

I'm a bit late here, but that is really sad news. I remember the
Eindhoven meetings fondly.

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.

All the best, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] Sinclair QL for Everyone on Facebook

2018-03-08 Thread Marcel Kilgus via Ql-Users
Darren Branagh via Ql-Users wrote:
> Darren Branagh
>
> Sent from My iPhone X.

Is that footer mandatory for people working for Apple? ;)

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] TK2 v2.32

2018-03-04 Thread Marcel Kilgus via Ql-Users
Dave Park via Ql-Users wrote:
> As I am working on accelerated boards, would you be willing to outline the
> tuning/timing issues and what code needs editing to achieve correct
> performance?

Well, the code only has the right timing from ROM as RAM is usually
slower. Same would be true for MDV code.

GC/SGC patch the QDOS code in the ROM copy to comply with the timings
and/or come with their special version of TK2 that includes the
different timings.

SMSQ/E comes with timing constant tables in the network code for the
different platforms, though I don't pretend to fully understand
what's going on there.

> How do you test? By successive approximation, or using a
> calculation?

I didn't do anything, I just used the existing code which is known to
work and give it a quick spin. TT calculated the cycles for his code.

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] TK2 v2.32

2018-03-04 Thread Marcel Kilgus via Ql-Users
Marcel Kilgus via Ql-Users wrote:
> I have released a new (or actually two new) versions of TK2.

Due to feedback from Markus I found another SMSQ/E-dependant code part
in ED that I have now removed. I have updated the files.

Marcel

___
QL-Users Mailing List


[Ql-Users] TK2 v2.32

2018-03-04 Thread Marcel Kilgus via Ql-Users
I have released a new (or actually two new) versions of TK2.

One versions only includes the timing critical parts of the QL-NET
code and the rest can be LRESPRed afterwards.

The other versions included the complete QL-NET code and misses the
"ED" SuperBasic editor instead, which can be LRESPRed afterwards.

Depending on your QL-NET affinity you can chose which version you like
more, in the end both version have the same capabilities when the
missing parts are loaded.

https://www.kilgus.net/2017/03/19/toolkit-ii-the-sequel/

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] R: Source code availability for Minerva v1.92 or v1.89?

2018-03-03 Thread Marcel Kilgus via Ql-Users
Davide Santachiara via Ql-Users wrote:
> As we are riding the wave do you see any chance to fix the palette bug in
> Qmenu which was found by Giorgio Garabello a few weeks ago (cut and paste
> below for your convenience)?

QMenu 8.05 is out

https://www.kilgus.net/smsqe/qmenu/

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] Source code availability for Minerva v1.92 or v1.89?

2018-02-28 Thread Marcel Kilgus via Ql-Users
Martyn Hill via Ql-Users wrote:
> Is QMON yet available as freeware, or otherwise for purchase?

I don't think it's available yet, but should be eventually. Wolfgang,
did you by any chance talk to TT about it?

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] R: Source code availability for Minerva v1.92 or v1.89?

2018-02-28 Thread Marcel Kilgus via Ql-Users
Davide Santachiara via Ql-Users wrote:
> As we are riding the wave do you see any chance to fix the palette bug in
> Qmenu which was found by Giorgio Garabello a few weeks ago (cut and paste
> below for your convenience)?

I don't think you all realize how much work these "tiny fixes" usually
are... but okay, I'll have a look eventually.

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] R: Source code availability for Minerva v1.92 or v1.89?

2018-02-28 Thread Marcel Kilgus via Ql-Users
Dave Park via Ql-Users wrote:
> Would it be possible to send me a copy of this full repaired 64K ROM image
> by email, for testing? I will not distribute it.

You can download it from my blog post if you're satisfied with only
48KB.

> I'm trying to solve a qlnet issue and this might get me on the way...

Unless you're using LBYTES or any other file-header function you are
probably not affected by this issue.

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] Source code availability for Minerva v1.92 or v1.89?

2018-02-27 Thread Marcel Kilgus via Ql-Users
Martyn Hill via Ql-Users wrote:
> I looked again at the other serio vectored routines that themselves call
> io_pend and determined that it was wise to preserve /their/ serio key in
> d0 before resetting to 0 for io_pend, to avoid hammering their ability
> to locate the correct NET driver vector. This step may prove 
> unnecessary, but harmless.

The called routines do not rely on the value in D0 and they have to
overwrite it anyway with their result status. So yeah, it's harmless
but unnecessary ;)

> Both with and without TK2 active, Minnie v1.98b was able to successfully
> LBYTES the image from another QL across the QLNet.

:-)

> As MK put it - back to '...more productive work' - aka, the QLNet to USB
> Bridge adapter (QLUB) - just another couple of weeks before I complete
> the SMSQ/E coding to talk to the uC...

Sounds like a much better use of your time, good luck :-)

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] Source code availability for Minerva v1.92 or v1.89?

2018-02-27 Thread Marcel Kilgus via Ql-Users
Martyn's reply was also sent to the list but probably wasn't published
because it was HTML and my original replay wasn't published because it
came from the wrong sender address... so anyway, here it is once more:

Martyn Hill wrote:
> OMGosh!
>
> Do you know how long I have been staring at the serio/relio code -
> but failed to see that potential flaw?
>
> I shall test by recompiling Minnie an report back here...
>
> Thank you, Marcel, bl**dy genius!!!

Thanks and you're welcome ;) It actually wasn't very difficult so I
have written up a short essay about how I go about debugging this kind
of stuff

https://www.kilgus.net/2018/02/27/debugging-minerva/

It also includes ROM images with the fix. I didn't increase the
version number for now because, well, Minerva is not my project and
we're running out of "sub 2.00" version numbers, which might have
compatibility implications in the future.

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] Source code availability for Minerva v1.92 or v1.89?

2018-02-26 Thread Marcel Kilgus via Ql-Users
Martyn Hill via Ql-Users wrote:
> Specifically, when receiving via LBYTES (and SBYTES at the remote end),
> Minerva 1.97+ on its own receives perfectly, but once the NET driver is
> effectively replaced with TK2 (upto v2.23), issuing LBYTES will 
> completely hang the /receiving /QL - immediately and regardless of 
> whether the sending end has even started.

I had a quick look and actually this was caused by Lau trying to save
2 bytes. When you look at io_serio_asm

io_pend
*moveq   #0,d0   test routine is the first element
bsr.s   vectest set up test routine address
bra.s   callit  go do it

you see that the moveq is commented out because "d0 is 0 anyway!".
Well, except in the case when io_pend is called through headr1, in
this case D0 has some other value and the whole thing will crash.

I hope you can now resume more productive work :-)

Cheers, Marcel

___
QL-Users Mailing List


Re: [Ql-Users] QA.RESRI info incorrect

2018-02-14 Thread Marcel Kilgus via Ql-Users
pjwitte via Ql-Users wrote:
> On 14/02/2018 15:04, Marcel Kilgus via Ql-Users wrote:
>> pjwitte via Ql-Users wrote:
>>> Error returns:
>>> IMEM out of memory [SMSQ]
>> This is correct.
> If this is correct, isnt that bad news for any old toolkits that dont 
> expect the call to return on IMEM (as per the original Technical 
> Guide)? They would assume the memory is there and poke a hole in it..

Yes, actually I might be wrong here, looks like it tries to abandon
the current command in this case.

>>> Error returns: none
>> This is not ;-)
> You are certain of this?

Nah, for me nothing is certain in SBasic ;-)

By the way, if you look at the Minerva code you see

retzero
moveq   #0,d0   this was silly, but Qlib expected it!
rts

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] QA.RESRI info incorrect

2018-02-14 Thread Marcel Kilgus via Ql-Users
pjwitte via Ql-Users wrote:
> Error returns:
> IMEM out of memory [SMSQ]

This is correct.

> A1                                     A1 ???

This is probably correct.

> Error returns: none

This is not ;-)

Marcel

___
QL-Users Mailing List

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

2018-02-02 Thread Marcel Kilgus via Ql-Users
Dave Park via Ql-Users wrote:
> Marcel, would you be willing to share your modifications for QL-SD2?

Sure, I can be bribed :-P Also, it's GPLed anyway... but I want to
make some more tests, preferably with the original hardware first.

Marcel

___
QL-Users Mailing List


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

2018-02-02 Thread Marcel Kilgus via Ql-Users
pgraf--- 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.

I've heard, but bot on my system. There was one driver version where
it briefly managed to display halve a directory before it turning into
scrambled screen, but that was about it.

> 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?

Well, the Tetroid-Card has the 30ns displacement between the adress
bus changing and ROMOE being cleared. I think it's entirely plausible
that other GoldCards might have a different timing, making the "it
works or not" a matter of pure probability.

As Tobias wrote "I have mixed experiences with GoldCards - One doesn't
work at all, the other one (at least in one specific QL) rather well
for days together with a QL-SD. But not well enough to go through the
nuisance of destroyed file system every other week or so." You might
get lucky for a while, especially if timing is very tight, but then
one day you might not.

I've also heard that for some people it only works when the driver is
loaded into RAM, which reduces the ROM accesses and once again reduced
the probability for a spurious actions.

Mind you I don't consider this a bug in QL-SD, it's more a bug in GC
and I'm trying to create a stable workaround. It'd be very interesting
how an SGC handles this.

Marcel

___
QL-Users Mailing List


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

2018-02-02 Thread Marcel Kilgus via Ql-Users
Marcel Kilgus 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 :-)

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/

Now I'm looking forward to test the fix on the original hardware, as
the clone is still a bit unwieldly ;-)

Marcel

___
QL-Users Mailing List


Re: [Ql-Users] Disk Mate 5

2018-02-01 Thread Marcel Kilgus via Ql-Users
simon629--- via Ql-Users wrote:
> Hi Everyone
> Is there and more news when Disk Mate 5 is being updated
> OK Thankssimon629Simon Foster

Disk Mate will never be updated, there are no sources for it anymore.

Marcel

___
QL-Users Mailing List


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

2018-01-23 Thread Marcel Kilgus via Ql-Users
Graeme Gregory via Ql-Users wrote:
> Doesnt gold card have a parralell port?
>
> That should be enough IO pins to connect an SD card which just needs SPI.

I think bit-banging would noticably reduce the transfer speed.

Marcel

___
QL-Users Mailing List


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

2018-01-23 Thread Marcel Kilgus via Ql-Users
Tobias Fröschle via Ql-Users wrote:
> that Schmidt-trigger is already there. Nice little SMD bug under
> the socket that sits in the ROMOEH line. Apparently, it doesn't help.

At this point I'm just glad that my idea was not nonsense but turns
out to be actually implemented in the design :-) And wow, that thing
is small! A digital filter in the CPLD might help then, but that needs
Flip-Flops which are usually not massively available in those kind of
chips...

Marcel

___
QL-Users Mailing List

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

2018-01-22 Thread Marcel Kilgus via Ql-Users
pgraf--- via Ql-Users wrote:
> Remark: This new driver can not be expected to resolve the signal
> quality issue between (Super)GoldCard and QL-SD. This remains a 
> hardware problem.

One beta release ALMOST worked with my Gold Card, it could read a
directory half-way before outputting garbage.

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, because the chip samples them faster as older chips would, is
that about right? Would it help to put a 74-style Schmitt-trigger in
front of ROMOEH or something like that?

Marcel

___
QL-Users Mailing List


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

2018-01-22 Thread Marcel Kilgus via Ql-Users
Martyn Hill via Ql-Users wrote:
> Do we have any understanding of the QL (Minerva) memory utilisation of
> WIN as compared to SDC? I'm thinking about the need with the SDC driver
> to keep container file-size small in order not to consume QL memory too
> aggressively for its (equivalent of) slave-blocks. E.g. for an 
> unexpanded QL of 128k, about 1.5MB container size seems to be the limit
> before you take too much memory to run the machine effectively.

Well, both drivers need to keep the FAT in memory, so the bigger the
container, the more memory you need for that (my 100MB file needs
about 100kb, so you probably want to stay smaller ;). More than 1.5MB
should be possible, though. Slave blocks probably don't really matter
IMHO.

Marcel

___
QL-Users Mailing List


  1   2   3   4   5   6   7   8   9   10   >