freemint / fvdi Goto Github PK

The fvdi_gnu.prg binary is getting quite large particularly when built with recent versions of Freetype.

Is this a problem at all? Running in Aranym on my fast machine makes it difficult to spot any performance issues, but maybe running on real Atari hardware or Firebee hardware shows issues.

A simple change from compiling with -O2 to -Os (optimise for size) gives some significant savings under gcc 10:

Moving from Freetype 2.5.2 to 2.11.1 only costs 6KB? That's pretty nice.

Looking at an unstripped binary with nm shows we could save an additional 60KB if we could get rid (somehow!) of some big lists of glyph names, which don't seem to be useful for fVDI as I don't think there's a VDI interface using glyph names:

$ m68k-atari-mint-nm --print-size --size-sort --radix=d fvdi_gnu.prg | tail  
00359748 00001598 t _t1_keywords
00376176 00001804 t _cid_field_records
00338602 00002002 t _cff_field_handlers
00475284 00002050 D default_functions
00490348 00003600 b _spdchar_map
00250144 00003696 T _ft_standard_glyph_names
00466580 00004096 t _fixed_tl
00152906 00005534 T _af_blue_strings
00479548 00008192 b _vdi_stack
00191824 00055998 T _ft_adobe_glyph_list

There are some flags to gcc that help the linker discard unused functions (compile with -ffunction-sections, and link with --gc-sections) but they seem ELF-specific and do not work with the m68k-atari-mint toolchain. No easy win here.

Is this worth pursuing?

FVDI latest builds for Aranym ( I have tested every version in the repository) give wrong colors with phweather and zview.
See Screenshot : https://ibb.co/Q82JFzL
tested with aranym 1.1.0, emutos 1.1.1, fvdi 0.96a-* and Mint 1.19.1a9

It occurs to me that the 1_plane and 1_dummy directories are quite useless nowadays. The 1_plane drivers does not even compile from the makefile, it needs some special processing by the make.sh script. Similar for 1_dummy driver, which seems to be incomplete and does not even have a Makefile. Would be ok to just remove them? monochrome modes are already handled by the bitplane driver.

"fvdi + nvdi" works to some degree
vr_transfer_bits() seems incomplete
fvdi +nvdi crash at a null address to the screen with vr_transfer_bits()

And vs_ctab_entry() commands seem not fully supported, which makes fvdi uncomplete compared to nvdi.

Thank you.

While doing some tests i found this:

I don't know where the problem comes from. Is it caused by a single function or by the combination of several?

	wind_get (hwind, WF_WORKXYWH, &xw, &yw, &ww, &hw);	/* Zone de travail */
	pxy[0] = xw;                				/* Preparer effacement fenetre */
	pxy[1] = yw;
	pxy[2] = xw + ww - 1;
	pxy[3] = yw + hw - 1;
	vswr_mode (handle, MD_REPLACE);  		 	/* Dessin en mode Remplacement */
	vsf_color (handle, 0);            			/* Couleur blanche */
	v_bar (handle, pxy);              			/* "Vider" la fenetre */
	vsf_color (handle, 1);					/* Couleur noire */
	vsf_perimeter (handle, 1);				/* Tracer le contour */

	...

	case T_ELL :						/* Ellipses */
		vsf_interior (handle, FIS_HOLLOW);		/* Vide */
		vsf_perimeter(handle, 1);
		vswr_mode (handle, MD_TRANS);			/* Mode transparent */
		for (i = 0 ; i < hw ; i += 3)			/* Boucle de dessin */
			v_ellipse (handle, xw + (ww / 2), yw + (hw / 2), i , (hw / 2) - i); /* Ellipse */
		break;

Missing features

VDI

• v_clrwk/v_updwk
• v_cellarray/vq_cellarray
• vrq_locator/vsm_locator/vrq_valuator/vsm_valuator/vrq_choice/vsm_choice/vsm_string
• vsin_mode/vqin_mode
• v_contourfill

GDOS

• vq_scan/v_form_adv/v_output_window/v_clear_disp_list/v_bit_image
• vq_tabstatus/v_hardcopy/v_rmcur/v_alpha_text/vt_resolution/vt_axis/vt_origin
• vq_tdimensions/vt_alignment/vqp_films/vsp_film/vqp_filmname/vqp_expose/
• vqp_state/vsp_state/vsp_save/vsp_message/vqp_error
• v_meta_extents/v_write_meta/vm_pagesize/vm_coords/vm_filename
• v_offset/v_fontinit/v_escape2000/v_pgcount/vq_margins

NVDI

• v_opnprn/v_orient/v_copies/v_tray/vq_tray_names/v_page_size/vq_page_name
• vs_calibrate/vq_calibrate/v_bez_qual
• vst_name/vqt_name_and_id/vst_width/vqt_real_extent/vqt_real_extent_unicode
• v_killoutline/v_getoutline/vst_skew/vst_setsize32/vq_ext_devinfo
• vqt_trackkern/vqt_pairkern/vst_kern/vst_track_offset/v_getbitmap_info/vst_arbpt32/vqt_advance32

NVDI 5.x

• vr_clip_rects_by_dst/vr_clip_rects_by_src/vr_clip_rects32_by_dst/vr_clip_rects32_by_src
• vq_prn_scaling/v_setrgb/v_create_driver_info/v_delete_driver_info/v_read_default_settings/v_write_default_settings
• vs_hilite_color/vs_min_color/vs_max_color/vs_weight_color
• vq_hilite_color/vq_min_color/vq_max_color/vq_weight_color
• v_get_outline
• vsr_fg_color/vsr_bg_color/vqr_fg_color/vqr_bg_color
• v_color2value/v_value2color/v_color2nearest/vq_px_format
• vs_ctab_entry/vs_dflt_ctab
• vq_ctab_entry/vq_ctab_id/v_ctab_idx2value/v_get_ctab_id/vq_dflt_ctab/v_create_ctab/v_delete_ctab
• v_create_itab/v_delete_itab

PC-GEM

• vs_palette/v_sound/vs_mute/vqt_justified

GEM/3

• v_etext/v_xbit_image/vs_bkcolor/v_setrgbi/v_topbot/v_ps_halftone
• vsf_xperimeter/vst_ex_load_fonts/vs_grayoverride/v_pat_rotate

GEM/4

• function -1 (subfunctions 1-8, including v_get_driver_info)
• v_pline/v_fillarea with extra parameters
• three unknown functions (135/142/143)

EdDI

• v_resize_bm/v_open_bm

Speedo 4.x

• vst_error/vqt_advance/vqt_devinfo/vst_setsize/vqt_get_table/vqt_cachesize

Speedo 5.x

• v_set_app_buff/vs_backmap/vs_outmode/vs_use_fonts/vqt_drv_avail
• v_set_cachedir/v_get_cachedir/v_def_cachedir/v_clr_cachedir
• v_delete_cache/v_save_cache/v_load_cache
• v_mono_ftext/v_fgetoutline/vqt_cacheinfo

Sound drivers

• vspl_play/vspl_load_sample/vspl_unload_sample/vspl_play_dma/vspl_stop_dma/vqspl_status_dma/vqspl_position_dma/vspl_pause_dma
• vspl_load_d2d/vspl_unload_d2d/vspl_play_d2d/vspl_pause_d2d/vspl_stop_d2d/vqspl_status_d2d/vqspl_position_d2d/vqspl_time_left_2d2/vspl_make_d2d
• vsspl_monitor_on/vsspl_monitor_off
• vmid_load/vmid_unload/vmid_play

Printer drivers

• vq_driver_info/vq_bit_image/vs_document_info/vs_page_info/vs_crop/vq_image_type/vs_save_disp_list/vs_load_disp_list/vq_driver_name/vs_lum

MATRIX TC-VDI

• vsf_rgb/vst_rgb/vsl_rgb/vrf_rgb/vrt_rgb/vrl_rgb/
• vs_pixcol/vq_pixcol/vs_pixrgb/vq_pixrgb
• vrun_rect/vrun_parallel/vrun_triangle
• vs_colors/vq_colors

Unknown

• vq_ptsinsz/vqt_f_extent16/v_ftext16/v_ftext_offset16
• vst_scratch/v_savecache/v_loadcache/v_flushcache/v_gtext_unicode

Incomplete/bugged/unavailable features

VDI

• v_justified/vst_rotation/vsl_type/vsl_width/vsl_color/vsf_interior/vsf_style/vsf_color/vsl_udsty

NVDI

• vq_devinfo/vqt_f_extent/vqt_ext_name

NVDI 5.x

• vr_transfer_bits (#45)

EdDI

• v_opnbm/v_clsbm

fVDI Map

not functional yet. It appears the workstation screen address is not set

fVDI does not build for me with commit 7d17626 ("We do not need to preprocess some simple assembler include files")

make[1]: Verzeichnis „/home/mfro/Dokumente/Development/atari/fvdi/fvdi/engine“ wird betreten
  GEN      fvdi.gnu.s
  GEN      ../drivers/1_plane/1_expand.inc.gnu
  AS       fvdi.gnu.o
/tmp/ccxlRoFD.s: Assembler messages:
/tmp/ccxlRoFD.s:29: Error: can't open vdi.gnu for reading: Datei oder Verzeichnis nicht gefunden
/tmp/ccxlRoFD.s:30: Error: can't open macros.gnu for reading: Datei oder Verzeichnis nicht gefunden
fvdi.gnu.s:181: Error: syntax error -- statement `move.l control(a2),a2' ignored
fvdi.gnu.s:297: Error: Unknown operator -- statement `save_regs' ignored
fvdi.gnu.s:300: Error: syntax error -- statement `move.l control(a2),a1' ignored
fvdi.gnu.s:450: Error: Unknown operator -- statement `return' ignored
fvdi.gnu.s:478: Error: syntax error -- statement `move.l control(a1),a2' ignored
fvdi.gnu.s:547: Error: syntax error -- statement `move.l control(a1),a2' ignored
fvdi.gnu.s:568: Error: syntax error -- statement `move.l control(a1),a2' ignored
../utility/conv2gas/RULES:93: recipe for target 'fvdi.gnu.o' failed
make[1]: *** [fvdi.gnu.o] Error 1
make[1]: Verzeichnis „/home/mfro/Dokumente/Development/atari/fvdi/fvdi/engine“ wird verlassen
Makefile:10: recipe for target 'all' failed
make: *** [all] Error 1

This is for m68k builds; CPU=v4e works fine.

Building with freetype-2.10.2 seems to work. Building with freetype-2.11.1 explodes with many thousands of compiler errors. It might actually be less, but make -j makes it hard to see.

echus$ cd fvdi/modules/ft2
echus$ CPU=000 M68K_ATARI_MINT_CROSS=yes make      
  CC       ftinit.o
In file included from ../../modules/ft2/freetype/include/freetype/fttypes.h:26,
                 from ../../modules/ft2/freetype/include/freetype/freetype.h:25,
                 from ../../modules/ft2/freetype/include/freetype/ftmodapi.h:23,
                 from ../../modules/ft2/freetype/include/freetype/ftrender.h:23,
                 from ../../modules/ft2/freetype/include/freetype/internal/ftobjs.h:29,
                 from ../../modules/ft2/freetype/src/base/ftinit.c:42:
../../modules/ft2/freetype/include/freetype/ftimage.h:700:23: warning: implicit declaration of function 'FT_STATIC_BYTE_CAST' [-Wimplicit-function-declaration]
  700 |           value = ( ( FT_STATIC_BYTE_CAST( unsigned long, _x1 ) << 24 ) | \
      |                       ^~~~~~~~~~~~~~~~~~~
../../modules/ft2/freetype/include/freetype/ftimage.h:747:5: note: in expansion of macro 'FT_IMAGE_TAG'
  747 |     FT_IMAGE_TAG( FT_GLYPH_FORMAT_NONE, 0, 0, 0, 0 ),
      |     ^~~~~~~~~~~~
[...]

It'd be nice to track freetype releases in case there are security and other bug fixes.

While fvdi supports the v_ftext() etc calls from SpeedoGDOS that use fractional advances (i.e. internally they move the pen position using fractional pixels) actually it just ends up calling v_gtext() which uses integer advances.

It seems NVDI 5 supports both calls correctly, as can be seen by comparing text rendered using v_gtext() (top), v_ftext() (middle) and overlayed for illustration (bottom):

Clearly as you render longer lines the errors accumulate.

FreeType uses fractional fixed-point values internally, so it should be possible to expose this through fvdi using the SpeedoGDOS fix31 type.

A brief review of the fvdi code suggests this would require quite changing quite a lot of existing assembler. VDI calls that would certainly need changing include:

• v_getbitmap_info()
• vqt_advance32() and vqt_advance()
• vqt_pairkern() and vqt_trackkern() (there's no kerning support currently)
• vst_arbpt32()
• vst_setsize32()
• v_ftext() and all variants.
• vqt_f_extent()

This might mean adding fix31 versions of various existing Fontheader fields such as size (short) into Fontextra. Presumably an application can use vst_arbpt32() and then use v_gtext() so it would mean modifying existing non-fix31 code as well.

Hi Team,

according to documentation https://toshyp.atari.org/en/Inquire_functions.html#vq_extnd CLUT flag should be "0" for mono mode and "1" for 2 and more bitplanes (also 15/16/32bpp):
"work_out[5] CLUT flag (0 = no CLUT, 1 = CLUT or pseudo-CLUT (TrueColor) exists)"

I've checked the latest Freemint release and I see that FVDI set "0" for 8 and 32bit mode. In the source code for Aranym/Firebee/Radeon/SAGA/UAE driver I see following code:
https://github.com/freemint/fvdi/blob/master/fvdi/drivers/aranym/spec.c
https://github.com/freemint/fvdi/blob/master/fvdi/drivers/radeon/radeon_spec.c
" wk->screen.look_up_table = 0; /* Was 1 (???) Shouldn't be needed (graphics_mode) */"

Could you please check that?

Thanks
Regards

Please, remove PortAsm dependency for 68k.

Reported via Discord.

commit de37692 breaks fVDI for the FireBee.

This commit changed the code in check_cookies() to set cpu to 0 if the _CPU cookie is not set (when get_cookie() returned -1).

This is wrong for ColdFire. EmuTOS on the FireBee does not set the _CPU cookie at all (but sets the _MCH cookie instead), FireTOS sets it (AFAIK) as if it had a 040 CPU.

Was this done on purpose (I think I have tested that fVDI worked fine in 000 emulation in Hatari?), i.e. is this required or just "to keep things clean"?

If the latter, this should be reverted, in my opinion. If this setting is however required for some reason, I most likely have to revisit all the cases where cpu is used and fix them for ColdFire with conditional compilation.

See also https://www.atari-forum.com/viewtopic.php?p=440010#p440010 ; reverting the patches fixed a problem with AES using the wrong font.

Seems that something is going wrong now, when fvdi initalizes the workstation in https://github.com/freemint/fvdi/blob/master/fvdi/engine/workstn.c#L350

The free "SourceSans3-ExtraLight.ttf" file from Adobe's github causes freemint to crash the entire machine with:

pid  16 (desktop): halt: coprocessor protocol violation
FATAL ERROR. You must reboot the system.

My FVDI build of master is using Freetype 2.10.2. The crashing app is iterating across all loaded fonts and doing this:

fontid = vqt_name(handle, i, fontname);
vst_font(handle, fontid);

/* is proportional? */
vst_point(handle, 10, &dummy, &dummy, &dummy, &dummy);
vqt_width(handle, 'i', &iwidth, &dummy, &dummy);

which is simulating the font selector in Teradesk - which then does a vqt_width(.. 'm'..) to check if this is a proportional font. Obviously there are other ways to do that check, but vqt_width() should not crash the machine.

This works fine on other TTFs I'm using.

Some copious logging later reveals it to be crashing in ft2_load_glyph() when it calls FT_Load_Glyph(). I wrote a quick and dirty Mac application making the same sequence of calls directly against Freetype 2.11.1, and it did not crash. I think we're passing the correct glyph index in.

I'm not entirely sure how to proceed. Is there a way to get a fuller stack trace out of aranym + freemint?

Possibly updating FVDI to 2.11.x would help?

There are (apparently random) mouse artifacts when moving AES windows or browsing through menus

The CI workflow is broken. I'm not familiar with the scripts, but it appears older packages at savannah.gnu.org regularly get moved into the freetype-old directory?

As it stands, one of the packages required for the CI process just moved and isn't found anymore, causing the CI process to bail out prematurely.

@th-otto : is that something you could look into (if time permits), please?

all drivers (tested with firebee.sys and bitmap.sys) appear to support offscreen bitmaps opened with v_opnbm() just fine.
GDP output is redirected to that bitmap and can be copied from there to the screen.

While the aranym.sys driver also opens a bitmap using v_opnbm() without error, it does not draw to the bitmap representing the passed bitmap handle with any output function, but what appears to be the physical screen workstation instead (output overwriting the XaAES menu bar items).

this is the original reply I got from MicroAPL back in Oct 2012:

Delivered-To: [email protected]
Received: by 10.58.80.72 with SMTP id p8csp20558vex;
        Fri, 19 Oct 2012 01:21:43 -0700 (PDT)
Received: by 10.180.87.132 with SMTP id ay4mr1404848wib.5.1350634903042;
        Fri, 19 Oct 2012 01:21:43 -0700 (PDT)
Return-Path: <[email protected]>
Received: from anchor-post-2.mail.demon.net (anchor-post-2.mail.demon.net. [195.173.77.133])
        by mx.google.com with ESMTP id j71si1053229wep.137.2012.10.19.01.21.42;
        Fri, 19 Oct 2012 01:21:42 -0700 (PDT)
Received-SPF: neutral (google.com: 195.173.77.133 is neither permitted nor denied by best guess record for domain of [email protected]) client-ip=195.173.77.133;
Authentication-Results: mx.google.com; spf=neutral (google.com: 195.173.77.133 is neither permitted nor denied by best guess record for domain of [email protected]) [email protected]
Received: from microapl-adsl.demon.co.uk ([83.104.132.173] helo=[192.168.200.10]) by anchor-post-2.mail.demon.net with esmtp (Exim 4.69) id 1TP7pu-0004yl-km for [email protected]; Fri, 19 Oct 2012 08:21:42 +0000
Mime-Version: 1.0
Message-Id: <p06230900cca6bd4ac3c5@[192.168.200.10]>
In-Reply-To: <CA+zYZ3-4bcgfBj3nBRtZ1zwVuRok3hqNVCNANL3GRa2t_rLKSQ@mail.gmail.com>
References: <CA+zYZ3-4bcgfBj3nBRtZ1zwVuRok3hqNVCNANL3GRa2t_rLKSQ@mail.gmail.com>
Date: Fri, 19 Oct 2012 09:21:39 +0100
To: Paul Wratt <[email protected]>
From: Richard Nabavi <[email protected]>
Subject: Re: Coldfire web site info
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Dear Paul,

Yes, no problem. I confirm that MicroAPL gives you permission to copy 
the text from that page and place it on your wiki, provided only that 
you acknowledge the source.

Regards
Richard Nabavi
Director, MicroAPL Ltd



>http://www.microapl.co.uk/Porting/ColdFire/cf_68k_diffs.html
>
>Infomation like this is extremely hard to find, ands as of 2011 a lot
>of older detailed information is being lost.
>
>We have new hardware due for release using v4e and our "users wiki" is
>in desperate need of this simplied info
>
>Can I past a quoted copy of the text (and link to where is came from)
>in said wiki (which require copyright holders permission)
>
>Two copies on the net might make it easier to find.
>
>Thanks for your time, and to your developers for their useful CF68KLib
>and PortASM utilities
>
>Paul
>http://firebee.info/     <= users wiki
>http://acp.atari.org/   <= developers announcements


-- 
MicroAPL Ltd.  Registered in England No. 1415598.  Registered office:
The Roller Mill, Mill Lane, Uckfield, E.Sussex TN22 5AA, UK

WWW :  http://www.microapl.co.uk       Phone: +44 1825 768050
E-Mail :  [email protected]       Fax:   +44 1825 749472

this has become even more liberal/laxed in recent years, and I expect that sometime in the near future (couple of years) this will disappear, as m68k/CF is no longer supported - they are very accommodating - there is another thread from one or two months ago on the list that is more uptodate, someone from the FreeMiNT administration need to compile all relevant docs, web pages and software into the FreeMiNT repos. I have a single PDF that compiles all the m68k/CF related web pages, and software, all that is linked from the MicroAPL link mentioned in the fVDI readme.

It seems that there is a redraw error in 8bpp resolutions: freemint/freemint#256.

I tried to draw a single line of text in multiple fonts, aligned at the baseline. The results are not great, using 40pt text just to make it a bit more obvious:

The red line is my baseline. I'm doing:

vst_alignment(handle, 0, 0, &dummy, &dummy); // left, baseline

vst_font(handle, fontid1);
vst_point(handle, 40, &dummy, &dummy, &dummy, &dummy);
v_ftext(handle, xstart, ystart, "DejaVu");

vst_font(handle, fontid2);
vst_point(handle, 40, &dummy, &dummy, &dummy, &dummy);
xstart += (width-of-DejaVu-text);
v_ftext(handle, xstart, ystart, "Bookerly");

vst_font(handle, fontid3);
vst_point(handle, 40, &dummy, &dummy, &dummy, &dummy);
xstart += (width-of-Bookerly-text);
v_ftext(handle, xstart, ystart, "Helvetica");

NVDI 5 does get the vertical alignment correct.

The ft2_text_render() assembles the character bitmaps into a bigger buffer and blits it to the screen using a vertical offset from extra.distance. The computation of the extra.distance fields seems to be OK, but the more I read about metrics and sizes at freetype.org the less I feel I know! Is the bbox the right way to measure things, or just the ascent+descent?

The errors are reasonably significant (up to 16 pixels in my screenshot!), so they can't be just simple rounding errors.

Just to have this written down in correct repository... see freemint/freemint#102 for details and repro.

vro_cpyfm() calls utilizing the ALL_WHITE (0) or ALL_BLACK (15) logic op constants appear to be interchanged: ALL_WHITE gives black while ALL_BLACK gives white at least with the 16 and 32 bit drivers (Aranym) and the FireBee driver that seems to have inherited the same behaviour (others I can't test currently).

fVDI documentation states:

If you have NVDI too, you can make NVDI use fVDI for the actual screen output by making sure that NVDI runs last. This will be slower, but you'll be able to use NVDI's outline fonts and printer drivers (if you don't need the outline fonts, NVDI can run before fVDI and then there will be no speed penalty for screen output).

Then there is nvdifix in fvdi.sys which somehow tries to move NVDI in the trap chain so it's not first:

Modify a loaded NVDI so that it will never try to move itself forward in the Trap 2 chain.

but its description is not very encouraging:

With this uncommented fVDI can use NVDI as a background VDI (for dealing with non-screen devices). Some strange problems still remain, though.

FreeMiNT's INSTALL file says:

NVDI must always be started before MiNT.

So this would imply that the best supported combination of those three is:

1. FVDI.PRG (with booted set and nvdifix not set)
2. NVDI.PRG (with screen drivers disabled)
3. MINT.PRG

However this means that both NVDI and FVDI are outside of FreeMiNT's control. If I understand it correctly, they even use TOS supervisor stack (right?) and are not listed as separate processes. This seems to create a strange issue.

Repro steps:

• take the latest bootable snapshot
• create a separate drive image for C:
• copy all files from hostfs's C: to image's C:
• install NVDI (5.03 in my case) to image's C:
• disable / delete all NVDIDRV?.SYS files
• make sure that the programs in AUTO are in order as described above

Now start QED (/opt/GEM/qed/qed.app). Depending on the actual setup, sometimes it runs at the first time. Quit it. Run again. It wont run again. Sometimes it wouldn't run even on the first try, sometimes TosWin2 wouldn't run.

If started from TosWin2, one can see a simple "Bus error" message. When mint.prg compiled with debug infos, one can see in Aranym's console:

pid   8 (qed): [1][ PROCESS  "qed"  KILLED: | MEMORY VIOLATION.  (PID 008) | Type: free      PC: 01008F52 | Addr: 01397FF0  BP: 01318000 |         
pid   8 (qed): signal #10 raised [syscall_pc 0x1008F52, exception_pc 0x1008F52]

When looking where exactly it crashes, it goes all the way to gemlib's v_opnvwk. It wouldn't return from the trap. FreeMiNT's trap 2 handler is not even called in this case (i.e. it's not a bug related to freemint), fVDI's

seems to successfully enter and exit so it must be crashing somewhere in NVDI's trap handler. It seems to depend also on the resolution, if I set fvdi.sys with 640x480x8, it doesn't crash, if 640x480x16, it does.

It's very hard to debug as I can't find a way to reproduce this with anything else than aranym.sys.

Strangely, when following https://atari-forum.com/viewtopic.php?p=247471#p247471, i.e. all the possible recommendations thrown away:

• NVDI started after MINT.PRG
• FVDI started after NVDI with nvdifix enabled

Printing and vector fonts not only work but also the crashing v_opnvwk is gone.

Could be the issue caused by a stack overflow in NVDI.PRG ? Symptoms seems to be very similar to freemint/freemint#269 however when I started investigating this one, I had the 'wrong' setup (NVDI.PRG after MINT.PRG, FVDI.PRG in mint.cnf with nvdifix enabled) so the stack was wrong on a different place. Ironically, after fixing that I tried also the correct setup and everything seemed to work: https://atari-forum.com/viewtopic.php?p=435414#p435414 ... so the problem can be easily hidden as it seems.

I'm trying to build on macOS, and it is rather frustrating to say the least. It'd be nice to just run 'make' at the top level and for it to do the "right thing". The freemint make system seems pretty good and generally does good things, for example.

It isn't obvious there is a "wrong" version of freetype. I've raised a separate issue for that.

Building with gcc 10 fails in bitplane/spec.c. The following diff seems to fix it correctly (the same ifdef is used in the code using screenpt).

diff --git a/fvdi/drivers/bitplane/spec.c b/fvdi/drivers/bitplane/spec.c
index ff92fcf..7f3e231 100644
--- a/fvdi/drivers/bitplane/spec.c
+++ b/fvdi/drivers/bitplane/spec.c
@@ -134,8 +134,10 @@ long check_token(char *token, const char **ptr)
  */
 long initialize(Virtual *vwk)
 {
+#ifdef __mcoldfire__
     /* use screenpt system variable on Firebee as Physbase() doesn't work there (see below FIXME) */
     short** screenpt = (short **) 0x45e;
+#endif
     Workstation *wk;
 #ifdef FAST
     char *buf;

Even though I'm setting CPU=000 it tries to build some v4e stuff (firebee?)

There is a dependency on a Linux x86 binary - pacf - for at least one driver. It'd be nice to make that bit optional somehow, or perhaps to check in whatever pacf produces?

I noticed a warning when building fvdi

loader.c:1243:40: warning: suggest braces around empty body in an 'else' statement [-Wempty-body]
                 PRINTF(("!!!failed\n"));
                                        ^

Fixed by this patch:
loader.c.patch.txt

Maybe I should learn how to create pull requests, it might be faster :-)

#24 introduced setting the GEM font name from the TrueType face name.

Unfortunately, that only works for TrueType fonts, resulting in .pcf font files (and probably others) not loading anymore

Fixed with 912baad

... is - ehm - dissatisfactory.

Even on the Firebee, it takes about 5 seconds to redraw a 640x480 sized window with about 40 different TrueType fonts. On hatari (32 MHz 040 TT emulation) the same window redraw takes > 25 seconds. No improvement after initial display (i.e. this is for every redraw).

Font cache settings don't seem to make any difference (other than crashes due to lack of memory elsewhere when too large). Is the font caching doing anything other than using up memory? Don't think so.

For comparision: NVDI (5.02) on hatari renders the same screen near instantly (80 ms) once initial font caching has been completed. Not that I think that fVDI needs to be as fast as NVDI, but a little closer than several hundred times slower would be nice ;)

It has m68k-atari-mint-gcc hardwired on several places.

It turns out that v_gtext() (and presumably v_ftext()) are supposed to honour the vst_alignment() settings. I never knew this, so I went back to the original DRI VDI doc to verify this. The ST Profibuch is (surprisingly) incorrect.

NVDI uses the alignment settings. I haven't tried an Atari VDI.

FVDI gets centring and right-alignment wrong for bitmap fonts, but is correct for Freetype fonts. In the following screenshot v_gtext() is being passed the coordinates of the red lines where they cross. Right-aligned text is visibly wrong, centred text requires a closer look with a paint program, but is also wrong.

I suspect this is going wrong somewhere in text.s's lib_v_gtext code, or maybe textlib.c's lib_vqt_extent().