Setting Resolution in FabGL

again not sure 320x200 is a default available mode:
// Change resolution (for example: ESC + "_#512x384x64$")

// Usable options:
// "1280x768x2","1024x720x4","800x600x8","720x520x16","640x480 73x16"
// "640x480 60x16","640x350x16","512x384x64","400x300x64"

On Tuesday, January 3, 2023 at 1:19:54 AM UTC-5 John Galt wrote:
i found the patch here:

"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$""

https://groups.google.com/g/altair-duino/c/Jnf9dGsmaPg/m/xqtJN8ZTBAAJ

On Tuesday, January 3, 2023 at 12:54:25 AM UTC-5 John Galt wrote:

I don’t remember 320x200 being an available mode
Hit f12 for available modes
Eightbit put out some code to allow font switching via escape codes
It’s buried in one of his threads here

He made a petsci font
https://github.com/eightbitswide/FabGl_font_8x8_replacement

I have my resolution locked so I can have 80x48 character rows

Message has been deleted

Tom Lake

unread,

Jan 8, 2023, 5:34:03 AM1/8/23

to Altair-Duino

OK, thanks! I added a 320x200x64 mode to the source code myself so I could run the HAT.BAS program to display a green hat.
I haven't been able to test it yet to see if the origin is at the upper left or lower left.

If it's at the upper left, then subtract the Y coordinates from 200 in line 520:

530 DEF FNLN$(X1,Y1,X2,Y2)=PRINT CHR$(27)+"_GLINE"+STR$(X1)+";"+STR$(200-Y1)+";"+STR$(X2)+";"+STR$(200-Y2)+"$" ' DRAW LINE FROM X1,Y1 TO X2,Y2

Otherwise the program should work as is.

10 GOSUB 500 ' INITIALIZE GRAPHICS FUNCTIONS
20 P=160: Q=100
30 XP=144: XR=1.5*3.1415927
40 YP=56: YR=1: ZP=64
50 XF=XR/XP: YF=YP/YR: ZF=XR/ZP
60 FOR ZI=-Q TO Q-1
70 IF ZI<-ZP OR ZI>ZP THEN GOTO 150
80 ZT=ZI*XP/ZP: ZZ=ZI
90 XL=INT(.5+SQR(XP*XP-ZT*ZT))
100 FOR XI=-XL TO XL
110 XT=SQR(XI*XI+ZT*ZT)*XF: XX=XI
120 YY=(SIN(XT)+.4*SIN(3*XT))*YF
130 GOSUB 170
140 NEXT XI
150 NEXT ZI
160 STOP
170 X1=XX+ZZ+P
180 Y1=YY-ZZ+Q
190 PRINT FNPEN$(0,255,0) : PRINT FNPIXEL$(X1,Y1) ' Set green pixel at X,Y
200 IF Y1 = 0 THEN GOTO 220
210 PRINT FNPEN$(0,0,0) : PRINT FNLN$(X1,Y1-1,X1,0) ' Draw a black line from current position -1 to bottom of screen
220 RETURN
500 PRINT CHR$(27);"_#320X200X64$" ' SET RESOLUTION TO 320X200 IN 64 COLORS
510 DEF FNPEN$(R,G,B)=CHR$(27)+"_GPEN"+STR$(R)+";"+STR$(G)+";"+STR$(B)+"$" ' SET PEN COLOR
520 DEF FNPIXEL$(X,Y)=CHR$(27)+"_GPIXEL"+STR$(X)+";"+STR$(Y)+"$" ' SET PIXEL ON
530 DEF FNLN$(X1,Y1,X2,Y2)=PRINT CHR$(27)+"_GLINE"+STR$(X1)+";"+STR$(Y1)+";"+STR$(X2)+";"+STR$(Y2)+"$" ' DRAW LINE FROM X1,Y1 TO X2,Y2
540 RETURN
999 END

On Saturday, January 7, 2023 at 10:31:19 PM UTC-5 John Galt wrote:

Tom I wrote to you on Github.

Let me put the information here.

the original Asci Terminal Code seems to be bugged.

if you look into the source code it tells you:

// onUserSequence is triggered whenever a User Sequence has been received (ESC + '_#' ... '$'), where '...' is sent here
Terminal.onUserSequence = [&](char const * seq) {
// 'R': change resolution (for example: ESC + "_#R512x384x64$")
for (int i = 0; i < RESOLUTIONS_COUNT; ++i)
if (strcmp(RESOLUTIONS_CMDSTR[i], seq) == 0) {
// found resolution string
preferences.putInt(PREF_TEMPRESOLUTION, i);
if (ConfDialogApp::getBootInfo() == BOOTINFO_ENABLED)
preferences.putInt(PREF_BOOTINFO, BOOTINFO_TEMPDISABLED);
ESP.restart();
}
};
}

this actually does not work.

I took eightbitwide's code

//----------------------------------------------------------------------------------------------------------------------
//
// EXCHANGE THE CODE ABOVE WITH THE CODE BELOW: Recompile and upload to the ESP32
// Code will allow BASIC/PASCAL control over Resolution, Color Level, and Fonts upon Demand.
//
//----------------------------------------------------------------------------------------------------------------------

// onUserSequence is triggered whenever a User Sequence has been received (ESC + '_#' ... '$'), where '...' is sent here
Terminal.onUserSequence = [&](char const * seq) {

// Change resolution (for example: ESC + "_#512x384x64$")

// Usable options:

// "1280x768x2","1024x720x4","800x600x8","720x520x16","640x480 'ATSIGN'73x16"
// "640x480'ATSIGN'60x16","640x350x16","512x384x64","400x300x64"

for (int i = 0; i < RESOLUTIONS_COUNT; ++i)
if (strcmp(RESOLUTIONS_CMDSTR[i], seq) == 0) {
// found resolution string
preferences.putInt(PREF_TEMPRESOLUTION, i);
if (ConfDialogApp::getBootInfo() == BOOTINFO_ENABLED)
preferences.putInt(PREF_BOOTINFO, BOOTINFO_TEMPDISABLED);
ESP.restart();
}

// Change font (for example: ESC + "_#VGA 8x8$")

// Usable options:
// "Auto", "VGA 4x6", "VGA 5x7", "VGA 5x8", "VGA 6x8", "VGA 6x9", "VGA 6x10", "VGA 6x12", "VGA 6x13",
// "VGA 7x13", "VGA 7x14", "VGA 8x8", "VGA 8x9", "VGA 8x13", "VGA 8x14", "VGA 8x16", "VGA 8x19", "VGA 9x15",
// "VGA 9x18", "VGA 10x20", "BigSerif 8x14", "BigSerif 8x16", "Block 8x14", "Broadway 8x14",
// "Computer 8x14", "Courier 8x14", "LCD 8x14", "Old English 8x16", "Sans Serif 8x14", "Sans Serif 8x16",
// "Slant 8x14", "Wiggly 8x16"

for (int i = 0; i < FONTS_COUNT; ++i)
if (strcmp(FONTS_STR[i], seq) == 0) {
// found font string
preferences.putInt(PREF_FONT, i);
if (ConfDialogApp::getBootInfo() == BOOTINFO_ENABLED)
preferences.putInt(PREF_BOOTINFO, BOOTINFO_TEMPDISABLED);
ESP.restart();
}

};
}

spliced it in and recompiled.

now when you type in
10 PRINT CHR$(27)+ "_#512x384x64$"
20 END

it does work, note the missing 'R' with what eightbitwide patched.

you can also change fonts.
30 PRINT CHR$(27)+"_#VGA 8x8$"

Keep this in mind, when you switch resolutions or fonts the terminal will reset to a blank screen. you need a keypress to get the system to respond and start to use the new mode on the display

these are the only supported resolutions
// "1280x768x2","1024x720x4","800x600x8","720x520x16","640x480'ATSIGN'73x16"
// "640x480 'ATSIGN'60x16","640x350x16","512x384x64","400x300x64"

there is no 320x200 mode programmed for the terminal build

when you change the mode or font it overwrites the existing terminal settings so when you reboot the terminal or power it off it will not return to your original settings you will have to reset your defaults save and reboot the terminal again.

at note 'ATSIGN' i had to put because google is stupid and refused to believe it was not a email address and would not let me post

Tom Lake

unread,

Jan 8, 2023, 5:37:39 AM1/8/23

to Altair-Duino

If Y coordinates are reversed so origin is at upper left, you also have to change line 520:

520 DEF FNPIXEL$(X,Y)=CHR$(27)+"_GPIXEL"+STR$(X)+";"+STR$(200-Y)+"$" ' SET PIXEL ON AT X,Y

Eightbitswide

unread,

Jan 17, 2023, 11:50:37 PM1/17/23

to Altair-Duino

Tom,

Good catch on that 320x200 resolution setting. I've added it to my own as option #9. I'm able to run it at 70Hz on my old 14" VGA screen. 60HzD didn't want to sync.

What is the best way to share these changes we have made to AnsiTerminal?

Eightbitswide

Message has been deleted

Tom Lake

unread,

Jan 18, 2023, 11:01:12 AM1/18/23

to Altair-Duino

You can send the changes to Github to have them considered for inclusion or you can post them as a fork.

The changes are in the file confdialog.h around lines 99-155

confdialog.h

Eightbitswide

unread,

Jan 18, 2023, 11:39:35 AM1/18/23

to Altair-Duino

Yup, those are the same changes I came up with here... Expect the resolution height. I was using 200 instead of -1. Changing it seems to make the monitor a little happier at startup.

8b

Walt Perko

unread,

Jan 18, 2023, 2:17:06 PM1/18/23

to Altair-Duino

Hi,

I'm hoping that when the local Altair-Duino users settle on a final version, it is posted here so all we have to do is send the file to the ESP32 and play with it rather than trying to figure out more complex compiling and configuring.

.

Message has been deleted

fridtjof.ma...@gmail.com

unread,

Jan 18, 2023, 4:13:51 PM1/18/23

to Altair-Duino

John

Yes -- and I find this frustrating. XTERM

https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Functions-using-CSI-_-ordered-by-the-final-character_s_

has the best coverage (I even use it for my la36 project).

For example (from that page)

CSI ? Pi ; Pa ; Pv S Set or request graphics attribute (XTSMGRAPHICS), xterm. If configured to support either Sixel Graphics or ReGIS Graphics, xterm accepts a three-parameter control sequence, where Pi, Pa and Pv are the item, action and value: Pi = 1 ⇒ item is number of color registers. Pi = 2 ⇒ item is Sixel graphics geometry (in pixels). Pi = 3 ⇒ item is ReGIS graphics geometry (in pixels). Pa = 1 ⇒ read attribute. Pa = 2 ⇒ reset to default. Pa = 3 ⇒ set to value in Pv. Pa = 4 ⇒ read the maximum allowed value. Pv is ignored by xterm except when setting (Pa == 3 ). Pv = n ⇐ A single integer is used for color registers. Pv = width ; height ⇐ Two integers for graphics geometry. xterm replies with a control sequence of the same form: CSI ? Pi ; Ps ; Pv S where Ps is the status: Ps = 0 ⇐ success. Ps = 1 ⇐ error in Pi. Ps = 2 ⇐ error in Pa. Ps = 3 ⇐ failure. On success, Pv represents the value read or set. Notes: o The current implementation allows reading the graphics sizes, but disallows modifying those sizes because that is done once, using resource-values. o Graphics geometry is not necessarily the same as "window size" (see the dtterm window manipulation extensions). XTerm limits the maximum graphics geometry according to the maxGraphicSize resource. The maxGraphicSize resource can be either an explicit heightxwidth (default: 1000x1000 as of version 328) or the word "auto" (telling XTerm to use limits the decGraphicsID or decTerminalID resource to determine the limits). o XTerm uses the minimum of the window size and the graphic size to obtain the maximum geometry. o While resizing a window will always change the current graphics geometry, the reverse is not true. Setting graphics geometry does not affect the window size. o If xterm is able to support graphics (compile-time), but is not configured (runtime) for graphics, these responses will indicate a failure. Other implementations which do not use the maximum graphics dimensions but are configured for graphics should report zeroes for the maximum geometry rather than a failure.

And, window manipulation commands... which could affect the hardware... if needed. A lingua franca if you will. And... not only Sixel and RegGIS (which are also standards), we get Tek 4010 (and, in colour, as an extension).

The only problem? When selecting 132 columns using the DEC command it changes to 132x28. Not a big deal! SuperCalc2 (where I use the mode) works fine.

And here is a screenshot:

Notice the graphic (yes this IS running CP/M -- This is my Altair-Duino booting from hard disk) -- that is a SIXEL. Notice the

double high/double wide DEJAH. Notice the Italic ALTAIR 8800... This works on XTERM. No... it will NOT work on almost

anything else (I hesitate to say "nothing", but I haven't found an emulator that works like this). Yes, I am looking. FabGL? why? I

would be giving up sixel, trek and regis, no? Also, double high/double wide and italic. Basically everything that makes this

image "pretty". Or am I wrong?

On Wednesday, January 18, 2023 at 2:30:24 PM UTC-5 John Galt wrote:

The problem is it will never be settled.

each person wants something different out of the terminals it just leads to endless multiple branches where eventually there will be incompatibilities.

the current modifications that have been posted do not interfere with each other yet.

the current mods involve adding the ability to change resolution or fonts through Escape codes and adding new resolution modes that can again be accessed via escape codes.

that does present problems as allowing changing fonts and resolution through escape codes means its possible to accidently send escape codes and cause the change when you do not want them to occur. you can always go into the configuration menu and change a font or resolution and leave it locked in(if its a valid font or resolution)

the fabgl code goes through various changes and updates on Github. its possible some features will integrate into the master code or that the code posted here could become invalid at some point because of a major shuffling of the code by the author.

when you change modes with the terminal it also has to reset and those changes become permanent on reboot or reset and that might not be what you want as you will need to manually change them back to how you want or you needed to manually code in return escape codes when your program ends to return to defaults.

Message has been deleted

Eightbitswide

unread,

Jan 18, 2023, 10:34:40 PM1/18/23

to Altair-Duino

It isn't really a fight.. It's actually true to the decades it comes from when there were "no established standards."

I'm all for adding features to FabGL that do not interfere with existing ones. If I can wrap my head around how fonts are handled, I'd love to see a way to redefine fonts from MBASIC for FabGL. I'm enjoying the 320x200 settings today.

8b

(By the way, I started another google group to focus on general Z80 and programming since I couldn't find one. https://groups.google.com/g/programming-on-cpm )

On Wednesday, January 18, 2023 at 10:06:23 PM UTC-5 John Galt wrote:

its a fight, people want to be period correct or they want extra function and if it can emulate period correct great if not oh well.

its the same graphics card wars from the 80s and 90s when you think about it. each "accelerator card" back then would be the type of terminal or emulation now.

each had pluses and minus and it took years into the late 1990s for things to become standardized.

many people put heart and soul into tek or gsx so they want all that functionality.

its also the issue of once you can see what a terminal is capable of you naturally want more.

its frustrating when you make something amazing and are unable to show it to somebody else because they do not have the hardware or software.

i would have loved to find an original working VT340 it would not be correct for an altair but color and graphics on a terminal from 1987 sign me up.

no your not wrong it looks pretty, its what you gave me with microshell and autoexec boot in cp/m, i had made some changes to work with the GEOFF terminal at that time.

with the VGA32 i think i could match that loading screen.
treat the CP/M inside as a Sprite for the VGA32 ASCI Terminal then i could overlay it

oh well whats the saying "don't hate the player hate the game" but the game is the game. :-)

Message has been deleted

Tom Lake

unread,

Jan 19, 2023, 8:34:41 AM1/19/23

to Altair-Duino

It may be a fight but it's a friendly fight. As for me, I want all original functionality to be present but I'd like enhancements as long as they don't replace original functions.

That's why I use real terminals (I consider Geoff's and fabGL to be real!) rather than terminal emulators running on a PC, real floppy drives rather than files on an SD card

and a real printer rather than a virtual or simulated one. I don't mind typing in long BASIC listings from a printed copy. That's the way we used to do it. I don't need a network

connection or file transfers in most cases. The only modern convenience I use is to copy disk images of OSes off the internet to real floppies since we can't buy the real

floppies with the OS on them already the way we could back then.

On Wednesday, January 18, 2023 at 10:06:23 PM UTC-5 John Galt wrote:

its a fight, people want to be period correct or they want extra function and if it can emulate period correct great if not oh well.

its the same graphics card wars from the 80s and 90s when you think about it. each "accelerator card" back then would be the type of terminal or emulation now.

each had pluses and minus and it took years into the late 1990s for things to become standardized.

many people put heart and soul into tek or gsx so they want all that functionality.

its also the issue of once you can see what a terminal is capable of you naturally want more.

its frustrating when you make something amazing and are unable to show it to somebody else because they do not have the hardware or software.

i would have loved to find an original working VT340 it would not be correct for an altair but color and graphics on a terminal from 1987 sign me up.

no your not wrong it looks pretty, its what you gave me with microshell and autoexec boot in cp/m, i had made some changes to work with the GEOFF terminal at that time.

with the VGA32 i think i could match that loading screen.
treat the CP/M inside as a Sprite for the VGA32 ASCI Terminal then i could overlay it

oh well whats the saying "don't hate the player hate the game" but the game is the game. :-)

On Wednesday, January 18, 2023 at 4:13:51 PM UTC-5 fridtjof.ma...@gmail.com wrote:

Message has been deleted

Walt Perko

unread,

Jan 19, 2023, 11:38:24 AM1/19/23

to Altair-Duino

Hi,

I feel the same, that the ASCII VT-100 terminal emulator is a hardware "real" terminal. That is what I'm looking for too.

For the FabGL = TTGO board = VGA32 ... I like that it can be an entire computer emulator, I wish there was an Apple II Plus version, a TRS-80 Model 4 or Coco version. Pretty much, I think the VIC20 was almost a waste of programming time. As for a terminal, the VT-100 is good, but until there's a nice big fat VT-100 that includes color graphics we can simply load into the TTGO they're a dead-end terminal.

One thing about the ESP32 is that the S100 group thinks it's a waste of money for a terminal. It just doesn't seem to have enough SPEED, RAM to bother with trying to make a better terminal, but they're looking into having higher resolutions and even HDMI outputs.

.

On Thursday, January 19, 2023 at 8:06:43 AM UTC-8 John Galt wrote:

there is also a trade off with how much space exists for the firmware.

I have hit walls with the Arduino Due and the ESP32. a few times i had to turn off optimization because there was no room for the expanded code.
Right now i have to turn off part of the optimization for the Altari-dino because it will run out of space and refuse to upload to the DUE. i packed too much into my build.

Its going to lead back to having to separate terminals ino-s rather then being able to simply switch between them in one conglomeration.
Nobody is going to want to strip features to make space for something else. I'm surprised there have not been offshoots of Fabgl. development of anything is almost non-existent.

When somebody really wants something they will figure out a way to build it.

right now the entire FABGL is super packed with goodies that have not been explored.

Message has been deleted

Walt Perko

unread,

Jan 19, 2023, 2:03:36 PM1/19/23

to Altair-Duino

Hi,

Not fast enough for 4K HDMI.

.

On Thursday, January 19, 2023 at 9:25:25 AM UTC-8 John Galt wrote:

I don't understand the S100 group complaint, it is extremely fast compared to some other terminal hardware or emulation.

Many people seem to not know that the VGA32/ESP32 asci terminal also supports color using VT-100 escape codes, plus you have mouse support and proper cursor key support.
you can port A LOT of games and apps that used VT-100 Color terminals back in the day.

The VIC-20 was designed to show what was possible with the FABGL library, for some reason it has not gained traction with developers to do other things.

it is honestly amazing for what it is packing, and its super cheap too.

fridtjof.ma...@gmail.com

unread,

Jan 19, 2023, 3:19:53 PM1/19/23

to Altair-Duino

John

And that is fascinating. The same problem as "back in the day" when we ran out of slots.

On the Altair, we started with 4 slots (afair), cpu, front panel, memory. Added sio... change

memory. And no room for cassette! Add 4 more slots...

And tedious!

I have never built or programmed the Altair-Duino DUE software! (yes, hard to believe).

So, I operate with the original firmware. I wrote an AM9511 math chip emulator see

https://github.com/ratboy666/am9511 that has been incorporated in z80pack. Period

correct math (32 bit float, 16 and 32 bit integer). Can be incorporated into the Altair-Duino

(but I haven't done it). Gives one heck of a nice boost in performance! That would make some

serious graphics fly! But... on the downside, would increase the firmware size (and it probably

would not fit again). And, if you do get it going -- I wrote APU library -

https://github.com/ratboy666/apu and THAT will let you integrate the AM9511 into compiled

FORTRAN and BASIC. For a pretty good kick in performance. APU library has even been tested

against a real AM9511 part, and that would have given supercomputer performance back

in the day (the AM9511 was expensive, and drew a LOT of power and so wasn't a common

device).

One day -- I will overcome my fear of bricking the "blinking lights" machine and actually do it!

As it is... these days I program and analyze really BIG iron (204 disks over 2 chassis for one client,

other clients have there own issues...). It get overwhelming, and I can take refuge in the

blinking lights... That is why I have not attempted to reprogram the device.

If you get the "mojo" to integrate AM9511 into the Altair-Duino, let me know how it goes!

But, if that is done, we can do some seriously kick-ass graphics demos (on most any

pixel or vector configuration). I think so -- my calculations have the DUE performing just

about par with the AM9511 chip in emulation. (looking at processor benchmark

comparisons, I haven't tried it.

FredW

On Thursday, January 19, 2023 at 11:06:43 AM UTC-5 John Galt wrote:

there is also a trade off with how much space exists for the firmware.

I have hit walls with the Arduino Due and the ESP32. a few times i had to turn off optimization because there was no room for the expanded code.
Right now i have to turn off part of the optimization for the Altari-dino because it will run out of space and refuse to upload to the DUE. i packed too much into my build.

Its going to lead back to having to separate terminals ino-s rather then being able to simply switch between them in one conglomeration.
Nobody is going to want to strip features to make space for something else. I'm surprised there have not been offshoots of Fabgl. development of anything is almost non-existent.

When somebody really wants something they will figure out a way to build it.

right now the entire FABGL is super packed with goodies that have not been explored.

Message has been deleted

fridtjof.ma...@gmail.com

unread,

Jan 19, 2023, 6:04:19 PM1/19/23

to Altair-Duino

John

Me too -- very busy!! As to the RTC stuff, its actually trivial (not in MBASIC interpreter, but with BASCOM

and F80):

(I) Configure interrupts : Use Vector Interrupt board

Configure interrupt settings

(R)eal-Time Clock : 10.00 Hz
(V)ector Interrupt board : Use Vector Interrupt board

(0) Real-Time Clock interrupt : VI1
(1) 88-SIO interrupt : Not connected
(2) 88-ACR interrupt : Not connected
(3) 88-LPC interrupt : Not connected
(4) 88-2SIO port 1 interrupt : Not connected
(5) 88-2SIO port 2 interrupt : Not connected
(8) Disk drive interrupt : Not connected
(9) 88-HDSK interrupt : Not connected

E(x)it to main menu

Command:

And that's all! That straps the RTC to VI1, which is RST1

And then the

https://github.com/ratboy666/virtc

VIRTC stuff just works... We want to use VIRTC to put the interrupt somewhere sensible.

And... we really don't need more than one (we can poll conditions if needed). The test FORTRAN

(Microsoft F80) code rtc.for uses the RTC to time code execution! To 0.1 seconds... It gets

really fun when you disable interrupts, and overwrite the RTCISX with a jump to your own

code! Like, a preemptive scheduler, for example. Or your own timekeeping clock code... or

whatever. I think 10 times per second is adequate.

PS. Adding the VIRTC configuration doesn't change anything if it is not used! It has to be

enabled in software before it does anything at all.

Put a lock on location 5, and you can even multiplex a high and low memory program in CP/M

(call it "cheap MP/M").

For that, use DR rmac, and link80 to produce a prl [nr,os] ... or use DR GENMOD with two files

... one page apart . Then, add in PRLOADER.ASM to the mix, and you can have a file which self-

relocates!, Either to the top, or to a fixed location.

FredW

On Thursday, January 19, 2023 at 3:33:20 PM UTC-5 John Galt wrote:

Fred i keep looking at your RTC and having the nerve to figure that out with the Arudino Altair RTC and making that work in basic.
my plate is still beyond full.

prloader.asm

Reply all

Reply to author

Forward