Re: Ortonview PCB
 

Indeed yes, we wave goodbye to the cap fix. I've had it running for something like five hours now without a single bit of corruption of any memory that is not being intentionally written to. I built mine on a stamp sized bit of stripboard placed copper up, but you could place the '74 in the position intended for U5 or U6, cut any unwanted PCB track connections to the pads and wire the mod up there.

On any subsequent revision of the PCB the buffers can be removed and the '74 placed where they were, leaving the U5 and U6 (noise generator) circuitry intact.

Re: Ortonview PCB
 

I am fairly certain that a 74ls74 would also work in the memory corruption fix, as its not dependent on RC delays.

The 74HCT74 fix for the white line seems to work, except for inverse graphics mode, but I don’t think thats a very usefull mode anyway. I think my wiring to a piece of proto board was too long which introduces noise in the video, but that would probably be ok if it was included in the layout.

I was wanting to try the 877A to see the issue, then maybe try adding a single NOP, but been too busy with work and travel over the holidays. Also spent too much time on an idea for a ttl processor, using 74AS870 for registers before realising that its not quite dual port registers and decided it wasn’t going to give a usefull ISA without serious workaround in the register addressing. I managed to find time to assemble one of Phil’s PICL boards, but still not programmed the 877 and tested it yet.

Re: Ortonview PCB
 

I agree that inverse (black text on white or black pixels on overall white) is not especially attractive but Karen went to a lot of trouble, in her final days, to emulate that and the other features of the SOC VDU exactly so I think it really has to work as advertised.

If you can somehow make your 74 based white line remover 'case-sensitive' so that it only acts when there is black (not white) immediately following the sync pulse on any given line, that would be great.

It's interesting that all of the original 'classic' ZX computers actually favoured black text on white and I think that was because they were expected to be used on low resolution TV displays (rather than monitors) where spindly white text on a black background might have been a lot harder to read.

Re: Ortonview PCB
 

It might be possible to drive the preset input of the 74HCT74 using a delayed PIC-24 input, inverted and combined with the PIC.26 using a nand gate. This would be relying on the race condition between preset and reset of the 74HCT74, really bad design practice but that makes it more fun.

It also adds more gates, which kind of spoils it.

I’ll keep thinking, probably won’t be able to stop thinking about this now until I think of a neat way to do it.

Re: Ortonview PCB
 

I don't know if it helps to remember that inverse mode doesn't actually need fixing because when any given line is being rendered in inverse, the bright line just blends into the overall white background.

It's only when a line is being rendered in non-inverse / normal mode that it requires some kind of active solution.

Re: Ortonview PCB
 

Yes, sorry about that my cancer reared its head again and I've been busy having tests etc. Not serious, just time consuming. I have looked at it somewhat, I can get it to produce a stable screen, its just not reading the memory for some reason, and locking up the MK14, so I probably have some more config changes to make. I'll be starting treatment soon so will have plenty of time to get out my logic analyser!

Re: Ortonview PCB
 

Sorry to hear you are in the wars again. Obviously you should be looking after yourself first and worrying about this later.

I wonder if there would be some mileage in knocking up an 887-->877 pinout adaptor to reverse that port swap which Karen did ultra-last-minute when she realised that her programmer didn't 'do' the 887. She must have had a very good reason to feel she needed to do that.

Just to recap, although the 877 and the 887 ostensibly have the same pinout, Karen altered her design and code to swap two of the 8-bit ports over when she went from what was going to be the 887 originally, to the 877.

If we have ambitions to use the 887 instead, it may be necessary to swap those ports back over (and change the code accordingly).

Re: Ortonview PCB
 

Yes, I was wondering about that. If the 887 works then there'd really be no reason to use the 877/877A so a new PCB layout wouldn't be a problem. I'll look into it as see if I can work out what Karen's thinking was; unfortunately she was a lot more knowledgeable about PICs than me :)

Re: Ortonview PCB
 

Here's the turning point from the original VDU thread:

Now the question is, what architectural improvements or changes had been made by the time the 887 came along? Are all of the 887 ports TTL compatible? It would seem odd for Microchip to maintain the overall pinout and yet move the only TTL compatible port from port B on the 877 to port D on the 887 - port D being the 887 port which Karen had originally planned to use as the data bus. She may just have chosen 887 port D as 'D for Data', a handy mnemonic reminder of the port's purpose.

Re: Ortonview PCB
 

I've just had eyeballs on both datasheets and it looks as though the port D pins on the 877 are Schmitt Trigger in input mode, whereas the port D pins on the 887 are TTL in, as are the port B pins. So - it may not be necessary to swap the ports back, unless I've missed something (highly likely).

Re: Ortonview PCB
 

Port D input mode is schmitt trigger with input levels of 0.2Vdd to 0.8Vdd, so would not be compatible with TTL input levels from the MK14. So Karen made these address outputs instead.

If the 887 is TTL level inputs on both B and D then I would agree with Sirius that there is no reason to swap them back, which would maybe allow the same pcb layout for both chips.

Re: Ortonview PCB
 

A couple of (part) tables from the 887 datasheet suggesting that the Port B pins and the Port D pins on the 887 are TTL inputs (when set as inputs) and CMOS outputs (when set as outputs).

Karen had originally intended to use the 887 port D as the bidirectional data bus port but hopefully port B on the 887 is OK for this as well.

Re: Ortonview PCB
 

Slothie, in #521 you posted a link to your work in progress for conversion to 887 from 877. Is that still active and the latest, or is there an unpublished later version?

Re: Ortonview PCB
 

I think thats the latest, its certainly the one that works "best". I think I tried something else but that made it less stable, so I reverted it.

Re: Ortonview PCB
 

I forgot to mention that The latest version of this branch (PIC16F887) is available publicly at https://bitbucket.org/IanKRolfe/orto...src/PIC16F887/

Re: Ortonview PCB
 

Just to recap, I think you said that it generates a stable video image but doesn't appear to be reading the data, at least from an MK14 or replica. If so I'd be interested to see if it can render an image from an EPROM like Karen's prototype, or whether it works when you do your trick of connecting the data lines to the lower address lines.

Re: Ortonview PCB
 

Because it was crashing the MK14, I was running it unconnected and configured to read from the RAM. The ram chip I was using defaulted to alternate bytes being 0x00 and 0xFF but I was just seeing all zeroes ('@' in text, blank in graphics). I didn't try connecting the data and address lines.

I'm going to dig it out and give it another look at, I came across my USB logic analyser the other day and that helped a lot with seeing the timing problems that Mark ultimately found a fix for. It had been put somewhere "safe"!

Re: Ortonview PCB
 

One stunt you could try is to put a programmed E(E)PROM (2716? 2816?) in place of the 6116 to give the OV known fixed memory content that it should be rendering from rather than the expected pseudo-random content of the RAM. That would save mucking about with wiring data lines to address lines etc.

Re: Ortonview PCB
 

Slothie- which assembler / which version are you assembling the .asm file with? I'm trying to use MPLAB 8.33 but it throws up three undefined label errors. Rather than tinker with the labels to get it to work I should probably use what you are using (some version of MPLAB X perhaps?)

Re: Ortonview PCB
 

I got it to assemble as written / unaltered with MPLAB X V5.35 - the IDE itself has me scratching my head as it's so different from pre-X versions of MPLAB that I don't even know if it is generating a hex file or if it is, where it's putting it...

Edit: OK, I found it (in Windows environment) in the path

C:\Users\youruseryame\MPLABXProjects\projectname.X \dist\default\production

as

Projectname.X.production.hex

I can't believe how hard that was to find out. No wonder I don't usually use this version of the MPLAB IDE.

Re: Ortonview PCB
 

I use MPLAB X as you have found out :) I was "converted" many years ago when I wanted to use a PIC that was only supported by the new IDE...

It is very different to the traditional IDE and pretty much forces you to create projects (no simple one-file assemble and go).

Re: Ortonview PCB
 

Great news! I found my schoolboy error, I'm not setting the bank flags right (or at all) when configuring out the new analogue features. Changing the reset bit to:
makes it work as intended, I now have Mr Sinclair staring at me from my screen. There does not seem to be any glitching in graphics mode, it all seems fine. I'm getting a tiny bit of "snow" but no more than with the '877 controller, and we've already discussed that may just be a decoupling problem.

The new version is uploaded to Bitbucket on the link in post #565

NB: I was also able to verify that the programming header on the PCB works to allow programming of the PIC without removing from the board.

Re: Ortonview PCB
 

Oh, you spoilsport (says he, secretly very relieved that you found that first). I confess the PICs are not my first love for assembly language and that tedious bank switching malarkey to access different blocks of registers is one of the reasons why.

Great to hear that the graphics shudder problem does not seem to be present when using the 887 - I'll try it and hopefully anyone else who is in a position to do so can try it as well.

Just to be clear, which original firmware version did you port this from? #692, or...?

If all pin usage is as before, this should mean that the pin which was dedicated to MCLR on the 877 should now be free to use as I/O (RE3) and if so there is the possibility to use that to generate a context-sensitive bright line blanking signal. I don't want to steal TTL-wrangler Mark's thunder, but that is obviously the right way to do it with the least additional components, if it can be done.

Re: Ortonview PCB
 

Yes, sorry, I know how much you were looking forward to it, but I just couldn't help myself!

This is based on FW #692.

The problem with using RE3 is that it is input only, so if we need it as an output to force blanking then we;d have to repurpose one of the other pins that is only being used as an input and use RE3 to replace it. That woud, of course, require PCB hacking and possibly make the reprogramming header problematic. Nothing that couldn't be worked around though, I suspect.

When I first connected up to the MK14 I noticed some ghosting on the LED display, so there may still be some timing issues to counter, but after a reset I haven't seen it return. I guess that is why some exhaustive testing by several of us would be a good idea.

Re: Ortonview PCB
 

Agggh! I didn't notice that. RE3 could certainly be reverted to its original intended function of reading one of the Page Select lines, but then as you say, some other pin would have to be multiplexed instead.

And this is with Mark's memory corruption busting patch still in place, and no capacitors on the address lines?

Re: Ortonview PCB
 

By the way, it looks as though you've got a nice printed bezel surrounding the keys on your issue VI now - is that being used with your printed keys or with the original tact switches and caps?

Re: Ortonview PCB
 

It's using my printed caps with normal tact switches underneath. The Bezel should work for the green and clear caps I think you have as I made them the same size - I'll check, if they do I'll send you one.

Re: Ortonview PCB
 

I'll PM you about that.

Re: Ortonview PCB
 

Good news on getting that working, well done.

It would be good to maintain compatibility with the 877 though and just add the 887 as an extra option to make sourcing easier.

I had a couple of ideas on the white line blanking in hardware, but didn’t like the complication and the extra gates required. I’ve been thinking of a possible combination of hardware and software but need to check the signal timing first to make sure its likely to work. I think still using the earlier blanking circuit but adding an extra falling clock transition on the clock output of the pic to set the initial line condition.

It’s probably going to be end of next week before I can take a look, snowed under with work, and clearing actual snow.

I did source a couple of 877A and 887, from aliexpress, the 877As have programmed ok, not tried the 887s yet, so hopefully I can try and verify with Slothie’s 887 code, again when I get time.

Mark

Re: Ortonview PCB
 

I move that we settle on one device only and stick to it, because the 887 can't be programmed with the 877 code and the 877 can't be programmed with the 887 code... (can it ??) - if you really mean to support both devices you then end up having to maintain two parallel forks of the code. Any tweaks made to one then have to be made to the other as well.

With the 887 apparently being easier to get and there being only a single version (no 'A' variant') I would suggest that the 887 is really the better choice.

Re: Ortonview PCB
 

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).

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

This is the hex I used.

Re: Ortonview PCB
 

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

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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?

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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?

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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).

Re: Ortonview PCB
 

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?

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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

Cheers

Mike T

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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.

Re: Ortonview PCB
 

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).