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
