Have a Sinclair QL? Please run it for me!

[XorA]

Up to Windows 3.1 at least parts of WIndows were written in Pascal.

I could find not a single source for that.

Windows 95 was written in Watcom C. God, it was taking hours to compile anything!

At that point they had their own C compiler for 10+ years, why would they use the competition?

In 98 where part of my job was windows drivers the DDK was solidly Visual C/C++ only so I doubt this claim!

[Andrew]

Up to Windows 3.1 at least parts of WIndows were written in Pascal.

I could find not a single source for that.

Windows 95 was written in Watcom C. God, it was taking hours to compile anything!

At that point they had their own C compiler for 10+ years, why would they use the competition?

I was part of the team that developed Win95. I developed the test framework for GDI testing and for third party printer and video drivers certification. We used Watcom C. If I remember correctly Microsoft C was not able to generate 32 bit code at that time, but I might be wrong. Nevertheless, we used Watcom C. Of course this does not mean that the bulk of Win 95 itself was written in Watcom C, but at that time we presumed it was.
I had access to some bits of legacy code that was written in Pascal. I do not remember if those were parts of older Windows or just some internal test tools for GDI, but I believe it were both.

[mk79]

Up to Windows 3.1 at least parts of WIndows were written in Pascal.

I could find not a single source for that.

Windows 95 was written in Watcom C. God, it was taking hours to compile anything!

At that point they had their own C compiler for 10+ years, why would they use the competition?

I was part of the team that developed Win95. I developed the test framework for GDI testing and for third party printer and video drivers certification. We used Watcom C.

Okay, interesting

If I remember correctly Microsoft C was not able to generate 32 bit code at that time, but I might be wrong.

Well yeah, the first 32-bit Visual C compiler was publicly available in 1993. Maybe Watcom C was still more mature, no idea, but interesting, thanks.

Cheers, Marcel

[vol]

Speed varies mainly with the fact if external extended memory is available or not. The internal memory is contended with the screen refresh and slow in comparison. Different OS can also make a difference, depending on how many facilities are used in the application (maths library or whatnot). In your case OS doesn't make a lot of difference, though QDOS is a bit faster (which is counter-intuitive). But putting a TrumpCard memory expansion in makes a HUGE difference (much more than I would have expected)... it's all the same QL BTW, with a QL-SD ROM drive to switch the OS.

Thank you very much for your very valuable results. So the QL like the Amiga has slow (internal) and fast (external) RAM. However on the Amiga 500 fast RAM is usually only about 10% faster but for the QL fast RAM makes CPU about 50% faster.
I have checked timer results with my stopwatch, they are very accurate. IMHO Minerva has a bit heavier standard interrupt handler and this makes it a bit slower than JS for ML programs.
It is unusual that sQLux is faster than the real iron for the 1st picture (1.88 vs 2.16) but slower for the 12th picture (13.12 vs 12.7). QemuLator is always slightly faster (approx. 6.8%) than the real QL. So this emulator is quite accurate, maybe it doesn't only take into account DRAM refresh or similar things.

Is the source code to the Mandelbrot rountine available?

I have attached the assembly source. I have made several improvements, so the program became faster. You need to call label start - this creates a lookup table and adds MANDLE and TIMER keywords to Basic. You need about 13 KB for code and the generated table. Then just use MANDLE to get a Mandelbrot. I am going to publish more details soon.

mandel-ql-asm.zip

(2.74 KiB) Downloaded 57 times

[vol]

I have another project that may be used for benchmarking. It is the number pi calculator. I have run it for 100, 1000, and 3000 digits. I got the next results.

Code: Select all

Q-emuLator 3.4 min197  100: 0.50, 1000: 32.82, 3000: 285.82
Q-emuLator 3.4 js      100: 0.50, 1000: 33.06, 3000: 288.62

Qemulator shows that Minerva ROM provides a faster character output routine than original JS ROM. I am not sure how accurate QemuLator is for this task. So I'm asking for one more favor. I am looking for results from real hardware. Results from a QL with fast external RAM are the most interesting because there is no any emulator that can emulate such fast RAM. Thank you in advance.

ql-pi.zip

(1.13 KiB) Downloaded 54 times

[Derek_Stewart]

Hi,

Always use Minerva, there are many bug fixes and grpahics routines are accelerated.

I had a look at your source code, it look very good.

Is there any chance of making the programme work on higher resolution QL systems, which might mean the screen is not located at 2000 Hex and the screen length is not 32K in size.

[Silvester]

IMHO Minerva has a bit heavier standard interrupt handler and this makes it a bit slower than JS for ML programs.

Just out of interest, try POKE!!53,128 on Minerva (POKE!!53,192 reverts to default). It turns off unnecessary IPC interrupt * (IMHO, methinks this is error).

BTW I have a copy of Lau Reeves fast PI calculator (definable string to 32767 places), He made it freely available but I haven't seen it since, I can dig it out if anyone is interested.

Edit: * On real hardware of course!

[XorA]

It is unusual that sQLux is faster than the real iron for the 1st picture (1.88 vs 2.16) but slower for the 12th picture (13.12 vs 12.7).

sQLux makes no attempt at accurately emulating CPU speed. @Exile did a good job of using number of instructions emulated hueristic to give you approx speed. But the actually speed depends on whether they are slow or quick instructions on real hardware. Also sQLux slows down a lot under heavy screen updates as every write to screen goes immediately to screen!

[mk79]

I have another project that may be used for benchmarking. It is the number pi calculator. I have run it for 100, 1000, and 3000 digits. I got the next results.

Code: Select all

Q-emuLator 3.4 min197  100: 0.50, 1000: 32.82, 3000: 285.82
Q-emuLator 3.4 js      100: 0.50, 1000: 33.06, 3000: 288.62

Code: Select all

QL 128kB Min198 1000: 33.98, 3000: 284.84
QL 768kB Min198 1000: 24.84, 3000: 215.08

[vol]

I had a look at your source code, it look very good.

Thank you very much. But it seems you flatter me. I am rather lazy to do all comments and other code chores.

Is there any chance of making the programme work on higher resolution QL systems, which might mean the screen is not located at 2000 Hex and the screen length is not 32K in size.

I think it is not difficult. You just need to use a proper address for the screen memory and change pixel output instructions. The video code for the plain QL is only 20 instructions. If anybody is interested they can clone my repo and I will try to help. I am rather interested to get results from ancient unmodded hardware. BTW the initial code for this Mandelbrot program has been written in the PDP-11 assembly.

Just out of interest, try POKE!!53,128 on Minerva (POKE!!53,192 reverts to default). It turns off unnecessary IPC interrupt * (IMHO, methinks this is error).

Thank you. However I have got no effect from this pokes. Maybe it is because my program uses supervisor mode.

BTW I have a copy of Lau Reeves fast PI calculator (definable string to 32767 places), He made it freely available but I haven't seen it since, I can dig it out if anyone is interested.

Pi spigot is not the fastest but it is the easiest. So I ported it to many platforms. Actually, it can calculate up to 9400 digits and this limit is caused by 16 bit arithmetic used in my implementations.

Code: Select all

QL 128kB Min198 1000: 33.98, 3000: 284.84
QL 768kB Min198 1000: 24.84, 3000: 215.08

Thanks a lot! I have added this info to the large table. I had only to estimate results for the newest version and for 100 digits. I hope they are quite close to results from hardware.
It is interesting that for 1000 digits the result from hardware is slower than from Qemulator but for 3000 digits hardware is faster. There were no such discrepancy for Mandelbrot results.