GitLab

He's old, and should keep his blood pressure down.
Do not walk on his lawn.

See https://www.pepto.de/projects/colorvic/ for details.

People are used to thinking about the aspect ratio of displays and
used to not thinking at all about that of pixels.  Most of the modes
are simplt 4:3 modes and the text area is the entire window.  The
only oddball here is the Commodore 64 and 128 40-column modes.
Because they have a border around them that's wider on the sides than
the top/bottom, the display aspect ratio is actually narrower than
a normal NTSC screen (6:5).  It seems the PAL version actually has
square pixels, but nobody has asked for a PAL Commodore mode, and I
think that has a different colour palette too so I'm not doing it.

Just to frustrate DigitalMan a bit, the default custom aspect ratio
is now 4:3 (but can be configured).  At present, modifying the custom
mode while *in* the custom modes "works", which no sane person would
want when adjusting the aspect ratio.

Was using the 14 row font with 350 screen rows and expecting 43 lines.

We're leaving the "Awesome Modes" as 1:1, but the rest all assume
a 4:3 display that is filled by the described text.

This uses the 720x400 with 9x16 character cell that always made
BBSs look so terrible.

SyncTERM doesn't support any "fat-pixel" modes.

I really need to do a sweep through and update all the aspect
ratios now that the data actually matters.

There are a number of conio changes in here too... too many to list.  Check
the diffs if you actually want to know what changed.

This allows Lt. Blue on Blue for C64, Green on bright black for C128 40 col,
and Light grey on black for C128.
Commodore modes are no longer capable of blinking, which I believe is accurate.

vidparam structure itself.

palette. I can only assume this was a typo? I'm also guessing this is the
same change that Payton Byrd made in his fork of SyncTERM (he erroneously
called 2.0), which I haven't been able to locate on github (anyone?). This
change makes SyncTERM (in C128 modes) appear more consistent with CGTerm.

With this change, I now see no difference between the C64_40X25 screen mode
and the C128_40X25 screen mode. (Deuce?)

I also have questions about the changes in some of the colors between
40 and 80 columns modes expressed here (but not observed with CGTerm):
https://www.commodore.ca/manuals/128_system_guide/app-i.htm
(e.g. 129 is supposedly green in 40 column mode and dark purple in 80 cols).
see also: 149, 151, and 159 - if this is true, then another palette
is needed for C128-80 mode but doesn't explain CGTerm's behavior
(the colors are the same in 40 and 80 column modes).

Also, the C64 palette changed pretty drastically since SyncTERM 1.0 where
the colors weres dull/muted and are now bright. And the initial attribute is
Blue on Grey (not black) - that wasn't the case with v1.0.

We're switching to TrueColor now, and maintaining a 65536 entry palette
for the various palettized bits.  This change hurts the overlay output most
since it currently means floating point calculations for every pixel.

The getfont() function now takes a fontnum argument so you can get all the
current fonts.

The vmem array now holds the font data, so once a glyph is written to the
screen, it can stay in that font "forever".  This still has some issues
with savescreen()/restorescreen() since there's no extension to grab the new
stuff... that'll be coming soon, likely replacing the pgettext() and
pputtext() functions.  For now, various popups will likely reset fonts to
the default font on the screen.

Now that we have all this, the status bar in SyncTERM can retain the default
font and colours at all times.  Further, menus can be displayed in the "right"
colours and fonts, and no more translation will be needed.  This is a work
in progress though, so there's likely to be glitches.  The scrollback doesn't
have the font data either (same issue as savescreen()/restorescreen()).

These are 132 column modes which use 8x16 fonts and have 16:9 and 5:4
aspect ratios respectively... DigitalMan hates them!  ;-)

Baiscally, fix all the cursor things.  I'm frankly amazed this ever worked.
While we're changing everything, remove pointless arguments from some functions.
Some were ignored, and some only had one possible value.

finish work.

This is going to be cool though.  Don't try this at home unless you're me.

Use C64 palette from CTerm
Switch drawrect to use 32-bit pixels
Put the colour palette index into the screen array, not the attribute palette one
Remove dac_colors from video_stat structure

When built withOUT the preprocessor macro WITH_SDL defined, ciolib.h doesn't
include gen_defs.h (perhaps it should), so the use of FREE_AND_NULL in this
file become function calls and the symbol is not found when linking.
This is why jsexec was not included in recent daily dev builds of v3.16.

For regular vstatlock things, only hold the lock long enough to copy the
variables that will be used.

For vstat.vmem stuff, create a separate reference-counting vmem structure
and a new vmem_lock so the memcpy() of the vmem won't block basic vstat
accesses.

This appears to fix the recently-added "blockiness" of screen updates in
SyncTERM, without risking deadlocks or unlocked accesses... the major issue
holding up a release.

video stats.  This makes the C64 80 column mode look less stupid.

the high intensity attribute can.  Using CTerm, this is controlled via the
CSI [ ? 34 h/l commands.

Also add CSI [ ? 35 h which disables blinking (reversed by CSI [ ? 35 l)

1) The ability to make attribute bit three select a second character set
2) The ability to make the blink attribute toggle background intensity
3) The ability to make attribute bit three NOT select high intensity
4) More control over the cursor than just three constants

CTerm support to follow using private set mode parameters.

as of yet, but instead uses an 8x16 font generated from the Atari 8x8 one.

Colours taken from Wikipedia image.

Current;y, I'm useing the PC palette for C128 modes since the documentation
I found on the C128 said that it used CGA monitors (which were digital)

Can someone clarify this (ie: Did the Commodore monitor use the C64 palette)

ie: Leftmost bit is the most significant bit.

assigning to char.