Re: Ortonview PCB
 

I did think that 470 ohms on the Ortonview was a bit low but it seemed to work for Tim and Sirius. My MK14 has a 4.7k resistor as advertised. I might remove the 470 ohm resistor on the Ortonview to see if it makes a difference.

Re: Ortonview PCB
 

I just took a quick look at the pic datasheet, it should be ok to drive 10ma and still provide 3.5v, so even after the voltage drop of the diode it should be reaching ttl logic high.

Re: Ortonview PCB
 

I seem to recall Karen mentioning that PIC pins have quite sturdy output drive, she quoted it somewhere as approx. 50R pulldown to 0V or 50R pullup to +5V when the PIC output was being driven low or high respectively.

Re: Ortonview PCB
 

Worth remembering that the original version of firmware which slowed the machine down a lot did not exhibit the blurred graphics mode problem when EITHER the 877 or 877A were used. The 877A / Graphics mode problem only appeared as a by-product of what Karen did to reduce the amount of time the system was held by NENIN.

Other pin compatible and largely code compatible 40-pin DIP PICs include the 16F887 and the 18F452. Karen actually meant to use the 887 originally because it has more pins which can be used as general I/O pins than the 877 does. Problem was, she found out at a late stage that the programmer she had available didn't support the 887 and with typical ingenuity, found a way to use the 877 with its lower I/O pin count.

We could just try making an MPLAB project set up for the 887 and bringing the code into that to see whether the 887 does or does not run the 'fast' version of the Ortonview code without any problems in graphics mode.

Re: Ortonview PCB
 

Oh, maybe I can try an 887 when I get everything working. They seem pretty cheap on eBay. I have an 877A too, so maybe I could investigate the graphics issue with that one, but that would be a "stretch goal" at the moment!

Re: Ortonview PCB
 

Have jiffy bags, just need to get a couple of them addressed and appropriately stamped up, hopefully this lunchtime if real life doesn't get in the way.

Re: Ortonview PCB
 

Cool! I just need to get this to work lol

Re: Ortonview PCB
 

And they're off!

Open carefully, the smaller return envelope is an exact internal fit inside the larger one I have sent it in, so if you take a pair of scissors to the end you will cut the end off the inner bag as well. I put one of our heaviest populated PCBs in the return bag while it was weighed so hopefully there is weight headroom for three small and three larger unpopulated - if not, it'll be me who gets the underpayment card through the door.

Re: Ortonview PCB
 

Thanks, I'll be careful and cut the flap rather than across the top. I presume you intend me to send 3 of each?

Re: Ortonview PCB
 

Indeed, that's what I have estimated for weight wise, provided the PCBs are not like paving slabs. The populated PCB I used as a dummy load has several relays and an audio transformer on board, so it hopefully weighed more than the 3 + 3 bare boards will.

Re: Ortonview PCB
 

**Update**

Well I tried connecting to my MK14 and it didn't go well, the MK14 crashed. Testing appears to show bus conflicts with the buffers in. I removed the buffers and bridged them using some turned pin headers plugged into the IC sockets, and tried again. This time the MK14 worked but had some corruption in the display, the reverse 'C' Sirius and Tim noted last year. I looked in my components and found some 220pF capacitors, the nearest I could find to the values Tim and Sirius used, fitted them to A11 to A8 on the board and everything seems to be working fine. I'm going to work on loading some of the programs from the other thread and seeing if it works, and then try fitting the INS8154 I have and trying out some of Tims test programs.

Overall, a good outcome (certainly no worse than anyone else). Going to need to experiment with the buffers a bit more. I wish I'd read the old thread a bit more carefully because Mark made a suggestion about enabling the buffers after NWDS goes high and I could have put in provision for that - but it shouldn't be too hard to hack the board about a bit to try something like that.

Re: Ortonview PCB
 

That is excellent news really as you can replicate the results exactly that we did - well done for prototype 1!

Re: Ortonview PCB
 

Re: The comet-tailing - sorry to suggest this but have you tried just turning down the contrast? - there is also often a 'sharpness' setting on both CRT and LCD displays, does adjusting either of those alter the degree of smear?

The video signal is only either deep black or brilliant white, so it's going from one extreme to the other the whole time. As far as the display hardware is concerned, it couldn't be harsher.

Re: Ortonview PCB
 

To be honest I haven't fiddled with it, I replaced the cable with a better one and it improved but that cable was still 5m long. I've ordered a 2m cable that should come in a few days.
Also I didn't have the resistor values for the output stage so I did a LTspice simulation and changed the values to ones I did have, to get the same waveforms, but maybe I've not taken something into account. I've got some resistors on the way to fit and maybe that will improve things, but I will adjust the TV a bit - when watching normal TV its very saturated and so maybe contrast needs adjusting. But I'm mostly happy that functionally things are going well, and I do at least have something I can take measurements from without worrying about wires falling out! The digital signals (luminance, sync) are good, I've just got an analogue problem.

Edit: Its also true to say it looks a bit worse in the photo than in real life.

Re: Ortonview PCB
 

I think that might have been my suggestion that we stop the ortonview from interrupting a write cycle by using an AND gate between NWDS and NENIN from ortonview. Looking more closely at the timing it might still be possible for a write cycle to start and then be terminated due to a delay between NENIN and NWDS. I was planning to try and measure the timing in more detail and try and determine what clock edges to reference for each signal.

Controlling the buffers might need a delay between asserting NENIN and enabling the buffers, I think Karen had a delay before setting the address outputs active, but I don’t think the original mk14 display had that.

Re: Ortonview PCB
 

Is the PCB generated directly from the circuit diagram? (I would expect so). I've just been going over the diagram again and I can see nothing obviously wrong there, checked the pinouts of the buffers and so on and so forth.

Regarding enabling of the buffer signals via NENIN alone, obviously the edge of the NENIN signal is what tells the SC/MP to relinquish the bus and as we remember it takes a significant amount of time to do that, so maybe the buffers are passing what they are seeing on the PIC pins - even though the PIC pins are in input mode - as soon as NENIN changes state, and therefore before the SC/MP has had time to finish what it is doing and get off the bus.

Karen's code no doubt waits for a period of time after it sets NENIN high before swapping the port directions to apply the address output drive to the system address bus, but here the buffers, when fitted, will immediately output whatever state they see coming onto their inputs from the PIC pins (high, when the PIC ports are still in input mode?) as soon as they are enabled by the rising edge of NENIN.

We could trying delaying the enable signal to the buffers with a simple RC circuit in the output from U1D to the enable inputs of U7 / U8 (series resistor, capacitor up to +5V).

Edit: Crossed with Mark.

Re: Ortonview PCB
 

Yes, the PCB is generated from the schematic. The correct schematic is in the notes but isn't very clear, so here it is as its own PDF.

I was looking at the code the other day, and it is a little complicated because the code for controlling the address bus and NENIN is duplicated in four or five places (one is slightly different due to timing) so I will have to look at it a bit closer.

Looking at the MK14 schematic diagram, it looks like the buffer enable and NENIN are not timed together, except that NENIN is always high when the bus is being driven, but its hard for me to tell exactly how it is timed. I really need to find a logic simulator that can cope with RC delays to see how it works, or get my hands on a replica of the original to take measurements from. But that would be another project.

Re: Ortonview PCB
 

Oops forgot to attach the schematic!

Re: Ortonview PCB
 

An RC would delay both turn on and turn off of the buffers, so the buffers would remain on after NENIN is switched back to low. Unless only one of the buffer gate inputs is delayed by the RC, then it would delay buffer turn on but not the buffer turn off time.

Re: Ortonview PCB
 

Maybe we could twist Tim’s arm to scope that. Unless he already did when Karen was working on the timing?