Ortonview PCB

[Slothie]

The assembler sets symbols to define the processor in use (__16F877, __16F887), so it should be possible to make one source for both processors, especially since the differences are so minor. If we want to add in code to do blanking, that would be a 887 only option due to the no of i/o pins.
Since the 887 is currently in production, cheap and easy to find I can't think of any good reason to worry about giving support the 877 if its not trivial, because it is getting hard to find and costs twice as much when you do - the code in FW#692 would still work for that anyhow (all versions are available on the Bitchute repository).

[SiriusHardware]

Just tried to take a moment to test the code as modified by Slothie for 887 and unfortunately, although the code programs OK (with PicKit2) it stops the MK14 dead. The most likely explanation is my unfamiliarity with MPLAB X, resulting in the assembled code being just plain wrong.

I went to poke around at the link given in #565 and although I can find the .asm file from which I apparently unsuccessfully assembled the hex, I can't find the assembled '887' version hex there.

Ian, could I ask you to post the known working assembled hex you made from that .asm in a .zip file here? I just need to verify that my 887 - brand new as far as I know - is actually working, then I'll try to work out what I'm doing wrong with MPLAB X.

[Slothie]

Originally Posted by SiriusHardware

Ian, could I ask you to post the known working assembled hex you made from that .asm in a .zip file here? I just need to verify that my 887 - brand new as far as I know - is actually working, then I'll try to work out what I'm doing wrong with MPLAB X.

This is the hex I used.

[Slothie]

p.s. the hex file in Bitbucket isn't the one for the version in the branch - I forgot to update it.

[SiriusHardware]

Just noticed this Slothie, thanks. It's a bit late for me to follow through this evening but I will have another bash at it tomorrow evening.

[SiriusHardware]

Yes, the PIC16F887 code attached to #583 is good and I can confirm that there is thankfully no side-to-side shudder in graphics mode. I am again struck by how beautifully clean and stable the image produced by Ortonview is. Mine 'just works' straight away from power on, no need for a post-power-on reset but my issue VI and Ortonview are heavily populated with supply decoupling capacitors including two highish value (10uF?) SMD ceramics right on the supply pins of the PIC.

I'll have to have a look at my MPLAB X project settings and try to work out why my version of the assembled code didn't work.

A while back we mused over the idea of making a few more images for the MK14 VDU / Ortonview to display, you (Slothie) used the Linux image utility GIMP to reduce a chosen image to a 64 x 64 monochrome .BMP.

How did you do that again?

[Mark1960]

I took another look at the video, sync and clock outputs of the PIC. I think the circuit of #519 could be made to work to remove the white band with a firmware mod.

As it is now the pic pin 25 is high when the serial output is not active. Then when the serial output is initialised pin 25 is pulled low and the data output initialises to high, which gives us the white band until the data output begins and pin 25 starts to clock data into the ‘74.

Possible solution is firmware mod as follows. Before init of the serial output, set the data output low for normal or high for inverse, then set pin 25 low, and then initialise the serial output. We might also need to set pin 25 high again at the end of each line, I’m not sure if the low state of pin 25 would be remembered when the serial output is disabled.

This might also allow removal of the RC network, which was to stop the falling edge of the clock at initialisation from clocking the initial state of the serial output into the ‘74.

[SiriusHardware]

I'm seriously considering making a third Ortonview, this time based on one of the Microchip '44-pin demo' boards which came with some versions of the Pickit2 and the Pickit3. I have several of them. The 44 pads will accept 44-pin QFP versions of several devices including the 877 / 877A and 887.

Using one of these would allow the video-out, sync, bright line blanking and Page select 4 all to have their own pins. Obviously, it is not easy to swap devices around on these solder-only boards so I'd probably pick the 887 and stick with that.

Mind you, given the time it seems to take me to get onto anything at the moment ... don't wait up.

[Slothie]

Originally Posted by SiriusHardware

A while back we mused over the idea of making a few more images for the MK14 VDU / Ortonview to display, you (Slothie) used the Linux image utility GIMP to reduce a chosen image to a 64 x 64 monochrome .BMP.

How did you do that again?

I adjusted the brightness/contrast, cropped and scaled to 64x64, then used the Image->Mode->Indexed... dialog, selecting "use black and white 1-bit pallette" and the "Floyd-Steinburg (reduced colour bleed)" algorithm (or whatever looks best).

If it looks wrong, use control-Z to undo, adjust the brightness/contrast and try again.

I think I then just used "File->Ecport As" and changed the file extension to .bmp, I might have had to change the image settings to make it monochrome?

[SiriusHardware]

Thanks Slothie - now I suppose we just need to come up with some suitably relevant images to grab and downscale.

Attached, offscreen graphic image from OrtonView_887. This was just crudely hand-drawn.

No left-hand bright line because I have the (CRT monitor) image shifted about 15% to the left, placing the bright line off screen.

[Timbucus]

Nice picture of the NatSemi logo! I have still not had chance to make the mods even though I have the chip sat on the Ortonview on my desk.

[SiriusHardware]

Not offscreen yet, but a 64 x 64 pixel homage to the MK14 manual cover (The actual writing on the lower half of the manual cover would be impossible to represent at such a rough pixel resolution).

[Timbucus]

That looks lovely but, I wish they had always had the K as a Capital as it stands for Microcomputer Kit rather than Mark. The box cover actually had a dot after the k as well to rub salt in the wound. The mains adapter used MK14 as did the adverts. Maybe as it is not on a slant in this instance as on the manual, it would look better as a Capital, he says as he does not have to make the change?

[SiriusHardware]

I took the font and format exactly the way it is written on the manual cover and on the lower edge of the original MK14 (See attached detail #1). I'm sure this original arrangement is the reason why people frequently took it for 'Mark' rather than 'Emm Kay', but for better or worse, the lower case 'k' is authentic at least for the manual.

I did originally mean to have 'Mk14' on the same roughly 15 degree upward slant as the parallel lines, but try as I might I could not get the font to look right due to the very coarse pixel resolution, so I had to settle for plain horizontal text. Attached #2, one of my earlier attempts. After I cleaned the rotated text up while doing my best to keep it looking approximately like the original, it was no longer quite at the same angle as the diagonal lines. If you prefer the slanted version I could possibly 'fix' the slant mismatch by changing the slope of the parallel lines to match the slope of the text, rather than trying to rotate the text a few degrees clockwise.

If you want to have a play with it I'd be happy to email you the original images and you can see what you can come up with. I'm just thinking that the simplest VDU 'demo' of all is a slideshow, the downside being that we need to have a few images for it to display. I welcome any suggestions for images for that purpose but it has to be something which can realistically be represented in 64 x 64 pixels, and ideally somehow relevant to the MK14.

You could use a modified, continually running version of send14 with a consecutive list of image hex files to upload - if you you didn't want to see them loading you could load them alternately at 0200-03FF and 0400-05FF in extra-extra RAM and have the script control the state of the relevant page select line via an 8154 or flag output so that the current image is displayed from one area of RAM while the next image is being loaded into the other.

[Timbucus]

I think you are right it looks better straight than on a slant and as you say it is authentic to the Manual and Box - I was merely musing their own lack of typographic consistency.

One I did wonder about was a version of the stylised early board in the first advert that might make an image with the £39.95 in a single pixel price. I may have a play with that one.

I had wondered about how many images could be fitted in RAM with some simple RLE encoding as maybe the effect of filling active video RAM would look like a nice wipe effect... I wish I had some time.

[Cobaltblue]

Thread re-opened as requested by SiriusHardware for new revision of pcb.

Cheers

Mike T

[SiriusHardware]

In another current thread Slothie mentioned that he was working on a revised Ortonview PCB incorporating some modifications which, thanks to the flexible / experimental nature of his original version of the PCB, we know work, and removing some features which proved unnecessary or ineffective. I've asked for this, the original Ortonview PCB thread to be re-opened so that the ongoing development of this hardware version of Ortonview can all be followed in one thread.

My thanks to Cobaltblue for re-opening the thread.

[Slothie]

Well, since Cobolt has been so kind, and I've been trying to keep myself occupied now that my chemo isn't kicking me so hard, I thought I'd share progress here and not pollute the other thread.

As I menttioned, I've added the 74LS74 to get the NENIN timing right, removed the redundant buffers, and had a go at getting the battery backup working (I know this wasn't a priority for others, but its a feature I really want so.....)
The Noise generator is still there, because I want to make some VDU games at some point.
There are a few spare gates flying around, and by moving the P3 option to the MCLR pin (which can be done on the '887) I could free up the RE2 pin for blanking the output of RC5 which during setup for the video bitstream gets forced to 1. The problem is to see how this can be done, I'm not against putting in an extra chip if necessary but so far the actual Ortonview is pretty close to Karens original design and I'd like to keep it that way if possible. And due to the way Karen had to put in repetative blocks of code for timing reasons means its going to be easy to miss something and upset the timing.....

Here's the schematics and a render of the progress so far - a lot of testing has to be done, but I wanted to catch up with the work I did at the end of last year while I can still vaguely remember what that was.

[SiriusHardware]

If I understand the operation of the composite-out circuit correctly,
RC5 and RC7 both at logic 0 turns Q1 off, leaving the video output at the lowest voltage it ever gets to, so,

RC7=0 and RC5=0 gives you the bottom edge of the sync pulse.
RC7=1 and RC5=0 turns Q1 partly on, giving black video level at Q1 emitter
RC7=1 and RC5=1 turns Q1 on harder, giving peak white video level at Q1 emitter.

While the unwanted vertical white line is 'in progress' we need to prevent the RC5 output from reaching R10 so that Q1 only outputs black level regardless of the state of RC5 and, to make it more complicated, this must only happen when the video line is being rendered in Normal, not Inverse mode.

One way to do this might be to put a FET between RC5 and R10 and use a spare PIC output to control the FET to gate the video output off during the bright line period. I don't know if this is practically possible because I don't know whether a FET deployed in this way will work at video frequencies. Also we don't want the FET to reverse-conduct when RC7=1 and RC5=0.

[Slothie]

If its a MOSFET it will reverse conduct, due to the body diode....
The other option could be to use the 2 spare "NOR" gates to switch the output of RC5 as mentioned.
Could also use a transistor and a diode to do the same job, I'd have to test it to see what effect the diode has on the video level - even a schottky diode will drop 0.2v so the resistance might need tweaking. (see diagram).