16 Color Mandelbrot Set for FabGL terminals.

[Eightbitswide]

More toys for FabGL Serial Terminal Based Systems.

This creates a 16 Color Mandelbrot Set in between 4-5 hours.

Created for Microsoft BASIC-80 Rev. 5.21 [CP/M Version] .

I've removed all the $ endings from the FabGL commands, as they seem to create

transmission errors, so I'm curious if this version of the program will run unmodified

on others who run the same terminal here.   Let me know.

-8b

[Eightbitswide]

Here's a compiled version that runs considerably faster.

-8b

http://www.gunstar.one/fabgl/MANDELB.COM

[Eightbitswide]

Thanks for the test, John.

I suspected that PPMVIEW could be cleaned up a bit when I saw that on my Mandelbrot program.

-8b

On Sunday, October 30, 2022 at 12:53:00 PM UTC-4 John Galt wrote:

i tested this on my altair pro after i connected a VGA32 V1.4 to the system.

works fine.

i went back and ran the PPMVIEWer in the other thread, ran into a few $ errors in the upper left corner.

I modified your PPMView code and pulled out the $s end of line statements and errors stopped and i think it sped it up a little also.

i recompiled everything with bascom. maybe its because basic print in mbasic is using the CP/M string Bdos call where it uses '$' to indicate EOL?? no idea.

would have to write a direct assembler call function for _GPIXEL and _GPEN i guess to speed it up but 9600 Baud is really slow too. i ran into similar issues with a 3d engine i made for the graham ascii terminal.

here is the changes.

-------------------

1 DEFINT A-Z updated 10/30/2022
2 ON ERROR GOTO 600
3 Y=100 : REM DOWNSCREEN STARTING POS.
10 REM  ___ ___ __  ____   _____ _____      __
20 REM | _ \ _ \  \/  \ \ / /_ _| __\ \    / /
30 REM |  _/  _/ |\/| |\ V / | || _| \ \/\/ /
40 REM |_| |_| |_|  |_| \_/ |___|___| \_/\_/
50 REM
60 REM By Eightbitswide  - Requires FabGL Terminal
70 REM
80 REM Written for Microsoft MBASIC to view .ppm files.
90 REM .ppm files must be in ASCII.
95 REM
100 PRINT CHR$(27)+"[2J"+CHR$(27)+"[H";
110 PRINT "MBASIC .PPM FILE VIEWER: BY EIGHTBITSWIDE":PRINT
120 PRINT "-----------------------------------------":PRINT: PRINT
130 PRINT ".PPM FILES MUST BE ASCII, EACH COLOR SEPERATED BY CR." : PRINT
140 PRINT "GIMP IS A GOOD PROGRAM FOR PICTURE CONVERSION.": PRINT
145 PRINT "REQUIRES FABGL TERMINAL SET IN 512x384, 64 COLORS.":PRINT
150 PRINT :FILES "*.PPM"
160 PRINT :PRINT : PRINT "Pick a file: (or QUIT):";
170 LINE INPUT "-> ";C$
180 IF C$="quit" THEN END
190 IF C$="QUIT" THEN END
200 PRINT CHR$(27)+"[2J"+CHR$(27)+"[H";
210 OPEN "i",2,C$
220 INPUT #2,TY$
230 INPUT #2,DC$
240 INPUT #2,SZ$ : REM WE ARE ONLY CONCERNED WITH SZ
250 INPUT #2,NM$
300 REM DETERMINE WIDTH OF IMAGE
310 I=LEN(SZ$)
320 X=1
330 A$=MID$(SZ$,X,1) : REM <---LOOP
340 IF A$=" " THEN GOTO 400
350 B$=B$+A$
360 X=X+1
370 IF X>I THEN END
380 GOTO 330
400 REM
410 REM CALCULATE CENTER
420 YY=VAL(B$)
430 PS=512-YY
440 PS=PS/2
500 REM FETCH AND PRINT PICTURE
510 Y=Y+1
520 FOR X = 1+PS TO YY+PS
530 INPUT #2,RD$
540 INPUT #2,GR$
550 INPUT #2,BL$
560 PRINT CHR$(27)+"[H";
570 PRINT CHR$(27)+"_GPEN"+RD$+";"+GR$+";"+BL$
580 PRINT CHR$(27)+"_GPIXEL";X;Y
590 NEXT X
595 GOTO 500
600 REM CLOSE UP AND POSITION CURSOR
610 CLOSE #2
620 PRINT CHR$(27)+"_F0;40"
630 PRINT CHR$(27)+"_GPEN255;255;255"
640 END
-----------

some feedback i didn't want to start changing all the code.

you can add in some error checking for the file name. so if the user does not include the file extension it will automatically append a PPM to the end use a string length check, rather then a dump to the prompt.

when the image is completed you could put a message either at the top or bottom of the screen letting the user know its completed, then have it wait for user input with a options message around the edge of the screen like "press 'ESC' to exit" press 'L' to load another file" This way it holds the screen as it is and does not dump right back to the Prompt when finished.

I can also modify the code so it acts like a printer output that would allow me to use the Graham Ascii terminal as primary and have it output to the VGA32 ESP32 FABGL terminal as secondary.

quick recap the Mandelbrot set worked on my machine. and after i modified your PPMView code and ditched the $ it did not error and seemed a little faster.

my setup is a little Kludgy since i added so many more terminals to the machine, i switch between the modified Graham Ascii Terminal, the VGA32 ESP32 and dazzler

i need to 3d print some more LCD stands and figure out how to clean up my desktop.

[Eightbitswide]

>I can also modify the code so it acts like a printer output that would allow me to use the Graham Ascii terminal

> as primary and have it output to the VGA32 ESP32 FABGL terminal as secondary.

John,

I suspect that we could add the Geoff Graham ASCII terminal [Z sequences to the FabGL AnsiTerminal code.

I've been digging in the code for the last couple days.  My C is weak, but if I can find the section of the terminal

code that supports _GLINE and _GPIXEL I'm sure that an addition for Z should be straightforward enough.

I'd also like to implement a _GVIDMODE which would allow the video mode to be switched from the controlling program.

-8b

[Eightbitswide]

John,

I've been playing with the AnsiTerminal code.  Attached is a few additional lines of code which will give BASIC

access to the Fonts and Resolution settings.   Just exchange the sections of code in the file and recompile it to your ESP32.

Then you can do print chr$(27)+"_#512x384x64$" and print chr$(27)+"#VGA 8x8$"

-8b

On Sunday, October 30, 2022 at 10:34:19 PM UTC-4 John Galt wrote:

for the altair pro its all built in around the graham terminal, if you are coming from using the ESP32 as an Altair or building one around the ESP32 then its a different story.

its possible to integrate the graham terminal into the ESP32 it already has a ton built in.

the way the pro kit is built its just easier to use the ESP32 as a secondary terminal then switch terminals in CP/M

i can also send serial commands to port b and just have it display information on both monitors if i setup a game or application that took advantage of it. however i have a dazzler and its faster to use that for animations since its DMA.

[villa...@gmail.com]

Thanks 8b for these additions, they work well, never thought of attempting to modify the code for extra commands, don't think I could any rate!!!

BTW the Mandelbrot works perfectly as is.

I've been playing with the AnsiTerminal code.  Attached is a few additional lines of code which will give BASIC

access to the Fonts and Resolution settings.   Just exchange the sections of code in the file and recompile it to your ESP32.

Then you can do print chr$(27)+"_#512x384x64$" and print chr$(27)+"#VGA 8x8$"

[Eightbitswide]

I've started working on splitting these to two commands so that you can send the resolution and font changes, then do a single apply settings command.   I'll post some more code late tonight.

-8b

[Walt Perko]

Hi, 

Sounds like another argument for a stand-alone do all of it type keyboard/terminal.  

.

On Wednesday, November 2, 2022 at 12:39:08 PM UTC-7 John Galt wrote:

there is a ton you could keep adding same with Grahams Ascii terminal(its a little more limited due to pic32 space) the problem is getting out of sync with the original code and then people having to find your changes which might become incompatible with the original.

it also starts turning into the FABGL driving the Altair verse Altair driving the FABGL. 

which is fine since at 2mhz you can't really do much and having some hardware acceleration helps even emulated.

[Walt Perko]

Hi, 

A modern computer doesn't have the software, firmware or even hardware to connect a parallel ASCII terminal with various emulated line paper printer displays etc.  

Also, a modern computer generally isn't a kit you solder everything onto.  

The starting with the original Don Lancaster TV Typewriter, but creating a newer circuit board design, still through hole so almost any age can solder it up. 

 The physical keyboard would be a USB keyboard compatible connection and there would be VGA and maybe HDMI video outputs. 

 There would also be at least one RS-232 serial port to goto the computer console connection as well as a parallel ASCII output that would carry all the signals used by the top 5 or 10 different vintage computers so that the user would make a special cable to make the connections to their vintage computer.  Also, I think tapping off the parallel port to LEDs so that users can see the keys as they’re typed and might also aid in troubleshooting. 

 The “bell” would be loud like on old teletypes and typewriters … maybe a real bell with a hammer triggered by the electronics (that would be awesome!) 

 There should be a Function key select to get into configurations to select as a dumb terminal, ASCII keyboard, change background and fonts and font colors. 

 The choice of backgrounds should be adjustable colors, look like fan-fold paper, green bar paper, multi-color bar paper, plain black, plain white, and faded 1940’s yellow teletype paper. 

 I think if a kit like this can be designed, it might help to bring more people into the vintage computer hobby, but also help kids all ages just play with the historical emulations. 

 Once that device is created, I don’t know if there would be another little device to connect to it, or maybe built-in … a way to connect to a LAN or maybe WiFi, but it would require setting up the transceiver BAUD rate like a vintage terminal and maybe restricted to about 19K BAUD if not even 9600 BAUD. 

 The ideal terminal would be able to emulate the sounds of various devices (Teletype noises, Dot Matrix printers, Modems connecting, Cassette I/O sounds like the Kansas protocol or earlier Altair cassette sounds). 

Also, the display should be selectable on the fly as well, switching between WWII teletype faded yellow paper, ASR33 wide carriage paper various paper types/color schemes, 80 column dot matrix paper, IBM Selectric paper etc.  Also basic CRT screens with green or orange or yellow or white letters on a black background or a faded grayish green background. 

Pretty much the whole vintage experience in the terminal that connects via RS232 and when needed Parallel ASCII lines to old computers.  

There are these, but I'm not sure they can completely fill the bill.  Somebody would need to add the software/firmware and even Parallel ASCII OUT, but this is a close solution.  

. 

On Wednesday, November 2, 2022 at 1:38:29 PM UTC-7 John Galt wrote:

its called a modern computer.

[Eightbitswide]

John,

Yeah, I want the Altair to control the FabGL as much as possible. Definitely not the other way around.

As soon as I can pick my way further into the Terminal Library part of FabGL, I will try to implement the Z commands from the Geoff Terminal so that compatibility won't be an issue.  My C is a bit weak and free time only really on the weekends, so it will be a bit.  ;)

-8b

[Eightbitswide]

Yeah, I've gotten nothing back on any of the discussions on Github.   If you purchase one of his boards, he seems a bit for inclined to answer/communicate.

8b

On Tuesday, November 8, 2022 at 10:26:06 AM UTC-5 John Galt wrote:

i emailed  Fabrizio at fabgl but i doubt i will hear back from him.

On Sunday, November 6, 2022 at 4:58:17 PM UTC-5 John Galt wrote:

i noticed an issue with the fabgl library there is no option to return a pixel value from the terminal. there needs to be a PUT PIXEL function opposite of get pixel. such that when you call  PRINT CHR$(27)+"_PUTPIXEL";X;Y
it should return a value from the terminal allowing a bidirectional exchange of information. the mouse function returns values so you can locate where it is on the screen. the pixels need to be able to do the same.

this would allow you to screen capture from the terminal or compare values between the terminal at X,Y and what is expected.

This leads to an issue with having to hold a screen array of (x,y, values) to keep tabs on what is occurring on the screen since you cannot get feedback from the terminal memory.

example if you draw a line on the terminal you would need to run through the line algo on the altair to get X,Y position and what color save that information in disk file since there is not enough memory then send out the _GLINE string to the terminal and draw it there. its an extra step and very slow in order to keep a record of what is being displayed on the screen. 

when you have DMA you can simply go to the memory location of the X,Y position and read that byte of data and strip what color you need from that, you can't do that with a serial terminal.