UK Vintage Radio Repair and Restoration Discussion Forum

UK Vintage Radio Repair and Restoration Discussion Forum (https://www.vintage-radio.net/forum/index.php)
-   Vintage Computers (https://www.vintage-radio.net/forum/forumdisplay.php?f=16)
-   -   Ortonview PCB (https://www.vintage-radio.net/forum/showthread.php?t=181460)

Mark1960 20th Jan 2022 6:18 pm

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.

SiriusHardware 21st Jan 2022 4:00 pm

Re: Ortonview PCB
 
2 Attachment(s)
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.

SiriusHardware 22nd Jan 2022 5:44 pm

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?

Slothie 23rd Jan 2022 1:26 am

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1442896)
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?

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.

Slothie 23rd Jan 2022 9:29 am

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/

SiriusHardware 23rd Jan 2022 10:12 am

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.

Slothie 23rd Jan 2022 10:24 am

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1443041)
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.

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"!

SiriusHardware 23rd Jan 2022 10:31 am

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.

SiriusHardware 24th Jan 2022 6:43 pm

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

SiriusHardware 24th Jan 2022 8:10 pm

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.

Slothie 25th Jan 2022 5:08 am

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

Slothie 27th Jan 2022 12:12 pm

Re: Ortonview PCB
 
2 Attachment(s)
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:
Code:

; Reset
        ORG        0
        ;+changes for '887
        ;Make sure analogue & compare functions disabled (new to '887)
        BANKSEL CM1CON0
        CLRF        CM1CON0                ; bank 2
        CLRF        CM2CON0                ; bank 2
        BANKSEL ANSEL
        CLRF        ANSEL                ; bank 3  Disable analogue ports
        CLRF        ANSELH                ; bank 3
        BANKSEL PORTA
        CLRF        ADCON0                ; bank 0
        ;-changes for '887
        MOVLW        B'00010000'        ; NRDS pullup others free
        MOVWF        PORTA

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.

SiriusHardware 27th Jan 2022 12:46 pm

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.

Slothie 27th Jan 2022 1:14 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1444187)
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.

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.

SiriusHardware 27th Jan 2022 1:37 pm

Re: Ortonview PCB
 
Quote:

The problem with using RE3 is that it is input only
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.

Quote:

When I first connected up to the MK14 I noticed some ghosting on the LED display
And this is with Mark's memory corruption busting patch still in place, and no capacitors on the address lines?

SiriusHardware 27th Jan 2022 1:47 pm

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?

Slothie 27th Jan 2022 1:58 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1444204)
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?

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.

SiriusHardware 27th Jan 2022 3:12 pm

Re: Ortonview PCB
 
I'll PM you about that.

Mark1960 27th Jan 2022 3:52 pm

Re: Ortonview PCB
 
Good news on getting that working, well done.

Quote:

Originally Posted by SiriusHardware (Post 1444187)
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.

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

SiriusHardware 27th Jan 2022 4:03 pm

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.


All times are GMT. The time now is 9:29 pm.

Powered by vBulletin®
Copyright ©2000 - 2022, vBulletin Solutions, Inc.
Copyright ©2002 - 2021, Paul Stenning.