Ortonview PCB

[SiriusHardware]

Also, what logic familiy are your 365 buffers? Mine are LS365s.

[Slothie]

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]

Originally Posted by Slothie

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]

Sketch circuit to try and block NENIN interrupting a write cycle

[Slothie]

Originally Posted by Mark1960

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]

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]

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]

Originally Posted by Slothie

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]

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]

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.

[SiriusHardware]

Switch set to:

00001100

...and TOP linked to P3...

Gives you:

Screen RAM = 0F00 / 0BFF
VDU on
Display mode = Characters
Pages swapped = No
Normal (Not inverse) video

P1-P4 switches OFF means P1-P4 inputs = high = base address 0F00, but connecting TOP to P3 overrides the P3 pullup resistor and toggles the address between 0Fxx (upper half) and 0Bxx (lower half)

[Timbucus]

Thanks - I had worked out the second one but, could not work out why the first config did not work. In a lucky decision I had not soldered the switches in with ON towards the PIC. When I turned it around (as I had put it in a socket I was unable to get the machine to stay in Text mode - anyway long story short was that one of the switches would not go on. Swapped to another one and now I can render graphics to either config flawlessly. Charset runs fine in main RAM at full pelt.

In real terms I cannot find anything that does not work yet... So the other RAM chips may not be needed and indeed I would have been surprised if this had not worked as it is the same one as was in the RAM expansion I built and used with my protoboard OrtonView.

[SiriusHardware]

Assume you are still running in MK1 (unbuffered) mode? In that mode I don't have any problems either, provided I have capacitors on A8-A11. (And provided I don't fit any of my Hitachi 6116-3 chips, which cause problems for some reason).

It's the buffered mode, which we hoped would remove the need for the capacitors, which seems to be causing problems.

[Slothie]

Its been a long time since I've got something working, then broken it because I want it to work a different way

[Timbucus]

Originally Posted by SiriusHardware

Assume you are still running in MK1 (unbuffered) mode? In that mode I don't have any problems either, provided I have capacitors on A8-A11. (And provided I don't fit any of my Hitachi 6116-3 chips, which cause problems for some reason).

It's the buffered mode, which we hoped would remove the need for the capacitors, which seems to be causing problems.

Indeed yes unbuffered but, using the 6116P-4 which according to your table is even slower than yours...

I will of course play with the buffers later to confirm all your findings and the strange case of the A (maybe the A11-A8 220pF caps fixed that as well?) we never tried it after firmware 357... shop duties call first so I will report in later.

[Slothie]

I've been writing some test programs to "exercise" the memory. This:

	.CR scmp
	.TF testmem.hex, INT
        .OR 0xF20

data	.EQ 0x200

start	ldi /data	Point P1 to data area
	xpah	1
	ldi #data
	xpal	1
	ldi 0
	st count
loop	ld char
	st @1(1)
	dld count
	jnz loop
	ild char
	jnz start
	xppc 3


count	.DB 0
char	.DB 0
;
; Bytes for loader
	.OR 0xFFFE
	.DB start>>8
	.DB start
	;.DW start

will fill a 256 byte page with values 00 to FF. Sometimes it runs through to completion and drops back into the monitor, sometimes it seems to stop early, on occasions it starts filling the bottom half of the screen.... This looks like memory in the program area (0F20->) getting corrupted. So my "rock solid" configuration isn't as rock solid as it appears. Loading images into the 0200-03FF area using the uploader seems to work still, but then the monitor PROM can't get corrupted so the chances are its the same problem that you were seeing with your prototypes, i.e. random bits of the MK14s memory getting corrupted.

I've zipped and included the asm and hex in case its useful.

[Timbucus]

Cool - I will try that now. I have put the buffer chips in and it all seems to work the same as with them strapped out, running static images into the video at 0x200 and also running CHARSET with video in standard memory etc. Even played a few rounds of MINEFIELD!

[Timbucus]

How many times do I need to run this? I have done it 10 times - always succeeds and this is with the Buffers in place.

[Slothie]

Originally Posted by Timbucus

How many times do I need to run this? I have done it 10 times - always succeeds and this is with the Buffers in place.

I would say it runs OK for a dozen or so goes then stops prematurely or starts writing elsewhere. Fails are fairly rare, and your hardware combo may be "luckier" than mine!

I've hooked up my Ortonview to my cheapo logic analyser and trying to see if I can trap any problems. I'm seeing write cycles after NENIN goes high, but they all seem to terminate within 1uS of NENIN going high, and we're building in a bigger margin as far as I can see. The only problem with the Sigrok software is that combination triggers with this hardware don't seem to be possible, so I'm having to scroll through megabytes of data!

[SiriusHardware]

Groan, this is awful. Three substantially different results with essentially similar hardware.

Tim: Buffers in, but... capacitors in, or capacitors out? What chip family are your 365s?

Are we all agreed that the classic mode - unbuffered and with capacitors on A8-A11 - is working 100%?

I have been out for most of the day so that is where my testing is going to be for now, in classic (unbuffered) mode. We need to show that there is at least one configuration in which this can be expected to work for all builders / users.