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.