ST SHIFTER operation ?

General discussions or ideas about hardware.
Atarian Computing
Posts: 76
Joined: Tue Aug 22, 2017 4:27 am

Re: ST SHIFTER operation ?

Post by Atarian Computing » Fri Oct 27, 2017 12:28 pm

Yes, 25hz is most likely out of range for most panels. 30hz should be possible by most. Personally I’m willing to work with 30hz for better gains elsewhere.

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

Re: ST SHIFTER operation ?

Post by exxos » Fri Oct 27, 2017 1:15 pm

Atarian Computing wrote:
Fri Oct 27, 2017 12:28 pm
Yes, 25hz is most likely out of range for most panels. 30hz should be possible by most. Personally I’m willing to work with 30hz for better gains elsewhere.
Sounds like we could be into iffy territory then :(

It could possibly be better to go with overscan and gain something on the vertical resolution that way.. In any case I would shelve this idea for the time being..

I need to get basically low resolution working first anyway yet :)
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
IngoQ
Posts: 475
Joined: Tue Aug 22, 2017 8:38 am
Location: Germany

Re: ST SHIFTER operation ?

Post by IngoQ » Fri Oct 27, 2017 1:23 pm

At least for computer displays this would be quite an unusual requirements, and you will most likely have a hard time finding one, because no one actually tried that. Although I have to admit, that this is speculation on my side.

Exxos new NEC MultiSync EA190M for example goes horizontally down to 31.5 kHz, which will be sufficient for PAL/NTSC based signals, i.e. med and low res. But even that display is specwise not under 56 Hz vertically.

Source: http://www.necdisplay.com/p/desktop-mon ... pe=support

You might have more luck with a TV, which's video processor could accept a 30p progressive signal and internally double it to 60Hz which the panel natively accepts.
Ingo :geek:

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupéry

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

Re: ST SHIFTER operation ?

Post by exxos » Fri Oct 27, 2017 1:41 pm

IngoQ wrote:
Fri Oct 27, 2017 1:23 pm
You might have more luck with a TV, which's video processor could accept a 30p progressive signal and internally double it to 60Hz which the panel natively accepts.
I think this is getting back onto some other talks at some point earlier. Will basely need to store a entire frame in ram as a buffer, and then output this twice to the monitor, basically a frame doubler.

Though if we are getting into using external RAM, we might as well use some fast ram, and just forget the MMU altogether, and is why the CPU bus straight to the video RAM. Now with a stock machine at 8 MHz, is probably not a good idea, with the CPU was running at 32 MHz, we could write to video RAM a whole lot faster and it wouldn't be a problem.

Ideally then we would need some way stop the MMU updating the original shifter totally. Properly just bypass DE to the MMU never strolled to send data to the shifter, basically just turn the shifter off.

Of course the problem is video RAM would not be in the ST ram area any more. Basically we would be looking more like adding a external graphics card onto the bus.. In which case we will probably be better looking for a actual graphics chip where we can just simply send data to it and have it take care of all the video modes internally.

Problem is of course, we're basically breaking compatibility and creating a huge amount of work :roll:

I think eventually, if someone created a new MMU, this really would not be a problem. So in terms of compatibility, I think recreating the shifter is close to the original as possible is the way to go, of course at the new video modes before as we can double clocked the MMU. Anything more than that we would need to double clock the MMU again.. All in all I think this is the better way to go.

While lots of new fancy features more graphics power is always welcome, I don't want to break any compatibility with any existing software. This is one reason why I have basically stuck to the 68000 and overclocking this as much as possible. Of course the 030 is 32 bit and has catches and is vastly faster, but a new CPU is of course going to start breaking compatibility. Overall I think I am more in favour of getting the existing architecture running faster and faster, but basically using the original designs.
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: 82
Joined: Sat Oct 28, 2017 10:21 am

Re: ST SHIFTER operation ?

Post by Smonson » Sat Oct 28, 2017 10:53 am

Hi guys! Hope I'm not intruding in this thread, I just wanted to say that I'm coincidentally working on an FPGA shifter replacement as well, very similar to what you guys are talking about here (you may have seen my post on Atari Forum). I have implemented monochrome video out to HDMI using a Cyclone-II EP2C5. I have been thwarted by clock instability but will be receiving new PCBs on Monday that might fix that.

I'm so great to see people collaborating on a project and not trying to shoot it down. Keep up the amazing work!

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

Re: ST SHIFTER operation ?

Post by exxos » Sat Oct 28, 2017 2:49 pm

Smonson wrote:
Sat Oct 28, 2017 10:53 am
Hi guys! Hope I'm not intruding in this thread, I just wanted to say that I'm coincidentally working on an FPGA shifter replacement as well, very similar to what you guys are talking about here (you may have seen my post on Atari Forum). I have implemented monochrome video out to HDMI using a Cyclone-II EP2C5. I have been thwarted by clock instability but will be receiving new PCBs on Monday that might fix that.

Sounds very cool, maybe you could fill us in in another thread here to catch us up ? :)
Smonson wrote:
Sat Oct 28, 2017 10:53 am
I'm so great to see people collaborating on a project and not trying to shoot it down. Keep up the amazing work!
Thanks! Yes, far to much negativity and project killing people about, such things are not tolerated here :)
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
Maeke
Posts: 201
Joined: Thu Aug 17, 2017 3:09 pm

Re: ST SHIFTER operation ?

Post by Maeke » Sat Oct 28, 2017 3:33 pm

Smonson wrote:
Sat Oct 28, 2017 10:53 am
Hi guys! Hope I'm not intruding in this thread, I just wanted to say that I'm coincidentally working on an FPGA shifter replacement as well, very similar to what you guys are talking about here (you may have seen my post on Atari Forum). I have implemented monochrome video out to HDMI using a Cyclone-II EP2C5. I have been thwarted by clock instability but will be receiving new PCBs on Monday that might fix that.

I'm so great to see people collaborating on a project and not trying to shoot it down. Keep up the amazing work!
That's all this forum is about, no BS, no bullying, no hindering by breaking one's reputation, only fair collaboration or competition and knowledge as accurate as possible (meaning no "i'm the expert so shut up!" coming from random guys or stupide admins (follow my glare on atari-forum which should be renamed bullshit-forum now)).
If i take too long to reply, sorry my cat is sleeping on my laps.

User avatar
Smonson
Posts: 82
Joined: Sat Oct 28, 2017 10:21 am

Re: ST SHIFTER operation ?

Post by Smonson » Sun Oct 29, 2017 10:01 am

exxos wrote:
Sat Oct 28, 2017 2:49 pm
Sounds very cool, maybe you could fill us in in another thread here to catch us up ? :)
I've just posted an overview in another thread. Thanks for the encouragement!
Maeke wrote:
Sat Oct 28, 2017 3:33 pm
That's all this forum is about, no BS, no bullying, no hindering by breaking one's reputation, only fair collaboration or competition and knowledge as accurate as possible (meaning no "i'm the expert so shut up!" coming from random guys or stupide admins (follow my glare on atari-forum which should be renamed bullshit-forum now)).
Yeah... I wasn't going to name names, but all of that does sound very familiar ;)

By the way, about the conversation early in this thread regarding shift registers:
keli wrote:
Mon Oct 16, 2017 8:03 am
exxos wrote:
Sun Oct 15, 2017 10:39 pm
OK, so we need 4x 16bit shifters. Assume this 16bit data is read consecutively from RAM ? Such as , 16bit plane 1, then 16bit plane2.. etc

That would indeed greatly complicate things :roll:
You'd probably need 8 of them. 4 for the data currently being loaded from memory and the other 4 for the data being shifted out to the screen.

But yes the bit planes are interleaved in memory so the blittter will always get one word from alternate bit planes on every load.
You actually only need four 16-bit shift registers and three 16-bit memories (latches, whatver). You don't need the fourth one because on the 4th load all the data is moved into the shift registers, so you can just write your data there directly for the last one.

This is how I implemented it (untested) in verilog:

Code: Select all

palette_index <= {
	shift_ir[0][15],
	shift_ir[1][15],
	shift_ir[2][15],
	data[15]
};
shift_rr[0] <= {shift_ir[0][14:0], 1'b0};
shift_rr[1] <= {shift_ir[1][14:0], 1'b0};
shift_rr[2] <= {shift_ir[2][14:0], 1'b0};
shift_rr[3] <= {data[14:0], 1'b0};
In the above, which runs on the edge of the 4th LOAD pulse, the pixel colour register is being written from the combined high bits of all four LOADs (in shift_ir registers plus the data bus), and the other 15 bits go into the shift registers (shift_rr) for subsequent pixels. It would probably look simpler if you loaded the shift registers and then immediately shifted one pixel out, but I'm not very good with verilog yet.

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

Re: ST SHIFTER operation ?

Post by exxos » Sun Oct 29, 2017 11:16 am

Smonson wrote:
Sun Oct 29, 2017 10:01 am
Yeah... I wasn't going to name names, but all of that does sound very familiar ;)
Welcome to the group of outcasts :lol:
Smonson wrote:
Sun Oct 29, 2017 10:01 am
By the way, about the conversation early in this thread regarding shift registers:

You actually only need four 16-bit shift registers and three 16-bit memories (latches, whatver). You don't need the fourth one because on the 4th load all the data is moved into the shift registers, so you can just write your data there directly for the last one.
Never thought of it that way! There seems to be two methods for the loading.

What seems to be a popular one is to help all the data as soon as the latches are full.

The second method is counting the 16 bits which are outputted, and then loading the data from the data latches. This is actually the method I was going for. I don't think it really matters either way. But I'm also thinking a little further ahead in terms of future MMU designs. In that the data written from the MMU to the shifter can be written at any speed, without it upsetting the actual pixel drawing to the screen.

Ultimately it may not really make any difference, but I am preferring to try and make the shifter more future proof.
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: 82
Joined: Sat Oct 28, 2017 10:21 am

Re: ST SHIFTER operation ?

Post by Smonson » Sun Oct 29, 2017 11:43 am

exxos wrote:
Sun Oct 29, 2017 11:16 am
The second method is counting the 16 bits which are outputted, and then loading the data from the data latches. This is actually the method I was going for. I don't think it really matters either way. But I'm also thinking a little further ahead in terms of future MMU designs. In that the data written from the MMU to the shifter can be written at any speed, without it upsetting the actual pixel drawing to the screen.

Ultimately it may not really make any difference, but I am preferring to try and make the shifter more future proof.
I understand - I know you have been trying very hard in the past to improve the ST's clock speed, and the current shifter just gets in the way of that. It would be great to have a more configurable shifter/MMU combo so that when you're running at 16MHz you could execute a LOAD only every 4th bus cycle instead of every 2nd. Alternatively you could clock the shifter every 2nd cycle, as it is now, and have a 256-colour lo-res video mode, or 4 colour 640x400, etc. I think that's very achievable.

Post Reply