SUGGESTIONS

All information relating to the Alpha plus all the WIP threads etc.
troed
Moderator
Moderator
Posts: 497
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: 7846
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
Trusted Guru
Trusted Guru
Posts: 550
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: 7846
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: 276
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
Trusted Guru
Trusted Guru
Posts: 550
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: 7846
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: 7846
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.

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

Re: SUGGESTIONS

Post by stephen_usher » Tue Aug 21, 2018 6:47 pm

I was just wondering, given a lot of the slow-down for the ST is due to sharing the memory between the CPU and video sub-system, would a redesign using dual ported RAM for the screen memory be a good idea?

Of course, for full compatibility the wait states would have to be emulated but in other modes it would allow the CPU far more cycles.
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 » Tue Aug 21, 2018 6:56 pm

stephen_usher wrote:
Tue Aug 21, 2018 6:47 pm
I was just wondering, given a lot of the slow-down for the ST is due to sharing the memory between the CPU and video sub-system, would a redesign using dual ported RAM for the screen memory be a good idea?
I already talked about adding ram to shifter a few posts up..
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

Return to “ALPHA DEVELOPMENT INFO”