SUGGESTIONS

Open source STF clone project.
Cyprian
Posts: 59
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
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/

Petari
Software Moderator
Software Moderator
Posts: 538
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.

troed
Trusted Guru
Trusted Guru
Posts: 400
Joined: Mon Aug 21, 2017 10:27 pm

Re: SUGGESTIONS

Post by troed » Mon Aug 20, 2018 3:09 pm

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

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

Re: SUGGESTIONS

Post by exxos » Mon Aug 20, 2018 3:35 pm

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.
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
Software Moderator
Software Moderator
Posts: 538
Joined: Tue Nov 28, 2017 1:32 pm

Re: SUGGESTIONS

Post by Petari » Mon Aug 20, 2018 4:26 pm

exxos wrote:
Mon Aug 20, 2018 3:35 pm
Chunky with palette makes best sense I think. I guess 2 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.
No, 256 colors with palette means 8 bits or 1 byte per pixel. Falcon type 'true color' is what is 16 bits per pixel - any pix can have one of 65536 colors - and of course then no sense to use palette - it's direct (it's called hi-color now, true color is 24 bits/pix, or may be even 32 - then extra 8 bits are for transparency) . For 256 colors with palette need of course to expand color palette RAM to 2x256 bytes instead 2x16 bytes .

In RAM bandwith it would be: 256 colors, palette based: 2x more than current - since we have 8 instead 4 bits/pix - in case of low res, of course.
65536 colors: 4x current - will it be possible depends on RAM speed, and of course must leave some time for CPU to access RAM. In case of Falcon that mode slows it down some 30% .
Btw. that 'slow frames' reminds on Sinclair ZX 81 :D
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.

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

Re: SUGGESTIONS

Post by exxos » Mon Aug 20, 2018 5:02 pm

Typo, meant 1 byte per pixel.. I corrected it.

we would have from 8mhz to 16mhz to 32mhz, to 48mhz.. so 6x more bandwidth easily. Design aim is 50mhz. But thats mostly CPU limit.. FPGA MMU to FPGA shifter may even get 100mhz speeds.. So 12x rate could be possible if all logic is fast enough (probably not).

Though if shifter had own video ram, we could for example load a static background image, and move a sprite around all internally in shifter. background would be direct copy by shifter from video ram to RGB output.. sprites could be done the same way.. just need more video ram. This way , at least that simple example, wouldn't need to update the whole frame from ST-RAM each time. So leaves more time for CPU, DMA etc.
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
Smonson
Posts: 152
Joined: Sat Oct 28, 2017 10:21 am

Re: SUGGESTIONS

Post by Smonson » Tue Aug 21, 2018 3:02 am

exxos wrote:
Mon Aug 20, 2018 5:02 pm
Though if shifter had own video ram, we could for example load a static background image, and move a sprite around all internally in shifter.
I feel like this would be going a bit too far outside the ST's design for my comfort, into Sega Megadrive territory.

I can only speak for the existing FPGA shifter - it doesn't have enough RAM to do it anyway (less than 15KB), and not enough pins to add an external ram bus. Enough for bigger palettes and increased colour depth, though.

Petari
Software Moderator
Software Moderator
Posts: 538
Joined: Tue Nov 28, 2017 1:32 pm

Re: SUGGESTIONS

Post by Petari » Tue Aug 21, 2018 10:55 am

I think that possibilities are endless. Doing some sprite support in Shifter would be C64-ST hybrid - I guess Tramiel would like it :D
But need to be realistic and not going into some very complicated and HW demanding ideas. ST is enough fast to deal with sprites with CPU and blitter(edited).

Agree with Simonson - doing some extended modes. They may be slower, but good for some static pic. show. We will hardly see plenty of new games for new ST with 65536 colors (maybe some adventure though) , or HW sprites ...
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.

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

Re: SUGGESTIONS

Post by exxos » Tue Aug 21, 2018 11:59 am

True. Was just thinking out loud :)

With a FPGA MMU, like 10ns, maybe 10ns SRAM.. data loading to the shifter will be extremely fast. Of course if we run everything at normal 8MHz then nothing should break. It could be possible to switch between 8MHz and 50MHz so anything which needs timing dependent stuff can run as normal, but loading to shifter can be done at 50MHz.. not sure if it be useful or not, but the key of faster MMU opens the doors to almost anything.

As mentioned before, blitter can run 50MHz or even higher speeds, once I get to test the suska blitter, we could even add more features in there if needs be.
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: 4089
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: SUGGESTIONS

Post by exxos » Tue Aug 21, 2018 6:09 pm

As another thought.. the MMU itself could have some new functions built in.. for example a new register to quickly clear a block of ram... Once the CPU loaded start and end address, internal counters can clear the RAM contents very quickly internally. Had the thought while talks in other threads talking about fast clear of backgrounds for drawing next screen..

Blitter can likely do fast work with screen clear also as has direct access to RAM, but still takes some time to complete. Not sure how many cycles it would take to clear full screen area ? In anycase, internal MMU counters could do block clear faster and no need to use CPU or blitter for main work (only for address setup).
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.

Post Reply