Mandelbrot with Amstrad

[litwr]

Sorry I'm not quite following your comments at the moment.

Sorry for possible grammar quirks. Is it about unbalanced NEXT or a program for BBC Micro?  I also wrote that monochrome high resolution Mandelbrot may look quite fine.
I can't imagine what makes Pascal code about 7 times faster...

[AMSDOS]

Sorry for possible grammar quirks. Is it about unbalanced NEXT or a program for BBC Micro?  I also wrote that monochrome high resolution Mandelbrot may look quite fine.
I can't imagine what makes Pascal code about 7 times faster...

Apologies, I hijacked your thread. I was initially responding to @robcfg Mandelbrot which I worked out by pulling it apart and remove all the GOTO lines which wouldn't be required for the Pascal. I ended up with that BASIC program which took nearly 3.5 hrs to complete in BASIC and around 28Minutes in Pascal. The timing of the Mandelbrot can vary depending on the Iterations, I only had 16 in my Pascal, but the more I added I started noticing everything slowing down, though Pascal is always Compiled into Machine Code, that improves performance (as you're probably aware?). The initial Mandelbrot @robcfg posted has a Blue centre, but when I stripped it down to the BASIC version, it's rendering the centre, which my Pascal version is also doing. I thought it might of been due to the number of Interations I had, but that doesn't seem to be the case, so I'm unsure why that's happening. 


I was then looking at SRS which simply fills around the edges which saves time in using the background for the centre of the mandelbrot, but should have been looking at your mandelbrot. For some reason I thought it was in Mode 2, but I should have been looking at the code rather than the screenshot. Like the one SRS posted it shouldn't be too difficult to interpret into Pascal. Just gone on what SRS said, an Array I don't think is necessary, I see your's has 3, must be taking up large amounts of Data, that maybe more of a problem in a Compiled Language like Pascal, BASIC probably has the edge there since it's a small program located at &170. Unfortunately I don't have the means of playing around with your program at the moment, I was just wondering if you needed to subtract t% twice in your PLOT & TEST commands, instead of using STEP 2 in your FOR t%=0 TO 199 STEP 2, which is faster I think. Also I noticed your starting your Mandelbrot off the top of the screen at 402, couldn't that be the top line at 398?

[robcfg]

It may sound silly, but you changed ON J GOSUB 1300,1330,1350,1380,1400,1430,1450 for CASE j OF 1..7, and I think the range of the case statement should be 0..6, so when the value of j is 7 it uses the chosen color which is 3.


I tried your program on Winape and it's amazingly fast in comparison to the BASIC one!


Please try to change the range and tell me if that works.

[SRS]

...though 32 minutes sounds awfully impressive improvement.

I'm just wondering on the back of the Mandelbrot is that Gap, in your code the plot that's plotting from the top for the ypos starts at 400 with a variable (which I don't remember what it's called) starts at 0. 398 is the very top line (400 is offscreen), just wondered if that was the fault causing that gap to occur? Unfortunately I didn't have time to test this. 

Well, 32 minutes was with "turbo mode" active (like DI .. EI). And that Gap ... as you said change 400 to 398 and its gone. I sometimes publish beta versions

You, Sir, should think about a career as software testmanager (if you aren't now) !

[litwr]

Apologies, I hijacked your thread. I was initially responding to @robcfg

It is fine we have a fine thread.

Unfortunately I don't have the means of playing around with your program at the moment, I was just wondering if you needed to subtract t% twice in your PLOT & TEST commands, instead of using STEP 2 in your FOR t%=0 TO 199 STEP 2, which is faster I think.

Thanks but it is not so easy.  STEP 2 will not work.
I've just made a Mandelbrot video for the BBC Micro program.  The program had worked during about 5 minutes but the video is accelerated.  The speed and the GUI are very good.   IMHO it is the best Mandelbrot in the 8-bit world.
[attachimg=1]

[AMSDOS]

It may sound silly, but you changed ON J GOSUB 1300,1330,1350,1380,1400,1430,1450 for CASE j OF 1..7, and I think the range of the case statement should be 0..6, so when the value of j is 7 it uses the chosen color which is 3.


I tried your program on Winape and it's amazingly fast in comparison to the BASIC one!


Please try to change the range and tell me if that works.

For some reason (probably due to the example in the Manual), I always think the 1st number the Subroutine goes to, is based on the variable having a value of 1, but in the Manual is suggests values can be between 0 and 255.


For the CASE statement I tried all sorts of combinations, 0 doesn't seem to be valid in this case because the lowest k can be is 0.25, which is then multiplied by 8 to return 1 for j, but eventually I've added an 8th routine to obtain the Blue for the Centre, I also had to change the values from the Iterations so mi=16 and ni=17, which gets me that Blue Centre.

Well, 32 minutes was with "turbo mode" active (like DI .. EI). And that Gap ... as you said change 400 to 398 and its gone. I sometimes publish beta versions

I was gonna ask if you used turbo mode.    I could whip it up in Pascal and it will probably be completed within 10 minutes.

You, Sir, should think about a career as software testmanager (if you aren't now) !

Haven't always been able to debug an Amstrad program, C is probably avenue into that sort of career, sadly i need brushing up on. 

It is fine we have a fine thread.
Thanks but it is not so easy.  STEP 2 will not work.
I've just made a Mandelbrot video for the BBC Micro program.  The program had worked during about 5 minutes but the video is accelerated.  The speed and the GUI are very good.   IMHO it is the best Mandelbrot in the 8-bit world.

Huh! Sorry I still need to get to your code    Okay I can see why STEP 2 wouldn't work, I was trying to use another approach instead of using Arrays.
Unfortunately I haven't looked at your program and so I'm baffled on lines 12 & 13. I can tell they are putting information into the r & j arrays, but that's about it.


Otherwise it's an interesting collection of Mandelbrot's, I'm somewhat surprised there's not that many on CPC-Power (well I only found 3).


And yeah I saw the BBC program (for some reason the GIF wouldn't work on Safari), that will take some doing.

[robcfg]

The BBC program is quite interesting, is there any source to take a look at?

[litwr]

The BBC program is quite interesting, is there any source to take a look at?

http://www.stardot.org.uk/forums/viewtopic.php?f=2&t=12028#p152674

[AMSDOS]

Sorry I forgot to attach the updated Pascal program for anyone interested:


[attachimg=1]

[RichTW]

http://www.stardot.org.uk/forums/viewtopic.php?f=2&t=12028#p152674

Haha, how funny to find this discussion here!  I've just joined up to the forum, and I'm the author of this BBC Micro demo.  If anyone has any questions, I'm more than happy to (try to) answer them!  Basically it does colour boundary tracing in order to try to minimise the number of pixels it has to evaluate (which particularly helps when there are plenty of onscreen pixels "in" the Mandelbrot set, which take the greatest number of iterations).  It uses the low resolution mode (like MODE 0) with pairs of pixels, so they are square and can be dithered, in order to increase the apparent number of colours as the BBC only has an 8 colour palette.


The key to the speed is the boundary tracing, and the fast multiplication routine which uses the "difference of two squares" method with an additional optimization.  The source is there if you can read 6502!  I'm sure a CPC version would perform even better with a similar optimized Z80 multiply, and would look prettier too!

[litwr]

The key to the speed is the boundary tracing, and the fast multiplication routine which uses the "difference of two squares" method with an additional optimization.  The source is there if you can read 6502!  I'm sure a CPC version would perform even better with a similar optimized Z80 multiply, and would look prettier too!

IMHO BBC Micro is about 2 times faster for such kind of graphics but Amstrad CPC may show more colors.  BTW I thought that BBC Micro was a big rarity outside England.

Sorry I forgot to attach the updated Pascal program for anyone interested:

Thanks! I have checked it and even converted it back to Basic with slight optimization. 

Code Select Expand


5 TI=TIME
10 MI%=15:FX=-2.4:F2=1.04:FY=-1.3:RX%=320:RY%=200
20 MODE 1:BORDER 6:INK 0,6:INK 1,18:INK 2,26:INK 3,1:GOSUB 580
25 PRINT (TIME-TI)/300
30 END
580 DX=F2-FX
590 DY=RY%/RX%*DX
610 E=FY
620 YP%=0
630 WHILE YP%<RY%
650 D=FX
660 XP%=0
670 WHILE XP%<RX%
690 S=0:R=0:A%=0:Z2=0:I2=0
700 WHILE(A%<MI%)AND(Z2+I2<4)
710 R=2*R*S+E
720 S=Z2-I2+D
760 A%=A%+1
770 Z2=S*S
780 I2=R*R
790 WEND
810 RST%=(XP%AND 1)=(YP%AND 1)
830 J%=A%AND 7
840 COL%=1
860 IF J%=1 THEN IF NOT RST% THEN COL%=3:GOTO 940 ELSE GOTO 940
870 IF J%=2 GOTO 940
880 IF J%=3 THEN IF RST% THEN COL%=2:GOTO 940 ELSE GOTO 940
890 COL%=2:IF J%=4 THEN 940
900 IF J%=5 THEN IF RST% THEN COL%=0:GOTO 940 ELSE GOTO 940
910 COL%=0:IF J%=6 GOTO 940
920 IF J%=7 THEN IF NOT RST% THEN 940
930 COL%=3
940 PLOT XP%*2,YP%*2,COL%
960 D=D+DX/RX%
970 XP%=XP%+1
980 WEND
990 E=E+DY/RY%
1000 YP%=YP%+1
1010 WEND
1020 RETURN

Hisoft Pascal shows very good quality of the generated code.  Its big disadvantage is impossibility to work with ASCII.  Is there any converter from ASCII?  I worked with MANBOLT.PAS.  The results:
Hisoft Pascal - 1807 sec (I've added GETTIMER procedure to the code)
Basic - 9754 sec
Basic with the code compressed by BPC - 9585 sec
Basic compiled by Fabacom - 3911 sec
I'd tried CPC Basic cross-compiler but it doesn't support the real numbers.
Fabacom has the manual in German and it is a scanned text.  So I can't use any translator.
Hisoft Pascal makes more than two times faster code.  I can think that this Basic compiler makes not pure machine code but uses p-codes.

[AMSDOS]

@litwr Like BASIC, Hisoft Pascal tokenises keywords to help reduce the amount of memory being used, which becomes more apparent when programs become larger. However I use it in Winape, so in the Printer Settings I can create a file (with the name of the program) & use the "Z" option in Hisoft Pascal which would dump the program to printer, but in this case it dumps it to a file (as ASCII). On occasions I've done this and have edited the programs with Notepad and used Winape to Paste the code, which Hisoft Pascal happily accepts (just be careful not to exceed 80 chars per line).


In CPC BASIC 3 Real Numbers are not usually supported, though a number of RSXs are available, in the guide I have it specifies that you have to state how many real numbers in a box at the top of the application window. The default is 0, which disables the RSXs available, any other number and the RSXs are available and a little bit of memory is assigned to a table, I haven't used this, but I think the larger the number the more table space is assigned, and is probably a good opportunity to test on a Mandelbrot.


The RSX commands available look like this:

Code Select Expand



|ABS,i1,i2: equivalent to the operation table(i1)=ABS(table(i2)).
|ADD,i1,i2,i3: equivalent to the operation table(i1)=table(i2)+table(i3).
|ATN,i1,i2: equivalent to the operation table(i1)=ATN(table(i2)).
|CINT,@variable,i: corresponds to the operation variable=CINT(table(i)), storing the index value i in the specified variable, ignoring the sign. Useful to pass the value of an item in the table of real values to a CPC Basic program variable.
|CMP,@variable,i1,i2: stored in variable a value 1 if table(i1)>table(i2), a value 0 if table(i1)=table(i2), or a value 255, interpetable as -1 if table(i1)<table(i2).
|COS,i1,i2: equivalent to the operation table(i1)=COS(table(i2)).
|CREAL,i,expression is equivalent to the operating table(i)=expression. Useful to pass a value of CPC Basic program to an item in the table of real values.
|DEG: equivalent to the command DEG.
|DIV,i1,i2,i3: equivalent to the operation table(i1)=table(i2)/table(i3).
|EXP,i1,i2: equivalent to the operation table(i1)=EXP(table(i2)).
|FIX,i1,i2: equivalent to the operation table(i1)=FIX(table(i2)).
|INT,i1,i2: equivalent to the operation table(i1)=INT(table(i2)).
|LET,i1,i2: equivalent to the operation table(i1)=table(i2).
|LOG,i1,i2: equivalent to the operation table (i1)=LOG(table(i2)).
|LOG10,i1,i2: equivalent to the operation table(i1)=LOG10(table(i2)).
|MUL,i1,i2,i3: equivalent to the operation table(i1)=table(i2)*table(i3).
|PI,i: corresponds to the operation table(i)=PI.
|POW,i1,i2,i3: equivalent to the operation table(i1)=table(i2)^table(i3).
|RAD: equivalent to the command RAD.
|REV,i1,i2: equivalent to the operation table(i1)=-table(i2).
|ROUND,i1,i2,expression: equivalent to the operation table(i1)=ROUND(table(i2),expression).
|SGN,@variable,i: corresponds to the variable operation=SGN(table(i)).
|SIN,i1,i2: equivalent to the operation table(i1)=SIN(table(i2)).
|SQR,i1,i2: equivalent to the operation table(i1)=SQR(table(i2)).
|STR,@variable,i: corresponds to the operation variable=STR$(table(i)), where variable is of type string and with a minimum length of 11 characters.
|SUB,i1,i2,i3: equivalent to the operation table(i1)=table(i2)-table(i3).
|TAN,i1,i2: equivalent to the operation table(i1)=TAN(table(i2)).
|VAL,i,@variable: equal to the operating table(i)=VAL(variable) where variable is of type string or can also be a string constant without the @ operator.





If you do manage to get it to work, the result will probably be an improvement on Hisoft Pascal.

[RichTW]

IMHO BBC Micro is about 2 times faster for such kind of graphics but Amstrad CPC may show more colors.  BTW I thought that BBC Micro was a big rarity outside England.

In the Mandelbrot program, the slow part is iterating the z²+c until it diverges or reaches the iteration limit - using the difference of squares method to perform the multiplies, it can be reduced to a bunch of 16 bit subtractions, followed by a bunch of 16 bit additions, and this is something that the Z80 has the edge over the 6502 (16 bit arithmetic in general).  But given the effective clock speed (2MHz 6502 versus ~3.3MHz Z80), maybe it ends up roughly the same.


The actual plotting is not really a bottleneck.  But the CPC could certainly render it much better, given its far nicer palette!


Yeah the BBC Micro was pretty much only seen in the UK - I spent my childhood years there before moving to Spain.

[robcfg]

@litwr , is there a source or explanation of the techniques used in the BBC program?


I find that much 6502 assembler a little too much too digest.

[RichTW]

I wrote a little about the multiplication technique that it uses here - that's pretty much the guts of the program. The values it manipulates are fixed-point, holding 29 fractional bits and 3 signed integer bits, allowing values between -4.0 and <4.0. A cute consequence of the method is that it can square a number slightly more quickly than multiply two different numbers, which is great as there are two square operations per iteration!


The border tracing is fairly straightforward, but instead of using recursion it maintains a queue of pixels to process, and carries on until there's nothing left in the queue. First thing it does is pushes all the screen edge pixels to the queue. Then the algorithm is:


For each item in the queue:

   
• Evaluate the pixel at that position and plot it. Note that the pixel may already be plotted, the screen essentially acts as a cache to save reevaluating a pixel.
• Evaluate all 8 neighbours and plot them (again remembering that their result may already be known from the screen itself). If any neighbour colour differs from the central pixel, we have found a border - push this to the queue so we trace along the border.

Once the queue is empty, we have all the borders rendered on screen (the border is actually two-sided, containing both colours). Now we just do a full screen pass to fill in the colour. This is simple, for any pixel not yet drawn, we just duplicate the pixel directly above, and iterate in columns, top to bottom, left to right.


This approach requires two special pixel values - one to denote that the pixel hasn't been written, and one to denote that a pixel has already been added to the queue (otherwise we could quickly fill the queue with duplicates). On the Beeb version, I use a bit each for these two things. This is possible because the Beeb has 4bpp but only 8 unique colours - I pair up pixels vertically so I can dither, and use the top bits of each to indicate these two different things. This is just an implementation detail though. On the CPC there's enough memory to be able to store these bit arrays separately from the screen.


Hope that clarifies things a bit. Who's going to be the first to make a CPC version then? 

[litwr]

@litwr Like BASIC, Hisoft Pascal tokenises keywords to help reduce the amount of memory being used, which becomes more apparent when programs become larger. However I use it in Winape, so in the Printer Settings I can create a file (with the name of the program) & use the "Z" option in Hisoft Pascal which would dump the program to printer, but in this case it dumps it to a file (as ASCII). On occasions I've done this and have edited the programs with Notepad and used Winape to Paste the code, which Hisoft Pascal happily accepts (just be careful not to exceed 80 chars per line).

Basic may save/load ASCII.  The paste function is very useful.  Ep128emu missed it.  So I used the internal Hisoft Pascal editor.  It is not easy to work with it...  Did anybody try to use graphics with Turbo Pascal?  Turbo Pascal works with ASCII and has the very friendly editor...  I wrote a lot of Turbo Pascal codes for Amstrad CPC/PCW at the 80s but I never used graphics.

In CPC BASIC 3 Real Numbers are not usually supported, though a number of RSXs are available, in the guide I have it specifies that you have to state how many real numbers in a box at the top of the application window. The default is 0, which disables the RSXs available, any other number and the RSXs are available and a little bit of memory is assigned to a table, I haven't used this, but I think the larger the number the more table space is assigned, and is probably a good opportunity to test on a Mandelbrot.
If you do manage to get it to work, the result will probably be an improvement on Hisoft Pascal.

I'm not sure because we should replace all arithmetic by these ugly and slow RSX...

In the Mandelbrot program, the slow part is iterating the z2+c until it diverges or reaches the iteration limit - using the difference of squares method to perform the multiplies, it can be reduced to a bunch of 16 bit subtractions, followed by a bunch of 16 bit additions, and this is something that the Z80 has the edge over the 6502 (16 bit arithmetic in general).  But given the effective clock speed (2MHz 6502 versus ~3.3MHz Z80), maybe it ends up roughly the same.
The actual plotting is not really a bottleneck.  But the CPC could certainly render it much better, given its far nicer palette!

z80 @3.2 MHz is generally as fast as 6502 @1.33 MHz. A skilled z80 programmer may do codes as fast as 6502 @1.5 MHz but it is very uneasy.  Z80 requires more hard work to get the faster code than 6502. z80 is good with division but for fast table multiplication 6502 is better...
Amstrad CPC's Video memory layout is more complex to use than BBC Micro's.  So I gave my estimates about 2 times speed difference.  16 colors will require more time too.

I find that much 6502 assembler a little too much too digest.

Agreed, it is very difficult to convert 6502 codes to z80.  The backward conversion is much easier.  However for a man with experience with 6809 6502 should not be too alien.

[AMSDOS]

Basic may save/load ASCII.  The paste function is very useful.  Ep128emu missed it.  So I used the internal Hisoft Pascal editor.  It is not easy to work with it...  Did anybody try to use graphics with Turbo Pascal?  Turbo Pascal works with ASCII and has the very friendly editor...  I wrote a lot of Turbo Pascal codes for Amstrad CPC/PCW at the 80s but I never used graphics.

In that case I'd suggest Hisoft Pascal 80. It operates in CP/M like Turbo Pascal (and compiles programs for CP/M like TP), supports ASCII files, I don't remember what you use to edit the programs, but at least the manual for HP80 documents how to incorporate GSX into your programs. It's possible to do in Turbo Pascal I think, but it's not documented in the manual (version 3), and you really need to find someone who knows how to do it.

I'm not sure because we should replace all arithmetic by these ugly and slow RSX...

I've only encountered "slow RSX" from within Interpreted Locomotive BASIC which had to spend more time translating the ASCII component from within the bar command & people were suggesting a tokenised CALL had better response time. From a compiled language, this doesn't seem to be an issue, though from CPC BASIC 3, you can produce an output file in Assembly, which should reveal those RSX routines, it would just be a matter of finding the appropriate routines.

[litwr]

I've only encountered "slow RSX" from within Interpreted Locomotive BASIC which had to spend more time translating the ASCII component from within the bar command & people were suggesting a tokenised CALL had better response time. From a compiled language, this doesn't seem to be an issue, though from CPC BASIC 3, you can produce an output file in Assembly, which should reveal those RSX routines, it would just be a matter of finding the appropriate routines.

Try to imagine the complete ugliness of R=2*R*S+E expression in the RSX syntax...

[litwr]

I have run AMSDOS's program with Turbo Pascal under CP/M 2.2.  It takes 4804 seconds.  So its codes are not so good as Hisoft Pascal.  However Turbo Pascal has better editor, disk i/o support, a lot of libraries, ...
Nobody has mentioned the very fast programs for Amstrad CPC - http://www.octoate.de/wp/?s=mavdelbrot...
IMHO the bw picture at the beginning of this thread shows pixels in the most accurate way.

[AMSDOS]

Try to imagine the complete ugliness of R=2*R*S+E expression in the RSX syntax...

Hmm I see your point, I'm not quite sure what you would use in CPC BASIC 3 for that either.

I have run AMSDOS's program with Turbo Pascal under CP/M 2.2.  It takes 4804 seconds.  So its codes are not so good as Hisoft Pascal.  However Turbo Pascal has better editor, disk i/o support, a lot of libraries, ...

I think I know which Mandelbrot program you're referring to, it's the one posted on the forum.
I don't know why it takes longer, it was originally written in Modula-2 before someone converted it to turbo pascal 6 before I converted it to turbo pascal 3, but that was all done on the IBM-PC version.
I'm unsure what video mode I was using 640x480x16 I think, so it took a bit of effort just to have that one working on a CPC.
I'm unsure if there's anything within it which is just wasting time, it appears to be stripped down to do what it needs to do, the next thing I looked at was what the Turbo Pascal version has. The Hisoft Pascal version doesn't use the SQR() function, Turbo Pascal maybe slow in that regard to SQR().
The Turbo Pascal program is using a FUNCTION to obtain a colour value, and from within that FUNCTION a loop is declared which I think would be holding things up. The Hisoft Pascal version has loops within it's main loop (no function has been declared), so the result for the colour is obtained faster and CASE is used to determine the Colour based on the True/False results from rst1 & rst2.
So there's a good chance that what I converted to CPC earlier lags since it's code is derived from a faster computer, there maybe some other things in it which might be slowing the program down, as you pointed out it works in CP/M 2.2 and I was using Turbo Pascal to incorporate Firmware Instructions. To do that from CP/M 2.2 you need to use the assigned Enter Firmware Call to access Firmware and as the program requires obtaining Colours & Plotting Pixels heavily, however much slower that is compared to having direct access (which Hisoft Pascal has), could explain the time difference.

[litwr]

I had used your Hisoft Pascal sources with Turbo Pascal.  I has only slightly adjusted them. 

Code Select Expand


PROGRAM Mandelbrot;

{$i firmware.lib}

CONST ft=1; sm=3; pa=0; mi=15; ni=16;
      fx=-2.4; f2=1.04; fy=-1.3;
      rx=320; ry=200;

VAR timer:real;

function get_timer: real;
   var
      hl, de: integer;
begin
       Inline($CD/$9B/$BE/
          $0D/$DB/
          $22/hl/
          $ed/$53/de);
       if hl<0 then
          get_timer := ((de+1)*65536.0+hl)/300
       else
          get_timer := (de*65536.0+hl)/300
end;

PROCEDURE drawbolt;
VAR xpos : integer;
    ypos : integer;
    col  : integer;
    dx   : real;
    dy   : real;
    d    : real;
    a    : integer;
    s    : real;
    z2   : real;
    z    : real;
    i2   : real;
    i    : real;
    e    : real;
    j    : integer;
    r    : real;
    rst : boolean;
BEGIN
  dx:=0.0; dy:=0.0;
  dx:=f2-fx;
  dy:=dx*(ry/rx)*2;
  dy:=dy/2;
  e:=fy;
  ypos:=0;
  WHILE ypos<ry DO
  BEGIN
    d:=fx;
    xpos:=0;
    WHILE xpos<rx DO
    BEGIN
      z:=0.0; i:=0.0; a:=0; z2:=0.0; i2:=0.0;
      WHILE ((a<mi)) AND ((z2+i2)<4.0) DO
      BEGIN
        s:=(z2)-(i2)+d;
        r:=(2*i*z)+e;
        z:=s;
        i:=r;
        a:=a+1;
        z2:=z*z;
        i2:=i*i
      END;
      col:=3;
      rst := odd(xpos) = odd(ypos);
      j:=a and 7;
      CASE j OF
       1   : IF (rst) THEN col:=1 ELSE col:=3;
       2   : col:=1;
       3   : IF (rst) THEN col:=2 ELSE col:=1;
       4   : col:=2;
       5   : IF (rst) THEN col:=0 ELSE col:=2;
       6   : col:=0;
       7   : IF (rst) THEN col:=3 ELSE col:=0
      END;
      grapen(col);
      plot(xpos*2,ypos*2);
      IF col=1 THEN col:=1 ELSE col:=1;
      d:=d+dx/rx;
      xpos:=xpos+1
      END;
    e:=e+dy/ry;
    ypos:=ypos+1
  END;
END;
BEGIN
  mode(1);
  border(6);
  ink(0,6);
  ink(1,18);
  ink(2,26);
  ink(3,1);
  timer := get_timer;
  drawbolt;
  writeln(get_timer-timer:8:2);
  repeat until keypressed;
  mode(2)
END.

The FIRMWARE module is taken from http://turpas3.angelfire.com/.  The results show that quality of Hisoft Pascal codes is much higher than Turbo Pascal codes.  I commented the calls to plot and grapen and got 4606 seconds.  So this code should be only slightly slower with CP/M+.  Hisoft Pascal codes prove that they are 2.5 times faster.  It is a very good compiler but without ASCII and proper disc i/o support and with a very poor editor.

[AMSDOS]

I'm not sure why Turbo Pascal would be taking so long to get the job done. At one stage I discovered Turbo Pascal was being slow for drawing a simple circle (as found in the Amstrad manual's), though those were using COS & SIN (I also had to use a formula to calculate in degrees), the explanation I got for TP being so slow in that was BASIC was using Lookup Tables to get it's results. Still either of those are used in this Mandelbrot and program is still functions poorly. I can only conclude that TP struggles when it's dealing in the Math, I demonstrated earlier that storing the results in an array works better in TP, as opposed to calculating the result.

[AMSDOS]

I've gone back to the 1st Mandelbrot example in this thread and have written a Hisoft Pascal example of one, but I haven't got the result quite right, apart from the occasion where I took this screenshot of it:


[attachimg=1]


followed by the code I made up for it:

Code Select Expand



   10 PROGRAM Mandelbrot;
   20
   30 CONST r0=-1.9; r1=0.5; j0=-0.1; j1=0.95; n=30;
   40
   50 VAR data : ARRAY[0..2,0..319] OF integer;
   60       j2 : ARRAY[0..199] OF real;
   70       dj : real;
   80       dr : real;
   90        t : integer;
  100        s : integer;
  110        m : integer;
  120        x : real;
  130        y : real;
  140       xy : real;
  150        r : real;
  160        j : real;
  170       x2 : real;
  180       y2 : real;
  190        i : integer;
  200        z : integer;
  210        a : integer;
  220        b : integer;
  230        c : integer;
  240
  250 PROCEDURE mode(num : integer);
  260 BEGIN
  270   ra:=chr(num);
  280   user(#bc0e)
  290 END;
  300
  310 PROCEDURE plot(x,y,col : integer);
  320 BEGIN
  330   ra:=chr(col);
  340   user(#bbde);
  350   rde:=x;
  360   rhl:=y;
  370   user(#bbea)
  380 END;
  390
  400 PROCEDURE ink(ink,col1 : integer);
  410 BEGIN
  420   ra:=chr(ink);
  430   rb:=chr(col1);
  440   rc:=chr(col1);
  450   user(#bc32)
  460 END;
  470
  480 FUNCTION rdkey : char;
  490 BEGIN
  500   user(#bb1b);
  510   rdkey:=ra
  520 END;
  530
  540 FUNCTION test(xpos,ypos : integer) : integer;
  550 BEGIN
  560   rde:=xpos;
  570   rhl:=ypos;
  580   user(#bbf0);
  590   test:=ord(ra)
  600 END;
  610
  620 BEGIN {Main PROGRAM}
  630   a:=0; b:=1; c:=2;
  640   dr:=(r1-r0)/320;
  650   dj:=(j1-j0)/200;
  660   FOR t:=0 TO 199 DO
  670     j2[199-t]:=j0+dj*t;
  680   mode(1); ink(0,1); ink(1,26);
  690   FOR t:=2 TO 199 DO
  700   BEGIN
  710     j:=j2[t];
  720     FOR s:=2 TO 319 DO
  730     BEGIN
  740       r:=r0+dr*s;
  750       x:=r;
  760       y:=j;
  770       i:=1;
  780       x2:=x*x;
  790       y2:=y*y;
  800       WHILE (x2+y2<4) AND (i<=n) DO
  810       BEGIN
  820         xy:=x*y;
  830         x:=x2-y2+r;
  840         y:=2*xy+j;
  850         i:=i+1;
  860         x2:=x*x;
  870         y2:=y*y
  880       END; {WHILE Interation Statement}
  890       data[c,s]:=i;
  900       IF (i<=n) THEN plot(s+s,400-(t*2),1);
  910       IF (s<319) OR (t<199) THEN
  920       BEGIN
  930         IF test(s+s-2,402-(t*2))<>0 THEN
  940         BEGIN
  950          m:=data[b,s-1];
  960          IF (data[b,s-2]<m) AND (data[b,s]<m) THEN plot(s+s-2,402-(t*2),0);
  970          IF (data[a,s-2]<m) AND (data[b,s]<m) THEN plot(s+s-2,402-(t*2),0);
  980          IF (data[c,s-2]<m) AND (data[a,s]<m) THEN plot(s+s-2,402-(t*2),0);
  990          IF (data[a,s-1]<m) AND (data[c,s-1]<m)THEN plot(s+s-2,402-(t*2),0)
1000         END {IF test Statement}
1010       END; {IF s OR t is Less than 2}
1020     END; { FOR S Statement }
1030     z:=a; a:=b; b:=c; c:=z;
1040   END { FOR T Statement }
1050 END. {Main PROGRAM}



I've also attached the DSK image.

[SRS]

Looking at the Mandelbrot Example running (slow!) from here  http://turpas3.angelfire.com/
with WinApe debugger it seems the code is using EXX and EX AF,AF' almost every time it works with a register .. so this may be one reason why it is slower than HiSoft.

[AMSDOS]

Looking at the Mandelbrot Example running (slow!) from here  http://turpas3.angelfire.com/
with WinApe debugger it seems the code is using EXX and EX AF,AF' almost every time it works with a register .. so this may be one reason why it is slower than HiSoft.

I guess if you've got a lot of them combined, both of those instructions use up 8 clock cycles.

The other problem with Turbo Pascal is it has to run on a number of CP/M systems, it needs a Z80 system though. Hisoft initially developed their Pascal on a Spectrum and there was a number of versions from what I understand. The Amstrad version of it seems to just have a release date of 26/9/84 and comes with provisions to easily access the Amstrads firmware, along with a couple of other specific Amstrad related Procedures & Functions.

I'm glad I've moved from Turbo Pascal to Hisoft Pascal, though was initially ranting about Hisoft Pascal on c.s.a.8, mainly about the editor, though would not of had a manual either & using a different emulator at the time (probably Caprice). Richard was nice enough to add an Paste option in Winape which allows me to use a Text editor and simply Paste the code, which the Hisoft Pascal editor handles quite well, even though it goes against what one did when coding on an Real Amstrad.