Mk14 vdu

[Timbucus]

I have just burned an AMD2716 so it will be in the post tomorrow hopefully.

[Timbucus]

I have a small number of these variants as they are 12.5v programmable so can be done on my TL866II+

[SiriusHardware]

For future reference, you can usually use a 2732 / 27C32 (normally require a lower programming voltage) as a 2716 substitute by programming the code into the upper half of the 27x32 (0x0800 - onwards).

When inserted into a socket originally wired to hold a 2716, the highest address pin on a 27x32 is held at +5V so the upper half of the 27x32 is permanently selected.

[Karen O]

I've captured the font tables. I use MATLAB to display the tables for verification, and for automated generation of PIC code text.

Should have that done and dusted tomorrow. With Tim's kind help in programming the EPROM, the task is purely one of firmware now.

[Timbucus]

Thanks for the info Sirius filed under useful tips. Just made the Post Office so EPROM on its way Karen!

[SiriusHardware]

I note from Karen's post #300 that she was originally planning to use a 2732, and the EPROM socket on her prototype is presumably wired for that device.

If so the EPROM socket pin 21 which would have been A11 on a 2732 is VPP on a 2716, and as such has to be held at +5V when the 2716 is in read mode.

[Karen O]

In a previous post I extolled the trick of cacheing data to avoid repeatedly fetching it. As things have transpired, this trick has become essential to fitting everything into the 256 cycle scan line. The upshot of this is that, while generating a line of text, it is busy fetching the data for the next line. This overlapping of lines means that a pre-charge of data for the first line must happen in the scan lines above the text.

This is okay for the top half of the screen, but presents a problem for the bottom half. I'm trying hard to ensure the last lines of the top half enmesh with the first lines of the bottom half, but it is looking to be very challenging.

At the worst, I'll have to introduce a blank line half way down the display. That would provide the preparation time the firmware needs while causing minimal discontinuity of the picture.

[SiriusHardware]

In character mode as opposed to graphics mode can you make any use of the 'empty' line between each row of characters? You need not actually stream/output that pixel line because you know you can just generate the sync pulse, set the video output at black level and leave it that way for the rest of the line.

If you're not shovelling black into the UART for it to stream out all the way across that line, you can spend that precious time doing something else instead.

Of course in graphics mode there is no such gap, but the pixel output rate in that mode is halved and I think each line of graphics pixels data is the same data repeated four times, so read once, render four times? Does that mean you can get away with reading a line of pixel data only once every four scan lines in graphics mode?

[Karen O]

Yes, the blank line that separates characters offers an opportunity, however I was planning on filling this with the background colour, according to inverse video status. This means 26 writes to the serial port - either 0x00 or 0xff.

I'm still thinking hard about this...

[SiriusHardware]

You can't just manually 'set' the state of the video output to the required state (black or white) and leave it that way for the duration of the blank line? That might buy back some time.

[Karen O]

Hi SH, yes I could do that - thanks for that tip.

The trouble is, graphics mode doesn't have a blank line that I can claw back like character mode.

If the top half of the picture is graphics, and the bottom half characters, then there's no time to be found for the preparations for the lower half of the display.

[SiriusHardware]

Well, assuming that there is always a blank line under any row of characters, even the last one, there will always be a black scan line between the last row of characters in the upper half and the first row of pixels in the lower half.

[SiriusHardware]

Oh, sorry, I read that situation backwards.

Graphics followed by characters, yes, does pose a problem. However I think in that situation you certainly could get away with inserting an extra blank scan line after the last graphics pixel line. Nobody would expect (or even want) the bottom edges of the pixels in the upper half to 'touch' the top edges of the characters in the lower half anyway.

I'll try my 'mockup' again but with a line of text on the very first line to see if there is a gap between the last scan line of the graphics and the first line of the text when rendered by the real VDU.

[SiriusHardware]

OK:

If all text, put a blank scan line immediately below each character row (as is normal)

If text upper half, graphics lower half, put a blank scan line underneath each line of text (as per normal). This gives you a blank line between the end of the text and the beginning of the graphics.

If graphics upper, text lower, put a blank scan line -above- each line of text rather than below (and an extra blank line below the last row of text if you want). Is that doable?

[Karen O]

Graphics followed by graphics is also a problem.

I plan to use an 8 scan line cycle. One set of 8 scan lines will fetch data for the next 8 scan lines. Trouble is the last 8 scan lines of the top half. They'll fetch data alright, but not necessarily from the page that the lower half needs to source from.

[Slothie]

Originally Posted by Karen O

Graphics followed by graphics is also a problem.

I plan to use an 8 scan line cycle. One set of 8 scan lines will fetch data for the next 8 scan lines. Trouble is the last 8 scan lines of the top half. They'll fetch data alright, but not necessarily from the page that the lower half needs to source from.

Is it not possible to get the 8 bytes for graphics during the back porch/hsync/front porch period? I know its tight but from the pictures it doesn't look like the display fills the whole 'display' area (~52uS) and theres ~12us of back/sync/front as well.

I'm just throwing it out there, I've not done this and understand its like juggling cats.

[SiriusHardware]

At the beginning of each frame, just after the frame sync pulse, read the state of PS1-PS4 and the control inputs, then momentarily assert TOP PAGE and read PS1-PS4 and the control inputs again to see which PS inputs and which other inputs are changed by TOP PAGE.

This will give you (in advance) the base addresses of both parts of the screen and will also tell you whether you are expecting all graphics, all text, or a mix, and in which order.

[Karen O]

First light!

It can only do text at the moment. I've also implemented reverse video but it doesn't show up well enough to photo successfully.

The display is showing nonsense due to the floating data bus (there's nothing in the EPROM socket). Hopefully when Tim's programmed 2716 arrives it'll display something more recognisable

[Karen O]

This will give you (in advance) the base addresses of both parts of the screen and will also tell you whether you are expecting all graphics, all text, or a mix, and in which order.

That's exactly what I do! I assert TOP unless SWAP is asserted, read the states of PS1-PS4 and also the flags. This gives me full info on the top half of the display.

I then do the same but with opposite sense for TOP to get the bottom half details.

[Slothie]

Originally Posted by Karen O

First light!
...
The display is showing nonsense due to the floating data bus (there's nothing in the EPROM socket). Hopefully when Tim's programmed 2716 arrives it'll display something more recognisable

You could just hotwire the address pins to the data pins....

Very impressive progress!