ST SHIFTER operation ?

[exxos]

Sorry for the lo-res shot, the file export to JPEG keep ending up corrupted I don't know why so I had to do a screenshot

This is ball pretty simple. As before there is a one of four selector which selects one of the four banks of latches. The load signal latches the data in the latch only when that latches selected, this is the function of the or gates. Basically a clock inhibit line, or a enable line may be easier to understand.

Each databank goes to a 16 bit shift register. When the counter reaches 15 the register will clock on the positive edge the 32 MHz cycle, and the shifter load select is done on the negative side 32 MHz clock cycle. I'm not totally sure this is correct, but I cannot currently think of another way of doing it. Basically when the shifter has outputted its last bit of data, the shift registers have to switch into load and load the data from the data latches. Then on the next clock cycle shifters are shifted back into shift mode, and then they will start to output the next bank of bits.

Similarly as before I was not sure about clocking the one of four decoder from the load line on the MMU. Though thinking about it I put a inverter in that line, so what should happen is on the falling edge of the load line the binary counter should count up one. So what should happen is the load line goes low, data is latched, the load line goes high to latch data and then when the load line goes low again counter is counted one for the next bank of latches.

While I think this should probably work, there is probably going to be a bug because the first time the load line toggles, it will also count up one. So basically latching of data will start from the second bank of latches (or bit plane one said of bit planes zero).

The probable fix for this is to only clock the counter on the rising edge of the MMU load line.. The problem is here that data will also be latched at exactly the same time, so I do not think this is a good idea either..

The first method of using both sides of the load line I think is the way to go. This way the first falling edge of the load line will cause the counter to count up one, and select the next day to register, data is settling at the same time, and then will be latched on the rising edge of the load line. Of course they could be is here that the reset of the binary counter, or the one of four decoder, will always start from number one, not zero..

I could probably bodge this simply by reordering the shift registers and making the second shifter bank is actually shifter banks zero. So instead of the order on the registers going 0,1,2,3 they would actually go 1,2,3,0 the overall output of the shifter bank still be as expected just the internal operation would be a bit odd

I guess the way around it would be for me to try and reset the binary counter so it starts from "11" this would select latch bank for, and then when the first load pulse comes from the MMU, it will then knock the counter back to 0 and select the correct latch bank.

So I will see if I can fiddle the binary counter actually reset number four instead of zero. Have starting adding in the input and output nodes, so hopefully at some point in the near future I can set up a simulation and try and simulate what is going on with all this

Obviously I want to try and get this part finished before adding in the colour palette registers etc

c1.JPG (550.74 KiB) Viewed 5659 times

[exxos]

Cannot believe this..

I have used 138 macrocells already. The maximum I can have with this series of chip is 160.. Considering I have yet to do the pallet look up registers, and the programming registers, I'm going to need way more than 160 I think

Capture.JPG (31.49 KiB) Viewed 5652 times

EDIT:

Looks like there must be some larger chips.. Somewhere..

1.JPG (60.37 KiB) Viewed 5652 times

It seems I need to go to a high pin count TQFN package, I only had PLCC selected before. This kind of sucks as I don't really need really high pin count IC, but this looks like the only option to get higher macrocells

The EPM570 (MAX II SERIES) runs on a 3.3 V core, but does support 5 V I/O.

I am currently looking at the max five series... It does quote 5 V I/O on the higher end PLD's..

max5.JPG (80.54 KiB) Viewed 5648 times

max51.JPG (126.72 KiB) Viewed 5645 times

So it looks like the core has to run on 1.8 V.. Not really a problem.. But that I/O drive can only actually output 3.3 V.. And I think this would actually be a problem anyway.. Just the RGB driver outputs would need to be tweaked to run from 3.3 V input said a 5 V input.. Transistor biasing can be fiddled about with but that is the problem which can be fixed at the time anyway..

So it looks like I will have to think about moving to a more modern PLD. As the 7000 series is actually obsolete is probably not a bad idea anyway. The time being the device does not really matter as I think it will be a long time before I get this design into hardware anyway.

I may just get the evaluation board as this would save some hassle at some point...





One thing I never considered, was that Intel brought out altera... So if this new shifter makes it into the real world, the Atari will actually be powered by Intel technology


https://newsroom.intel.com/news-release ... of-altera/

[Gunstick]

don't forget mid-rez and monochrome modes.
And 50/60 Hz stuff.
That's how you make fullscreens, and they mess up the shifter pretty well
Think misaligned bitplanes phenomen where the shifter becomes desynchronized with the mmu (it's 1 word late).

[exxos]

don't forget mid-rez and monochrome modes.
And 50/60 Hz stuff.
That's how you make fullscreens, and they mess up the shifter pretty well
Think misaligned bitplanes phenomen where the shifter becomes desynchronized with the mmu (it's 1 word late).

Yes, need to get low res working first

I should be able to fix the "bugs" like that in the shifter though

[keli]

Have you considered some of the popular FPGA Dev boards such as the KNJN Pluto boards?

They have a small foot print and both Altera and Xilinx options.

I haven't tried them myself, but I was interested in the one with the HDMI port, although that one does not have 5v tolerant I/O

[exxos]

Have you considered some of the popular FPGA Dev boards such as the KNJN Pluto boards?

They have a small foot print and both Altera and Xilinx options.

I haven't tried them myself, but I was interested in the one with the HDMI port, although that one does not have 5v tolerant I/O

I had not seen those no. I could do with a breakout board like that for the PLD which I am using.

One thing which may not be apparent as yet, is that while I'm designing this on a gate level, basically to get full compatibility with the shifter, and it has not been done before yet as I know anyway, but also the software does actually explore into VHDL, so someone could pretty much copy and paste this code into any other device and edit it etc.

I have wondered about scan doubling, where the shifter could output the same line twice to basically gain twice the vertical resolution, sort of, but then the vertical sync would need doubling in speed also. Obviously we cannot do this from the glue, so it will probably have to have a PLL two double the vertical sync speed and use that on the monitor socket. So then the shifter will be basically faking 400 pixels vertical and vertical sync will be running at double speed.

I did also consider last week about replacing the vertical sync generator in the glue and generating it externally. I seem somewhere in the glue it handles some sort of resolution change, so assume there is a register in there somewhere to do with this. I think vertical sync doubles in speed by high-resolution so obviously something us to tell the glue to change speed.

Though if that register was bypassed from the glue and mapped elsewhere, the register could be emulated, and if there is a spare bit or two we could add actually extra resolutions and vertical sync combinations. Obviously we would need faster MMU and shifter in order to obtain the bandwidth needed for a higher resolution. So this is probably more of the future thought than anything else.

As a side note, I spend weekends with my girlfriend, though she generally does not get up very early on the Sunday, so I will take my Altera software up on my USB stick, and see if I can start mapping the colour registers Sunday morning

[exxos]

I'm trying to work out the palette lookup stuff...

The easy bit is that the output of the shifters go to a decoder to select a one of 16 palette bank and output RGB.. like below..

1.PNG (32.1 KiB) Viewed 5610 times

Problem is, we need to read from the registers also ?

Actually there is no address selection at all here (yet) for reading or writing...

But does anyone know is reading or writing from the palette registers causes any sort of glitch in the video at all ?

What I mean is, if the shifter is outputting colour 10 for example, and we read from colour 5 for example, then the RGB outputs would need to be changed to colour 5 during the read, which will change the colour colour of the pixel on screen while the read or write to that palette register is happening.. now that can't be right... ?

Rodolphe said CS is the register access, it looks like in the posted LA traces, it happened during the border draw.. even so, reading while the border is outputting colour 0, reading or writing to the registers would still upset the palette index.

Obviously, we can't have 2 circuits using the same palette registers at the same time ?!

Only way it could be done is if the RGB outputs are latched, and independent from the actual palette registers. Have a bidirectional latch for the palette registers, but isolate them from the RGB output latches so the reading and writing from the palette registers doesn't effect the actual RGB output colours.

[exxos]

I have run into one of those "chicken and egg" problems.

The problem is, the palette registers have to be selected to output the RGB data, this is actually really easy. The problem is, if any of the palette registers are accessed, e.g. a read or write, then the palette registers selected will be changed and updated.

The trouble is, as the shifter is outputting the palette data, if any of the palette data registers or accessed during a pixel write, the output RGB data would be changed and there would be a glitch in the video.

For example if we constantly fill the screen up with colour 10, and then accessed colour 2 and updated it with some new value, and this would change the pointer to the register, and the screen would glitch for a pixel and actually draw colour to is that is the register which is selected.
Any workaround for this, would be to probably make a copy of all the colour registers, so that reading and writing is done in a buffer, and then the data is clocked to the RGB output registers later.

It was still have a similar problem as before though.. But another workaround will be to only update their RGB output registers when that particular colour is selected. So if colour 2 isn't selected at any point during the screen filled with colour 10, and the register simply isn't updated until colour two is actually used.

So I am open to ideas if anyone has any thoughts on how this is actually supposed to work.

Obviously we cannot have two things accessing a single memory block at the same time..

EDIT:

Someone suggested dual port ram, this could actually work...

Capture.JPG (94.71 KiB) Viewed 5583 times

This way, one output port could be linked to the RGB output data.. Another output could be used as the feedback when reading from a register, obviously this will have to be tri- stated as it will be linked to the databus...

Then a second input from the databus to allow simultaneous write operations to the register while not upsetting their RGB output register..

This will likely be a easy implementation, but I think back in the 80s, Atari must have built this out of basic logic gates for prototyping. So must have found a way around this problem somehow.. Slightly annoying as I don't know actually how they did it..

EDIT2:

Troed pointed me to this thread here

What Dio is referring to is actually using dual port ram. Though it also means that the latches I have in my circuit and the shift registers would not actually be needed. I could just simply use a second dual port ram.

Idea now is that we just have a counter on one part of the RAM where data is loaded from the MMU to the shifter. So the 4 words loaded direct into the first dual port ram bank.

A second counter which counts to 16 will be on the second part of the RAM block which will drive the palette register logic. This second dual RAM block will contain all the palette registers. Which can then output to the RGB port, and also the registers can be written or read to at the same time to prevent the video colour glitches I was referring to..

At the moment this design would seen to solve a lot of problems and be a whole lot easier to design... So I will see if I can come up with a basic outline of how this would now work.. aka total redesign

[exxos]

SCH1.JPG (598.01 KiB) Viewed 5567 times

This is the first draft the RAM circuit for the colour registers and decoding...

Basically on the BUSMUX data B input, we have output of the shift registers, so four bit inputs there..

On input A, is simply grounded. This is to select palette colour zero when DE switches.. So the BUSMUX either allows plane data to pass through, or it will select colour zero.

The SYNCRAM block has a bit plane data coming in on port A. And it is output on port A to the RGB outputs. This is basically set to read mode only.

Port is B a little more complicated. The inputs here allow /RW only to pass to the RAM when /CS is low. Obviously the read/write imports to the RAM have to be selected individually seems (not totally sure yet how it is supposed to work). In any case WRITE will only happen when /CS is low, and the read is then disabled.

So basically read all rights can happen to the registers without upsetting the RGB outputs on port A.

Port B outputs will ultimately have a tri-state buffer to connect outputs of the registers back to the databus on read operations. Obviously we need to isolate the RAM outputs from the databus unless we are reading data from the RAM. I still need to why this chip in.. But I'm still trying to figure out how this RAM chip is supposed to work..

There is no clocking involved it seems, or actually I do not think it needs clocking, on the RAM chip. I'm assuming data is latched on writes when the input deselected...

I think overall this is basically it, at least for low resolution. Will of course need to set up the resolution registers as well, and mash in the various bit plane combinations etc but as it stands I think this is pretty much the entire shifter design..

As a side note, I'm still trying to figure out why I cannot export circuit to a image correctly, it seems to be a bug in the software

[exxos]

Finally got the image to export, I found a print to PNG driver so I use that to export the image instead...

If you click on the image, and right click, and choose open imaging new tab, the image will open in a high resolution in the browser... It is quite large so the browser may hang for a little bit while it opens...

shifter_copy_3.png (360.34 KiB) Viewed 5561 times

I had a small thought as well, that the resolution register needs to be a separate latch register, as I will likely need to directly interface this register to the internal logic, and this would be tricky to do with the RAM.

EDIT:

I have had to move to a max 10 series as the RAM block is not supported on the max 2, or max 5 series

https://www.mouser.co.uk/ProductDetail/ ... yPoA1KEA==


I have also had to redo the ram part as the software crashed and seem to corrupt my design file though as I had a backup from midday, at least I did not have to redo the entire thing. Still extremely annoying as it wasted almost 3 hours to rewire it

In the mix of things I was using versions 13 of Quartus, I was using this as it was the last version which supported the MAX7000 series. Though as I cannot use this chip any more for what I want to do, I downloaded the latest version 17. So hopefully the more stable software. Sadly the image export still seems to be not working

On a bit better note...

11.JPG (14.93 KiB) Viewed 5547 times

My design does compile the warning seemed to be something that it does not like about some signal names. Something about things been in brackets and not in brackets, it has renamed some things but need to look into this some more, but at least it's not a catastrophic failure

If anyone is interested I will do a write-up on exactly what is going on with this circuit, or at least supposed to most of it is explained before anyway somewhere...