exxos's Atari, Amiga & retro forum

Exxos, what about adding a slot ISA for ET4000 card?
Your motherboard is smaller than original one, therefore there is a plenty place for a e.g video card

Cyprian wrote: ↑Sun Aug 19, 2018 1:11 pm Exxos, what about adding a slot ISA for ET4000 card?
Your motherboard is smaller than original one, therefore there is a plenty place for a e.g video card

Surely a PCI slot and interface logic would be better as ISA graphics cards are extremely rare and basically non-existent after about 1995. PCI graphics cards are far more populous.

Mapping that into the ST(e) memory map in a compatible manner might be the biggest problem, however.

stephen_usher wrote: ↑Sun Aug 19, 2018 1:22 pm

Cyprian wrote: ↑Sun Aug 19, 2018 1:11 pm Exxos, what about adding a slot ISA for ET4000 card?
Your motherboard is smaller than original one, therefore there is a plenty place for a e.g video card

Surely a PCI slot and interface logic would be better as ISA graphics cards are extremely rare and basically non-existent after about 1995. PCI graphics cards are far more populous.

Mapping that into the ST(e) memory map in a compatible manner might be the biggest problem, however.

There's not much need for a video card with the new shifter in the making.. once we have a faster MMU, we will have seveal times the bandwidth to the shifter.. and the blitter will run several times faster for blitting.. new shifter will have higher resolutions, more colours, maybe even chunky mode.. so trying to hack on cards just isn't need anymore. Cards need drivers as well ? A new shifter pretty much doesn't.

you've convinced me. A new SHIFTER with chunky mode and a new BLiTTER is a much better solution.

ST original:

• 320x200x16 15kHz 50/60Hz
  640x200x4 15kHz 50/60Hz
  640x400x2 35.5kHz 71Hz

doubleST (overclocked MMU and Shifter):

• 640x200x16 15kHz 50/60Hz
  320x400x16 35.5kHz 71Hz
  640x400x4 35.5kHz 71Hz

FPGA-Shifter (replacing the ST Shifter, also gives digital video out):

• I'll let Smonson talk about that.

(Note: I did not list all new modes, only those I consider to have "sane" horisontal/vertical ratios)

So, with the exception of what the FPGA-Shifter will bring, we will get a nice upgrade to medium and high resolutions:

Medium res gets a Medium+ equivalent: 16 colors instead of 4
High res gets a High+ equivalent: 4 colors instead of monochrome

Both still using the same sync signals as before, i.e, Medium+ runs on TVs/15kHz screens and High+ runs on any VGA monitor.

There's also a new vertically compressed 320x400 "Low+" which is VGA monitor compatible. It hasn't got a direct regular ST resolution equivalent but might be interesting anyway.

Hopefully Smonson can add chunky into there as well... I assume it would be easier than doing palette based lookups, just pretty much data in to data out.. Think I did wonder about the "format" of this a few months ago... it would be best usage of 16bit data... Can't remember exactly..

8bits per pixel would be maybe XXRRGGBB (kinda sucky since we have 3 bit resolution) BUT I think I read the human eye can't easily tell brightnesses of 1 colour, cant remember, so we could use like RRRGGGBB for example.. then we have 2 pixels per 16 bit packet.

16 bits per pixel XXXXXRRRRGGGGBBBB (4bit resolution) or XRRRRRGGGGGBBBBB (5bit resolution) of course would need some serious bandwidth as a full 16bit packet would be only 1 pixel. May even need to eventually go to 32bit to do it in any good resolution..

Can't think what palette based data is, think we worked it out in packets per frame available somewhere.. (got migraine here so cant think )

Also thinking way to ahead again..

If a super shifter could actually use a frame buffer, then the "shifter/MMU" could just update the buffer rather than the whole frame each time..

One example is addressable frame manipulation.. that if you only wanted to update a few lines on screen, you could just set a address and RAM and have special feature to copy that sprite data directly to the frame buffer.. It wouldn't require any action , the copy would be done internally in the FPGA.

With a frame buffer as well, we don't necessarily have to keep outputting the entire screen data each frame.. Could probably tweak the MMU the only output data when we want it, it will probably speed up the CPU power a fair bit as the MMU would have a lot less data transfer having to update to shifter constantly.

Really gets into proper video RAM, not video RAM held in ST-RAM.. of course not saying to stop doing that, of course it takes up a lot of MMU/CPU cycles to transfer data to the shifter.. If we could hold some data like sprites internally in the the, we could just issue a couple of packets to send the command to copy that data the frame buffer directly.. Would not take any time up at all MMU wise.. And of course while the MMU is busy, is stalling the CPU from accessing main RAM.

exxos wrote: ↑Mon Aug 20, 2018 1:32 pm Hopefully Smonson can add chunky into there as well... I assume it would be easier than doing palette based lookups, just pretty much data in to data out.. Think I did wonder about the "format" of this a few months ago... it would be best usage of 16bit data... Can't remember exactly..

8bits per pixel would be maybe XXRRGGBB (kinda sucky since we have 3 bit resolution) BUT I think I read the human eye can't easily tell brightnesses of 1 colour, cant remember, so we could use like RRRGGGBB for example.. then we have 2 pixels per 16 bit packet.

8bit direct color isn't a good idea due to its limited colors range.
IMO 8bit chunky should be palette based. E.g. in TT Shifter address range (12 bit pallette): $FFFF8400 - $FFFF85FE or Falcon (18bit palette): $FFFF9800 - $FFFF98FC

I think someone is waiting for someone to solder and write some code and then all will be clear ...

Chunky with palette makes best sense I think. I guess 1 bytes per pixel for 256 colour palette. so 16bit packet equates to 2 pixels like $1122..

16bit "true colour" would need a lot of bandwidth power, or as said earlier, would need a frame buffer to allow "slow frames" to be drawn.. may only be useful for static images though.