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