subject:"\[Ql\-Users\] Q60 aging problems"

Peter Graf wrote:

> 2) Use the QLWA driver of SMSQ/E and change the intitialization / block
> operations for SDHC card. You could look at the QL-SD driver sources or
> at the sources of my Q68 bootloader (written in C) for that purpose.

For a start, SMSQ/E could consider the SDHC card fully initialized,
because the bootloader has already done that job. Then, for example,
reading a 512 bytes sector becomes as simple as this:

unsigned char sdhc_read_sector (unsigned long addr,
  unsigned char* buffer)
{
  static unsigned short a;
  static unsigned char cmd[6];

  cmd[0] = 0x51;
  cmd[1] = addr >>24;
  cmd[2] = addr >>16;
  cmd[3] = addr >>8;
  cmd[4] = addr;
  cmd[5] = 0xFF;

  MMC_ENABLE;
  if (sdhc_write_command (cmd) != 0)
  {
return 0;
  }
  for (a=0;a<512;a++)
  {
*buffer++ = sdhc_read_byte();
  }
  sdhc_read_byte();
  sdhc_read_byte();
  MMC_DISABLE;
  return 0;
}

___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

Wolf wrote:

> Though I don't remember you trying to reach out to me in this respect,
> if the question is whether somebody could port SMSQ/E to your machine, I 
> might be tempted to have a go a it.

Thierry has expressed interest in the Q68, and SMSQ/E will obviously be
needed for him. That's why I asked.

It was very easy to port QDOS Classic to the Q68, so I suspect that
SMSQ/E should not be much harder for someone who knows it. Changing ROM
on the Q68 is as easy as writing a binary to SDHC card or download it
from serial port.

Before you get tempted too much, please consider the SDHC card driver
issue. QDOS Classic and Minerva both work on the Q68, but the QL-SD
driver clashes with other extensions. Similar effects were seen under
Qemulator and UQLX, for which the same native driver minus the hardware
specific code exists.

Basically, I see three options:

1) Use the same driver for SMSQ/E and likely run into similar problems.
You could debug most of the driver without hardware, if you implement
the simple BDI interface, used by Qemulator and UQLX, in your own
emulator also. See http://www.dilwyn.me.uk/qlsd/bdi_spec.txt for the BDI
spec and qlsd-starterpack.zip at the same website for the driver.

2) Use the QLWA driver of SMSQ/E and change the intitialization / block
operations for SDHC card. You could look at the QL-SD driver sources or
at the sources of my Q68 bootloader (written in C) for that purpose. I
think the chance to get a rock-solid driver is better with QLWA, but the
SDHC card won't be readable on the black box then - unless you extend
the (S)GC version of SMSQ/E also.

3) Wait until someone else has solved the QL-SD driver issues.

> Please note the choice of words. There would be no guarantee that I 
> could ever pull it of, or that I could spend a certain amount of time on 
> this project. Nor could I give a timeframe... Moreover, my experience 
> with really programming for a determined machine approaches 0.

All we do is without guarantee or timeframe. I have lost track of SMSQ/E
completely, so I'm not sure how much help I can be. And like must of us,
I suffer from lack of time.

The Q68 is sort of a mix between QL and Q60, minus the difficult stuff.
A very simple machine from an OS perspective.

Peter

___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

Thierry Godefroy wrote:

>>> Again, I don't see why you exclude the possibility to bring the necessary
>>> signals to the daughter board via "flying" wires soldered on the
>>> corresponding pads under the Q60 PCB... I'd rather use a solder iron once
>>> and for all than loose performances with a kuldgy display driver.
>>
>> Because the wiring is HF-critical,
> 
> 66MHz is not *that* high a frequency, and using short, flat wires ("câbles
> en nappe" in French: I don't remember the name in English) would likely do
> just fine.

Would be pure luck! Firstly, there are 80 MHz machines also. Secondly,
we are not talking a situation where both ends are terminated correctly
for a ribbon cable. The only reasonable way would probably be to use
wire-wrap lines, evenly glued to the mainboard, so the ground plane
still has some effect. I do not want to explain this to average users,
nor deal with the complaints if it only works "sometimes".

Mind you, in the late 68K / early PowerPC area, companies like Apple had
difficulties to make 66 MHz mainboards, even with multilayer PCBs and
ground planes! Ribbon cable wiring is far worse.

Peter

___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

2016-03-12 Thread Thierry Godefroy

On Sat, 12 Mar 2016 17:27:37 +0100, Peter Graf wrote:

> > I therefore (and I don't think I'm alone with that feeling) don't
> > consider "genuine QDOS" (and QL hardware) compatibility as a requirement,
> > especially not when it involves forbidding myself to use more modern
> > hardware or simply to keep my systems up to date with modern peripherals
> > (such as a monitor).
> 
> Then let me understand, why do you still want native hardware at all?

Perhaps because I want to keep the computers I got (in order of
acquisition: ZX-81, QL, Thor XVI, PC+QXL, Atari 1040 STE, SGC+Aurora,
Falcon 030, Q60, several PCs, and a few more "minor" computers) fully
functionnal, even if I won't use some of them more than once a year ?

Call me nostalgic or conservative... :-D

> You seem to want native hardware as up-to-date as possbile. Wouldn't it
> be better then to concentrate efforts on the FPGA-based Q68 approach?

Perhaps because I spent a lot of money for the Q60 ?
Perhaps because the Q60 is still the fastest native hardware I can run
SMSQ/E onto and which, as a bonus, can also run Linux ?

> I mean the Q68 is based on a 8 year old chip and reaches QXL speed
> without caching already. It is only a matter of time, when FPGAs will
> surpass the Q60.

I'd love to see this happening: I could then consider adding a new
computer to my collection. ;-)

> I understand this, but reading such a statement from one of the last QL
> developers who are at least reachable, is a bit depressing. I ask myself
> wether the only way I can bring forward a piece of QL hardware, is to do
> EVERYTHING on the software side myself?

Alas, the QL world lost a load of excellent programmers to pragmatism,
lack of time, lack of incentive, financial constraints, etc...
One programmer (or even ten very competent and proficient programmers)
can't fill the gap which now separates the QL-compatible computers with
modern computers. Now is a time of networking, 3D real time rendering,
video streaming, etc, all of which can't be done (or only in an
extremely rudimentary way, e.g. for networking) with a QDOS/SMS machine.

Back in 2001, when I released the ATAPI driver for the Q60 (and Qubide,
but it was really originally developed for and on the Q60), I still had
plenty of projects (I first wanted to finish the CDROM driver and make
it into a proper, full fledged level3 SMS driver, then I wanted to write
an Ethernet driver and port a C-written lightweight TCP/IP stack to
SMSQ/E... among other projects).
But professionnal and life constraints decided otherwise, and when I
could again get access to my Q60, two years later, things already
dramatically changed, both in the QL world, and in the PC world...
That's when I realized that the way of the pragmatism was, sadly, the
only way for me...

Believe me, I'd like that each day would count 72 hours: then, perhaps
I would be able to do everything I want to do, including programming
old computers, even if just for the fun of it.

So, yes, it's kind of depressing. But I'm not really someone who wallows
in depressive mood. ;-D

> The first QL-SD drivers were developped by myself, I was at least
> capable to understand the code and to change it. I moved to Adrians
> drivers, because I was glad for the help, but he suddenly left the
> scene, and now I don't have the time to learn and debug his code. His
> driver seems to have an issue which conflicts the Pointer Environment -
> on both Qemulator and the Q68. I tried to motivate others to debug this,
> but failed.
> 
> Do you think your decision "pragmatism over passion" is final? If not,
> what could be an incentive?

I learned by experience, over the past 5 decades, that "you can never say
never", and neither I. I just don't see things changing favorably in a
foreseeable future.

The problem is not as much the incentive (I'd really love to develop again
under QDOS/SMS on 68K hardware, just for the fun of it) as the lack of
free time.

> > Again, I don't see why you exclude the possibility to bring the necessary
> > signals to the daughter board via "flying" wires soldered on the
> > corresponding pads under the Q60 PCB... I'd rather use a solder iron once
> > and for all than loose performances with a kuldgy display driver.
> 
> Because the wiring is HF-critical,

66MHz is not *that* high a frequency, and using short, flat wires ("câbles
en nappe" in French: I don't remember the name in English) would likely do
just fine.

> and because I would have to organize a service who does it in a
> professional manner! A normal user could not just buy and insert a board,
> but would need to remove the Q60 mainboard from his system, ship it
> somewhere with risk of damage and loss, etc.

I was more seeing it as a hobbyist DIY mod... Time for a poll among Q60
owners ?

> > Problem: as I understand it, you'd use additional RAM on the daughter
> > board, but that RAM won't be dual ported, like the Q60 VRAM is, so the
> > access to it would be much slower... Not really

Re: [Ql-Users] Q60 aging problems

2016-03-12 Thread Wolf


Hi,

(snp)


I understand this, but reading such a statement from one of the last QL
developers who are at least reachable, is a bit depressing. I ask myself
wether the only way I can bring forward a piece of QL hardware, is to do
EVERYTHING on the software side myself?

The first QL-SD drivers were developped by myself, I was at least
capable to understand the code and to change it. I moved to Adrians
drivers, because I was glad for the help, but he suddenly left the
scene, and now I don't have the time to learn and debug his code. His
driver seems to have an issue which conflicts the Pointer Environment -
on both Qemulator and the Q68. I tried to motivate others to debug this,
but failed.


Though I don't remember you trying to reach out to me in this respect,
if the question is whether somebody could port SMSQ/E to your machine, I 
might be tempted to have a go a it.


Please note the choice of words. There would be no guarantee that I 
could ever pull it of, or that I could spend a certain amount of time on 
this project. Nor could I give a timeframe... Moreover, my experience 
with really programming for a determined machine approaches 0.


Wolfgang




___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

Thierry Godefroy wrote:

> Frankly, I never ran QDOS Classic short of one quick test. SMSQ/E is so
> much better (and now even Open Source and thus free, just like QDOS
> Classic), that it makes no sense whatsoever for me to run any old-
> fashioned QDOS "flavour" (my QXLs, SCG+Aurora systems and the QPC2 and
> SMSQmulator emulators are also all running SMDQ/E).
> 
> I therefore (and I don't think I'm alone with that feeling) don't
> consider "genuine QDOS" (and QL hardware) compatibility as a requirement,
> especially not when it involves forbidding myself to use more modern
> hardware or simply to keep my systems up to date with modern peripherals
> (such as a monitor).

Then let me understand, why do you still want native hardware at all?

You seem to want native hardware as up-to-date as possbile. Wouldn't it
be better then to concentrate efforts on the FPGA-based Q68 approach? I
mean the Q68 is based on a 8 year old chip and reaches QXL speed without
caching already. It is only a matter of time, when FPGAs will surpass
the Q60.

>> [Q68]
>>> Sounds and looks good... The small size would make it an ideal "portable"
>>> QL...
>>
>> Thanks. Who would best be able to port SMSQ/E?
> 
> Good question... Several people could (Tony, Wolf, Marcel, myself,
> Adrian for the SD driver, probably a few others), but the relevant
> question is: who would be ready/capable of spending time porting it ?
> 
> I cannot answer for the others but I'm myself involved in several large
> pieces of software (mostly under Linux, mostly in C++), under various
> nicknames (for privacy purpose: we are no more in the 90s, when Internet
> was only used by scientists, programmers and geeks; Big Brother(s) is(are)
> indeed watching us nowadays) and can't afford spending time any more
> programming seriously under QDOS/SMS, alas... I love SMSQ, I love the 68K,
> I love(d) programming (especially in assembler) for them, but pragmatism
> won over passion: I just can't miss all the things modern OSes and harware
> can do nowadays, even if it's shitty hardware (PCs and x86 CPUs: what a
> pile of dung !) and poor OSes (in my view, even Linux sucks). :-/

I understand this, but reading such a statement from one of the last QL
developers who are at least reachable, is a bit depressing. I ask myself
wether the only way I can bring forward a piece of QL hardware, is to do
EVERYTHING on the software side myself?

The first QL-SD drivers were developped by myself, I was at least
capable to understand the code and to change it. I moved to Adrians
drivers, because I was glad for the help, but he suddenly left the
scene, and now I don't have the time to learn and debug his code. His
driver seems to have an issue which conflicts the Pointer Environment -
on both Qemulator and the Q68. I tried to motivate others to debug this,
but failed.

Do you think your decision "pragmatism over passion" is final? If not,
what could be an incentive?

> Again, I don't see why you exclude the possibility to bring the necessary
> signals to the daughter board via "flying" wires soldered on the
> corresponding pads under the Q60 PCB... I'd rather use a solder iron once
> and for all than loose performances with a kuldgy display driver.

Because the wiring is HF-critical, and because I would have to organize
a service who does it in a professional manner! A normal user could not
just buy and insert a board, but would need to remove the Q60 mainboard
from his system, ship it somewhere with risk of damage and loss, etc.

>> It would be up to the driver to use only 32 bit wide access! (This might
>> be achievable by making the screen area copyback-cacheable and force a
>> flush with every 50 Hz interrupt.)
> 
> Kludgy...

I know.

>> The normal video circuitry of the Q60 would remain intact, a second
>> 800x600 screen would be added, with separate VGA connector. I would be
>> mapped into the ROM address area.
> 
> Problem: as I understand it, you'd use additional RAM on the daughter
> board, but that RAM won't be dual ported, like the Q60 VRAM is, so the
> access to it would be much slower... Not really appealing...

You misunderstand. The FPGA and RAM would be so fast, that access from
video side and CPU side would interleave without any need for waits.
Effectively faster than the Q60 VRAM.

Peter

___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

2016-03-12 Thread Thierry Godefroy

On Sat, 12 Mar 2016 10:52:38 +0100, Peter Graf wrote:

> Derek Stewart wrote:
> .../...
> > If the Jamma GBS8220 board is connected to the Q60 VGA port, this does 
> > make the display better, but still needs a little tweaking to get full 
> > screen display.

I got no result at all (no sync) with a GBS8220 v3, and no amount of sync
signals tweaking resulted in anything for me... :-(

> > Maybe solution would be to signal condition the VGA signal coming out
> > of the Q60 VGA connector.
> > 
> > This is also difficult, but non-destructive on the Q60 board.

Since most of the work of a converter is to reconstitute the pixel clock
and deduce the resolution to also reconstitute proper line and frame
clocks, it would be indeed easier if we could get all these clock signals
right from the Q60 (or any other QL compatible: I'm thinking about the
Q40, the Thor XVI, the QL itself...), especially knowing the exact format
of the picture (resolution, number of colours). The "converter" would then
just have to store a full frame (or two) in memory and output them back
as a SVGA signal.

> The problem with most VGA converters is that they detect 800x600 from
> the Q60's signal. I'm sure that in many cases, 1024x512 would be
> possible if the converter just knew about the existence of this mode.

Possibly, depending whether the converter is using "standard" chips
(designed for standard EGA/*VGA resolutions) or not...

> Maybe if we can find someone who has connections to a smaller converter
> manufacturer, they would do a change if we commit to buy a certain
> number of devices.

That would be great, yes...

Thierry.
___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

2016-03-12 Thread Thierry Godefroy

On Sat, 12 Mar 2016 01:00:17 +0100, Peter Graf wrote:

> > Frankly, such old pieces of software are probably best ran from emulators
> > if they can't cope with variable size/address display... They would also
> > fail to run on a QXL in (S)VGA mode or on an Aurora/SGC system too. I won't
> > call this an issue and I think this kind of "incompatibility" should not
> > limit and forbid us to get a better Q60 display...
> 
> Well the Q60 is a retro computer now, and QDOS Classic running old
> software is part of the heritage. I'm reluctant to restrict the Q60 to
> newer QL software - the whole combination is no longer modern anyway!

Frankly, I never ran QDOS Classic short of one quick test. SMSQ/E is so
much better (and now even Open Source and thus free, just like QDOS
Classic), that it makes no sense whatsoever for me to run any old-
fashioned QDOS "flavour" (my QXLs, SCG+Aurora systems and the QPC2 and
SMSQmulator emulators are also all running SMDQ/E).

I therefore (and I don't think I'm alone with that feeling) don't
consider "genuine QDOS" (and QL hardware) compatibility as a requirement,
especially not when it involves forbidding myself to use more modern
hardware or simply to keep my systems up to date with modern peripherals
(such as a monitor).

> Also, some software like PQIV was optimized for the Qx0 aspect ratio and
> screen size.

The aspect ratio has always been a (quite minor) issue with all modern QL
compatible hardware (QXL, Aurora, QPC2, etc), so it's not a show stopper
either as far as I am concerned.

> [Q68]
> > Sounds and looks good... The small size would make it an ideal "portable"
> > QL...
> 
> Thanks. Who would best be able to port SMSQ/E?

Good question... Several people could (Tony, Wolf, Marcel, myself,
Adrian for the SD driver, probably a few others), but the relevant
question is: who would be ready/capable of spending time porting it ?

I cannot answer for the others but I'm myself involved in several large
pieces of software (mostly under Linux, mostly in C++), under various
nicknames (for privacy purpose: we are no more in the 90s, when Internet
was only used by scientists, programmers and geeks; Big Brother(s) is(are)
indeed watching us nowadays) and can't afford spending time any more
programming seriously under QDOS/SMS, alas... I love SMSQ, I love the 68K,
I love(d) programming (especially in assembler) for them, but pragmatism
won over passion: I just can't miss all the things modern OSes and harware
can do nowadays, even if it's shitty hardware (PCs and x86 CPUs: what a
pile of dung !) and poor OSes (in my view, even Linux sucks). :-/

On Sat, 12 Mar 2016 11:19:58 +0100, Peter Graf wrote:

> Hi Thierry,
> 
> your persistance wanting 800x600 resolution for the Q60,

I'd prefer "pargmatism" over "persistance": I'm open to any other
solution that would provide proper display on modern monitors...

> combined with your optimism about the OS changes

The software changes for a simple display size change are indeed
totally trivial (just a few constants to modify in the SMSQ/E and
Linux sources). See:
- smsq/iod/con2/q40/disp_size.asm (q40_sizes label) for SMSQ/E
- drivers/video/fbdev/q40fb.c for Linux.
And that's it !

> has inspired a new idea in my head.

I didn't know I was a muse... :-D

> The memory area accessible on the Q60 ROM sockets is 1048576 bytes long,
> but 800x600 requires only 96 bytes, leaving 88576 bytes free.
> 
> I could make an FPGA, which places bootloader code into the free area
> (at address 0) on reset. That bootloader could load an SMSQ/E or QDOS
> Classic Binary from SD card into RAM. Later on, the OS could overwrite
> the bootloader with it's own exception vectors. I wrote similar FPGA
> bootloader code for the Q68 already.
> 
> The board would require not much more than the connectors, one FPGA, one
> RAM, and some resistors/capacitors. No additional wiring.
> 
> Disadvantage: No 8 bit or 16 bit access possible - there are no such
> signals on the ROM sockets.

Again, I don't see why you exclude the possibility to bring the necessary
signals to the daughter board via "flying" wires soldered on the
corresponding pads under the Q60 PCB... I'd rather use a solder iron once
and for all than loose performances with a kuldgy display driver.

> It would be up to the driver to use only 32 bit wide access! (This might
> be achievable by making the screen area copyback-cacheable and force a
> flush with every 50 Hz interrupt.)

Kludgy...

> The normal video circuitry of the Q60 would remain intact, a second
> 800x600 screen would be added, with separate VGA connector. I would be
> mapped into the ROM address area.

Problem: as I understand it, you'd use additional RAM on the daughter
board, but that RAM won't be dual ported, like the Q60 VRAM is, so the
access to it would be much slower... Not really appealing...

Best regards,

Thierry.
___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

Derek Stewart wrote:

> Even cutting the PLCC socket would have risks to damage the tracks on 
> the board due to stress of the cutting.
> 
> I have temperature controlled vacuum desoldering equipment, which should 
> desolder the PLCC socket pins without damage. Much better and safer than 
> hand pump desoldering equipment.
> 
> The plugin adapter is a good idea, but the development costs would be 
> high and the changes to the operating system would difficult.
> 
> If the Jamma GBS8220 board is connected to the Q60 VGA port, this does 
> make the display better, but still needs a little tweaking to get full 
> screen display. Maybe solution would be to signal condition the VGA 
> signal coming out of the Q60 VGA connector.
> 
> This is also difficult, but non-destructive on the Q60 board.

The problem with most VGA converters is that they detect 800x600 from
the Q60's signal. I'm sure that in many cases, 1024x512 would be
possible if the converter just knew about the existence of this mode.

Maybe if we can find someone who has connections to a smaller converter
manufacturer, they would do a change if we commit to buy a certain
number of devices.

Peter

___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

2016-03-12 Thread Derek Stewart

Hi,

Even cutting the PLCC socket would have risks to damage the tracks on
the board due to stress of the cutting.

I have temperature controlled vacuum desoldering equipment, which should
desolder the PLCC socket pins without damage. Much better and safer than
hand pump desoldering equipment.

The plugin adapter is a good idea, but the development costs would be
high and the changes to the operating system would difficult.

If the Jamma GBS8220 board is connected to the Q60 VGA port, this does
make the display better, but still needs a little tweaking to get full
screen display. Maybe solution would be to signal condition the VGA
signal coming out of the Q60 VGA connector.

This is also difficult, but non-destructive on the Q60 board.

Regards,

Derek

On 11/03/16 23:46, Thierry Godefroy wrote:

On Fri, 11 Mar 2016 23:22:40 +, derek wrote:

I would be careful desoldering a PLCC chip,

Actually, the socket, not the chip... ;-)

the D Q60 was soldered correctly under the correct soldering
temperature.

I have repaired some Qbranch Q40 boards, which had issues with the
over heating of the soldering, resulting in detachment of the through
hole plating.

Yes, I do agree that it won't be for the faint hearted... A "dirty"
but safer (for the PCB) solution, since the PLCC socket will be trashed
anyway, is to use a small cutting pliar to (carefully) destroy the
socket, then to unsolder each pin individually once all the plastic
parts have been removed.

This said, an adapter is still the best solution. A quick search on
the web lead me to this:
http://www.ironwoodelectronics.com/catalog/Content/Templates/PartGrids.cfm?StartRow=21=PL-PLCC44-H-01=PL-PLCC_TABLE
http://www.ironwoodelectronics.com/catalog/Content/Drawings/PL-PLCC44-H-01Dwg.pdf

Not sure how mush it costs, but maybe not much more than the
RTC+battery chip as sold by Farnell... ;-P

Thierry.
___
QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

Thierry Godefroy wrote:

> This said, an adapter is still the best solution. A quick search on
> the web lead me to this:
> http://www.ironwoodelectronics.com/catalog/Content/Templates/PartGrids.cfm?StartRow=21=PL-PLCC44-H-01=PL-PLCC_TABLE
> http://www.ironwoodelectronics.com/catalog/Content/Drawings/PL-PLCC44-H-01Dwg.pdf
> 
> Not sure how mush it costs, but maybe not much more than the
> RTC+battery chip as sold by Farnell... ;-P

I had a quote from Ironwood, too.
Forgot the figure, but it was so painful that I immediately decided it
makes no sense.
___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

Thierry Godefroy wrote:

>>> No chance to get a "larger" (i.e. with more gates) CPLD that would fit
>>> the same socket ?... Or perhaps by using a modern and larger (in both
>>> size and number of gates) CPLD that would piggy-back on the old CPLD
>>> socket via a small adpater printed circuit ?...
>>
>> I have considered that, but adaptors which fit into PLCC are
>> prohibitively expensive and hard to get.
> 
> Well, the mod could also involve unsoldering the PLCC (correct me if
> I'm wrong but IRC, it's a through-holes one) and replacing it with
> pinheads, for example, that would plug into the add-on board.

Yes. But that's work with some risk.

>>> A native 800x600 resolution would be a definitive (and probably the
>>> best) solution to the problem, so I think it would be worth investigating
>>> some more its feasability...
>>
>> Still 800x600 would require change of all three operating systems
> 
> These are extremely *minor* and *easy* changes (and SMSQ/E can already
> cope with 800x600 screens)...

Not sure how much sense QDOS Classic would make without the QL style
screens, and how one would easily change it.

>> and several pieces of application software! Moreover, software that directly
>> writes into QL 512x256 would fail, like the beloved QL Chess.
> 
> Frankly, such old pieces of software are probably best ran from emulators
> if they can't cope with variable size/address display... They would also
> fail to run on a QXL in (S)VGA mode or on an Aurora/SGC system too. I won't
> call this an issue and I think this kind of "incompatibility" should not
> limit and forbid us to get a better Q60 display...

Well the Q60 is a retro computer now, and QDOS Classic running old
software is part of the heritage. I'm reluctant to restrict the Q60 to
newer QL software - the whole combination is no longer modern anyway!
Also, some software like PQIV was optimized for the Qx0 aspect ratio and
screen size.

>> .../...
>>> However, another issue with this solution could be the lack of room to
>>> piggy-back a daughter board on the EPROM slots, especially with the 2
>>> ISA slots occupied and a heat-sink+fan on the 68060...
>>
>> It depends. Using SMD components, the board could be about as small as
>> the ROM socket area.
> 
> In this case, I think it's still worth a solution...

Noted.

>> Q68 runs about QXL speed, even without the cache I am working on.
> 
> Not bad at all.
> 
>> Features
>>
>> - Plain 68000 core, 68020 nearly complete
>> - 32 MB SDRAM
>> - PS/2 keyboard and mouse
>> - Two fullsize SD card interfaces
>> - SER
>> - Ethernet
>> - Battery buffered RTC (and yes, the battery is separate!)
> 
> :-D

I just saw that it is actually a capacitor, not a battery! The hardware
design was done so long ago - I even forget the simple things.

>> - Stereo sound
>> - Up to 1024x768 VESA VGA, QL modes in hardware
>> - 8x10 cm board size, fitting existing nice case
>> - Single 5V power supply
>>
>> I demonstrated my Q68 at the "QL is 30" show, where someone took a picture:
>>
>> http://www.qlforum.co.uk/viewtopic.php?f=12=1087=10
>>
>> Meanwhile I replaced the wired components you see on that picture by SMD
>> for machine manufacture. QDOS Classic and Minerva are running, but
>> issues with QL-SD driver and Pointer Environment.
> 
> Sounds and looks good... The small size would make it an ideal "portable"
> QL...

Thanks. Who would best be able to port SMSQ/E?

Peter

___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

On Fri, 11 Mar 2016 23:22:40 +, derek wrote:

> I would be careful desoldering a PLCC chip,

Actually, the socket, not the chip... ;-)

> the D  Q60 was soldered correctly under the correct soldering
> temperature. 
> 
> I have repaired some Qbranch Q40 boards, which had issues with the
> over heating of the soldering, resulting in detachment of the through
> hole plating.

Yes, I do agree that it won't be for the faint hearted... A "dirty"
but safer (for the PCB) solution, since the PLCC socket will be trashed
anyway, is to use a small cutting pliar to (carefully) destroy the
socket, then to unsolder each pin individually once all the plastic
parts have been removed.

This said, an adapter is still the best solution. A quick search on
the web lead me to this:
http://www.ironwoodelectronics.com/catalog/Content/Templates/PartGrids.cfm?StartRow=21=PL-PLCC44-H-01=PL-PLCC_TABLE
http://www.ironwoodelectronics.com/catalog/Content/Drawings/PL-PLCC44-H-01Dwg.pdf

Not sure how mush it costs, but maybe not much more than the
RTC+battery chip as sold by Farnell... ;-P

Thierry.
___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

I would vote for the Q68

Regards

Derek

 Original message 
From: Peter Graf <pg...@q40.de> 
Date: 11/03/2016  23:19  (GMT+00:00) 
To: ql-us...@q-v-d.com 
Subject: Re: [Ql-Users] Q60 aging problems 

Am 11.03.2016 23:30, schrieb Malcolm Lear:
> Assuming the PLCC has a through hole socket, would it be possible to 
> solder a pcb carrier for a more modern chip on the back of the board 
> using the PLCC pins that protrude through?

Probably yes. But soldering would require to heat up all PLCC pins at
once, or to desolder them first, so the carrier board can fit decently.
Seems a bit risky for the mainboard.
___
QL-Users Mailing List
___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

2016-03-11 Thread Malcolm

Yes true, thinking caps on :-)

On 11 March 2016 23:19:18 GMT+00:00, Peter Graf  wrote:
>Am 11.03.2016 23:30, schrieb Malcolm Lear:
>> Assuming the PLCC has a through hole socket, would it be possible to 
>> solder a pcb carrier for a more modern chip on the back of the board 
>> using the PLCC pins that protrude through?
>
>Probably yes. But soldering would require to heat up all PLCC pins at
>once, or to desolder them first, so the carrier board can fit decently.
>Seems a bit risky for the mainboard.
>___
>QL-Users Mailing List

-- 
Sent from my Android phone with K-9 Mail.
___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

Hi,

I would be careful desoldering a PLCC chip, the D  Q60 was soldered correctly 
under the correct soldering temperature. 

I have repaired some Qbranch Q40 boards, which had issues with the over heating 
of the soldering, resulting in detachment of the through hole plating.

Regards

Derek

 Original message 
From: Thierry Godefroy <ql.us...@free.fr> 
Date: 11/03/2016  23:03  (GMT+00:00) 
To: ql-us...@q-v-d.com 
Subject: Re: [Ql-Users] Q60 aging problems 

On Fri, 11 Mar 2016 23:17:52 +0100, Peter Graf wrote:

> .../...
> > No chance to get a "larger" (i.e. with more gates) CPLD that would fit
> > the same socket ?... Or perhaps by using a modern and larger (in both
> > size and number of gates) CPLD that would piggy-back on the old CPLD
> > socket via a small adpater printed circuit ?...
> 
> I have considered that, but adaptors which fit into PLCC are
> prohibitively expensive and hard to get.

Well, the mod could also involve unsoldering the PLCC (correct me if
I'm wrong but IRC, it's a through-holes one) and replacing it with
pinheads, for example, that would plug into the add-on board.

> > A native 800x600 resolution would be a definitive (and probably the
> > best) solution to the problem, so I think it would be worth investigating
> > some more its feasability...
> 
> Still 800x600 would require change of all three operating systems

These are extremely *minor* and *easy* changes (and SMSQ/E can already
cope with 800x600 screens)...

> and several pieces of application software! Moreover, software that directly
> writes into QL 512x256 would fail, like the beloved QL Chess.

Frankly, such old pieces of software are probably best ran from emulators
if they can't cope with variable size/address display... They would also
fail to run on a QXL in (S)VGA mode or on an Aurora/SGC system too. I won't
call this an issue and I think this kind of "incompatibility" should not
limit and forbid us to get a better Q60 display...

> .../...
> > However, another issue with this solution could be the lack of room to
> > piggy-back a daughter board on the EPROM slots, especially with the 2
> > ISA slots occupied and a heat-sink+fan on the 68060...
> 
> It depends. Using SMD components, the board could be about as small as
> the ROM socket area.

In this case, I think it's still worth a solution...

> Q68 runs about QXL speed, even without the cache I am working on.

Not bad at all.

> Features
>
> - Plain 68000 core, 68020 nearly complete
> - 32 MB SDRAM
> - PS/2 keyboard and mouse
> - Two fullsize SD card interfaces
> - SER
> - Ethernet
> - Battery buffered RTC (and yes, the battery is separate!)

:-D

> - Stereo sound
> - Up to 1024x768 VESA VGA, QL modes in hardware
> - 8x10 cm board size, fitting existing nice case
> - Single 5V power supply
> 
> I demonstrated my Q68 at the "QL is 30" show, where someone took a picture:
> 
> http://www.qlforum.co.uk/viewtopic.php?f=12=1087=10
> 
> Meanwhile I replaced the wired components you see on that picture by SMD
> for machine manufacture. QDOS Classic and Minerva are running, but
> issues with QL-SD driver and Pointer Environment.

Sounds and looks good... The small size would make it an ideal "portable"
QL...

Thierry.
___
QL-Users Mailing List
___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

Am 11.03.2016 23:30, schrieb Malcolm Lear:
> Assuming the PLCC has a through hole socket, would it be possible to 
> solder a pcb carrier for a more modern chip on the back of the board 
> using the PLCC pins that protrude through?

Probably yes. But soldering would require to heat up all PLCC pins at
once, or to desolder them first, so the carrier board can fit decently.
Seems a bit risky for the mainboard.
___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

On Fri, 11 Mar 2016 23:17:52 +0100, Peter Graf wrote:

> .../...
> > No chance to get a "larger" (i.e. with more gates) CPLD that would fit
> > the same socket ?... Or perhaps by using a modern and larger (in both
> > size and number of gates) CPLD that would piggy-back on the old CPLD
> > socket via a small adpater printed circuit ?...
> 
> I have considered that, but adaptors which fit into PLCC are
> prohibitively expensive and hard to get.

Well, the mod could also involve unsoldering the PLCC (correct me if
I'm wrong but IRC, it's a through-holes one) and replacing it with
pinheads, for example, that would plug into the add-on board.

> > A native 800x600 resolution would be a definitive (and probably the
> > best) solution to the problem, so I think it would be worth investigating
> > some more its feasability...
> 
> Still 800x600 would require change of all three operating systems

These are extremely *minor* and *easy* changes (and SMSQ/E can already
cope with 800x600 screens)...

> and several pieces of application software! Moreover, software that directly
> writes into QL 512x256 would fail, like the beloved QL Chess.

Frankly, such old pieces of software are probably best ran from emulators
if they can't cope with variable size/address display... They would also
fail to run on a QXL in (S)VGA mode or on an Aurora/SGC system too. I won't
call this an issue and I think this kind of "incompatibility" should not
limit and forbid us to get a better Q60 display...

> .../...
> > However, another issue with this solution could be the lack of room to
> > piggy-back a daughter board on the EPROM slots, especially with the 2
> > ISA slots occupied and a heat-sink+fan on the 68060...
> 
> It depends. Using SMD components, the board could be about as small as
> the ROM socket area.

In this case, I think it's still worth a solution...

> Q68 runs about QXL speed, even without the cache I am working on.

Not bad at all.

> Features
>
> - Plain 68000 core, 68020 nearly complete
> - 32 MB SDRAM
> - PS/2 keyboard and mouse
> - Two fullsize SD card interfaces
> - SER
> - Ethernet
> - Battery buffered RTC (and yes, the battery is separate!)

:-D

> - Stereo sound
> - Up to 1024x768 VESA VGA, QL modes in hardware
> - 8x10 cm board size, fitting existing nice case
> - Single 5V power supply
> 
> I demonstrated my Q68 at the "QL is 30" show, where someone took a picture:
> 
> http://www.qlforum.co.uk/viewtopic.php?f=12=1087=10
> 
> Meanwhile I replaced the wired components you see on that picture by SMD
> for machine manufacture. QDOS Classic and Minerva are running, but
> issues with QL-SD driver and Pointer Environment.

Sounds and looks good... The small size would make it an ideal "portable"
QL...

Thierry.
___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

2016-03-11 Thread Malcolm Lear

Assuming the PLCC has a through hole socket, would it be possible to 
solder a pcb carrier for a more modern chip on the back of the board 
using the PLCC pins that protrude through?




On 11/03/2016 22:17, Peter Graf wrote:

Am 11.03.2016 21:48, schrieb Thierry Godefroy:

On Fri, 11 Mar 2016 21:16:08 +0100, Peter Graf wrote:


Strange... I'd have expected that the problem was the video memory,
but 800x600 pixels consume less memory than 1024x512 pixels...

Yes it is strange. Has to do withe the fact that neither 800 nor 600 are
powers of two and the CPLDs are manually optimized to the last gate.

No chance to get a "larger" (i.e. with more gates) CPLD that would fit
the same socket ?... Or perhaps by using a modern and larger (in both
size and number of gates) CPLD that would piggy-back on the old CPLD
socket via a small adpater printed circuit ?...

I have considered that, but adaptors which fit into PLCC are
prohibitively expensive and hard to get.


A native 800x600 resolution would be a definitive (and probably the
best) solution to the problem, so I think it would be worth investigating
some more its feasability...

Still 800x600 would require change of all three operating systems and
several pieces of application software! Moreover, software that directly
writes into QL 512x256 would fail, like the beloved QL Chess.


I can display it without scaling here also, but it looks crazy with only
about a quarter of the screen area covered.

True, but better than a blank screen... :-P

Yup.


.../...

Well, depending on how many are "a few", this could be done with
manual wiring...

If I remember correctly, it was 6 wires.

That's definitely not a problem then: I've seen (and did) hardware mods
with more "flying" wires than this...
However, another issue with this solution could be the lack of room to
piggy-back a daughter board on the EPROM slots, especially with the 2
ISA slots occupied and a heat-sink+fan on the 68060...

It depends. Using SMD components, the board could be about as small as
the ROM socket area.


.../...

It would be another machine... Not sure you'd find a "market" for it.

I guess not, but I'm not looking for a market anyway. The fewer people
want it, the less work I have. The two things that still motivate me, is
to have fun and to keep the QL alive.

So the best thing will probably be to concentrate on the Q68. This cute
piece of hardware is in working condition for more than 8 years now,
only struggling with "soft" issues and my notorious lack of time.

Any picture/spec sheet ?

Q68 runs about QXL speed, even without the cache I am working on. Features

- Plain 68000 core, 68020 nearly complete
- 32 MB SDRAM
- PS/2 keyboard and mouse
- Two fullsize SD card interfaces
- SER
- Ethernet
- Battery buffered RTC (and yes, the battery is separate!)
- Stereo sound
- Up to 1024x768 VESA VGA, QL modes in hardware
- 8x10 cm board size, fitting existing nice case
- Single 5V power supply

I demonstrated my Q68 at the "QL is 30" show, where someone took a picture:

http://www.qlforum.co.uk/viewtopic.php?f=12=1087=10

Meanwhile I replaced the wired components you see on that picture by SMD
for machine manufacture. QDOS Classic and Minerva are running, but
issues with QL-SD driver and Pointer Environment.

All the best
Peter

___
QL-Users Mailing List
.



___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

Am 11.03.2016 21:48, schrieb Thierry Godefroy:
> On Fri, 11 Mar 2016 21:16:08 +0100, Peter Graf wrote:
> 
>>> Strange... I'd have expected that the problem was the video memory,
>>> but 800x600 pixels consume less memory than 1024x512 pixels...
>>
>> Yes it is strange. Has to do withe the fact that neither 800 nor 600 are
>> powers of two and the CPLDs are manually optimized to the last gate.
> 
> No chance to get a "larger" (i.e. with more gates) CPLD that would fit
> the same socket ?... Or perhaps by using a modern and larger (in both
> size and number of gates) CPLD that would piggy-back on the old CPLD
> socket via a small adpater printed circuit ?...

I have considered that, but adaptors which fit into PLCC are
prohibitively expensive and hard to get.

> A native 800x600 resolution would be a definitive (and probably the
> best) solution to the problem, so I think it would be worth investigating
> some more its feasability...

Still 800x600 would require change of all three operating systems and
several pieces of application software! Moreover, software that directly
writes into QL 512x256 would fail, like the beloved QL Chess.

>> I can display it without scaling here also, but it looks crazy with only
>> about a quarter of the screen area covered.
> 
> True, but better than a blank screen... :-P

Yup.

>> .../...
>>> Well, depending on how many are "a few", this could be done with
>>> manual wiring...
>>
>> If I remember correctly, it was 6 wires.
> 
> That's definitely not a problem then: I've seen (and did) hardware mods
> with more "flying" wires than this...
> However, another issue with this solution could be the lack of room to
> piggy-back a daughter board on the EPROM slots, especially with the 2
> ISA slots occupied and a heat-sink+fan on the 68060...

It depends. Using SMD components, the board could be about as small as
the ROM socket area.

>> .../...
>>> It would be another machine... Not sure you'd find a "market" for it.
>>
>> I guess not, but I'm not looking for a market anyway. The fewer people
>> want it, the less work I have. The two things that still motivate me, is
>> to have fun and to keep the QL alive.
>>
>> So the best thing will probably be to concentrate on the Q68. This cute
>> piece of hardware is in working condition for more than 8 years now,
>> only struggling with "soft" issues and my notorious lack of time.
> 
> Any picture/spec sheet ?

Q68 runs about QXL speed, even without the cache I am working on. Features

- Plain 68000 core, 68020 nearly complete
- 32 MB SDRAM
- PS/2 keyboard and mouse
- Two fullsize SD card interfaces
- SER
- Ethernet
- Battery buffered RTC (and yes, the battery is separate!)
- Stereo sound
- Up to 1024x768 VESA VGA, QL modes in hardware
- 8x10 cm board size, fitting existing nice case
- Single 5V power supply

I demonstrated my Q68 at the "QL is 30" show, where someone took a picture:

http://www.qlforum.co.uk/viewtopic.php?f=12=1087=10

Meanwhile I replaced the wired components you see on that picture by SMD
for machine manufacture. QDOS Classic and Minerva are running, but
issues with QL-SD driver and Pointer Environment.

All the best
Peter

___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

On Fri, 11 Mar 2016 21:37:15 +0100, Marcel Kilgus wrote:

> Thierry Godefroy wrote:
> > That would be nice too: I'm worried that the EPROMs contents will end
> > up ebbing away with time (I saw this happening many times, even on
> > military grade systems), and these EPROMs are so large that they don't
> > fit any of my EPROM programmers (which are limited to 27C512 for the
> > largest EPROM).
> 
> Same here, but 27C010 and 27C256 have basically the same pins, except
> the 2 additional address lines. I built a simple adapter board which
> includes DIP switches to toggle A15 and A16. This way I can program
> the chips in 4 parts.

The Q60 EPROMS are 27C1024 (16 bits data bus): such a trick won't work
for them.

Thierry.
___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

Hi,

The Q60 was fitted with 27C1024 eproms.

Regards

Derek

 Original message 
From: Marcel Kilgus <ql-us...@mail.kilgus.net> 
Date: 11/03/2016  20:37  (GMT+00:00) 
To: ql-us...@q-v-d.com 
Subject: Re: [Ql-Users] Q60 aging problems 

Thierry Godefroy wrote:
> That would be nice too: I'm worried that the EPROMs contents will end
> up ebbing away with time (I saw this happening many times, even on
> military grade systems), and these EPROMs are so large that they don't
> fit any of my EPROM programmers (which are limited to 27C512 for the
> largest EPROM).

Same here, but 27C010 and 27C256 have basically the same pins, except
the 2 additional address lines. I built a simple adapter board which
includes DIP switches to toggle A15 and A16. This way I can program
the chips in 4 parts.

Marcel

___
QL-Users Mailing List
___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

On Fri, 11 Mar 2016 21:16:08 +0100, Peter Graf wrote:

> > Strange... I'd have expected that the problem was the video memory,
> > but 800x600 pixels consume less memory than 1024x512 pixels...
> 
> Yes it is strange. Has to do withe the fact that neither 800 nor 600 are
> powers of two and the CPLDs are manually optimized to the last gate.

No chance to get a "larger" (i.e. with more gates) CPLD that would fit
the same socket ?... Or perhaps by using a modern and larger (in both
size and number of gates) CPLD that would piggy-back on the old CPLD
socket via a small adpater printed circuit ?...
A native 800x600 resolution would be a definitive (and probably the
best) solution to the problem, so I think it would be worth investigating
some more its feasability...

> .../...
> 
> I can display it without scaling here also, but it looks crazy with only
> about a quarter of the screen area covered.

True, but better than a blank screen... :-P

> .../...
> > Well, depending on how many are "a few", this could be done with
> > manual wiring...
> 
> If I remember correctly, it was 6 wires.

That's definitely not a problem then: I've seen (and did) hardware mods
with more "flying" wires than this...
However, another issue with this solution could be the lack of room to
piggy-back a daughter board on the EPROM slots, especially with the 2
ISA slots occupied and a heat-sink+fan on the 68060...

> .../...
> He owns a multisync *flatscreen*. Built into a self designed case.
> Remarkable.

I'm jealous now... :-D

> .../...
> > It would be another machine... Not sure you'd find a "market" for it.
> 
> I guess not, but I'm not looking for a market anyway. The fewer people
> want it, the less work I have. The two things that still motivate me, is
> to have fun and to keep the QL alive.
> 
> So the best thing will probably be to concentrate on the Q68. This cute
> piece of hardware is in working condition for more than 8 years now,
> only struggling with "soft" issues and my notorious lack of time.

Any picture/spec sheet ?

Regards,

Thierry.
___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

2016-03-11 Thread Marcel Kilgus

Thierry Godefroy wrote:
> That would be nice too: I'm worried that the EPROMs contents will end
> up ebbing away with time (I saw this happening many times, even on
> military grade systems), and these EPROMs are so large that they don't
> fit any of my EPROM programmers (which are limited to 27C512 for the
> largest EPROM).

Same here, but 27C010 and 27C256 have basically the same pins, except
the 2 additional address lines. I built a simple adapter board which
includes DIP switches to toggle A15 and A16. This way I can program
the chips in 4 parts.

Marcel

___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

Hi,

I would anything that would  make the Q60 better, looks only to be the display.

I can programme the 27C1024 eproms for Q40 and Q60.


Regards

Derek


 Original message 
From: Peter Graf <pg...@q40.de> 
Date: 11/03/2016  20:16  (GMT+00:00) 
To: ql-us...@q-v-d.com 
Subject: Re: [Ql-Users] Q60 aging problems 

Hi Thierry,

>> 1) Create a 1024x768 signal with a modified CPLD, generating 
>> 1024x512 plus a black bar at the bottom of the screen. 800x600 does 
>> not fit the PLD.
> 
> Strange... I'd have expected that the problem was the video memory,
> but 800x600 pixels consume less memory than 1024x512 pixels...

Yes it is strange. Has to do withe the fact that neither 800 nor 600 are
powers of two and the CPLDs are manually optimized to the last gate.

>> This solution seems to work with recent flatscreen monitors. For me
>> on a 1920x1080 LG. But 1024x768 does not interpolate nicely, and the
>> black area is annoying.
> 
> Would it be possible to have black areas (lines) both above and below
> the Q60 screen, instead ?... It would look nicer.

I tried that, but did not find a way.

> As for scaling, some monitors can have it disabled; mine, a Hyundai
> W220D, can display any standard EGA/*VGA resolution below its own
> (1680x1050) without scaling and centered on the screen (of course,
> displaying a 320x200 screen without scaling on such a monitor gives a
> tiny picture, but 1024x768 would be quite OK).

I can display it without scaling here also, but it looks crazy with only
about a quarter of the screen area covered.

>> so the only socket where a graphics card could go 
>> (without modifying the mainboard) is the ROM sockets. This would 
>> have the nice side effect to replace the UV EPROMs by Flash.
> 
> That would be nice too: I'm worried that the EPROMs contents will end
> up ebbing away with time (I saw this happening many times, even on
> military grade systems), and these EPROMs are so large that they don't
> fit any of my EPROM programmers (which are limited to 27C512 for the
> largest EPROM).

There are several commercial programming services who do it for a few
Euro. In the worst case, I also can still do the programming.

>> Unfortunately, a few additional address and byte select lines are 
>> required, which are not present on the ROM sockets.
> 
> Well, depending on how many are "a few", this could be done with
> manual wiring...

If I remember correctly, it was 6 wires.

>> 3) Find a converter which can handle the Q60's 1024x512 resolution 
>> and does not misinterpret it as 800x600 like most VGA converters.
> 
> Good luck with that !... Forget about the Ambery and Jamma Boards
> products: bought them and they don't work with the Q60... Neither
> with the Thor XVI in 512x256 resolution (or very badly).

I also had no luck with that yet.

>> 4) Find a flatscreen monitor with true multisync. A fellow QLer here 
>> in Germany owns such a rare monitor and the results are nice. It is 
>> sort of an industrial monitor. Unfortunately my attempts to get 
>> hands on a batch of similar devices failed yet.
> 
> Same here. True multi-sync monitors are History (I'm still so sad and
> annoyed that my NEC-3D died, 8 or so years ago).

He owns a multisync *flatscreen*. Built into a self designed case.
Remarkable.

>> 5) Design a Q60 successor. I had seriously considered this, because 
>> debugging the FPGA-based CPU core inside the Q68 took so long. It 
>> would be a piggyback 68060 board on top of the Q68 hardware. The Q68 
>> board providing video circuitry and peripherals, while the 68060 
>> board holds the CPU, main RAM and glue logic. But this solution 
>> leads away from the original. Considering the Q60 is a vintage 
>> machine worth preserving, this has limited appeal.
> 
> It would be another machine... Not sure you'd find a "market" for it.

I guess not, but I'm not looking for a market anyway. The fewer people
want it, the less work I have. The two things that still motivate me, is
to have fun and to keep the QL alive.

So the best thing will probably be to concentrate on the Q68. This cute
piece of hardware is in working condition for more than 8 years now,
only struggling with "soft" issues and my notorious lack of time.

> I'd personally vote for solution 1 (preferred) or 2. :-)

Solution 1 is MUCH easier than solution 2.

All the best
Peter

___
QL-Users Mailing List
___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

Hi Thierry,

>> 1) Create a 1024x768 signal with a modified CPLD, generating 
>> 1024x512 plus a black bar at the bottom of the screen. 800x600 does 
>> not fit the PLD.
> 
> Strange... I'd have expected that the problem was the video memory,
> but 800x600 pixels consume less memory than 1024x512 pixels...

Yes it is strange. Has to do withe the fact that neither 800 nor 600 are
powers of two and the CPLDs are manually optimized to the last gate.

>> This solution seems to work with recent flatscreen monitors. For me
>> on a 1920x1080 LG. But 1024x768 does not interpolate nicely, and the
>> black area is annoying.
> 
> Would it be possible to have black areas (lines) both above and below
> the Q60 screen, instead ?... It would look nicer.

I tried that, but did not find a way.

> As for scaling, some monitors can have it disabled; mine, a Hyundai
> W220D, can display any standard EGA/*VGA resolution below its own
> (1680x1050) without scaling and centered on the screen (of course,
> displaying a 320x200 screen without scaling on such a monitor gives a
> tiny picture, but 1024x768 would be quite OK).

I can display it without scaling here also, but it looks crazy with only
about a quarter of the screen area covered.

>> so the only socket where a graphics card could go 
>> (without modifying the mainboard) is the ROM sockets. This would 
>> have the nice side effect to replace the UV EPROMs by Flash.
> 
> That would be nice too: I'm worried that the EPROMs contents will end
> up ebbing away with time (I saw this happening many times, even on
> military grade systems), and these EPROMs are so large that they don't
> fit any of my EPROM programmers (which are limited to 27C512 for the
> largest EPROM).

There are several commercial programming services who do it for a few
Euro. In the worst case, I also can still do the programming.

>> Unfortunately, a few additional address and byte select lines are 
>> required, which are not present on the ROM sockets.
> 
> Well, depending on how many are "a few", this could be done with
> manual wiring...

If I remember correctly, it was 6 wires.

>> 3) Find a converter which can handle the Q60's 1024x512 resolution 
>> and does not misinterpret it as 800x600 like most VGA converters.
> 
> Good luck with that !... Forget about the Ambery and Jamma Boards
> products: bought them and they don't work with the Q60... Neither
> with the Thor XVI in 512x256 resolution (or very badly).

I also had no luck with that yet.

>> 4) Find a flatscreen monitor with true multisync. A fellow QLer here 
>> in Germany owns such a rare monitor and the results are nice. It is 
>> sort of an industrial monitor. Unfortunately my attempts to get 
>> hands on a batch of similar devices failed yet.
> 
> Same here. True multi-sync monitors are History (I'm still so sad and
> annoyed that my NEC-3D died, 8 or so years ago).

He owns a multisync *flatscreen*. Built into a self designed case.
Remarkable.

>> 5) Design a Q60 successor. I had seriously considered this, because 
>> debugging the FPGA-based CPU core inside the Q68 took so long. It 
>> would be a piggyback 68060 board on top of the Q68 hardware. The Q68 
>> board providing video circuitry and peripherals, while the 68060 
>> board holds the CPU, main RAM and glue logic. But this solution 
>> leads away from the original. Considering the Q60 is a vintage 
>> machine worth preserving, this has limited appeal.
> 
> It would be another machine... Not sure you'd find a "market" for it.

I guess not, but I'm not looking for a market anyway. The fewer people
want it, the less work I have. The two things that still motivate me, is
to have fun and to keep the QL alive.

So the best thing will probably be to concentrate on the Q68. This cute
piece of hardware is in working condition for more than 8 years now,
only struggling with "soft" issues and my notorious lack of time.

> I'd personally vote for solution 1 (preferred) or 2. :-)

Solution 1 is MUCH easier than solution 2.

All the best
Peter

___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems

2016-03-11 Thread Derek Stewart


Hi Thierry,

I can get the RTC Chip for under 10 Euro

Regards,

Derek

On 11/03/16 16:29, Thierry Godefroy wrote:

On Fri, 11 Mar 2016 16:53:56 +0100, pg...@q40.de wrote:


On 11 Mar 2016 at 14:41, Thierry Godefroy wrote:


[...]
This problem was (apparently) due to the lack of poper system date setting
before starting the build process (my Q60 RTC's battery is alas dead, and
given it's a built-in battery inside the RTC package itself, it can't be
replaced);


The Q60 RTC with integrated battery should be available
off-the-shelf for about 12 € from the usual electronic distributors
like Mouser, Digikey, etc.


See my last message: 20€ + VAT (+ postage) from Farnell...


To my surprise, the RTC in my own Q60 has been working for about 18
years.


Mine lasted 12 years or so (it's been dead for alreay a couple of years
and started loosing *minutes* per day when the Q60 was not powered two
years earlier).
Not bad, but still economically silly when compared with a RTC+quartz
chip and independent battery (or supercap: I love those and use them
in all my RTC-fitted electronic projects).


My much bigger concern is the flatscreen monitor issue. I have troubled
my mind about that for years, and if it wasn't for the QL-SD project,
I might have designed a solution. Now that my own CRT monitor faded,
the pain level is growing.


Agreed, this is *the* weak point of the Q40/Q60: without a monitor to
connect it onto, the Qx0 is just a dead part... :-(


Basically, I see five options:

1) Create a 1024x768 signal with a modified CPLD, generating
1024x512 plus a black bar at the bottom of the screen. 800x600 does
not fit the PLD.


Strange... I'd have expected that the problem was the video memory,
but 800x600 pixels consume less memory than 1024x512 pixels...


This solution seems to work with recent flatscreen monitors. For me
on a 1920x1080 LG. But 1024x768 does not interpolate nicely, and the
black area is annoying.


Would it be possible to have black areas (lines) both above and below
the Q60 screen, instead ?... It would look nicer.

As for scaling, some monitors can have it disabled; mine, a Hyundai
W220D, can display any standard EGA/*VGA resolution below its own
(1680x1050) without scaling and centered on the screen (of course,
displaying a 320x200 screen without scaling on such a monitor gives a
tiny picture, but 1024x768 would be quite OK).


2) Design a Q60 graphics card. An ISA card would be slower than the
onboard graphics,


And both slots are already taken: one for the I/O board, the other for
the Ethernet card...


so the only socket where a graphics card could go
(without modifying the mainboard) is the ROM sockets. This would
have the nice side effect to replace the UV EPROMs by Flash.


That would be nice too: I'm worried that the EPROMs contents will end
up ebbing away with time (I saw this happening many times, even on
military grade systems), and these EPROMs are so large that they don't
fit any of my EPROM programmers (which are limited to 27C512 for the
largest EPROM).


Unfortunately, a few additional address and byte select lines are
required, which are not present on the ROM sockets.


Well, depending on how many are "a few", this could be done with
manual wiring...


3) Find a converter which can handle the Q60's 1024x512 resolution
and does not misinterpret it as 800x600 like most VGA converters.


Good luck with that !... Forget about the Ambery and Jamma Boards
products: bought them and they don't work with the Q60... Neither
with the Thor XVI in 512x256 resolution (or very badly).


4) Find a flatscreen monitor with true multisync. A fellow QLer here
in Germany owns such a rare monitor and the results are nice. It is
sort of an industrial monitor. Unfortunately my attempts to get
hands on a batch of similar devices failed yet.


Same here. True multi-sync monitors are History (I'm still so sad and
annoyed that my NEC-3D died, 8 or so years ago).


5) Design a Q60 successor. I had seriously considered this, because
debugging the FPGA-based CPU core inside the Q68 took so long. It
would be a piggyback 68060 board on top of the Q68 hardware. The Q68
board providing video circuitry and peripherals, while the 68060
board holds the CPU, main RAM and glue logic. But this solution
leads away from the original. Considering the Q60 is a vintage
machine worth preserving, this has limited appeal.


It would be another machine... Not sure you'd find a "market" for it.

I'd personally vote for solution 1 (preferred) or 2. :-)

Thierry.
___
QL-Users Mailing List


___
QL-Users Mailing List

Re: [Ql-Users] Q60 aging problems