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 5th Aug 2021 7:58 am

Re: Ortonview PCB
 
Brought the board into work with a view to converting it to 'classic' configuration, but before I did I scoped the enable 1 / enable 2 signals with the 1K / 2.2nF RC values in place on one of the enables.

Obviously one enable is sharp and one has very pronounced rising and falling slopes and it's quite difficult to know where the delayed enable will be crossing the threshold, but I would say that it is crossing the half supply mark at about 1.8uS after the vertical edge on the undelayed enable - so there may be some leeway to increase the capacitor value a little bit more.

I've hacked a couple of 16-pin sockets by soldering little wire hoops into their top contacts so I can bypass the buffers by plugging the wired sockets into the buffer sockets, making it easy to swap between one method and the other.

Slothie 5th Aug 2021 9:55 am

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1395663)
Brought the board into work with a view to converting it to 'classic' configuration, but before I did I scoped the enable 1 / enable 2 signals with the 1K / 2.2nF RC values in place on one of the enables.

Obviously one enable is sharp and one has very pronounced rising and falling slopes and it's quite difficult to know where the delayed enable will be crossing the threshold, but I would say that it is crossing the half supply mark at about 1.8uS after the vertical edge on the undelayed enable - so there may be some leeway to increase the capacitor value a little bit more.

I've hacked a couple of 16-pin sockets by soldering little wire hoops into their top contacts so I can bypass the buffers by plugging the wired sockets into the buffer sockets, making it easy to swap between one method and the other.

I would have been happier if I'd been able to use a schmitt trigger type input where the input thresholds are better defined, but there you are. There is a danger of instability if the slope becomes too slow, but given that you see these RC delays in logic circuits fairly often it can't be too dodgy!
The sockets idea is good, I used 4 strips of turned pin header with the adjacent pins bridged with solder, which works but looks a bit clunky due to the solder blobs!
It seems to work well enough with the load capacitors, its just a little technically unsatisfying for me as at the moment I don't understand where the problem is, the intended approach of asserting NENIN and waiting should be working, but there is obviously some nuance we are missing. It should be possible to fix this in the firmware.

SiriusHardware 5th Aug 2021 10:12 am

Re: Ortonview PCB
 
One avenue to explore is the possibility of using the 887, which Karen originally meant to use. If you move the code over to the 887 that gets you at least one more I/O pin to play with (RE3, which on the 877 is MCLR). What we don't yet know is whether the graphics blur issue which only happens with the 877A will also be a problem on the 887. We'll just have to try it.

I had originally hoped to use that ruse to do the bright line blanking but it could be used instead to properly control the buffer enable / disable line - enable the buffers just after the PIC address drive lines have been swapped to output mode, disable the buffers just before the PIC address drive lines are swapped back to input mode.

Of course if you are definitely going to go with buffers then you no longer need to keep swappping the PIC pin directions, they can remain in output mode with the buffers gating their access to the system address bus on and off as per the SOC VDU. But leaving that bit in for now leaves us the option of going back to the original scheme whenever we want to try or check something.

Mark1960 5th Aug 2021 3:03 pm

Re: Ortonview PCB
 
I think the write to wrong address when a write cycle is interrupted is going to need a hardware fix, I don’t see how it can be fixed with the software timing. When NENIN is raised it resets the 8060 bus cycle, tristates the NWDS and Address lines, NWDS is then pulled up by pull up resistor and the address lines float. The high address lines don’t seem to hold their level long enough for NWDS to be pulled high, possibly due to 74ls ttl address decoding input bias currents pulling the logic level before NWDS is inactive. This doesn’t seem to be a problem on the original mk14 vdu so the possibility is that the input current of the PIC is pulling the address lines faster than just the address decoding logic.

There may be some timing difference internal to the 8060 between the NWDS floating and the address lines floating. Adding capacitors is just increasing the hold time on the address bus.

The buffers are an attempt to match the address interface of the original mk14 vdu, it will be interesting to see if that provides any further confirmation that the PIC inputs are contributing to the address bus hold problem, though adding two chips to the design.

As we have 3.75us delay from raising NENIN before the PIC reads data and the memory access cycle of the 8060 at 4MHz is less than 2us, we could possibly delay NENIN until the end of any active memory cycle. I’m not sure if we could do this in software on the PIC, but it could probably be done with external logic.

We could also try an active bus hold circuit instead of capacitors to “remember” the address driven by the 8060 until driven by the PIC.

SiriusHardware 5th Aug 2021 4:17 pm

Re: Ortonview PCB
 
Quote:

This doesnít seem to be a problem on the original mk14 vdu so the possibility is that the input current of the PIC is pulling the address lines faster than just the address decoding logic.
This what I'm banking on, the fact that the main difference between SOC and Ortonview VDUs is that the SOC VDU completely disconnects its address drive lines from the system address lines, while OrtonView just turns them into inputs as the pins used don't have a high impedance / tristate state which they can be placed in.

You may already have suggested this but what if we generate the buffer enable signal from NENIN(active, high) and NRDS? It's Karen's code which 'flaps' NRDS up and down for each read from the RAM so there is probably a signifcant delay between the instruction which takes NRDS low and the instruction which reads the data from the databus.

As long as the address buffers can turn on in that interval, will the RAM (system RAM or extra RAM) be able to respond and supply the data from the address which has been supplied 'just in time' for the PIC to read it?

Even if the timing is OK there will be one drawback, if the NRDS signal edge occurs just before the address arrives on the databus it would probably break compatibility with the IM65x.. RAMs which are an option on the issue VI replica PCB... the very reason why Karen's code does 'flap' NRDS, unlike the SOC VDU which just holds it low all the way through one video line.

Slothie 5th Aug 2021 5:57 pm

Re: Ortonview PCB
 
TBH if we lose compatibility with the IM65X rams it wouldn't be a disaster. It seems to be easy enough to get the AMD 9111 RAMs these days.

SiriusHardware 5th Aug 2021 6:35 pm

Re: Ortonview PCB
 
I've just busy trying out Slothie-OV in the conventional mode and I seem to have a problem in so far as I initially got the same haywire behaviour as I did when the buffers were involved, Narrowing it down it seems the problem only really happens when I am trying to let OrtonView render from the 6116 RAM.

If I set P1-P4 (Page select inputs) to render from the MK14's onboard RAM (0F00-0FFF and 0B00-0BFF) or from the ROM 0000-1FFF it actually works fine, it only goes haywire when I 'point' OrtonView at RAM in the range 0200-0600.

Yet, if I remove the PIC and leave only the 6116 and the 7402 fitted the system is able to write to and read from memory in that range.

This invalidates all my observations to date since the problems I was having were obviously not specifically related to operations with the buffers in place, and Slothie may find that if he tries the buffers again but this time with the enable delay (I would suggest maybe 1K + 3.3nF) it may work.

I'll see if I can get to the bottom of this problem.

The 6116 isn't the same brand / type as the one I used on my original 'Bridge board', so I may try to find another one of those, an EL6116LP. The device currently fitted is a Hitachi 6116LP-3 which according to the datasheet (and in spite of what the -3 would suggest) is a 150nS part. This is a chip I've owned since the 1980s, so unlikely to be fake.

Mark1960 5th Aug 2021 6:38 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1395816)
You may already have suggested this but what if we generate the buffer enable signal from NENIN(active, high) and NRDS? It's Karen's code which 'flaps' NRDS up and down for each read from the RAM so there is probably a signifcant delay between the instruction which takes NRDS low and the instruction which reads the data from the databus.

Yes, thats what I suggested in #195, but we need to isolate NRDS generated by the PIC from NRDS generated by the 8060 to avoid buffers turned on for every 8060 read. That means cutting track and inserting a schottky diode. There would be no set up time on the address lines for the RAM to latch the address but no problem for 2111 or 9111 ram.

Could also try #199, use UA11 to enable the buffer. Doesnít need track cut, just a pullup resistor, but limits orton view to low 2k, so just the 6116 on the expansion, but we would need to check ram in high 2k is not corrupted by interrupted writes. Might be worth trying as it avoids hacking the pcb until we know if the buffer solves the problem.

SiriusHardware 5th Aug 2021 6:40 pm

Re: Ortonview PCB
 
EL6116 as originally fitted is 100nS, so I'm off in search of one of those...

SiriusHardware 5th Aug 2021 6:42 pm

Re: Ortonview PCB
 
Quote:

we need to isolate NRDS generated by the PIC from NRDS generated by the 8060 to avoid buffers turned on for every 8060 read
Are you sure? Remember I said to derive the buffer enable from NENIN(=High) and NRDS. NENIN is only ever high when the VDU is trying to read from RAM. The 8060 should be off-bus and never assert NRDS itself when NENIN=High, so NRDS pulses during NENIN = high can only be coming from the PIC.

Mark1960 5th Aug 2021 6:45 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1395862)
Yet, if I remove the PIC and leave only the 6116 and the 7402 fitted the system is able to write to and read from memory in that range.

What type of 7402? If its not hct then it might add more load to the address lines.

SiriusHardware 5th Aug 2021 6:48 pm

Re: Ortonview PCB
 
It is HCT (forgive my shorthand earlier). The chip I used for the address decoder on the bridge board I used with the prototype OrtonView was an LS, and continues to work OK.

Mark1960 5th Aug 2021 6:49 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1395867)
Quote:

we need to isolate NRDS generated by the PIC from NRDS generated by the 8060 to avoid buffers turned on for every 8060 read
Are you sure? Remember I said to derive the buffer enable from NENIN(=High) and NRDS. NENIN is only ever high when the VDU is trying to read from RAM. The 8060 should be off-bus and never assert NRDS itself when NENIN=High, so NRDS pulses during NENIN = high can only be coming from the PIC.

I was thinking about the orton view interrupting an 8060 read cycle, might give a temporary bus conflict.

SiriusHardware 5th Aug 2021 7:07 pm

Re: Ortonview PCB
 
I keep forgetting that the VDU just barges in no matter what the SC/MP happens to be doing at the time.

I've just been up to my chip museum for some more RAM, found another Hitachi 6116LP-3 and a EL6116LP-10 which has obviously never been inserted in a socket before.

Fit Hitachi 6116: System goes nuts when VDU is set to render from the 6116.
Fit EL6116LP-10 - Works perfectly when the VDU is set to render from the 6116.

Slothie, what exactly do you have fitted in yours - in particular, what speed?

Slothie 5th Aug 2021 7:15 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1395883)
Slothie, what exactly do you have fitted in yours - in particular, what speed?

I used an M5M5117P-15, 150nS memory.

Slothie 5th Aug 2021 7:17 pm

Re: Ortonview PCB
 
1 Attachment(s)
Here's the datasheet if you want to compare it to anything you might have.

SiriusHardware 5th Aug 2021 7:31 pm

Re: Ortonview PCB
 
I forgot you had specified something a little bit less mainstream. I've just checked a few sites and to be sure, got up off my launch pad and strolled as far as the bookshelf to get out my green and white 'Hitachi IC Memory Data Book' - all agree that

Hitachi 6116LP-4 = 200nS
Hitachi 6116LP-3 = 150nS
Hitachi 6116LP-2 = 120nS

So, I have no idea what's going on there. Ortonview obviously does rattle through the RAM quite quickly to try to keep the PIC fed with pixel data.

If I removed OrtonView, left the Hitachi IC fitted and wrote a bit of software to access the memory continually, maybe then it would fall over. Previously, I was checking the Hitachi RAM by just using the monitor to browse to various locations in the 6116's range to edit data and see if it would stick and could be read back (it did, it could).

SiriusHardware 5th Aug 2021 7:46 pm

Re: Ortonview PCB
 
Anyway, this means I'm right back at square one. To summarise, the sequence of events was:

1) Fit Hitachi 6116LP-3 RAM and address decoder only and check, using the crude process outlined above, that the RAM was working. It was.

2) Fit the VDU related components and modify the feed to the second enable on the buffers so that it was delayed by RC, initially 1K + 220pF then as high as 1K +2.2nF. In all cases the system went haywire when powered on.

3) Revert to original OrtonView design with address driving pins of PIC directly connected to system address bus, still pointed at memory at 0x200 onwards. Discover that the system still goes haywire when powered on.

4) Then tried pointing the VDU at areas of memory which were NOT in the 6116. Worked OK.

5) Replaced Hitachi 6116LP-3 with Elcap EL6116LP-10 - now working OK even when the VDU is pointed at any address within the 6116.

This should be a good starting point from which to attempt to get the buffers working again. I'm going to fit turned pin socket strips so that the address bus capacitors can be removed and fitted more easily.

Timbucus 5th Aug 2021 7:49 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1395894)
I forgot you had specified something a little bit less mainstream. I've just checked a few sites and to be sure, got up off my launch pad and strolled as far as the bookshelf to get out my green and white 'Hitachi IC Memory Data Book' - all agree that

Hitachi 6116LP-4 = 200nS

Blast that is all I have - better hunt around for a different one then.

SiriusHardware 5th Aug 2021 7:53 pm

Re: Ortonview PCB
 
I can whizz you one of the Elcap 6116LP-10s if you have difficulty finding one (one good turn, etc)...

Slothie 5th Aug 2021 7:54 pm

Re: Ortonview PCB
 
Interesting, 300nS memory is too slow? I suppose if the pic is setting the address and then reading the data with the next instruction then thats 250nS. Still doesn't explain why it sent the MK14 mad given the delays before/after asserting NENIN.

SiriusHardware 5th Aug 2021 7:57 pm

Re: Ortonview PCB
 
The thing is, the 6116-3 is not 300nS (as you would reasonably expect)... it's 150nS. Like yours.

SiriusHardware 5th Aug 2021 8:12 pm

Re: Ortonview PCB
 
Incidentally I'm not getting any noise / unwanted flicker at all on the MK14 displays now that the RAM problem is sorted - but I do have R3 (NWDS pullup resistor)= 4K7, not 10K.

SiriusHardware 6th Aug 2021 4:02 pm

Re: Ortonview PCB
 
After last night's setback and then recovery from the Hitachi ram induced problems, the PCB is looking a little bit tidier now thanks to Tim's kind contribution of a Cliff-type RCA socket. I've also fitted turned pin socket strips which make it easy to fit and remove the A8-A11 capacitors.

Today's experiment was to revert the PCB back to buffered configuration and no capacitors on A8-A11, this time with the known good EL6116LP-10 RAM fitted and with 1K / 3.3nF in the buffer enable delay RC circuit.

Results are somewhat better than Slothie's original attempt with no buffer enable delay at all, which with hindsight wasn't likely to work well.

With the setup just described operation of the MK14 is normal with a rock steady 'ready prompt, and with the VDU pointed at 0x200-03FF I can edit addresses in that range and see the characters representing those addresses changing.

Unfortunately it's not quite there yet: Just sitting at the ready prompt I can see perhaps 5-6 of the characters in the 0300-> address range continually whizzing around, being changed at a high rate when they should be static. Also when I'm typing codes into successive addresses in the 0200-> range I see characters several bytes ahead of the ones I am typing into occasionally changing.

If I can find a pot or preset I may try winding the resistance of the R up and down to see what effect that has going higher and lower than 1K, the current fixed value.

Slothie 6th Aug 2021 4:10 pm

Re: Ortonview PCB
 
If anything is going to help I would imagine it will be increasing the value of R but this is encouraging news. I wish I understood precisely the mechanics of the problem...

SiriusHardware 6th Aug 2021 4:19 pm

Re: Ortonview PCB
 
I'll try to find a 2K2 or 4K7 pot or preset. Make the delay too long and the buffers still won't be enabled at the point where the PIC tries to place the address on the system address bus.

Are you going to have a go at this as well? It always helps to have a range of feedback on which values work and which values don't.

SiriusHardware 6th Aug 2021 4:37 pm

Re: Ortonview PCB
 
Just quickly tried it with a 10K preset initially set to 1K and then going up and down in value.

Going upwards, the effects on the screen don't alter until a certain threshold when the whole screen content starts to ripple / change and I would guess that is the point where the buffers no longer turn on in time for the VDU address to pass through to the system bus when needed.

Going downwards in R value from 1K nothing changes until the system suddenly crashes and won't run properly even after reset unless the resistance is increased a bit first. I would guess that this lower threshold is where the SC/MP still has not relinquished the buses and ends up clashing with the enabled buffer outputs which will be outputting a '1' if the PIC pins are still inputs at that point.

SiriusHardware 6th Aug 2021 4:49 pm

Re: Ortonview PCB
 
I should clarify that between the two thresholds described in #227, the unwanted behaviour, several characters in the 0300-> range and one in the 0200-> range rapidly changing, continues in the same way. The speed / frequency of change and number of characters affected does not change as I wind the resistance between the two thresholds.

Slothie 6th Aug 2021 5:07 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1396113)
I'll try to find a 2K2 or 4K7 pot or preset. Make the delay too long and the buffers still won't be enabled at the point where the PIC tries to place the address on the system address bus.

Are you going to have a go at this as well? It always helps to have a range of feedback on which values work and which values don't.

I will do, recently I have been spending time looking at the code to try and see how the various timings work (without much progress so far) and writing some SC/MP test programs too. I seem to have forgotten a load about writing assembler :)

I'm going to see about cutting the tracks to the buffer enables, since they are no use as they are anyway, and see what playing with the RC values does. I might also see if I can think up some scheme to delay NENIN if NWDS is active.

SiriusHardware 6th Aug 2021 5:10 pm

Re: Ortonview PCB
 
With the R and C back to 1K / 3.3nF which places the timing value between the thresholds mentioned above, I tried other things.

1) Swap the two buffers over. No change, the locations which are cycling are the same ones.

2) Swap the EL6116LP-10 for another one that I have here. I still have characters flickering but they are different characters (different locations).

With either of the two EL6116LP-10s in, the start-up content of the RAM is specific to each of the chips, each bit in each chip appears to have a preferred start up value which it nearly always reverts to but this pattern is different in RAM (1) and RAM (2). The locations which flicker/change are also diffferent between chips but consistent on a per-chip basis. (Every time I start it up with a particular 6116 fitted, it's always the same locations which flicker in that chip).

SiriusHardware 6th Aug 2021 5:17 pm

Re: Ortonview PCB
 
Quote:

delay NENIN if NWDS is active.
This all ties into the timing which generates video lines though doesn't it - the PIC has to have priority access to the RAM and it needs the screen data exactly when it needs it at precisely timed intervals. Holding off asserting NENIN will most likely cause tearing / jitter on the video lines.

SiriusHardware 6th Aug 2021 6:19 pm

Re: Ortonview PCB
 
Two further bits of info: - I thought the changing characters might be a side effect of the action of the OS code running where, if you have the VDU pointed at 0F00-> you can always see some characters constantly changing.

So,

- Hold down the reset button to stop all SC/MP activity.

and

- Enter and run short loop program 90 FE, the purpose being to allow the SC/MP to run but at the same time stop it from running the OS maintenance routines.

In either case, the flickering / changing characters in the 0x200- 0x3FF area continue to flicker.

Timbucus 6th Aug 2021 6:48 pm

Re: Ortonview PCB
 
That sounds like it is just rendering different characters not that they are physically changing in memory like was happening with the memory corruption.

Slothie 6th Aug 2021 6:51 pm

Re: Ortonview PCB
 
Well I have some (slightly) different results.

I cut the tracks, joined the pins and put in a RC as described, using a 1K resistor and 2.2nF capacitor.

With the switches and jumpers set to display Fxx and Bxx I get all the characters changing rapidly on the screen, maybe a few stable but most changing. However, as far as the SC/MP is concerned the memory isn't changing - I can change the values in memory and they read back the same (I didn't test this exhaustively, but I tried several ranges of memory). You can see some effect on the display, but the characters flick from one to another.

Set the VDU to display the memory at 2xx and 3xx and its as stable as a rock... Changing values in the memory stick and change what is displayed on the screen.

All the time the MK14 has a stable LED display and doesn't appear to have hung yet.

So maybe there isn't enough time between putting the address on the bus and reading the data with the extra delay and the MK14 memory/signal path is too slow? I can't find a trimmer yet but I will try a variable RC delay when I do, although your results would seem to imply this isn't going to help.

I'm still using the 10k/10k NWDS pullups fyi but I am seeing this more as a PIC accessing the RAM problem that write corruption. When I can get display of 02xx etc stable then we'll go back to seeing if we have corruption problems (I expect we may).

I might see if I can film the results I'm getting and upload it (no promises!)

SiriusHardware 6th Aug 2021 6:54 pm

Re: Ortonview PCB
 
Quote:

That sounds like it is just rendering different characters not that they are physically changing in memory
Actually if I browse to the exact locations in question with the monitor, the monitor display goes unstable, so I think the locations really are being changed.

I've gone back to direct address connection and A8-A11 capacitors for now. In static operation at least, the screen memory content is rock stable. I still need to stress test it using CHARSET or something similar.

I don't think I can do more on the buffer problem side until you and Slothie and eventually Mark either do or don't have the same problems when you try it. If I turn out to be the odd man out, I may have to try a third type of RAM just to see if that makes a difference.

There are a couple of other differences between Slothie's setup and mine - one is that his machine is 4.43MHz and the other is that I am, as far as I remember, running earlier OrtonView firmware - the earliest fast version which worked properly - the reason being that none of the subsequent alterations to the code had the hoped for beneficial effect, so they just make the code more complicated for no additional gain. However, I will try going to the version Slothie is using so we are both working from the same base.

Timbucus 6th Aug 2021 6:57 pm

Re: Ortonview PCB
 
Just finishing family things but, hoping to have an hour to solder it together as I have all the parts now.

Mark1960 6th Aug 2021 6:57 pm

Re: Ortonview PCB
 
Characters still changing when there are no writes to memory by the 8060 could indicate a different problem than the interrupted writes. Are you able to scope NENIN and NWDS?

According to earlier posts there is a 3.75 us delay from raising NENIN to the PIC driving the address. Write cycles are 2us max. If NENIN is raised by the PIC while a write cycle is in progress it should be ok to delay NENIN to the 8060 until the write cycle is complete.

Due to ILD and DLD instructions holding the NBUSRQ for 6us, we can’t just gate NENIN with NBUSRQ.

Simplest method might be to AND gate NENIN from PIC with NWDS, but its possible the fairly slow 150ns propagation of NENIN to NENOUT also applies to NENIN to NWDS and we might still have a short glitch on NWDS when we interrupt the write cycle just before NWDS is active.

We could latch the RFLG from the data bus at the rising edge of NADS, and clear at the rising edge of NWDS. This could then be gated with NENIN. Its more complicated, but I think could be done with a 74HCT74 and 74HCT08 in place of the two buffers so not increasing chip count.

Probably needs to be HCT to avoid any extra loading on NWDS which could impact timing of NWDS rise to Address lines floating.

Edit: cross posted with #233 onwards, I type too slow on the ipad.

Slothie 6th Aug 2021 7:26 pm

Re: Ortonview PCB
 
Interestingly if displaying from the extension memory (0200/0300) I can upload an image using the uploader and it displays perfectly.

I looked up my AMD AM9111 memory and I have AM9111C memory which is 300nS. Maybe that is why I am seeing a difference between the MK14 and extension memory...

It also shows that the VDU isn't interfering with the function of the monitor when operating in this mode.

I'm going to have another look at the firmware...

Slothie 6th Aug 2021 7:44 pm

Re: Ortonview PCB
 
Weeellll...
The macro to read memory looks like this:
Code:

; Read data from memory macro
RDMEM        MACRO
        BCF        PORTA,NRDS        ; RDMEM = 7~
        DELAY        3
        MOVF        DBUS,W
        BSF        PORTA,NRDS
        INCF        ADRSSL
        ENDM

This macro is used wherever memory is read, and is called at least 4uS after the NENIN has been set high.

Can someone confirm: With a 16Mhz clock, the machine cycle is 4MHz, ie 250nS.

So the code above is setting NRDS low, waiting 3 cycles (=750nS) then reading the databus port, so the access time is at least 750nS.

The last thing the read does is to increment the Address lower 8 bit port, PORTD. If there were problems incrementing the port, then the display wouldn't work when running from the extension memory; yet it would appear the code is allowing 750nS access time...

Thoughts?

SiriusHardware 6th Aug 2021 8:15 pm

Re: Ortonview PCB
 
Slothie, remind me which #nnn firmware you are running?

SiriusHardware 6th Aug 2021 8:19 pm

Re: Ortonview PCB
 
Also, what logic familiy are your 365 buffers? Mine are LS365s.

Slothie 6th Aug 2021 8:41 pm

Re: Ortonview PCB
 
I am using fw #692 (That's the last revision I think) and the one Tim is using I beleive. https://bitbucket.org/IanKRolfe/ortonview.x/src/fw692/

My buffers are 74HCT365s. They should have pretty much the same behaviour. I couldn't get LS ones and the I read that they are pretty much a drop-in replacement.

Mark1960 6th Aug 2021 8:59 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Slothie (Post 1396180)
I looked up my AMD AM9111 memory and I have AM9111C memory which is 300nS. Maybe that is why I am seeing a difference between the MK14 and extension memory...

Are you sure they are not AM9111BPC? I think you have 450ns same as my original MK14.

Iím sure I remember Karen asking about memory speed and setting up the timing to work with original MK14 memory, so surprised if that is making a difference now.

Mark1960 6th Aug 2021 9:27 pm

Re: Ortonview PCB
 
1 Attachment(s)
Sketch circuit to try and block NENIN interrupting a write cycle

Slothie 6th Aug 2021 9:32 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Mark1960 (Post 1396214)
Quote:

Originally Posted by Slothie (Post 1396180)
I looked up my AMD AM9111 memory and I have AM9111C memory which is 300nS. Maybe that is why I am seeing a difference between the MK14 and extension memory...

Are you sure they are not AM9111BPC? I think you have 450ns same as my original MK14.

Iím sure I remember Karen asking about memory speed and setting up the timing to work with original MK14 memory, so surprised if that is making a difference now.

Well they say AM9111CPC on them which according to the data sheet is 300nS.

Well looking at the code I can't see that its access time, as I noted above. Perhaps its something else. I wish I still had access to my old analog scope!

SiriusHardware 6th Aug 2021 9:46 pm

Re: Ortonview PCB
 
Mark, re: Sketch in #244. If you read back you may have seen that I have problems with a number of displayed characters rolling even when the SC/MP is held in reset, in which circumstances we can definitely say that NENIN is not crashing into the middle of an SC/MP NWDS pulse.

Slothie and I appear to have such different variations of the same problem that I think we are going to have to narrow down the differences between systems and OrtonViews. I'll have to find my PicKit2 tomorrow and reflash the PIC to #692 so we are both starting on the same page.

The AM9111s on my issue VI are AM9111DPC x 4. I haven't yet tried pointing the VDU at the standard / extra RAM (0F00, 0B00) with the VDU in buffered configuration.

Slothie 6th Aug 2021 10:01 pm

Re: Ortonview PCB
 
I didnt mention but when displaying from the MK14s RAM and holding down the reset there were still some characters changing but not as many.
Tomorrow I'll try to do that video.

Mark1960 6th Aug 2021 10:11 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by Slothie (Post 1396190)
Can someone confirm: With a 16Mhz clock, the machine cycle is 4MHz, ie 250nS.

Yes, page 135 of the spec says four oscillator periods for each instruction cycle.

Timbucus 6th Aug 2021 10:18 pm

Re: Ortonview PCB
 
Well I have assembled the board - it seems to have memory using my slow 6116 at 0200 - not fully tested but tried writing data in and around it - I must write a memory test program!

I have 2.2n and 1K on the Buffer mod but, at the moment just have linked them out.

When I worked out that you had to have the DIP switch on to get a display I finally found the video was working as well. I need to remember how to patch out to have two pages displayed not the same page top and bottom! Can anyone give me the manual patching for P1 to 4 for each mode as all my software sets it using the I/O chip.

With my 692 PIC877 I get a display and can see the text and graphics modes quite clear but, with a little ghosting. Just for a laugh for initial test I tried my 'A' chip with 352 firmware - that seemed to work as well with no jumping in Graphics mode - I will flash the latest firmware and report back tomorrow on that interesting finding.

Just hooking up the PI to try some code and try to work out the settings. I expect my 6116 will be too slow but, the others will be here Tuesday. For reference my main RAM is AM9111DPCx4 as well

SiriusHardware 6th Aug 2021 10:39 pm

Re: Ortonview PCB
 
The switches when ON connect the associated configuration / page set inputs to 0V. When the associated switch is OFF, the corresponding control input is pulled high, but also able to be wiggled up and down by something else, particularly TOP.

Assuming you've soldered the switch in so that the ON direction on the switches is towards the PIC, then this setting

00111110

...and TOP linked to P1...

Gives you:-

Screen RAM = 0200-03FF
VDU on
Display mode = Characters
Pages swapped = Yes
Normal (Not inverse) video

Page Swap is invoked so that the two address blocks 0200 and 0300 are displayed in logical order on the upper and lower halves of the screen respectively, so that the screen represents a straight run of 512 consecutive memory bytes from upper left to lower right.


All times are GMT. The time now is 3:22 am.

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