Mk14 vdu

[SiriusHardware]

Ah, I think I see where the confusion came in.

Originally Posted by Karen O

Yes, the PIC is a PIC16F887. My preference is the PIC16F877 but that device doesn't have enough I/Os. And it uses a 16MHz crystal.

I think Tim took this to mean that the 877 has to have a 16MHz crystal.

Not so...

Karen meant the VDU project uses a 16MHz crystal.

The 877 and the 887 can both run at 20MHz but it's easier to generate all the sub-frequencies the VDU requires by starting with 16MHz.

[Slothie]

Originally Posted by SiriusHardware

Ah, I think I see where the confusion came in.

The VDU project needs a 16MHz crystal.

The 877 and the 887 can both run at 20MHz but it's easier to generate all the sub-frequencies the VDU requires by starting with 16MHz.

Phew! That makes sense. Good news because I soldered in my 20MHz crystal this afternoon....

[Timbucus]

I soldered mine in before I read that as well which is also why I panicked... I will move to the PIC14 thread now for this but, as it is relevant to this project for anyone reading: the TL866II+ programmer I have, running its software under Wine on Linux programmed one of my PIC16F877's fine - I know this because my display on the PIC14 says 0000 00 - thanks Karen and Phil!

Ordered the PIC and Crystal for the VDU just now so one project down so time to start this one

[Karen O]

I'm sorry for the confusion over crystal frequency. I go for 20MHz unless there's a compelling reason not to (maximum oomf). In this case I need pixel clocks of 2MHz (graphics mode) and 4MHz (character mode). Since the serial port clock is derived from the crystal, I need to use 16MHz for this project.

Sorry again.

[Slothie]

Originally Posted by Karen O

I'm sorry for the confusion over crystal frequency. I go for 20MHz unless there's a compelling reason not to (maximum oomf). In this case I need pixel clocks of 2MHz (graphics mode) and 4MHz (character mode). Since the serial port clock is derived from the crystal, I need to use 16MHz for this project.

Sorry again.

Its OK just the natural result of a group of people working on 2 projects at once using similar technology... Good job we're not working on getting astronauts to Mars!

[SiriusHardware]

Karen's sentence (which somehow got read out of context) was a direct response to my asking whether she still planned to use a 16F887 with a 16MHz crystal. If the question and the answer were read together, it made perfect sense.

Still waiting for this 64 way DIN a/b male connector to arrive - it has been posted apparently, but still has not flopped onto my doormat.

[Karen O]

I'll make a point of including the original question in a quote box when giving answers to specific questions.

I've just had a worrying thought. Depending on how new the PIC16F887 is, my PIC programmer may not include it in its list of supported devices

Is there any way to determine how old a particular PIC is?

My only comfort: there's a newer version of the PIC16F877 (the 'A' version) and my programmer supported that okay.

I forget how old the technology I'm using really is.

[SiriusHardware]

My 16F887 is a 'non-A' version, as it happens. You didn't say which programmer you have?

I am reasonably sure my Pickit2 programmes these as I already used one in a project some time ago, if that helps?

[SiriusHardware]

I've just been on a quick voyage around the internet and couldn't actually find any reference to a 16F887A, only to the 16F887 (without 'A').

There certainly are 'A' and 'non-A' versions of the 16F877 and many others of that generation.

[Slothie]

Originally Posted by SiriusHardware

I've just been on a quick voyage around the internet and couldn't actually find any reference to a 16F887A, only to the 16F887 (without 'A').

There certainly are 'A' and 'non-A' versions of the 16F877 and many others of that generation.

If you search for "PIC16F887A" on the Microchip website it returns only references to the 887 (non-A). I think the references on google to it must just be people getting confused.

[SiriusHardware]

From the point of view of a project which is specifically designed for hobbyists to build and enjoy there is a lot to be said for sticking with older parts, especially if you happen to have absolute mastery over them as Karen does.

One is that they are exponentially more likely to come in a humanly-handleable, solderable DIP package, and the other is that they can probably run on 5V, which is important if you want to be able to interface directly with other retro hardware.

We use several current high end microprocessors in products at work and all of them are absolutely useless for tinkering with because they are 3V-only parts which only come in very fine-pitch SMD packages or in packages which don't even have pins at all, only 'pads' on the underside of the device.

Give me a DIP packaged PIC or Atmel 89C55 (Flash programmable, runs 8051-family code) any day.

Edit: Just checked, and the standalone programmer software (V2.61) for my Pickit 2 lists all of the 'A' and 'Non-A' versions of PIC16F87x and many other series, but only lists 'non-A' versions for the PIC16F88x series.

[Karen O]

SH,

Your post #211 echoes my sentiments exactly!

Long live DIP!

An interesting thing I've noted about the 'A' version of PIC16F876 is that there is no speed grading. They can all be clocked at 20MHz.

The same is true of the PIC16F887 it seems.

[Timbucus]

So the A just means - we tested them on the production line and we guarantee they won't fall over at 20MHz unlike the others where we solve the problem by rating them lower.

[SiriusHardware]

It's not just that, I think there are certain other significant differences - the 'A' types can use the 'LV' device programming regime for example.

By the time of the 16F88x which came along slightly later, they must all have used the same underlying architecture so there was no need for an 'A' on the end.

With regard to crystal speeds, many of the PICs of that generation have a choice of two config settings for crystal clocks - 'XT' for 'normal' low frequency crystals and 'HS' for 'high frequency' crystals. A few have more modes, for example the 18F452 has a 'PLL' mode which effectively quadruples the crystal clock frequency, up to a maximum of 40MHz (so you'd use a 10MHz crystal to obtain the maximum speed in that particular case).

Karen, I often think modern components will be the doom of our hobby as they become increasingly difficult to solder or even see. Some of the passive components we use in products at work are no bigger than grains of coarse sand, and they don't even have their values marked on them.

[Timbucus]

Oh I have bought non A versions of the 887 that and the crystals (16Mhz) were in the post this morning - hopefully that should be OK - ready to get stuck in on the VDU now...



I fear you may be correct Sirius on electronics as a hobby - the maker community are very much focused around modules at human sizes with the small devices arranged on them. So the skills to work with discrete components will slowly become focused on a few specialists - like the software world we will have generations of engineers who string together 10 modules which at the end create a straight through piece of wire.

I actually saw something similar with a large ICL installation back in the 90's where the salesman had listed a huge range of DB9/DB25 connectors, gender changers, DB25 cables, Baluns, Xover connectors, RJ45 converters etc for every terminal. I traced the cabling and realised we could just use one standard part either end - saved 10's of thousands on the job.

This miniaturisation has of course led to clever 40 pin plug in replacements for long unavailable ULA's for the ZX81,Spectrum and Interface 1 (with similar devices for the CBM PLA etc) although a lot of the space is taken up by 5v level converters...

[SiriusHardware]

I often wonder how the people who make those replacement chips get started - do they start off with a dev-kit for the device (CPLD, etc) that they've chosen and then once they have a prototype up and running in 'rough' form with added bits of circuitry hanging off it, get a specific PCB made? I assume so.

It appears that there is only one version of the PIC16F887 and it effectively has 'A' architecture under the bonnet, even if there is no 'A' on the end of the part number. They definitely run at up to 20MHz, so you should be good to go.

Still waiting for that @~!! DIN connector. I may have to force it to arrive by clambering around in the loft, digging out an old board which has one attached and painstakingly desoldering the connector. If I do that, the new one will arrive within a few minutes of my desoldering the last pin.

I do already have a spare MK14 edge connector but I want to hang the 'new' VDU off the end of the 'bridge' board so I can point it at the continuous RAM area on there. For that, I need a DIN connector.

[Karen O]

My plan for testing the PIC Mk14 VDU is to hang a 2732 EPROM on the bus connections. I can pre-program this with some images already kindly made available in this thread. It is not a perfect test but should give us enough confidence to try it on a real Mk14.

As for the NENIN signal: I'll probably arrange that this is asserted while the monitor is tracing through the 256 lines of graphics/character portion of the frame. NENIN will go inactive during frame blanking, thus giving the SC/MP at least a little bit of a look-in. But it'll still be clobbered when the VDU is enabled

Inverse video sounds straightforward: just complement all the bits however, I might not have enough cycles to do that! That being the case, I'll extend the character font to include inverse versions of each character (yeah, seems mad I know, but I have to use tricks such as these sometimes).

The plan in my head just gets clearer and clearer

[SiriusHardware]

I guess we should also make a couple of pre-cooked pages of text for it to display (and for you to programme into your EPROM), as you'll obviously want to know if the (more complicated) character mode works as well. I'll maybe have a look at that over the weekend.

I'll probably use the same EPROM trick initially to test my build of your project before connecting it to my issue VI MK14.

[Karen O]

I'd welcome assistance preparing the EPROM contents. An Intel hex file of up to 4kbyte would be ideal of course. I've already got such a file bearing graphics 'Clive' and 'SC/MP inside'. The addition of some distinctive text would be a very good idea.

[Karen O]

It's not just that, I think there are certain other significant differences - the 'A' types can use the 'LV' device programming regime for example.

I've seen the term 'die shrink' used in the context of newer PICs. This would doubtless open the way for more functionality, not to mention relaxing of speed constraints.

You know, when I first decided to get into PICs I almost ran away because the choice was so overwhelming. In the end I decided my projects would use PIC16F627, PIC16F876 or PIC16F877. Later I added PIC12F625. This core group has sufficed for 99% of my projects.