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 19th Jan 2022 10:09 pm

Re: Ortonview PCB
 
Indeed yes, we wave goodbye to the cap fix. I've had it running for something like five hours now without a single bit of corruption of any memory that is not being intentionally written to. I built mine on a stamp sized bit of stripboard placed copper up, but you could place the '74 in the position intended for U5 or U6, cut any unwanted PCB track connections to the pads and wire the mod up there.

On any subsequent revision of the PCB the buffers can be removed and the '74 placed where they were, leaving the U5 and U6 (noise generator) circuitry intact.

Mark1960 19th Jan 2022 10:56 pm

Re: Ortonview PCB
 
I am fairly certain that a 74ls74 would also work in the memory corruption fix, as its not dependent on RC delays.

The 74HCT74 fix for the white line seems to work, except for inverse graphics mode, but I don’t think thats a very usefull mode anyway. I think my wiring to a piece of proto board was too long which introduces noise in the video, but that would probably be ok if it was included in the layout.

I was wanting to try the 877A to see the issue, then maybe try adding a single NOP, but been too busy with work and travel over the holidays. Also spent too much time on an idea for a ttl processor, using 74AS870 for registers before realising that its not quite dual port registers and decided it wasn’t going to give a usefull ISA without serious workaround in the register addressing. I managed to find time to assemble one of Phil’s PICL boards, but still not programmed the 877 and tested it yet.

SiriusHardware 20th Jan 2022 12:06 am

Re: Ortonview PCB
 
I agree that inverse (black text on white or black pixels on overall white) is not especially attractive but Karen went to a lot of trouble, in her final days, to emulate that and the other features of the SOC VDU exactly so I think it really has to work as advertised.

If you can somehow make your 74 based white line remover 'case-sensitive' so that it only acts when there is black (not white) immediately following the sync pulse on any given line, that would be great.

It's interesting that all of the original 'classic' ZX computers actually favoured black text on white and I think that was because they were expected to be used on low resolution TV displays (rather than monitors) where spindly white text on a black background might have been a lot harder to read.

Mark1960 20th Jan 2022 7:27 am

Re: Ortonview PCB
 
It might be possible to drive the preset input of the 74HCT74 using a delayed PIC-24 input, inverted and combined with the PIC.26 using a nand gate. This would be relying on the race condition between preset and reset of the 74HCT74, really bad design practice but that makes it more fun.

It also adds more gates, which kind of spoils it.

I’ll keep thinking, probably won’t be able to stop thinking about this now until I think of a neat way to do it.

SiriusHardware 20th Jan 2022 9:45 am

Re: Ortonview PCB
 
I don't know if it helps to remember that inverse mode doesn't actually need fixing because when any given line is being rendered in inverse, the bright line just blends into the overall white background.

It's only when a line is being rendered in non-inverse / normal mode that it requires some kind of active solution.

Slothie 20th Jan 2022 1:37 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1442153)
Last we heard Slothie was trying to squeeze an 887 under the bonnet of Ortonview, I'm assuming that process is currently either parked or moving slowly. .

Yes, sorry about that my cancer reared its head again and I've been busy having tests etc. Not serious, just time consuming. I have looked at it somewhat, I can get it to produce a stable screen, its just not reading the memory for some reason, and locking up the MK14, so I probably have some more config changes to make. I'll be starting treatment soon so will have plenty of time to get out my logic analyser!

SiriusHardware 20th Jan 2022 1:59 pm

Re: Ortonview PCB
 
Sorry to hear you are in the wars again. Obviously you should be looking after yourself first and worrying about this later.

I wonder if there would be some mileage in knocking up an 887-->877 pinout adaptor to reverse that port swap which Karen did ultra-last-minute when she realised that her programmer didn't 'do' the 887. She must have had a very good reason to feel she needed to do that.

Just to recap, although the 877 and the 887 ostensibly have the same pinout, Karen altered her design and code to swap two of the 8-bit ports over when she went from what was going to be the 887 originally, to the 877.

If we have ambitions to use the 887 instead, it may be necessary to swap those ports back over (and change the code accordingly).

Slothie 20th Jan 2022 2:21 pm

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1442331)
Sorry to hear you are in the wars again. Obviously you should be looking after yourself first and worrying about this later.

I wonder if there would be some mileage in knocking up an 887-->877 pinout adaptor to reverse that port swap which Karen did ultra-last-minute when she realised that her programmer didn't 'do' the 887. She must have had a very good reason to feel she needed to do that.

Just to recap, although the 877 and the 887 ostensibly have the same pinout, Karen altered her design and code to swap two of the 8-bit ports over when she went from what was going to be the 887 originally, to the 877.

If we have ambitions to use the 887 instead, it may be necessary to swap those ports back over (and change the code accordingly).

Yes, I was wondering about that. If the 887 works then there'd really be no reason to use the 877/877A so a new PCB layout wouldn't be a problem. I'll look into it as see if I can work out what Karen's thinking was; unfortunately she was a lot more knowledgeable about PICs than me :)

SiriusHardware 20th Jan 2022 5:13 pm

Re: Ortonview PCB
 
Here's the turning point from the original VDU thread:

Quote:

Originally Posted by Karen_O
I will revert to using the PIC16F877 but I need to make two hardware changes: I must swap ports B and D so that the data bus uses the TTL compatible B port.

Really, the '887 only gives me one extra bit of I/O - the /MCLR pin is also port RE3 on the '887. On the '876 it is a straightforward master clear pin.

RE3 is used to sense PS4, so an input. Cunning plan: I use the serial port for video generation, but is only enabled on those scan lines that display text or graphics. During the frame blanking, when the PS4 state needs to be examined, the serial port is switched off. I can arrange that the clock output pin (RC6) is an input at this time and use this to sense PS4. I will couple through a resistor so that, when the serial port is enabled, the 2/4MHz coming out of RC6 doesn't try to drive PS4.

Now the question is, what architectural improvements or changes had been made by the time the 887 came along? Are all of the 887 ports TTL compatible? It would seem odd for Microchip to maintain the overall pinout and yet move the only TTL compatible port from port B on the 877 to port D on the 887 - port D being the 887 port which Karen had originally planned to use as the data bus. She may just have chosen 887 port D as 'D for Data', a handy mnemonic reminder of the port's purpose.

SiriusHardware 20th Jan 2022 5:44 pm

Re: Ortonview PCB
 
I've just had eyeballs on both datasheets and it looks as though the port D pins on the 877 are Schmitt Trigger in input mode, whereas the port D pins on the 887 are TTL in, as are the port B pins. So - it may not be necessary to swap the ports back, unless I've missed something (highly likely).

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.

Slothie 27th Jan 2022 5:32 pm

Re: Ortonview PCB
 
The assembler sets symbols to define the processor in use (__16F877, __16F887), so it should be possible to make one source for both processors, especially since the differences are so minor. If we want to add in code to do blanking, that would be a 887 only option due to the no of i/o pins.
Since the 887 is currently in production, cheap and easy to find I can't think of any good reason to worry about giving support the 877 if its not trivial, because it is getting hard to find and costs twice as much when you do - the code in FW#692 would still work for that anyhow (all versions are available on the Bitchute repository).

SiriusHardware 28th Feb 2022 9:44 pm

Re: Ortonview PCB
 
Just tried to take a moment to test the code as modified by Slothie for 887 and unfortunately, although the code programs OK (with PicKit2) it stops the MK14 dead. The most likely explanation is my unfamiliarity with MPLAB X, resulting in the assembled code being just plain wrong.

I went to poke around at the link given in #565 and although I can find the .asm file from which I apparently unsuccessfully assembled the hex, I can't find the assembled '887' version hex there.

Ian, could I ask you to post the known working assembled hex you made from that .asm in a .zip file here? I just need to verify that my 887 - brand new as far as I know - is actually working, then I'll try to work out what I'm doing wrong with MPLAB X.

Slothie 28th Feb 2022 10:28 pm

Re: Ortonview PCB
 
1 Attachment(s)
Quote:

Originally Posted by SiriusHardware (Post 1453048)
Ian, could I ask you to post the known working assembled hex you made from that .asm in a .zip file here? I just need to verify that my 887 - brand new as far as I know - is actually working, then I'll try to work out what I'm doing wrong with MPLAB X.

This is the hex I used.

Slothie 28th Feb 2022 10:34 pm

Re: Ortonview PCB
 
p.s. the hex file in Bitbucket isn't the one for the version in the branch - I forgot to update it.

SiriusHardware 28th Feb 2022 11:44 pm

Re: Ortonview PCB
 
Just noticed this Slothie, thanks. It's a bit late for me to follow through this evening but I will have another bash at it tomorrow evening.

SiriusHardware 1st Mar 2022 6:18 pm

Re: Ortonview PCB
 
Yes, the PIC16F887 code attached to #583 is good and I can confirm that there is thankfully no side-to-side shudder in graphics mode. I am again struck by how beautifully clean and stable the image produced by Ortonview is. Mine 'just works' straight away from power on, no need for a post-power-on reset but my issue VI and Ortonview are heavily populated with supply decoupling capacitors including two highish value (10uF?) SMD ceramics right on the supply pins of the PIC.

I'll have to have a look at my MPLAB X project settings and try to work out why my version of the assembled code didn't work.

A while back we mused over the idea of making a few more images for the MK14 VDU / Ortonview to display, you (Slothie) used the Linux image utility GIMP to reduce a chosen image to a 64 x 64 monochrome .BMP.

How did you do that again?

Mark1960 1st Mar 2022 11:48 pm

Re: Ortonview PCB
 
I took another look at the video, sync and clock outputs of the PIC. I think the circuit of #519 could be made to work to remove the white band with a firmware mod.

As it is now the pic pin 25 is high when the serial output is not active. Then when the serial output is initialised pin 25 is pulled low and the data output initialises to high, which gives us the white band until the data output begins and pin 25 starts to clock data into the Ď74.

Possible solution is firmware mod as follows. Before init of the serial output, set the data output low for normal or high for inverse, then set pin 25 low, and then initialise the serial output. We might also need to set pin 25 high again at the end of each line, Iím not sure if the low state of pin 25 would be remembered when the serial output is disabled.

This might also allow removal of the RC network, which was to stop the falling edge of the clock at initialisation from clocking the initial state of the serial output into the Ď74.

SiriusHardware 2nd Mar 2022 12:29 am

Re: Ortonview PCB
 
I'm seriously considering making a third Ortonview, this time based on one of the Microchip '44-pin demo' boards which came with some versions of the Pickit2 and the Pickit3. I have several of them. The 44 pads will accept 44-pin QFP versions of several devices including the 877 / 877A and 887.

Using one of these would allow the video-out, sync, bright line blanking and Page select 4 all to have their own pins. Obviously, it is not easy to swap devices around on these solder-only boards so I'd probably pick the 887 and stick with that.

Mind you, given the time it seems to take me to get onto anything at the moment ... don't wait up.

Slothie 2nd Mar 2022 1:26 am

Re: Ortonview PCB
 
Quote:

Originally Posted by SiriusHardware (Post 1453250)
A while back we mused over the idea of making a few more images for the MK14 VDU / Ortonview to display, you (Slothie) used the Linux image utility GIMP to reduce a chosen image to a 64 x 64 monochrome .BMP.

How did you do that again?

I adjusted the brightness/contrast, cropped and scaled to 64x64, then used the Image->Mode->Indexed... dialog, selecting "use black and white 1-bit pallette" and the "Floyd-Steinburg (reduced colour bleed)" algorithm (or whatever looks best).

If it looks wrong, use control-Z to undo, adjust the brightness/contrast and try again.

I think I then just used "File->Ecport As" and changed the file extension to .bmp, I might have had to change the image settings to make it monochrome?

SiriusHardware 2nd Mar 2022 6:02 pm

Re: Ortonview PCB
 
1 Attachment(s)
Thanks Slothie - now I suppose we just need to come up with some suitably relevant images to grab and downscale.

Attached, offscreen graphic image from OrtonView_887. This was just crudely hand-drawn.

No left-hand bright line because I have the (CRT monitor) image shifted about 15% to the left, placing the bright line off screen.

Timbucus 3rd Mar 2022 5:08 pm

Re: Ortonview PCB
 
Nice picture of the NatSemi logo! I have still not had chance to make the mods even though I have the chip sat on the Ortonview on my desk.

SiriusHardware 3rd Mar 2022 8:05 pm

Re: Ortonview PCB
 
1 Attachment(s)
Not offscreen yet, but a 64 x 64 pixel homage to the MK14 manual cover (The actual writing on the lower half of the manual cover would be impossible to represent at such a rough pixel resolution).

Timbucus 4th Mar 2022 4:04 pm

Re: Ortonview PCB
 
That looks lovely but, I wish they had always had the K as a Capital as it stands for Microcomputer Kit rather than Mark. The box cover actually had a dot after the k as well to rub salt in the wound. The mains adapter used MK14 as did the adverts. Maybe as it is not on a slant in this instance as on the manual, it would look better as a Capital, he says as he does not have to make the change?

SiriusHardware 4th Mar 2022 5:17 pm

Re: Ortonview PCB
 
2 Attachment(s)
I took the font and format exactly the way it is written on the manual cover and on the lower edge of the original MK14 (See attached detail #1). I'm sure this original arrangement is the reason why people frequently took it for 'Mark' rather than 'Emm Kay', but for better or worse, the lower case 'k' is authentic at least for the manual.

I did originally mean to have 'Mk14' on the same roughly 15 degree upward slant as the parallel lines, but try as I might I could not get the font to look right due to the very coarse pixel resolution, so I had to settle for plain horizontal text. Attached #2, one of my earlier attempts. After I cleaned the rotated text up while doing my best to keep it looking approximately like the original, it was no longer quite at the same angle as the diagonal lines. If you prefer the slanted version I could possibly 'fix' the slant mismatch by changing the slope of the parallel lines to match the slope of the text, rather than trying to rotate the text a few degrees clockwise.

If you want to have a play with it I'd be happy to email you the original images and you can see what you can come up with. I'm just thinking that the simplest VDU 'demo' of all is a slideshow, the downside being that we need to have a few images for it to display. I welcome any suggestions for images for that purpose but it has to be something which can realistically be represented in 64 x 64 pixels, and ideally somehow relevant to the MK14.

You could use a modified, continually running version of send14 with a consecutive list of image hex files to upload - if you you didn't want to see them loading you could load them alternately at 0200-03FF and 0400-05FF in extra-extra RAM and have the script control the state of the relevant page select line via an 8154 or flag output so that the current image is displayed from one area of RAM while the next image is being loaded into the other.

Timbucus 4th Mar 2022 5:29 pm

Re: Ortonview PCB
 
I think you are right it looks better straight than on a slant and as you say it is authentic to the Manual and Box - I was merely musing their own lack of typographic consistency.

One I did wonder about was a version of the stylised early board in the first advert that might make an image with the £39.95 in a single pixel price. I may have a play with that one.

I had wondered about how many images could be fitted in RAM with some simple RLE encoding as maybe the effect of filling active video RAM would look like a nice wipe effect... I wish I had some time.


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

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