VDI questions

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
Badwolf
Captain Atari
Captain Atari
Posts: 371
Joined: Thu Mar 16, 2017 12:09 pm

VDI questions

Post by Badwolf »

Hi guys,

Sorry -- I'm not much of an authority on the OS and have been reading through FVDI driver example and the VDI section of the TOS.HYP manual, but I'm a bit out of my depth here and seeking some advice.

I'm trying to adapt the FVDI 16 bit "true colour" driver to 8 bit "true colour" [1] and whilst it seems to work nicely with the desktop[2] and control panel, "Vision" "GEMView" and SDL (PM-Doom) get confused. Either producing nonsense or trying to set a non-existant palette.

So I'm trying to understand how True Colour modes are distinguished in the VDI.

What functions in the VDI behave differently when it's running in Falcon 16 bit TC so the calling program knows not to try to set a palette, but to ask for the colour it wants each time?

I'd like to write little test program to see if my driver is responding correctly, but am at a loss as to how this actually works.

Is anyone willing to explain to me the nicities of 'true colour' VDI from the application's point of view?

Thanks,

BW


[1] True colour as in non-palettised. Each pixel is 8 bits comprising RRRGGGBB. In direct comparison to the Falcon 16 bit True Colour mode which is RRRRRGGG GGGBBBBB.

[2] Apart from colour icons, which may be my fault at not having implemented all the functionality yet.



The below are from a baseline ST emulated in Hatari.
You do not have the required permissions to view the files attached to this post.
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
ThorstenOtto
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2367
Joined: Sun Aug 03, 2014 5:54 pm

Re: VDI questions

Post by ThorstenOtto »

Badwolf wrote: Mon Oct 17, 2022 12:51 pm So I'm trying to understand how True Colour modes are distinguished in the VDI.
Theoretically, that can be queried from vq_extnd(). workout[5] tells you whether a color lookup table is available. But note that NVDI implements a pseudo-lookup table, so you can set the 256 VDI colors even when real output is hi- or truecolor.
I also would bet that a lot of programs simply assume planar or chunky modes, when the number of planes is <= 8. The mode you are trying to implement just was not used anywhere until now ;)
What functions in the VDI behave differently when it's running in Falcon 16 bit TC so the calling program knows not to try to set a palette, but to ask for the colour it wants each time?
In typical programs, you don't have to set the colors every time. You assume a standard palette instead (at least for the first 16 colors). Only when drawing pictures of 256 colors or less it should be necessary to set the palette.
User avatar
mfro
Atari God
Atari God
Posts: 1167
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: VDI questions

Post by mfro »

Badwolf wrote: Mon Oct 17, 2022 12:51 pm So I'm trying to understand how True Colour modes are distinguished in the VDI.
They aren't, really. You'll have to have a palette anyways (for the first 256 VDI colors).
The only difference is if you change colors (meaning change of the "soft" palette), pixels already set will not recolor.
Last edited by mfro on Tue Oct 18, 2022 7:15 am, edited 1 time in total.
pixelpusher
Atarian
Atarian
Posts: 9
Joined: Sat Sep 25, 2021 1:59 pm

Re: VDI questions

Post by pixelpusher »

Badwolf wrote: Mon Oct 17, 2022 12:51 pm [....]

So I'm trying to understand how True Colour modes are distinguished in the VDI.

What functions in the VDI behave differently when it's running in Falcon 16 bit TC so the calling program knows not to try to set a palette, but to ask for the colour it wants each time?

I'd like to write little test program to see if my driver is responding correctly, but am at a loss as to how this actually works.

Is anyone willing to explain to me the nicities of 'true colour' VDI from the application's point of view?

[...]
There are several ways for a program to accomplish this.

1. Using GetPixel(). In this case an app writes several test values into a screen location and uses GetPixel to determine the pixel value. For the palette based modes (up to 8 bit per pixel) you get a pixel value (intout[0]) and the palette index (intout[1]).

For modes with more than 8 bits per pixel and up to 16 bits per pixel, intout[0] contains the pixel value (you need to determine with different test patterns how many rgb bits in which position are available). intout[1] contains the index of the pseudo palette (if there's a match - not sure anymore if that's true for TOS too, but for NVDI it is), otherwise -1

For more than 16 bits per pixel intout[0] contains the low-word of the pixel value, intout[1] the high word


2. When using NVDI 5 or 4 there is additionally the possiblity to call a function called "INQUIRE SCREEN INFORMATION" (VDI 102, 1), which returns all these infos about the pixel "size", order and number of bits per color, etc. (and therefore programms don't have to add test code using GetPixel() with all the possible variations).

3. If memory serves me well, then there was a free rasterkit code (of NVDI) that demonstrated how to deal with different color formats and transform data accordingly.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2834
Joined: Sun Jul 31, 2011 1:11 pm

Re: VDI questions

Post by Eero Tamminen »

I've found that surprisingly few of the "GEM" programs, especially older PD/shareware programs, are 100% GEM clean. They access screen directly e.g. for speed reasons, and do not expect 8-bit truecolor, so more programs than you expect, may not work correctly.

Your idea sounds great though! If you'll come up with some real HW, and have code for Hatari to emulate it, please contribute it.

PS. As to SDL Doom, whether it works may depends no which SDL backend driver you've configured it to use, and which SDL version that program happens to be built with.
JeanMars
Captain Atari
Captain Atari
Posts: 429
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: VDI questions

Post by JeanMars »

Hi,
that's an interesting topic and it recalls me a lot of questions back in the days (1993-) when I started develop VISION.
VISION, and I believe most of similar applications, does not handle 8bit truecolor mode (BTW first time I see that, what graphic card features this? To me True color starts at 15bit).
Reasons are various:
- In the 90s, on Atari, truecolor meant (almost) Falcon 16bit RRRRRGGGGGGBBBBB, so most programs will end-up with this format
- GetPixel method, referenced above, is way too slow to be used for the full image
- when it comes to conversion to specific format (e.g. planar vs chunky), the official way is to pass through standard VDI format (all planes in sequence, not interleaved like usual ST bitplane formats). Never found in a document what that could mean for a truecolor mode and I couldn't imagine 16 planes conversions for Falcon TC16 mode to screen like this
- So I would expect every application to do something similar to what VISION does at startup:
- If not truecolor, use standard VDI format and call VDI for internal/screen transformations (which could be quite CPU intensive and a waste as you can expect the application to load the image in chunky format, transform it to standard VDI and at the end the screen mode may be chunky :-) But that's the official way, other option would be to check screen is chunky to optimize that
- if truecolor, detect RGB screen organization and generate this format thanks to a couple of LSL/LSR instructions for the truecolor 15,16,24 and 32 bit modes, so yeah no TC8 bit mode here...

But if someone has an idea of a clean and time acceptable way to support any graphical mode using VDI and valid for all ST range, I'm all ears.

Cheers,
Jean
User avatar
AdamK
Captain Atari
Captain Atari
Posts: 416
Joined: Wed Aug 21, 2013 8:44 am

Re: VDI questions

Post by AdamK »

IIRC NVDI exposes bit-depth/format conversion functions, but those are specific for NVDI.

VDI does not offer bit-depth independence, any app you want to run must know how to handle specific bit-depth. I think your only choice is to report a known 16bit bit-depth mode and internally convert it to your 8bit mode. But there still might be problems if app only detects mode and bypasses VDI and draws to screen directly (but I think not many do).
Atari: FireBee, Falcon030 + CT60e + SuperVidel + SvEthlana, TT, 520ST + 4MB ST RAM + 8MB TT RAM + CosmosEx + SC1435, 1040STFM + UltraSatan + SM124, 1040STE 4MB ST RAM + 8MB TT RAM + CosmosEx + NetUSBee + SM144 + SC1224, 65XE + U1MB + VBXE + SIDE2, Jaguar, Lynx II, 2 x Portfolio (HPC-006)

Adam Klobukowski [adamklobukowski@gmail.com]
User avatar
mfro
Atari God
Atari God
Posts: 1167
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: VDI questions

Post by mfro »

AdamK wrote: Tue Oct 18, 2022 8:06 am ... any app you want to run must know how to handle specific bit-depth ...
Wrong from a VDI viewpoint. VDI is supposed to be device independent.

Clean applications that deal with bitmaps should use only the VDI raster functions. Load in device independent format, convert to device specific format (vr_trnfm()), draw. That might be slow at times, but guarantees that only the VDI needs to know about the device specific screen bitmap format.

Of course the screen driver needs to provide a suitable vr_trnfm() backend.

There shouldn't be any problem with GDP and attribute functions. They should work (with a VDI "soft" palette) just right.
JeanMars
Captain Atari
Captain Atari
Posts: 429
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: VDI questions

Post by JeanMars »

Hi mfro,
Clean applications that deal with bitmaps should use only the VDI raster functions. Load in device independent format, convert to device specific format (vr_trnfm()), draw. That might be slow at times, but guarantees that only the VDI needs to know about the device specific screen bitmap format.
What is device independent format in TC15,16,24,32 modes?
Assuming VDI standard mode, it should be 15,16,24,32 not interleaved bitplanes, never tried this as I memory/CPU load would be terrible and quite painful for a machine like a Falcon.

Also, I remember that using vro_cpyfm with a number of bitplanes different than the one of the screen is not always working (regular TOS or even some NVDI versions IIRC).

That's why relying only on VDI to do that seems quite difficult. Do you know any application doing that?
Cheers,
Jean
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 2721
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: VDI questions

Post by Cyprian »

Badwolf wrote: Mon Oct 17, 2022 12:51 pm I'm trying to adapt the FVDI 16 bit "true colour" driver to 8 bit "true colour" [1] and whilst it seems to work nicely with the desktop[2] and control panel, "Vision" "GEMView" and SDL (PM-Doom) get confused. Either producing nonsense or trying to set a non-existant palette.


[1] True colour as in non-palettised. Each pixel is 8 bits comprising RRRGGGBB.
It looks like a regular chunky 8bit mode, but with predefined and fixed palette.
There are drivers for 8bit chunky mode for ET4000. Maybe you can use them.
Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.atari.org
User avatar
Badwolf
Captain Atari
Captain Atari
Posts: 371
Joined: Thu Mar 16, 2017 12:09 pm

Re: VDI questions

Post by Badwolf »

Hi Thorsten,
ThorstenOtto wrote: Mon Oct 17, 2022 1:17 pm Theoretically, that can be queried from vq_extnd(). workout[5] tells you whether a color lookup table is available. But note that NVDI implements a pseudo-lookup table, so you can set the 256 VDI colors even when real output is hi- or truecolor.
Thanks for this -- I checked and I think my driver is behaving correctly on that one.

I wonder if fVDI does the same with the faked lookup table, and perhaps I'm not doing that correctly? I certainly see calls to it's internal c_set_colours() occurring.
I also would bet that a lot of programs simply assume planar or chunky modes, when the number of planes is <= 8. The mode you are trying to implement just was not used anywhere until now ;)
I've a nasty feeling this will prove to be correct!


Hi Mrfo,
mfro wrote: Mon Oct 17, 2022 3:27 pm
Badwolf wrote: Mon Oct 17, 2022 12:51 pm So I'm trying to understand how True Colour modes are distinguished in the VDI.
They aren't, really. You'll have to have a palette anyways (for the first 256 VDI colors).
The only difference is if you change colors (meaning change of the "soft" palette), pixels already set will not recolor.
This is interesting and not something I had understood (see my comment above about me seeing calls to set an palette). Will pursue this one further as it seems the most likely point where I've gone wrong.


Hi Wilfried,
pixelpusher wrote: Mon Oct 17, 2022 4:55 pm There are several ways for a program to accomplish this.

1. Using GetPixel(). In this case an app writes several test values into a screen location and uses GetPixel to determine the pixel value. For the palette based modes (up to 8 bit per pixel) you get a pixel value (intout[0]) and the palette index (intout[1]).

For modes with more than 8 bits per pixel and up to 16 bits per pixel, intout[0] contains the pixel value (you need to determine with different test patterns how many rgb bits in which position are available). intout[1] contains the index of the pseudo palette (if there's a match - not sure anymore if that's true for TOS too, but for NVDI it is), otherwise -1

For more than 16 bits per pixel intout[0] contains the low-word of the pixel value, intout[1] the high word
Thank you very much for this detailed description. So there is a substantive change at 8bpp which is likely going to cause me a headache.

I think I'm going to write some test code and see what falls out based on this description.


Hi Eero.
Eero Tamminen wrote: Mon Oct 17, 2022 7:49 pm I've found that surprisingly few of the "GEM" programs, especially older PD/shareware programs, are 100% GEM clean. They access screen directly e.g. for speed reasons, and do not expect 8-bit truecolor, so more programs than you expect, may not work correctly.
Yes, I suspect that's likely true. And whilst many would be a problem for any graphics card, my idea is likely pushing things too far. I know. :-)
Your idea sounds great though! If you'll come up with some real HW, and have code for Hatari to emulate it, please contribute it.
Thanks -- this was the original plan for the experimental graphcs card I made a few months back (https://youtu.be/o0OdxW-tmTo). Basically I dislike palettised modes (as you change program and all the other colours on screen alter), but thought a straight 16-bit graphics mode would be too slow for most tastes. I'm not particuarly concerned about rendering everything else in perfect colour so figured a fixed 256 colour 'TC' palette would be a good enough compromise.
PS. As to SDL Doom, whether it works may depends no which SDL backend driver you've configured it to use, and which SDL version that program happens to be built with.
The nice thing about SDL Doom, I suppose, is I can dig in the code to actually see what it's doing. But better to ask about the 'proper' way of doing things before trying to reverse engineer a driver from a client's behavour, I figured. ;)



Many thanks to everyone, I've definitely something to go on. I'll let you know if I may any progress with this little 'side' project of mine. :)

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
ThorstenOtto
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2367
Joined: Sun Aug 03, 2014 5:54 pm

Re: VDI questions

Post by ThorstenOtto »

JeanMars wrote: Tue Oct 18, 2022 9:42 am What is device independent format in TC15,16,24,32 modes?
Good question. Surely not 16/24/32 interleaved planes. But you may look at the vr_trnfm function of NVDI if that helps : https://github.com/th-otto/MagicMac/blo ... kfl.s#L563
User avatar
Badwolf
Captain Atari
Captain Atari
Posts: 371
Joined: Thu Mar 16, 2017 12:09 pm

Re: VDI questions

Post by Badwolf »

Hi Jean,

Thank for you response, it's very interesting to hear from the author of one of the tools I'm testing with to help me understand the behavour I'm seeing.
JeanMars wrote: Tue Oct 18, 2022 6:41 am that's an interesting topic and it recalls me a lot of questions back in the days (1993-) when I started develop VISION.
VISION, and I believe most of similar applications, does not handle 8bit truecolor mode (BTW first time I see that, what graphic card features this? To me True color starts at 15bit).
This is for my home-brew graphics card (https://youtu.be/o0OdxW-tmTo) and is based on my experiences using UltraVNC's 8-bit mode and reading about 8 bit colour options here:- https://en.wikipedia.org/wiki/8-bit_color. It seemed a nice compromise between speed, simplicity and convenience. :)
Reasons are various:
- In the 90s, on Atari, truecolor meant (almost) Falcon 16bit RRRRRGGGGGGBBBBB, so most programs will end-up with this format
- GetPixel method, referenced above, is way too slow to be used for the full image
- when it comes to conversion to specific format (e.g. planar vs chunky), the official way is to pass through standard VDI format (all planes in sequence, not interleaved like usual ST bitplane formats). Never found in a document what that could mean for a truecolor mode and I couldn't imagine 16 planes conversions for Falcon TC16 mode to screen like this
When you say 'pass through' are you referring to building what's described as the 'VDI Standard Format' here (https://freemint.github.io/tos.hyp/en/V ... _20formats) prior to a call to vr_trnfm()?
- So I would expect every application to do something similar to what VISION does at startup:
- If not truecolor, use standard VDI format and call VDI for internal/screen transformations (which could be quite CPU intensive and a waste as you can expect the application to load the image in chunky format, transform it to standard VDI and at the end the screen mode may be chunky :-) But that's the official way, other option would be to check screen is chunky to optimize that
- if truecolor, detect RGB screen organization and generate this format thanks to a couple of LSL/LSR instructions for the truecolor 15,16,24 and 32 bit modes, so yeah no TC8 bit mode here...
That's really helpful to understand what I'm up against.

Many thanks!

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
Badwolf
Captain Atari
Captain Atari
Posts: 371
Joined: Thu Mar 16, 2017 12:09 pm

Re: VDI questions

Post by Badwolf »

Cyprian wrote: Tue Oct 18, 2022 10:56 am It looks like a regular chunky 8bit mode, but with predefined and fixed palette.
There are drivers for 8bit chunky mode for ET4000. Maybe you can use them.
Annoyingly I can't find the source for these. the fVDI graphics card drivers all seem to be 16 or 24bit. Do you have a link at all?

Thanks,

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
Badwolf
Captain Atari
Captain Atari
Posts: 371
Joined: Thu Mar 16, 2017 12:09 pm

Re: VDI questions

Post by Badwolf »

AdamK wrote: Tue Oct 18, 2022 8:06 am I think your only choice is to report a known 16bit bit-depth mode and internally convert it to your 8bit mode.
I had considered that, but I think it would be just as slow as simply supporting 16 bit in the hardware.

It's in the back of my mind in case I can figure out a way to make it faster, though.

Cheers,

BW.
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
JeanMars
Captain Atari
Captain Atari
Posts: 429
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: VDI questions

Post by JeanMars »

Hi,

@Badwolf:
This is for my home-brew graphics card (https://youtu.be/o0OdxW-tmTo) and is based on my experiences using UltraVNC's 8-bit mode and reading about 8 bit colour options here:- https://en.wikipedia.org/wiki/8-bit_color. It seemed a nice compromise between speed, simplicity and convenience. :)
Wow, nice :-)
When you say 'pass through' are you referring to building what's described as the 'VDI Standard Format' here (https://freemint.github.io/tos.hyp/en/V ... _20formats) prior to a call to vr_trnfm()?
Yes, that's the official way to deal with a non ST graphic mode (works with ST graphic mode too of course at the cost of un-necessary memory/cpu usage).

@Cyprian:
It looks like a regular chunky 8bit mode, but with predefined and fixed palette.
There are drivers for 8bit chunky mode for ET4000. Maybe you can use them.
"Correct." But not sure how to report a fixed palette? Applications may edit the palette, which has no sense here.
But there could be a way here, should think about this.

@Thorsten:
Good question. Surely not 16/24/32 interleaved planes. But you may look at the vr_trnfm function of NVDI if that helps : https://github.com/th-otto/MagicMac/blo ... kfl.s#L563
Interesting! But looks only monochrome and 16bit color modes are supported:

Code: Select all

                  subq.w   #1,d0          ;nur eine Ebene, monochrom?
                  beq      vr_trnfm_mono
                  sub.w    #16-1,d0       ;16 Ebenen?
                  bne.s    vr_trnfm_exit
Cheers,
Jean
pixelpusher
Atarian
Atarian
Posts: 9
Joined: Sat Sep 25, 2021 1:59 pm

Re: VDI questions

Post by pixelpusher »

JeanMars wrote: Tue Oct 18, 2022 6:41 am [...]
- GetPixel method, referenced above, is way too slow to be used for the full image
[...]
You didn't do that for the full image, but to figure out with test values which specific transform code you had to use to efficiently transform your source data (that you had in some defined format at some point) into the destination format.

Remember that there were a lot of formats out. E.g.

16 bit:
5-6-5 RGB (motorola format)
x-5-5-5 RGB (motorola format)

then the same 16 bit pixel in Intel format...

24 bit:
8-8-8 BGR (Intel format)

32 bit
x-8-8-8 RGB (motorola format)
JeanMars
Captain Atari
Captain Atari
Posts: 429
Joined: Fri Apr 09, 2010 5:15 pm
Location: France
Contact:

Re: VDI questions

Post by JeanMars »

Yes, that's what I said about detecting screen organization at startup.
But you can't use a VDI routine to build the image then, tou have to use your wn ones with lsl, lsr, etc.
ThorstenOtto
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2367
Joined: Sun Aug 03, 2014 5:54 pm

Re: VDI questions

Post by ThorstenOtto »

Badwolf wrote: Tue Oct 18, 2022 11:31 am Annoyingly I can't find the source for these.
Those are not for ET4000, but i guess you are not interested in the parts that deal with hardware acceleration anyway: https://github.com/th-otto/MagicMac/blo ... off256pk.s
ThorstenOtto
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2367
Joined: Sun Aug 03, 2014 5:54 pm

Re: VDI questions

Post by ThorstenOtto »

JeanMars wrote: Tue Oct 18, 2022 12:21 pm Interesting! But looks only monochrome and 16bit color modes are supported:
Yes, because that's the driver for that mode, and i only linked it as an example. Of course there is also a driver for true-color.
User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 13285
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: VDI questions

Post by wongck »

Drivers are with these names, should be 1,2,4,8 bits and High colour (true colour?)
NVDIDRV1
NVDIDRV2
NVDIDRV4
NVDIDRV8
NVDIDRVH
My Stuff: FB/Falcon CT63 CTPCI ATI RTL8139 USB 512MB 30GB HDD CF HxC_SD/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff that are no longer for sale due to them over 30 years old - click here for list
User avatar
Badwolf
Captain Atari
Captain Atari
Posts: 371
Joined: Thu Mar 16, 2017 12:09 pm

Re: VDI questions

Post by Badwolf »

ThorstenOtto wrote: Wed Oct 19, 2022 3:18 am Those are not for ET4000, but i guess you are not interested in the parts that deal with hardware acceleration anyway: https://github.com/th-otto/MagicMac/blo ... off256pk.s
Thanks Thorsten. My German is not the best, aber mein 68k ganz schlimmer ist!

I think the harder part would be understanding the framework in which that's embedded, but I'll put that on my reading list.

Thanks!

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
pixelpusher
Atarian
Atarian
Posts: 9
Joined: Sat Sep 25, 2021 1:59 pm

Re: VDI questions

Post by pixelpusher »

Badwolf wrote: Wed Oct 19, 2022 9:19 am
ThorstenOtto wrote: Wed Oct 19, 2022 3:18 am Those are not for ET4000, but i guess you are not interested in the parts that deal with hardware acceleration anyway: https://github.com/th-otto/MagicMac/blo ... off256pk.s
Thanks Thorsten. My German is not the best, aber mein 68k ganz schlimmer ist!

[...]
Google translate does a decent job with the comments in the source (but can't help you with 68k asm :))
User avatar
Badwolf
Captain Atari
Captain Atari
Posts: 371
Joined: Thu Mar 16, 2017 12:09 pm

Re: VDI questions

Post by Badwolf »

I'm still pootling around with fVDI on an 8-bit true colour driver for my graphics card, although I do now think it's a bit of a dead end. Just for fun and to learn a thing or two.

As you can see there's something not quite right with colour icons and I think my line/blit routine is perhaps slightly off as something's wrong with the window frame, but here's an example of SDL rendering a BMP with the original to the left.

This is why I thought 8 bit TC was a good compromise. I'd be happy enough with that approximation of the image on the desktop without the rest of my apps having their palette messed up!
Screenshot_2022-10-26_15-55-30.png

I'll probably have to admit defeat and go for a 15/6 bit device next iteration, though.

Cheers,

BW
You do not have the required permissions to view the files attached to this post.
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
mfro
Atari God
Atari God
Posts: 1167
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: VDI questions

Post by mfro »

That does look pretty close already, however.
Post Reply

Return to “Coding”