SUGGESTIONS

Open source STF clone project.
User avatar
Maeke
Posts: 208
Joined: Thu Aug 17, 2017 3:09 pm

Re: SUGGESTIONS

Post by Maeke » Sun Oct 29, 2017 12:25 pm

arf wrote:
Sun Oct 29, 2017 11:59 am

There’s no point in re-inventing the wheel for sure, and as I wrote, I wouldn’t necessarily go for IDE, but for modern storage options that you can buy new. Like the SD cards you mentioned.

Ultrasatan uses sd cards.
If i take too long to reply, sorry my cat is sleeping on my laps.

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

Re: SUGGESTIONS

Post by exxos » Sun Oct 29, 2017 12:30 pm

Maeke wrote:
Sun Oct 29, 2017 12:25 pm
arf wrote:
Sun Oct 29, 2017 11:59 am
There’s no point in re-inventing the wheel for sure, and as I wrote, I wouldn’t necessarily go for IDE, but for modern storage options that you can buy new. Like the SD cards you mentioned.
Ultrasatan uses sd cards.
Ultimately I would try and have a ultra-Satan board which plugs over the top of the DMA chip via a expansion header. If the add-on board was close enough to the rear of the case, a small slot could be made in the back of the case so the SD card is accessable externally.

Jookie is planning at some point to release the design for Cosmo, so this could be adapted for internal mounting. But of course this is probably going to be all a long way away as I have still yet to finish the motherboard design, which I just do not have time for at the moment :(
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: 59
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
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/

stephen_usher
Posts: 133
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
Posts: 3541
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
Posts: 533
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: 59
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.
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/

troed
Posts: 343
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
Posts: 3541
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
Posts: 3541
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.

Post Reply