New shifter implementation 'THOUGHTS'

[mrbombermillzy]

So let me see if I "get it". There must be some software on the ST which takes a (presume) true colour image and compresses it? That data is output to the "magic box" ? Which then decompresses the data and displays the original image on the monitor ?

From the software side, the screen image has a 'magic cookie' on the first raster to activate processing. Any part of the image then has the data encoded in it (the picture would look like it's got stripes/lines on it).

As it happens, LP/Lonny from the AF (who does GFA BASIC stuff) has already made an Atari zview plug-in for converting/viewing DCTV images on the Atari machines: https://www.atari-forum.com/viewtopic.p ... 24#p428024.

[stephen_usher]

Here's a radical "Thought"...

Instead of a direct recreation with a few enhancements, how about creating a front-end to a frame buffer and a separate video output system behind it? i.e. a hardware "shim" fronting a "graphics card" behind.

I s'pose, if "we" want to get over enthusiastic, maybe a PCI PC graphics card could be made to work.

Anyway, just a "thought".

[mrbombermillzy]

Instead of a direct recreation with a few enhancements, how about creating a front-end to a frame buffer and a separate video output system behind it? i.e. a hardware "shim" fronting a "graphics card" behind.

Do you mean something along the lines of what e.g. the TT/MSTe VME bus ET4000/Mach32/64 cards do? Like a memory mapped graphics RAM that the VDI has access to?


I'm still wondering what exactly @Icky is doing with this 'overlay buffer' thingymajig. Is it a HW frame overlay system in the sense that there is a background buffer and a foreground one that are both present and can be colour keyed in and out of visibility?

[stephen_usher]

Not quite. I was thinking that as far as the rest of the ST was concerned there was just the shifter (with some added capability). The new sub-system would mirror any changes in RAM and mirror the contents to its own memory, which would be far higher speed, and the "graphics processor" would then generate the video signal from that. Memory contention and bandwidth issues would then not be an issue.

Extra registers in the ST front end would be able to tell the device where the start of screen memory was, the number of planes and the size of the screen memory so that it could monitor the data bus for writes to that area of memory and mirror the data across to its own memory, or push it over to some other graphics processor.

[ijor]

Not quite. I was thinking that as far as the rest of the ST was concerned there was just the shifter (with some added capability). The new sub-system would mirror any changes in RAM and mirror the contents to its own memory, which would be far higher speed, and the "graphics processor" would then generate the video signal from that. Memory contention and bandwidth issues would then not be an issue.

Extra registers in the ST front end would be able to tell the device where the start of screen memory was, the number of planes and the size of the screen memory so that it could monitor the data bus for writes to that area of memory and mirror the data across to its own memory, or push it over to some other graphics processor.

Shadow (mirror, if you want) RAM for video could be very powerful. But it requires a change in the architecture. This is not something that Shifter can implement by itself because it doesn't have access to the address bus. This would probably require combining Shifter and MMU.

[stephen_usher]

Well, it has a few address lines (which are used by memory expansions), but yes, it would have to pick the address lines form elsewhere, but that's not a major issue on the Phoenix boards.

[exxos]

I guess if the shifter had its own RAM and the CPU could access that RAM directly. The MMU wouldn't have to shift the whole frame to the shifter all the time. Easier said than done though.

[stephen_usher]

If the graphics sub-system (it's not a shifter any more) had its own copy of the screen data then it could totally ignore what the MMU was sending to it. Mirror the data being written to RAM in it's own memory and then do whatever it likes with it when it likes.

[ijor]

Well, it has a few address lines (which are used by memory expansions), but yes, it would have to pick the address lines form elsewhere, but that's not a major issue on the Phoenix boards.

When I said that Shifter doesn't have access to the address bus, I actually meant (and probably should have said), all the other signals required to snoop ram transactions. It is much more than just the rest of address signals. You also need some of the control signals, and you have a problem with DMA transactions when the program reads from floppy or the hard disk. The address bus is not driven at all at those DMA transactions.

That's why I said that the natural way to implement something like this is probably to combine Shifter with MMU.

[stephen_usher]

Memory access, even DMA, does use an address bus, just not the processor's. Tap into the memory address and data bus and you can do address decoding and copy the written data as it's being transferred. (You would merely need the memory address lines, data lines, /WR line and /OE.) It's doable.