ascjulia.c and ascbrot.c
Forum rules
Be nice. No drama.
Be nice. No drama.
ascjulia.c and ascbrot.c
First tries to do Julia fractal what intrested me in first place. Many Mandelbrot versions had been done earlier, but no Julia. So I had to do first Mandelbrot to get Julia. Later on I did Burning Ship which is based on Mandelbrot. I took many tries and fails to get it working. When the math was correct all fractals opened up. Ascii version seemed simple enough to do first.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Fist steps with Gigatron programming with LCC.
At some point this or other version of this code draw some waves.
Now it's stuck on giving floating point overflow.
The compiler doesn't warn it, but gtsim and actual Gigatron report that.
Any idea what to fix?
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Fist steps with Gigatron programming with LCC.
At some point this or other version of this code draw some waves.
Now it's stuck on giving floating point overflow.
The compiler doesn't warn it, but gtsim and actual Gigatron report that.
Any idea what to fix?
Last edited by veekoo on 22 Nov 2023, 08:34, edited 6 times in total.
Re: ascii-julia.c
This is optimized now for Gigatron 26x15 screen. Seems to be working now that I don't do all iterations.
I was curious how this runs at x86-pc with virtual ubuntu linux. I compiled with gcc and executable runs very fast compared actual gt1. Current speed is one screen in 2hrs.
I attached GT1 file which was compiled at default settings. So it runs on rom v5a?
I was curious how this runs at x86-pc with virtual ubuntu linux. I compiled with gcc and executable runs very fast compared actual gt1. Current speed is one screen in 2hrs.
I attached GT1 file which was compiled at default settings. So it runs on rom v5a?
Last edited by veekoo on 11 Sep 2021, 12:27, edited 1 time in total.
Re: ascii-julia.c
Glcc by default compiles for romv5a. Command glcc -info tells you exactly what is selected.
The runtime by default generates an exception on overflow. This is because the MS floating point format does not support nans or infinities. From your message it is not clear to me whether the floating exception arises because a floating point calculation is incorrect or because this is a genuine overflow.
* In the case of a genuine overflow, you could use signal(SIGFPE, SIG_IGN) to ignore the overflow. The overflowing code will simply return HUGE_VAR which will exceeed the threshold anyway. Alternatively you can define your own signal handler and set an overflow flag that you can test later. Whatever the signal handler returns (assuming it returns a float) will be returned by the overflowing instruction (see https://github.com/lb3361/gigatron-lcc/ ... STsignal.c for examples involving division by zero with ints and longs).
* On the other hand, if this arises because the runtime compiles something incorrect, then I have to investigate why. Can you send me a code that triggers the exception (the one above does not).
A x86 processor, even a virtual one, is considerably faster than the Gigatron. In addition the GLCC floating point is entirely written in software (vCPUs ource code at https://github.com/lb3361/gigatron-lcc/ ... me/rt_fp.s). In contrast, a modern x86 has this in hardware with a rather efficient pipeline.
The runtime by default generates an exception on overflow. This is because the MS floating point format does not support nans or infinities. From your message it is not clear to me whether the floating exception arises because a floating point calculation is incorrect or because this is a genuine overflow.
* In the case of a genuine overflow, you could use signal(SIGFPE, SIG_IGN) to ignore the overflow. The overflowing code will simply return HUGE_VAR which will exceeed the threshold anyway. Alternatively you can define your own signal handler and set an overflow flag that you can test later. Whatever the signal handler returns (assuming it returns a float) will be returned by the overflowing instruction (see https://github.com/lb3361/gigatron-lcc/ ... STsignal.c for examples involving division by zero with ints and longs).
* On the other hand, if this arises because the runtime compiles something incorrect, then I have to investigate why. Can you send me a code that triggers the exception (the one above does not).
A x86 processor, even a virtual one, is considerably faster than the Gigatron. In addition the GLCC floating point is entirely written in software (vCPUs ource code at https://github.com/lb3361/gigatron-lcc/ ... me/rt_fp.s). In contrast, a modern x86 has this in hardware with a rather efficient pipeline.
Re: ascii-julia.c
The problem with floating point overflow was caused by programming error. In the screen there should be put one character per "pixel'. I didn't exit the loop and put out all iterations on the screen.
Currently what I get from the program is far from fractal. Maybe some mistake mixing complex math with regular?
Currently what I get from the program is far from fractal. Maybe some mistake mixing complex math with regular?
Re: ascii-julia.c
This days work.
Last edited by veekoo on 02 May 2023, 18:38, edited 2 times in total.
Re: ascii-julia.c
It should look like this.
It seems to zoom out and the empty gap is minimized. It takes a couple of minutes to draw a screen. I doubt that the equations are correct, because it doesn't look like the picture
It seems to zoom out and the empty gap is minimized. It takes a couple of minutes to draw a screen. I doubt that the equations are correct, because it doesn't look like the picture
- Attachments
-
- Julia_-0.8_0.156.png (201.79 KiB) Viewed 9150 times
Last edited by veekoo on 02 May 2023, 18:39, edited 2 times in total.
Re: ascii-julia.c
I doubt the resolution (26x15) of Gigatron allows this julia to be shown. I first need it to get working on bigger screen/terminal (132x43). Here is what I tried with linux.
- Attachments
-
- julia132_43.PNG (65.78 KiB) Viewed 9133 times
Last edited by veekoo on 02 May 2023, 18:40, edited 1 time in total.
Re: ascii-julia.c
This time with Gigatron 26x15. It takes 2 minutes to draw the screen.
- Attachments
-
- IMG_0915.JPG (4.55 MiB) Viewed 9130 times
Last edited by veekoo on 02 May 2023, 18:40, edited 2 times in total.
Re: ascii-julia.c
Now with graphics?
Note: the code above assumes the screen has not been scrolled -- default videoTable.
Otherwise you can include <gigatron/console.h> and call console_clear_screen(void) to reset it.
Code: Select all
#include <gigatron/console.h>
void drawPixel(int x, int y, int color)
{
screenMemory[y][x] = color;
}
Otherwise you can include <gigatron/console.h> and call console_clear_screen(void) to reset it.
Re: ascii-julia.c
Yes logical step is to do next with graphics. I had lot to correct with code and I realized I had to do mandelbrot first to check the functionality of julia. So here is ascbrot.c and ascjulia.c. It takes 3 minutes to draw the fractals.lb3361 wrote: ↑12 Sep 2021, 03:03 Now with graphics?
Note: the code above assumes the screen has not been scrolled -- default videoTable.Code: Select all
#include <gigatron/console.h> void drawPixel(int x, int y, int color) { screenMemory[y][x] = color; }
Otherwise you can include <gigatron/console.h> and call console_clear_screen(void) to reset it.
- Attachments
-
- IMG_0919.JPG (4.18 MiB) Viewed 9100 times
-
- IMG_0918.JPG (4.29 MiB) Viewed 9100 times
Last edited by veekoo on 22 Nov 2023, 14:08, edited 3 times in total.