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)

SiriusHardware 28th Jul 2021 9:49 pm

Re: Ortonview PCB
 
Quote:

I think Karen had a delay before setting the address outputs active, but I don’t think the original mk14 display had that
She did, and the SOC VDU must have had a similar post-nenin-edge delay in hardware to allow the SC/MP time to get off the bus before jumping onto the address bus itself. Just on a quick look around, the onset of the output of the signal to NENIN itself is actually delayed by an RC network on one of the inputs of IC5, namely R15 / C11. There's also the strange 74L86 which as Slothie once pointed out has a propagation delay far longer than standard TTL, so maybe that is intentionally brought into play for delay purposes.

Timbucus 28th Jul 2021 9:50 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Mark1960 (Post 1393675)
Quote:

Originally Posted by Slothie (Post 1393672)
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.

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

Probably not a lot of arm twisting needed to get the VDU's out - probably no time until this weekend though due to work and other family commitments.

SiriusHardware 28th Jul 2021 9:54 pm

Re: Ortonview PCB
 
During the original troubleshooting phase we did a lot of scoping of NENIN vs. other signals including NENOUT which I seem to remember is the signal which shows when the SC/MP has relinquished the bus in response to a request on NENIN. From that, we were able to arrive at a likely maximum interval between NENIN rising and the buses being relinquished.

That's the delay we need to insert between the rising edge of NENIN and the buffers being enabled.

SiriusHardware 28th Jul 2021 10:10 pm

Re: Ortonview PCB
 
2 Attachment(s)
Ah, here we go. (Image 1). This shows the SOC VDU relationship between NENIN (top, active high) and the buffer enables (bottom, active low).

Bear in mind that on the SOC VDU NENIN and the buffer enables are enabled for a whole video line at a time, but this still shows a substantial delay between NENIN being taken high and the buffer enables being taken low.

The second image shows the delay between the rising edge of NENIN, output from the VDU, and the response from the SC/MP on NENOUT. In theory, you can not try to go onto the bus yourself until this delay has elapsed. It looks like around 160-170ns to me. Of course NENOUT is not available to the VDU so the rising edge of NENIN needs to be followed by a fixed delay slightly greater than the maximum time it takes the SC/MP to let go of the bus, after which delay the buffers can be enabled.

SiriusHardware 28th Jul 2021 10:40 pm

Re: Ortonview PCB
 
Quote:

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.
True, I just hoped we might get away with it as it will also take a certain amount of time for the SC/MP to come back onto the buses after NENIN is released low.

Quote:

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.
Unfortunately it's not two enable inputs acting in NAND fashion to enable or disable the whole buffer IC - instead, each active low enable independently controls three of the six buffers in the chip.

Mark1960 29th Jul 2021 12:44 am

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1393689)
Unfortunately it's not two enable inputs acting in NAND fashion to enable or disable the whole buffer IC - instead, each active low enable independently controls three of the six buffers in the chip.

74ls365 has two inverted inputs to an AND gate to enable the six buffers.

74ls367 has separate enable for a group of 4 and a group of 2.

Slothie has connected both enables together so could use either of the above.

Mark1960 29th Jul 2021 1:06 am

Re: Ortonview PCB
 
Scope plots in #104 for NENOUT is close to the datasheet, but should be a maximum of 150ns.

There would be a problem using NENOUT to gate the buffer as NENOUT is also high whenever the 8060 is using the bus.

Its not very clear in the 8060 spec that each memory access is 2 micro cycles. Its more obvious in the sc/mp technical manual that every instruction starts with a two microcycle instruction fetch. We might have just got away with a two micro second delay for the 8060 to finish using the bus and use NBUSRQ to stop bus access at the end of the current memory cycle. Unfortunately the ILD and DLD instructions would not release the bus until after 6 micro seconds as the bus is not released between the read and write cycles.

SiriusHardware 29th Jul 2021 7:09 am

Re: Ortonview PCB
 
Quote:

74ls365 has two inverted inputs to an AND gate to enable the six buffers.
Yep, I must have been tired when looking at the pinouts last night. You could maybe also use a diode across the R of RC to make the delay asymmetrical, so that disabling is faster than enabling.

Quote:

There would be a problem using NENOUT to gate the buffer
Using NENOUT directly has to be ruled out simply because it is not available on the edge connector of any MK14, not even the issue VI. It provides us with a good indicator of how long any NENIN->BufferEnable delay may need to be, but that's all.

SiriusHardware 29th Jul 2021 7:17 am

Re: Ortonview PCB
 
Quote:

Scope plots in #104 for NENOUT is close to the datasheet, but should be a maximum of 150ns.
At what CPU clock frequency? My Issue VI (from which those waveforms were taken) has a 4.00MHz crystal fitted so that it can be used with my SOC VDU.

This is another variable we need to be aware of: Many people may be running at 4.43MHz - The only reason anyone ever changed it to 4.00MHz was to make the system work with the SOC VDU.

Slothie 29th Jul 2021 9:28 am

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1393707)
Quote:

74ls365 has two inverted inputs to an AND gate to enable the six buffers.
Yep, I must have been tired when looking at the pinouts last night. You could maybe also use a diode across the R of RC to make the delay asymmetrical, so that disabling is faster than enabling.

Quote:

There would be a problem using NENOUT to gate the buffer
Using NENOUT directly has to be ruled out simply because it is not available on the edge connector of any MK14, not even the issue VI. It provides us with a good indicator of how long any NENIN->BufferEnable delay may need to be, but that's all.

It should be pointed out that in the "master plan" the r1.3 board was going to have NENOUT on pin a30 of the connector (next to NENIN), and that r1.2 boards can be modded thus..... :) However I don't see there being an r1.3 board any time soon unless a pressing need for some other change is found.

The instruction cycle of the PIC is 250nS with a 16MHz clock, so provided the software isn't putting NENIN high and enabling the buffers at the same time it will have at least that delay. I think the problem with the PCB is that I *don't* delay enabling the buffers. I'm going to be looking into this.

Slothie 29th Jul 2021 9:31 am

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1393711)
Quote:

Scope plots in #104 for NENOUT is close to the datasheet, but should be a maximum of 150ns.
At what CPU clock frequency? My Issue VI (from which those waveforms were taken) has a 4.00MHz crystal fitted so that it can be used with my SOC VDU.

This is another variable we need to be aware of: Many people may be running at 4.43MHz - The only reason anyone ever changed it to 4.00MHz was to make the system work with the SOC VDU.

Its not clear if the delay is clock related or just propagation delay, but 150nS should be safe for faster clocks I would imagine.

SiriusHardware 29th Jul 2021 11:48 am

Re: Ortonview PCB
 
Those pads you originally provided for the ICs of the noise generator could come in pretty handy for any extra gates you might need...

Slothie 29th Jul 2021 12:02 pm

Re: Ortonview PCB
 
Noooooo! Not my noise maker!!

SiriusHardware 29th Jul 2021 12:30 pm

Re: Ortonview PCB
 
I would honestly just try an RC or RC+diode in the line between the enabling gate and the enables of the buffers, the diode being a bypass for the R so that it slams the enables back off more quickly when NENIN goes back low.

I wonder whether Karen is looking down on us now, arms folded, fingers strumming on her elbows and a wry look on her face. We'll never know whether she would have been pragmatic enough to accept the four capacitor bodge as an acceptable solution, especially as it keeps the 'extra component' count, that is, major components in addition to the PIC, very low.

In the Mk1 version of her PIC14 she noticed a problem where the driver transistors for the display commons weren't switching fast enough and while she suggested an intermediate solution using a buffer IC, that had its own problems because the buffer outputs were totem-pole type and they were liable to clash when two keys on different columns were pressed at the same time. She then went back to V1 and put capacitors across the base resistors of the driver transistors - so fixing little problems with capacitors is an entirely authentic Karen method.

Slothie 29th Jul 2021 1:14 pm

Re: Ortonview PCB
 
One possible solution that I'm thinking of is to cut the 3 tracks that link pins 1 & 15 on the buffers to separate the enable pins, and put a RC circuit between pin 15 and pin 1 so that on the falling edge of the inverted NENIN signal (from U1d Pin 13) pin 1 goes zero ~150nS after pin 15. On the rising edge when NENIN is removed the buffer will immediately disable because pin 15 goes high. A 1k resistor and 150-200pF capacitor should be about right.

But before I start hacking away at the PCB I think I will remove the loading capacitors and see if there are any tweaks I can make to the timings in the software. Given that it originally worked without problems but was slow because it took up too much bus time, then there should be some tweak to make, and I think if Karen had been given the time to look into it she would have solved it in the software, but she was up against an unmovable time limit...

This was my plan for making the board in the first place. But the good news is that it does work with the capacitors as you and Tim established, and some of the work of trying out the buffers has been done if we need to go in that direction. If we need more board space for extra logic then I'd just cut the track between U1 and the buffers and run wires to a daughter board.

SiriusHardware 29th Jul 2021 1:31 pm

Re: Ortonview PCB
 
In the software, timing is everything, every cycle counts. I think Karen must have written a little utility to count instruction cycles for her - or else it was all just in her head. Probably the latter.

That's what I would find daunting about modifying the software. Knowing what functional change you want to make is one thing, but making that change while still retaining the exact number of instruction cycles within the same time period is the real trick.

SiriusHardware 29th Jul 2021 1:42 pm

Re: Ortonview PCB
 
By the way, we don't definitely know that the 'slow' version worked without the corruption problems.

When it became apparent that it was causing too much system slowdown it was more or less abandoned when Karen fairly quickly came up with the 'fast' firmware which held NENIN high for much shorter periods of time, so I'm not sure that the slow version got stress tested as much as it should have been.

I might try your hardware suggestion (which I think was also suggested by Mark a few posts ago), ref. delaying the buffer enable but not the buffer disable. My main interest in getting the buffers working is to prove whether the problem is or is not due to the fact that the PIC pins used to drive the address lines do not completely disengage from the address lines the way the address drive pins on the SOC VDU do.

That would be a useful thing for you to know one way or the other even if you prefer to try to solve it ultimately by tinkering with the code.

Slothie 29th Jul 2021 1:47 pm

Re: Ortonview PCB
 
i think its totally a good idea to find out, and if you get to it first then go for it. In fact, it will be easier to cut the tracks before you fit the DIL sockets - for me, its going to involve something akin to keyhole surgery because the tracks are on top of the pcb and the DIL sockets are kind of in the way!

Since I've not published the layout, I'll do a diagram of what I was thinking of doing to make it a bit clearer.

Slothie 29th Jul 2021 1:50 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1393796)
In the software, timing is everything, every cycle counts. I think Karen must have written a little utility to count instruction cycles for her - or else it was all just in her head. Probably the latter.

That's what I would find daunting about modifying the software. Knowing what functional change you want to make is one thing, but making that change while still retaining the exact number of instruction cycles within the same time period is the real trick.

Yes, fortunately most instructions are 1 cycle, and if I remove any instruction I can replace it with a NOP, if I need to add instructions there are DELAY macros that can be ajusted to suit and only a few places where timing is super-tight. But you're right, the timing needs paying close attention to, any errors are likely to cause on-screen jitter or complete failure of the picture.

Slothie 29th Jul 2021 2:10 pm

Re: Ortonview PCB
 
2 Attachment(s)
Quote:

Originally Posted by Slothie (Post 1393805)
Since I've not published the layout, I'll do a diagram of what I was thinking of doing to make it a bit clearer.

Here is the mod and a zip file of it in case forum compression kills it.

The white blobs are where the tracks would be cut, and the blue lines are links. The yellow components would probably go on the back (1k & 220p).

SiriusHardware 29th Jul 2021 2:18 pm

Re: Ortonview PCB
 
Thanks, the posted version is quite readable actually. I see why you suggest track cutting prior to fitting the sockets.

Slothie 30th Jul 2021 2:49 pm

Re: Ortonview PCB
 
1 Attachment(s)
Well I tried loading the "clive" and "inside" graphics to the memory expansion and found I had huge "jailbars" down the screen. After my heart sank a little, and a little investigation I noticed that pin 40 of the PIC was bent and not in the socket... some fiddling around and I had the pins straight and all in the socket and they all went away. I played with the contrast some and the smearing is a lot better too.

When displaying from the memory I did notice a very slight occasional flicker on the normally blank digits of the display between the address and data fields, so there is still some bus interaction, but I'm not noticing any memory corruption yet. I've been trying to get my head around Karens code again, and so far it looks like there is at least a 3.75uS delay between asserting NENIN and driving the address pins, for example the smallest:
Code:

L5        BCF        PORTC,NSYNC                ; VDU on
        BSF        PORTA,NENIN                ; Nenin high here
        DELAY        D'13'
        BSF        STATUS,RP0
        CLRF        TRISA                        ; on hi 4 bus ~15(3.75uS after NENIN)
        CLRF        TRISD                        ; on lo 8 bus ~16 (4uS after NENIN)
        BCF        STATUS,RP0
        BSF        PORTC,NSYNC

This also explains why my buffers didn't work so well, as I was effectively driving the bus immediately on putting NENIN high! However, correctly implementing the buffers will mean that we can remove the constant switching of PORTA and PORTD between input and output which will give more timing headroom if we need other tweaks to the code, and possibly eliminate other loading effects,

I am trying to think of a way of arranging the firmware code so that its structure is easier to understand, perhaps using more macros for the more repetitive parts of the code. of course this will have to be done with regard to timing, but if I am successful the generated hex file should be identical....

NB: While loading the graphic images I was getting some corruptions because of the keypress timing, so I doubled the default values in send14. This rather crude tweak solved the problems, slowing the process but to be honest not enough to worry me. Id rather it be slow and reliable that quick and flaky. The alternative of course would be to switch off the VDU so it isn't slowing the MK14.

SiriusHardware 30th Jul 2021 3:07 pm

Re: Ortonview PCB
 
Yes, put simply, the system slowdown induced by the the VDU means that keys have to be pressed for a slightly longer minimum amount of time in order for keypresses to be reliably read, hence the need to slow down the uploader if the VDU is actively running.

That smearing is still, to be honest, much worse than it should be but I think you still don't have a short video-rated photo lead so we'll see what it looks like when the replacement arrives.

Slothie 30th Jul 2021 3:20 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1394077)
That smearing is still, to be honest, much worse than it should be but I think you still don't have a short video-rated photo lead so we'll see what it looks like when the replacement arrives.

Yes, it is still bad but I have a better cable on the way, and I'm going to replace the output transistor as it got very hot while I was trying to solder it in and it might be underperforming..

SiriusHardware 30th Jul 2021 4:08 pm

Re: Ortonview PCB
 
"Photo lead?" (Phono lead, but you knew what I meant).

I've just arrived home to find the boards waiting for me, thanks for that. I'll put two pairs in the post to their respective future owners tomorrow (Saturday) morning.

Just today, I discovered that our little traditional electronics component shop down by the coast near here no longer opens on Saturdays, which is a big problem for me because my weekday working hours are the same as their weekday opening hours. I was relying on being able to go there tomorrow to get whatever misc parts I don't have, so that's a bit irritating. It means I'll have to scrape the parts together at work on Monday. I'll fit whatever I can find in the meantime.

Slothie 30th Jul 2021 4:39 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1394106)
"Photo lead?" (Phono lead, but you knew what I meant).

I've just arrived home to find the boards waiting for me, thanks for that. I'll put two pairs in the post to their respective future owners tomorrow (Saturday) morning.

Just today, I discovered that our little traditional electronics component shop down by the coast near here no longer opens on Saturdays, which is a big problem for me because my weekday working hours are the same as their weekday opening hours. I was relying on being able to go there tomorrow to get whatever misc parts I don't have, so that's a bit irritating. It means I'll have to scrape the parts together at work on Monday. I'll fit whatever I can find in the meantime.

Glad they arrived safely! I tried packaging them so they wouldn't burst out the bag (I've had PCBs cut through padded bags before due to their sharp milled edges!).

I'm going to do a build guide for the uploader board because things are a bit fiddly re: clearances, but the main thing to remember is to either wire over the reset jumpers or fit a right-angle header, vertical headers will short on the Pi Zero with regrettable results!
If you're fitting flying leads for the reset they can be plugged onto the header too.
Its worth fitting the 2x20 header for the Pi in conjunction with the 16 way DIP socket as they fit flush together, and slight mis-alignment of one might stop the other fitting well as some of the holes are generous. The rest of the Opto Isolators have sockets provided by 2x18 way DIP sockets, or you could used strips of turned pin sockets for all the Opto Isolators. Or you could just solder them in, as they are unlikely to need replacing.

Shame your local shop stopped opening Saturdays. I'm surprised, if they rely on the hobby trade at all thats the best day to be open. I suppose they must mainly sell to businesses. Its a shame small operations are all passing away due to the internet, mind you there are a lot of new small operations that are internet-only so I guess it balances out, but there's no immediate gratification!

SiriusHardware 30th Jul 2021 5:07 pm

Re: Ortonview PCB
 
I've continued the discussion about the uploader PCB in the specific thread for that. For the OrtonView, I'm unlikely to have mine fully built before the early part of next week unfortunately.

Slothie 30th Jul 2021 6:06 pm

Re: Ortonview PCB
 
FWIW I've just tried the battery backup option and it doesn't seem to work. I might have a wiring error, but putting in the battery makes the PIC fail to reset, or switch between graphics and text mode alternately after reset, so something wierd is happening! I guess you can save yourself the cost of a coin cell holder....(unless I work out where the problem is).

SiriusHardware 30th Jul 2021 6:28 pm

Re: Ortonview PCB
 
Although it's a nice feature to have, and I have dug out a Hitachi 6116LP specially for the occasion, it's not a priority for me. So, in your own time. ;)

In the days when the only way to get code into the machine was to first type it in and thereafter load it from a tape, it would have been a brilliant asset (which is no doubt why Buzby took the trouble to battery-back some of his memory on 'Micky').

We use through-hole CR2032 type coin cell holders in a couple of products at work, but I don't know yet whether one of those will just drop in.

Slothie 31st Jul 2021 1:55 pm

Re: Ortonview PCB
 
2 Attachment(s)
Quote:

Originally Posted by SiriusHardware (Post 1394147)
We use through-hole CR2032 type coin cell holders in a couple of products at work, but I don't know yet whether one of those will just drop in.

I shouldn't worry yet, it crashes the PIC if you put in the coin cell. I think the problem is the "S" (select) pin on the RAM gets pulled down if the RAM is powered but the gate feeding it is not. I've a mod in mind using a MOSFET but I'm still working on that.

The great news is that I have fixed the video issue I am having, the not so good news is its because I made a mistake on the PCB - I used the wrong footprint for the transistor. However, you just have to solder it in backwards (with the flat side on the opposite side from the screen print) and it works great! It even works with my 5m long cable (the old cheapo one works sort of too but has huge interference because its not screened!)

So thats one thing to sort out with the V2 PCB... Apparently BC547Bs don't like having their collector and emitter swapped.

SiriusHardware 31st Jul 2021 2:08 pm

Re: Ortonview PCB
 
Thanks for the info - incredible that it was working as 'well' as it was under the circumstances. Will try to get the majority of mine built up on Monday. Tim's and Mark's boards are on the way to them so Tim should have his early next week, Mark's may take a little bit longer to get there...

Now that it's working that output from OrtonView is much cleaner and crisper than anything which comes out of my original SOC VDU - it was the same with the output from my OrtonView lash-up - now partly dismantled for parts for the 'proper' build.

Timbucus 31st Jul 2021 4:21 pm

Re: Ortonview PCB
 
Looking great - nice timing for the 81st Birthday of Sir Clive as well to post that Picture... looking forward to building mine and maybe finally putting together that origin of OrtonView video I have been planning - now I have a capture card people may be able to see Minefield actually running...

SiriusHardware 31st Jul 2021 5:21 pm

Re: Ortonview PCB
 
Although the 'Clive' image is fortuitously on-message we could do with a few more different 64 * 64 1-bit monochrome (not greyscale) images for display or 'slideshow' purposes.

Anyone know a photo editor which can (attempt to) produce such stringently limited images from bits cropped out of colour or grey scale photos? I drew Clive by hand but it was very time consuming building him up dot by dot - a lazier / easier way would be nice.

Tim, when you get a bit of time would you be kind enough to draw a sketch of your Plus-three (optocouplers) interface so I know which extra GPIO pins you used for which of the extra three, and which three connections on the MK14 edge connector the extra opto go to? I would guess you left the original thirteen routed as found and just added the others in to the gaps, but maybe not.

Slothie 31st Jul 2021 6:46 pm

Re: Ortonview PCB
 
1 Attachment(s)
Well I managed to use Gimp to produce this picture of me, the question is how to convert it to a bitmap suitable for the MK14....

SiriusHardware 31st Jul 2021 6:57 pm

Re: Ortonview PCB
 
Can you save it / attach it as a .BMP instead? (Is BMP even an allowed attachment format?). I wrote a clumsy bit of python to extract a 1 bit 64 * 64 pixel .BMP to SBASM3 .DB statements but it only works on uncompressed .BMP files. Good image, considering the mega low pixel resolution / colour depth.

Slothie 31st Jul 2021 7:08 pm

Re: Ortonview PCB
 
1 Attachment(s)
Quote:

Originally Posted by SiriusHardware (Post 1394416)
Can you save it / attach it as a .BMP instead? (Is BMP even an allowed attachment format?). I wrote a clumsy bit of python to extract a 1 bit 64 * 64 pixel .BMP to SBASM3 .DB statements but it only works on uncompressed .BMP files. Good image, considering the mega low pixel resolution / colour depth.

Hmm try this. Its in a zip because the forum doesn't like BMP files....

SiriusHardware 31st Jul 2021 7:15 pm

Re: Ortonview PCB
 
2 Attachment(s)
Along other lines, and regarding the problem with the battery backed memory... This (attached as both image and .zip in case the forum downsizes it too much) is the relevant section of the circuit for my early '1990s Maplin Z80 CPU card' which had three battery backed 6116 RAMs, the three ICs on the right in this image. This did work, so maybe you can look at a variation on this method.

In this particular case the battery is a rechargeable NiMH (which almost destroyed the board while I thought it was safely stored) hence R8, which is the trickle charge resistor for the battery. You won't need that in your version.

Note the address decoder is a 74LS139 with active low CE outputs.

The three left hand switches turn the battery backup for their respective ICs on and off. The right hand switch has nothing to do with the battery backup, it enables the NMI from the offboard display / keypad circuit.

Where they have used an OA47 (Germanium!) diode as a low-drop diode we would presumably now use a Schottky.

Slothie 31st Jul 2021 7:42 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1394424)
Along other lines, and regarding the problem with the battery backed memory... This (attached as both image and .zip in case the forum downsizes it too much) is the relevant section of the circuit for my early '1990s Maplin Z80 CPU card' which had three battery backed 6116 RAMs, the three ICs on the right in this image. This did work, so maybe you can look at a variation on this method.

In this particular case the battery is a rechargeable NiMH (which almost destroyed the board while I thought it was safely stored) hence R8, which is the trickle charge resistor for the battery. You won't need that in your version.

Note the address decoder is a 74LS139 with active low CE outputs.

The three left hand switches turn the battery backup for their respective ICs on and off. The right hand switch has nothing to do with the battery backup, it enables the NMI from the offboard display / keypad circuit.

Where they have used an OA47 (Germanium!) diode as a low-drop diode we would presumably now use a Schottky.

Yes, it looks like they are decoupling the chip enables (pin 18) from the backup power using a common-base type transistor switch. My plan was similar, to use a MOSFET to create an open-drain inverter to replace U1C that inverts the chip select signal. I think that with the power off, the pullup on chip select is back-feeding power into U1 and possibly onto the main Vcc rail, causing latch-up or improper reset of the PIC. I wanted to take some measurements first. Once again the vital trace that needs cutting is on the top and runs near the DIP sockets!!

SiriusHardware 31st Jul 2021 7:55 pm

Re: Ortonview PCB
 
1 Attachment(s)
In the meantime you can amuse yourself by replacing the 'Clive' .DB image statements with the ones in the attached zipped .asm file. Note this is not embedded in a program to display the image, it's just the image converted to .DB statements so you need to cut and paste it into an existing 'displayer' program. It's obviously 512 consecutive bytes so best loaded into the 'new' RAM at 0200- and rendered by OrtonView from there.

I haven't tried this one, but I used the same wonky python program to extract the 'clive' image from the original .BMP to .DB statements.

SiriusHardware 31st Jul 2021 7:58 pm

Re: Ortonview PCB
 
Quote:

Once again the vital trace that needs cutting is on the top and runs near the DIP sockets!!
Can you cut the cross spars on the relevant socket out leaving only the two sides of the sockets left in the board? That will give you some leeway to see where you need to be.

SiriusHardware 31st Jul 2021 8:03 pm

Re: Ortonview PCB
 
Ref: #139 - or just put a .OR 0x200 statement at the start, assemble it and use the uploader to load it directly into screen memory.

Slothie 31st Jul 2021 8:37 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1394440)
Quote:

Once again the vital trace that needs cutting is on the top and runs near the DIP sockets!!
Can you cut the cross spars on the relevant socket out leaving only the two sides of the sockets left in the board? That will give you some leeway to see where you need to be.

Yes, I could probably do something like that. I think it also goes over to the other side of the board for a short bit so I might be able to scrape it there if its not too close to something else.

Slothie 31st Jul 2021 8:51 pm

Re: Ortonview PCB
 
1 Attachment(s)
Well that works well. It does make me look like I've got a handlebar moustache though :) But its a good proof of concept. I'll do a quick guide to what I did tomorrow.

SiriusHardware 31st Jul 2021 9:12 pm

Re: Ortonview PCB
 
1 Attachment(s)
Yes, I thought you were sporting a bit of a Wilf Lunn there. ;)

It goes to illustrate the point that if you're trying to represent something as detailed and individual as a face in so few pixels you have to get in quite a bit closer. Now we just have to go looking for as many suitable SOC / Sinclair related images as we can find. It's a shame we don't have a nice one of Karen.

The python 3 code I used to rip the image from the .BMP is even cruder than I remembered - it doesn't even output the .ASM code to a file, it just outputs it to the terminal window in the IDLE IDE and from there I cut and pasted it into Notepad and saved it with a .asm extension. Here it is, I know your python skills are much more polished so feel free to use as-is or improve. As written, it only works on 1-bit 64 * 64 pixel .BMP files.

Timbucus 31st Jul 2021 9:47 pm

Re: Ortonview PCB
 
To my great concern I was going to ask her daughter again for the photos but I just looked and when work swapped my phone all my contacts were lost so I no longer have her phone number - that is so sad.

SiriusHardware 31st Jul 2021 9:53 pm

Re: Ortonview PCB
 
I've thought a little more thought about it, Karen always struck me as a very private person who preferred to let her projects be her interface to the world - so she might have been rather horror stricken at the thought of her image being put 'out there', no matter how grainy or low-resolution.

Timbucus 31st Jul 2021 10:06 pm

Re: Ortonview PCB
 
That was my original assumption which is why I shied away from it in the Video I did but, I had discussed it with Emma just never chased it up in our conversations which obviously had other more important topics.

So on that note I will take some close ups that would work of the Mk14 related devices - we can do a slide show of those.

Mark1960 31st Jul 2021 10:40 pm

Re: Ortonview PCB
 
Another option for the ram instead of adding buffers might be to switch the ground connection to the ram using a diode from the battery and an npn transistor for 5v ground. With 5v switched off all inputs to the ram are pulled high.

SiriusHardware 2nd Aug 2021 5:18 pm

Re: Ortonview PCB
 
I'm about 80% of the way through the Ortonview build now - like Tim I don't seem to have any of the required skeleton phono sockets but I can just use the socket-on-a-bit-of coax which I used with the original lash-up until I get one.

Main jobs left are to add the timing mod for the 74LS365 buffers (I did have the foresight to make the necessary discrete track cuts before I fitted the buffer sockets) and to strap whatever needs to be strapped to make the 6116 work, ignoring the battery backup setup for the time being. One thing I don't have which I thought I did are 220pF capacitors, so I have some of those on the way. I either need four to run the board with the 'primitive' fix or one to use on the buffer timing mod, so either way, I am stalled until they arrive.

Following Slothie's observation that OrtonView + Memory adds very little to the supply current drawn from +5V I have for now just linked the incoming +5V from the MK14 to what would be the output terminal of the regulator if it was fitted. I've fitted as many 0.1uF supply decoupling capacitors as I can see holes for.

The additional reg could still come into its own when we start running other bits of hardware, so it is good that there is already a place for it on the PCB.

Slothie 2nd Aug 2021 5:51 pm

Re: Ortonview PCB
 
Its worth pointing out that many of the headers on the board are optional, the only ones you are likely to use the "options" ones and perhaps the I/O pins near the edge connector if you are going to drive the options from IO pins. And the 'noise' pins in the unlikely event you are going to build that part.


All times are GMT. The time now is 6:58 pm.

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