I've been interested for a long time to get one to check the modes and performances, and how to program it directly.
The card is not a native NOVA, it's a VME-ISA adapter connected to a VGA ET4000/AX with an ICS 5301-2 DAC. So it can go up to 24 bits mode but is limited to 1MB of RAM.
First of all I had to understand how to make it work because to be honest the documentation is very hard to get.
Installing and using
Basically there is three tools to put in AUTO folder : EMULATOR.PRG, MENU.PRG/XMENU.PRG and STA_VDI.PRG, in this precise order.
You can chose the video mode through MENU or XMENU and both are called by holding or pressing keys at boot time. They also can be ran from the desktop.
There is also another tool, VMG.PRG, which allows to create new modes or modify existing ones by patching the STA_VDI.BIB file in the AUTO folder. It's a tedious process because you need to find the correct pixel timing/resolution to fit into the 31kHz horizontal scan standard and the tool doesn't allow to setup the front/back porch values precisely, so your best bet is to "init" the vertical and horizontal position after each modification.
You need to get the correct driver for your card, if it's a NOVA card then get the official drivers, else this amazing site lists a lot of drivers for various VGA cards:
Unfortunately the source code of the drivers is not available. It's a shame because there is only a few people still using those cards nowadays. It should be time to free all sources (official NOVA and alternate) before it's too late...
Here is the card working in 1024x768, 256 colors (TOS 2.06):
https://peertube.fenarinarsa.com/w/u2ws ... XXpxrmMYNN
And a 320x240 24 bits mode I created with VMG.PRG:
https://peertube.fenarinarsa.com/w/w7qo ... roRjp3QcS9
Those videos were captured from my Mega STE.
The viewers I used are WATCH_IT.ACC (GIF, doesn't work correctly in >256 colors) and 1STGUIDE.ACC.
Basically software that work with Falcon modes will work with those cards.
Every other pure GEM software should work. Software that force the regular ST output will use the regular ST output (like Protracker). Software that do dirty things on GEM desktop won't work (for instance GFA basic's editor).
That was the main point I wanted to check. And... it's not very good. With 256 colors you can already feel GEM refresh is a lot slower. Everything scrolling text, in fullscreen (TOS software) or into windows, is really really slow. I don't know if the blitter is used but in any case it doesn't help that much. Switching from 8 to 16 Mhz doesn't change anything.
I saw videos of NOVA cards running on TT and it's a lot faster. I don't know if it's because the TT is faster but it also might be because the performance is better with native NOVA cards, something nobody never talks about.
Since it's quite rare to see VGA cards running on Mega ST/STE I didn't expect anything.
In 640x480x24 bits, it's too slow to be usable. Editing text in devpac is almost unusable as soon as the text needs to scroll.
As I said I couldn't find any driver source code, which is a shame. (please release the drivers source code!!)
The ET4000 documentation is complete so it's of course something to get: http://www.bitsavers.org/components/tse ... r_1990.pdf
However as expected it's very PC-oriented, even if it's stated that it can be implemented for 68000 computers.
The BIOS calls are of course useless, and all the memory mapping may not be relevant.
Also please note that the available modes depend on the DAC installed and not only the ET4000 chip.
Here's my findings:
Everything on the card is memory-mapped on the ST, starting at adress $A00000 (10MB). It means you can't use 14MB ALT-RAM expansions. As a matter of fact it's known that NOVA cards don't work on Falcon with 14MB of RAM.
XBIOS 2 (Physbase) still works and returns the real address of the VGA framebuffer.
From this page https://mikrosk.github.io/doitarchive/doitf030/0807.htm here's the memory mapping used:
$A00000 Monochrome framebuffer
$ABFC00 Memory mapped registers
$B00000 I/O address offset
$C00000 Color framebuffer
I also found this information:
$DC0000 I/O registers
I indeed confirmed that $C00000 is the start of framebuffer in 256 colors and 24 bits modes. Both use linear packed bytes, so 1 byte in 256 colors mode, and 3 bytes (BGR) in 24 bits. I didn't try the planar modes.
I could fill the screen using two different methods:
Code: Select all
; ET4000 direct draw test ; 640x480x24 bits BGR ; framebuffer located at $C00000 lea $c00000+(640*480*3),a0 move.w #480-1,d6 move.l #$ff0088ff,d0 move.l #$0088ff00,d1 move.l #$88ff0088,d2 move.l #$ff0088ff,d3 move.l #$0088ff00,d4 move.l #$88ff0088,d5 move.l d0,a1 move.l d1,a2 move.l d2,a3 move.l d3,a4 move.l d4,a5 move.l d5,a6 loopY move.w #(640/16)-1,d7 loopX movem.l d0-d5/a1-a6,-(a0) dbra d7,loopX dbra d6,loopY ; CONIN move.w #$1,-(sp) trap #1 addq #2,sp clr.w -(sp) trap #1
Code: Select all
; ET4000 direct draw test ; 1024x768x8b bits ; framebuffer located at $C00000 clr.l -(sp) move.w #$20,-(sp) trap #1 addq.w #6,sp move.w #2,-(sp) trap #14 addq.l #2,sp clr.w $ffff8a20.w ; src x byte increment clr.w $ffff8a22.w ; src y byte increment move.l #$5000,$ffff8a24.w ; src move.w #-1,$ffff8a28.w ; endmask1 move.w #-1,$ffff8a2a.w ; endmask2 move.w #-1,$ffff8a2c.w ; endmask3 move.w #2,$ffff8a2e.w ; dst x increment move.w #2,$ffff8a30.w ; dst y increment move.l d0,$ffff8a32.w ; dest move.w #512,$ffff8a36.w ; x word count move.w #768,$ffff8a38.w ; y count move.w #$010F,$ffff8a3a.w ; HOP+OP: 1s fill clr.b $ffff8a3d.w ; skew move.b #%11000000,$ffff8a3c.w ; start HOG nop nop ; CONIN move.w #$1,-(sp) trap #1 addq #2,sp clr.l -(sp) move.w #$20,-(sp) trap #1 addq #6,sp clr.w -(sp) trap #1
The conclusion is it's really slow, actually slower that accessing the main ST RAM.
The best performances were of course with the blitter. 1024x768x8b makes 363216 words to fill up, 4 cycles by word, so it should take around 1572k cycles. However it takes 20 frames out of 60, so around 2666k cycles. It's 65% slower than expected.
I remember reading that there is penalty cycles when accessing the VME bus for RAM extension. People on fb also told me it may be because of the ISA port, which is not fast.
So now I wonder if native NOVA cards are faster? In that case it might make them even more valuable than VME-ISA adapters.
If you have a real NOVA card installed in a Mega STE and are willing to test it, please let me know, I can write something to report more accurate results.
A final note about hardware acceleration:
The ET4000 has some sort of memory access optimization, but I didn't really dive into the documentation and I'm not sure it's relevant for the ST.
There is no bitblt hardware built into the ET4000/AX so every operation must be done from the CPU or blitter. However it can do hardware scrolling by displaying only a window of a bigger framebuffer and can do one screen-split.
The latest NOVA cards use different hardware, ATI Mach32 for STE and ATI Mach64 for TT. Those have internal bitblt capabilities but they're very hard to get. ISA Mach32 cards are overpriced nowadays and I couldn't find a proper documentation anyway.