exxos's Atari, Amiga & retro forum

Posted: **27 Oct 2017 12:28**

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.

Posted: **27 Oct 2017 13:15**

Atarian Computing wrote: 27 Oct 2017 12:28 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 :)

Posted: **27 Oct 2017 13:23**

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.

Posted: **27 Oct 2017 13:41**

IngoQ wrote: 27 Oct 2017 13:23 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.

Posted: **28 Oct 2017 10:53**

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!

Posted: **28 Oct 2017 14:49**

Smonson wrote: 28 Oct 2017 10:53 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: 28 Oct 2017 10:53 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 :)

Posted: **28 Oct 2017 15:33**

Smonson wrote: 28 Oct 2017 10:53 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)).

Posted: **29 Oct 2017 10:01**

exxos wrote: 28 Oct 2017 14:49 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: 28 Oct 2017 15:33 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: 16 Oct 2017 08:03
exxos wrote: 15 Oct 2017 22:39 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.

Posted: **29 Oct 2017 11:16**

Smonson wrote: 29 Oct 2017 10:01 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: 29 Oct 2017 10:01 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.

Posted: **29 Oct 2017 11:43**

exxos wrote: 29 Oct 2017 11:16 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.

exxos's Atari, Amiga & retro forum

ST SHIFTER operation ?

Re: ST SHIFTER operation ?

Re: ST SHIFTER operation ?

Re: ST SHIFTER operation ?

Re: ST SHIFTER operation ?

Re: ST SHIFTER operation ?

Re: ST SHIFTER operation ?

Re: ST SHIFTER operation ?

Re: ST SHIFTER operation ?

Re: ST SHIFTER operation ?

Re: ST SHIFTER operation ?