exxos's Atari, Amiga & retro forum

Morning.

Last year I threw together a little graphics card project based on a cartridge which, when paired with DSTB1 and some flyleads fufiled its sole purpose which was to output a fixed palette (3R-3G-2B bits) 8 bit chunky VGA (640x480) display.

Unfortunately I couldn't make a true colour 8 bit VDI driver work so instead I halved the display width and used the Falcon's TC 16-bit VDI and ended up with what you see in this video:





Something was a little off in my read timings, but it did kind of prove the concept.

Because of assumption I made about having a paletteless display and the speed rating of my 8-bit SRAM chip I could only really do mono or 16 bit displays with the VDIs available and 640 was the max X resolution.

Design-wise, it was a simple framebuffer (no HW acceleration) and it relied on the DSTB1 to decode 0xC00000 to 0xC7FFFF and long extension cables were provided off the 68k slot for RW and three extra address lines to allow the 512k memory to be accessed. It made no attempt to provide accelerated memory performance, running at the ST's stock 4MB/s.

Follwing a bit of a kick around over in this thread viewtopic.php?p=106414#p106414
with @mrbombermillzy and others, I'm tempted to buld a v0.2, just to play with again.

So what should we try in this one?

The cartridge port was nice as it gets the VGA port on the outside of the machine, can be easily probed and provides a lot of the lines required, but it doesn't have the RW line, it can't issue a DTACK and it only natively has 64k of address space (ie. A1-A15). This means it needs a companion board anyway (in the first case it was DSTB1) to handle the address decoding and it needs to pick up extra lines from somewhere.

An alternative is to plonk the whole thing on the 68k port and let the user worry about a) fitting it and b) routing out the VGA line.

In most STs, that suffers from the normal problem of relocating the 68k socket to make anything fit, but that's kind of a standard anyway. I could do an STE-only board, of course. Sockets are there already. Perhaps I'd end up in the unusual situation of needing an ST to STE adapter, for a change!

What do we think?

Then the next question is what would we like it to do. To me the obvious now is to have a palletised chunky 256-colour mode. There exist chunky drivers for this in NVDI, I'm told (not tried). Or would a 16 colour planar mode, but in VGA resolution be the target? What about a widescreen mode?

To be honest, this ties in a little bit with a Falcon project I had in mind: there is just over half a meg of expansion memory available on the Falcon in the ST-RAM address space (ie. it's blitterable). What's the best resolution to target to fit in 512 of framebuffer with 16 bit graphics? 640x400 True colour mode on VGA becomes possible on a non-accelerated Falcon. Would that be good on the ST? What about 704x368x16 bit?

Anyway, I'm idly chucking things around for a possible future project. What do you reckon?

BW

I personally think the cartridge port is rather limited, but either way it's a cool proof of concept. I personally would be more excited about an internal framebuffer that sits on the 68k bus. Something that can stack with the CPU. PeP/shoggoth keeps enticing us with the possibility of writing drivers that support the shifter output and extended resolutions. One can dream :)

Interesting. For a long time I had thought about making a new batch of VME / MegaBus gfx cards using an FPGA to replicate one of the existing ISA GFX chips of old (so that it would work with all the existing drivers etc) but the work done with PiSTorm gfx cards effectively makes it non-viable.

Fun project though. I enjoyed watching

Hah - watched your video just yesterday :D

Demo coders would like 8 bit chunky modes. If the device becomes really popular it might trigger demos/competitions made specifically for it (like dual-SID on C64 etc) - 320x200 resolution or even less if needed for bandwidth.

For desktop use (which I would assume is not that huge nowadays) then sure, VGA resolution in 16/256 colors. If 16 I think any of the old overscan-drivers would support it out of the box when configured for the x and y resolution.

If an STE-only version is what's needed to get to a single board that most people can fit then I think that's the way to go.

alexh wrote: 04 Oct 2023 13:00 Interesting. For a long time I had thought about making a new batch of VME / MegaBus gfx cards using an FPGA to replicate one of the existing ISA GFX chips of old (so that it would work with all the existing drivers etc) but the work done with PiSTorm gfx cards effectively makes it non-viable.

Fun project though. I enjoyed watching

That would plug into alanh's pending MonSTerbo board right? Perhaps not such a pointless idea?

How hard would a 8 bit CLUT colour index be to implement?

I will have to look back at my TT high colour code, but certainly having 256 colour indexes (even if the palette range is 12bit) can certainly make a big difference. I was chucking some fairly high colour content images at my routines and they were ok with it.

Not much use for GEM desktops, but still.

Other than that, the only way to fight the lack of bus and CPU bandwidth is to offload the compute/manipulation of the screen to the device:

i.e. onboard RAM with BLT functions, or even some form of co-processor/'copper' (see https://beamracer.net/ for a ALTERA C64 solution). But thats probably a bit of an ask, even for @Badwolfs amazing projects! :lol:

Perhaps a few cheap hacks, like the TT shifter had, (i.e. Sample and Hold/Smear mode,etc). The S+H can be used as an effective realtime RLE decoder/polygon fill. Maybe if we think of some more intelligent quick 'hacks' like these?

Anyway, Ive not even warmed up yet! :lol:

More later.

mrbombermillzy wrote: 04 Oct 2023 14:50 How hard would a 8 bit CLUT colour index be to implement?

Is there a functional difference between a CLUT and a palette? I had always assumed them to be different names for the same thing, to be honest.

BW

Badwolf wrote: 04 Oct 2023 14:54

mrbombermillzy wrote: 04 Oct 2023 14:50 How hard would a 8 bit CLUT colour index be to implement?

Is there a functional difference between a CLUT and a palette? I had always assumed them to be different names for the same thing, to be honest.

BW

It may be my bad naming :D but for example, there are 16 colour 'indexes' on a STFM/STe and the 'palette' is 512/4096.

Therefore we can choose beween 16 colours (by way of lookup table index values in the visible screen RAM area) out of the full 512 or 4096 range.

The benefit being less memory being consumed for displaying a specific screen size/area compared to a chunky real colour value pixel in the display screen RAM area (depending on colour depth, of course, but definitely beneficial above 8bpp).

The tricks that can be done for more colour is to change them index values either during the raster or at the end of the line...'cheaper' to write than the full colour 'actual' value, once the colour depth available reaches a certain point. IMO, 8bit colour is the sweet spot for this.

Again, this takes CPU time, hence the calling for a copper. ;)

(I hope this all makes sense, as Im being constantly hassled by kids at the moment, so it may not :roll: )

mrbombermillzy wrote: 04 Oct 2023 15:32

Badwolf wrote: 04 Oct 2023 14:54 Is there a functional difference between a CLUT and a palette? I had always assumed them to be different names for the same thing, to be honest.

It may be my bad naming :D but for example, there are 16 colour 'indexes' on a STFM/STe and the 'palette' is 512/4096.

Right. I see what you mean. Yes, I've heard things described that way around, it's true, but I've always referred to the 16 colours as the palette and the 512 didn't really have a name. ISWYM.

The tricks that can be done for more colour is to change them index values either during the raster or at the end of the line...'cheaper' to write than the full colour 'actual' value, once the colour depth available reaches a certain point. IMO, 8bit colour is the sweet spot for this.

Yeah, y'see, I'd call this 'palette switching', implying the palette is the 16 ones.

But yes, a colour-indexed 256 mode is what I was thinking about for this little wheeze.

Basically it needs another SRAM chip (or pair) that can hold the colours to use. 16 bits wide and with 256 addresses. Or in reality the cheapest one(s) that'll fulfil that requirement but likely have thousands more addresses unused.

I've not experimented with how many colours the CPLD itself could store in synthesised registers. Not that many I expect.

BW

Badwolf wrote: 04 Oct 2023 15:59 ut yes, a colour-indexed 256 mode is what I was thinking about for this little wheeze.

Basically it needs another SRAM chip (or pair) that can hold the colours to use. 16 bits wide and with 256 addresses. Or in reality the cheapest one(s) that'll fulfil that requirement but likely have thousands more addresses unused.

So youre looking at doing 256 colour indexes with a 65535 colour palette (in my terminology :D ). Sweet. I like. :)