SUGGESTIONS

All information relating to the Alpha plus all the WIP threads etc.
Cyprian
Posts: 140
Joined: Fri Dec 22, 2017 9:16 am

Re: SUGGESTIONS

Post by Cyprian » 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
Lynx II / Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
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.appspot.com/

stephen_usher
Posts: 349
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: SUGGESTIONS

Post by stephen_usher » 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.
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.

User avatar
exxos
Site Admin
Site Admin
Posts: 7846
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: SUGGESTIONS

Post by exxos » Sun Aug 19, 2018 2:00 pm

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.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

Petari
Trusted Guru
Trusted Guru
Posts: 550
Joined: Tue Nov 28, 2017 1:32 pm

Re: SUGGESTIONS

Post by Petari » Sun Aug 19, 2018 4:37 pm

Yes, I think that improved shifter together with faster RAM and MMU + other chips is much better solution than some added ISA or PCI card - which will need some logic too to put them on bus of ST . 8 bits/pix mode is what would be interesting, and is present in TT and Falcon too - that means 256 colors at once, for any pixel. Some bigger resolutions with existing modes too would be fine. TOS/VDI supports higher resolutions, but even it needs some small driver code (like in overscan). 8 bits/pix will need for sure driver, or any new mode where not only res. is changed. That could go in improved TOS.
Here to note that despite there is 8 bits/px mode in TT and Falcon they are not same. I needed to write separated code for them to display 256 color BMP file.
Considering mass storage adapter: IDE port is very simple. SD card adapter is not that simple. But SD cards are what is cheaper, and today is even not so easy to find CF cards. Maybe to go on IDE port + IDE/SD adapter solution ? What still allows attaching of IDE disk or CF card. Actually, I think that you just can not find anything simpler than IDE adapter.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Cyprian
Posts: 140
Joined: Fri Dec 22, 2017 9:16 am

Re: SUGGESTIONS

Post by Cyprian » Sun Aug 19, 2018 6:53 pm

you've convinced me. A new SHIFTER with chunky mode and a new BLiTTER is a much better solution.
Lynx II / Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
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.appspot.com/

troed
Moderator
Moderator
Posts: 497
Joined: Mon Aug 21, 2017 10:27 pm

Re: SUGGESTIONS

Post by troed » Mon Aug 20, 2018 12:25 pm

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.

User avatar
exxos
Site Admin
Site Admin
Posts: 7846
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: SUGGESTIONS

Post by exxos » 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.

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 :( )
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

User avatar
exxos
Site Admin
Site Admin
Posts: 7846
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: SUGGESTIONS

Post by exxos » Mon Aug 20, 2018 2:13 pm

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.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

Cyprian
Posts: 140
Joined: Fri Dec 22, 2017 9:16 am

Re: SUGGESTIONS

Post by Cyprian » Mon Aug 20, 2018 2:29 pm

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
Lynx II / Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
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.appspot.com/

Petari
Trusted Guru
Trusted Guru
Posts: 550
Joined: Tue Nov 28, 2017 1:32 pm

Re: SUGGESTIONS

Post by Petari » Mon Aug 20, 2018 2:49 pm

8 bits/pixel of course palette based, as is in most cases. And indeed 12-bit palette, as by STE or TT . More wouldn't harm :D
Direct color has sense with 16 bits/pix or more .
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Post Reply

Return to “ALPHA DEVELOPMENT INFO”