exxos's Atari, Amiga & retro forum

A small thought on not using a sync ram..

A lot isn't drawn, but the CPU can write to a block of registers (only 1 block shown aka colour 0) at any time without upsetting the output RGB colours.. Colour register (0-15) that is, which uses the bottom 1 of 16 decoder based on CPU address lines A1-A4.

Basically data from the 273 is latched when that particular colour is selected in the 373 latch by the top 1 of 16 decoder driven from the internal shifter registers which are outputting the pixels to the screen..

This way, writing to any colour register, will not affect the colour being selected by the shifters. There is actually no need to update any register until it is used on screen, so the update can happen at the same time as the colour is selected.

Of course, reading a register is not shown, but will be a simple feedback buffer as per my previous image.. Will try and route it more tomorrow..

This is one colour register block. There will be 16 of these each of the colour registers. Though as the circuit is rather large, I will convert these is a block symbol for my schematic later.

Basically on the top left is the databus, below that some select lines, and to the bottom right the RGB outputs.

So for example a CPU write, /CS & /RW will both go low and BUFFER_SEL will go high. /CS & /RW are inverted to the bottom AND gate so when this condition is met the output of the and gate is high.

So then the 373 latches act like a stray piece of wire and connect the inputs to the output directly. When /CS goes high, the output of the AND gate will go low the data is latched .

For a CPU read cycle, the bottom AND gate is disabled throughout that cycle so no data is latched or changed. The top and gate meets the conditions for the read and the 244 outputs are enabled. So the data which is on the 373 output is fed back to the databus. Obviously during any other cycle the 244 outputs are tri-stated as not to interfere with the databus.

As for the registers and actual RGB data on the screen, OUT_SEL will go high to access colour register and the second bank of 373 latches propagate the data from the first bank three latches, just like a stray piece of wire. Data on the second bank of the 373 is is also latched when that register is deselected.

So basically the CPU could access any colour register at any time. Each output colour register is always updated with a new colour data when it is enabled. Basically then acts as a straight piece of wire again.

As there will be 16 of these banks in parallel, we do not want output all 16 registers at the same time so the bank is simply tri-stated to disable all colour registers other than the one which is selected.

So data propagation throughout the circuit is ultrafast and the whole operation is asynchronous. The CPU can read or write to any colour register independently of the internal shift registers colour selection.

Basically a copy of all the colour registers are stored in the second bank of 373 latches, so the pixel colours to screen use a second bank of latches to output the actual RGB data. All those latches will always update from, let's just say the master bank, each time time the colour is selected.

In my initial design I had the issue that I could not have the CPU access a register as it would change the a internal pointer to select the particular register it was accessing, but also the shift registers needed to access the colour registers as well, and obviously we cannot have two things using the same register at the same time.

Later I basically thought that all the data sent by the CPU is stored in a latch, but we do not need to transfer the data to the output of latches until colour register is actually accessed.

So the result is the CPU can select any register at any time, it can read or write to the register at any time, and that the same time internal shift registers will be selecting the colour registers to output the screen data, and any register can be accessed at any time by the internal shifters. So this basically solves the problem of having to things needing to access colour registers the same time.

Circuit may look complicated, but it is actually very simple and really does not do that much :)

I see you're using and storing all 16 bits from the data bus, but on the ST, only 9 bits are stored (12 if you want to support 4096 colors like on the STE.)

Since you're building this on a programmable device (and not discreet components), couldn't you save some space by only using 12 bit wide RAM blocks?

keli wrote: 24 Oct 2017 17:05 I see you're using and storing all 16 bits from the data bus, but on the ST, only 9 bits are stored (12 if you want to support 4096 colors like on the STE.)

Since you're building this on a programmable device (and not discreet components), couldn't you save some space by only using 12 bit wide RAM blocks?

Good point actually..

I'm actually using a lot of gates like you say are not actively used.. I am basically building this out of 74 series ICs to keep things simple. So this basic limited me to 8 bit devices. Not sure if there is four bit transparent latch, there might be a dual four bit transparent latch, but does not really help anyway.

I don't know how good the Altera compiler is, as really, if nothing is connected to the input or output of the flip-flops, they shouldn't actually be compiled into the design.. I will ask on the Altera forum see if I can get any sense out of anyone.. I'm not hopeful..

I guess I could design my own transparent latches and do a 12 bit version..

... or you could use the extra bits to support 65536 colors similar to how the infamous dual shifter mod mentioned in another thread supports 32768 ;)

keli wrote: 24 Oct 2017 19:24 ... or you could use the extra bits to support 65536 colors similar to how the infamous dual shifter mod mentioned in another thread supports 32768 ;)

True :) I don't think extending the colours more going to be that useful as we are still limited to 16 on screen anyway :)

exxos wrote: 24 Oct 2017 20:15

keli wrote: 24 Oct 2017 19:24 ... or you could use the extra bits to support 65536 colors similar to how the infamous dual shifter mod mentioned in another thread supports 32768 ;)

True :) I don't think extending the colours more going to be that useful as we are still limited to 16 on screen anyway :)

Well ... if you're redesigning the Shifter then 32MHz MMU can feed 320*200*256 ... :) The question then becomes whether to hardcode a 256 color chunky byte mode (preferable, I think) or find space for 256 palette registers :)

troed wrote: 24 Oct 2017 22:26 Well ... if you're redesigning the Shifter then 32MHz MMU can feed 320*200*256 ... :) The question then becomes whether to hardcode a 256 color chunky byte mode (preferable, I think) or find space for 256 palette registers :)

Which uses less bytes for 256 colours, bit planes or chunky ?

Could be struggling for 256 colour registers in a "cheap" device.. Though adding 8 bit planes instead of 4, and added extra video modes shouldn't be a problem..

Is chunky 1 byte per pixel and we are simply sending RRGGBB every pixel ? If so, that would be really simple, its just if the MMU can bang out data fast enough for it..

Probably be easier with 16bit per pixel, as there (will be) 4 bits per colour on the RGB drivers... so RRRR GGGG BBBB... waste of a bit, so would need 5 bits per colour for RRRRR GGGGG BBBBB... to tired to work out how many words per line etc this would all be.. probably 40 pixels per line.. :lol:

Edit:

Currently we have 4 words for 16 pixels.. Or double clocked 8 words for 16 pixels.

So if we did chunky mode..

RRGGBB RRGGBB xxxx

2 pixels per word.. 8 words x 2 is 16 pixels.

Only 4 shades of each colour though..

Edit2

We have 320 pixels in block of 16, so 320 /16 = 20 x 4 bit planes = 80 words per line.

MMU double clock is 160words per line. So if we had 1 pixel per word, then we would be limited to 160 pixels per line :(

I don't know the bandwidth of video data, though I think the CPU would need its own fast ram and the shifter wired into the fast ram, aka video ram.. I don't know if the CPU would be able to shift data about faster than the MMU to shifter... Then its not such a simple project anymore..

Edit3.

I'm actually assuming the MMU data rate is fixed internally ? I actually don't know.. I assumed its just counting through video ram on a fixed clocked speed internally...

I half remember the video interrupts could be turned off or something to stop the MMU loading data at all into the shifter? I remember poking around in ram in stos and I could turn off the monitor somehow... Then makes me wonder if shifter cycles could be disabled totally and the system would run faster as the MMU wouldn't be updating the shifter anymore ?

If we could stop the MMU from outputting data, maybe keep DE low to make it think its drawing the border all the time... Then just hook up the shifter direct to the CPU instead.. CPU could access st-ram to access video data, but I don't know how fast the CPU could fetch data from ram and shove it into the shifter.. Would assume it would be slower than direct MMU to shifter .. No idea..

Got this reply from someone on Altera forum..

With an FPGA/CPLD, you're not implementing a component, like an old TI part, in the device. You are creating buffers and logic that are implemented using device resources. So if you have 4 buffers in a design, logic resources for 4 buffers will be implemented in the device.

So as long as the gates are not connected to anything, it should not actually use any resources within the chip.

I did half wonder about using those three bits something else like audio data..

Even so, if we fiddled with DE a little bit, we could actually interleave audio in the area such as the left border. We could flag either colour or audio data, and on audio data have the shifter simply output the border colour as before.. Though technically we would have a stream of data hidden away in the left border which could be output to a digital to analog converter, it would be cheap way of getting sound data from memory to the audio circuit.

Just because we are shifting video data to the shifter chip all the time, it does not mean we couldn't send some more data for something else as well.. No idea what, just thinking out loud again really :)

I guess DE could be replaced with new logic..

If the Vsync generated by the glue had a divide by two counter and Vsync was cut to the MMU and replaced with the slower vsync, then the MMU would output twice as much data before resetting with the Vsync signal. In effect it would actually output 400 pixels vertically, instead of 200 for example..

Obviously we are not going to see these on-screen just by doing that, but if you used a PLL on the Vsync and X2 multiplier, cut the Vsync to the monitor port and replace it with faster signal, then the vertical resolution rate should double and actually allow the 400 pixels to be viewed on screen..

Assuming the resolutions et cetera are internal to the glue, we could bypass these registers to the glue and set up a new register elsewhere.. We could emulate all the resolutions and add some new ones, and even double the vertical resolution, I think...


EDIT:
now got this reply..

Yes, It will implement all the logic blocks written in FPGA/CPLD irrespective of whether it is used in program.In other words, it is a open net.

Then this..

This is not my experience. The compiler is smart enough to remove logic that is not used logically, so large portions of logic that for example drive a node that is never used may be optimized out of the design. Likewise, if some large block of logic ends up generating a constant result, it can be optimized down to a constant.

There are directives available that can be attached to signals / nodes in the source that specify that the attached node NOT be removed, but rather preserved, but this is the not the default. The compiler will aggressively remove unused logic unless explicitly told not to by user directives.

:roll:

So I guess I will have to try and compile some example circuits and see what it says the "used" stuff is in the chip.

Back to new video mode thoughts... Please can someone check my workings out..

We have 320 pixels in blocks of 16 pixels, so 320 /16 = 20 words x 4 bit planes = 80 words per line Normally. Or 160 words double clocked.

80 words into 320 pixels would be, 4 pixels per word, or 2 pixels per byte. (thinking new video mode)

in a byte we have 8 bits, so RRGGBBxx is all we could have. This is limited to four brightness is per colour.. So 4x4x4=64 colour palette and 64 colours on screen at any time. Still a improvement over 16 colours..

This way each pixel has its own byte, though the MMU would still transfer data to the shifter in a word boundary, tho technically it would be sending two pixels at once.. I'm assuming that odd and even bytes are accessible individually. Worst case is that two pixels would have to be updated at once, though it is still better than having to update four words just to change one pixel..

Reading up online little, some seem to use RRRGGGBB as apparently the eyes less sensitive to blue changes in brightness, but this would be a little annoying as we really need three bits to output to the RGB drivers..

Probably a better thought, still have RRGGBBxx but use one of the bits as a intensity bit which will double up a lot on what we can use colour wise and on-screen.. So it would be RRGGBBxi.

So the colour index should then be 4x4x4 = 64 x 2 intensity bits is 128 colour palette and 128 colours on screen at once.

So for example black to white..

Would be ( RR GG BB i)
00 00 00 0 = black
00 00 00 1 = grey

11 11 11 0 = grey
11 11 11 1 = white

Or for a red intensity example..

11 00 00 0 = medium brightness red.
11 00 00 1 = full brightness red.

Obviously for three bit colour data we would normally have a palette of 512 colours. (16*16*16=512). Even though the palette would be still be 512, we can actually now select 128 colours from this palette, and have 128 colours on screen at once at any pixel. I have no idea how to work out what colours could and could not be used, but is still a vast improvement over 16 colours and a 16 colour palette.

Now if the MMU is double clocked, we can shift twice the data twice as fast per scanline. So we could actually have one pixel per word. This would mean we would have to up to 4 bit RGB drivers then we would have.. xxxxRRRRGGGGBBBB per pixel. Then we could have 4,096 colours on the screen at once.

While this sounds really good, I personally would prefer to gain extra resolution rather than gain more colours. So my idea of 128 colours on the screen at once, and limiting to one pixel per byte, would mean we could still do this at a high resolution for 640x200 x 128 colours. So I think a compromise between resolution and colours is the way to go..