MK14 memory

[Phil__G]

Originally Posted by SiriusHardware

Another point is that the I/O RAM and I/O device have several 'images' each on a real MK14 - at 08xx, 0Axx and 0Cxx, and for absolute compatibility the images should probably appear in all of their proper places in case there is any 'legacy' software which accesses the 8154 via one of the 'image' address ranges instead of what we usually think of as its 'real' address at 0800-08FF.

I think Martins approach on his 'maximal MK14' version (MK14EXP3_2kB-RAM_GAL16V8) was to preserve all the reflections except the ROM, to leave space for a maximum of 2176 bytes of RAM.

At the expense of compatibility with programs written to use them, you could reassign all the reflections too giving a total of 3,200 bytes on an MK14!

This is why I've taken to using gals as they make the whole memory map so flexible, so easy to chop & change when compared to hard-wired decoding. I have the occasional brainfart, dont we all, but generally they do what it says on the tin and save a lot of TTL

Another nice thing with Martins (or Kris's) expansion boards is that they're not permanent, if ever a set of real period chips turns up, you can just unplug the PCB, plug in your period chips and go 'au naturel'

One thing I will do is sort out an orderly list of gal options, ie:
Original 256 byte MK14 (for testing software on a minimal MK14)
MK14 expanded only to the SoC spec, total 512 bytes
MK14 fully expanded leaving the INS8154 RAM area free for a 'real' 8154
MK14 fully expanded including emulating the 128 byte INS8154 RAM
and for Sirius
MK14 fully expanded, with a full 256 bytes where the INS8154 would normally live.
(For these last 2 you would have to remember never to plug in an 8154!)
and of course the Micro-Introkit gal in two versions:
512 bytes ROM for the original NS Kitbug, 3.5k RAM
2k ROM for KB+ and 2k RAM

BTW up to now I've been using stock Atmel 16v8s from RS, but at Finningley Radio Rally I bought a tube of surplus Lattices - well I finally got around to trying them out and the Lattices also work great via the TL866Pro, no problems, in fact my Micro-Introkit is running 'Life' on one as we speak...

Sorry just realised what a rambling post this is...
Cheers
Phil

[Mark1960]

74ls159 could also give the same range of variations with links to wire or the outputs. The only thing missing would be an inverter for the serial output for LCDS.

[Phil__G]

It makes it so flexible though, in the 2k + 2k Micro-Introkit incarnation its just two inverters, but its so easy to go .5 + 3.5 for NS Kitbug, or until the most recent KB+ update it was 1.5 + 2.5, presently 2 + 2, and then the same board does any variant of MK14 expansion with no hardware changes through all these variations
An address latch is beyond me at the moment but its feasible, maybe even the single-stepper plus, theres a lot to learn (though 10+ years obsolete!) which makes them interesting to me
Cheers
Phil

[Mark1960]

The 74ls159 can do 256 byte mapping of ram and rom with jumpers, no need to reprogram anything.

[Phil__G]

Always many ways to skin a cat my soldering iron takes longer to heat up than it takes to flip a gal and adding the 880-8FF ram? Ha! Gotcha!!!
Also I like that the gal could resolve down to a single address decode if you needed to ...but each to his own, either way its a hobby we all enjoy!

[SiriusHardware]

What's the projected life span for the programming in devices like this?

Someone alarmed me a while back by suggesting it might be as little as 25 years. My old, expensive device programmer is totally dependent on several such devices for its operation and I have an Atari ST HDD disc controller which is already dead due to a failed GAL.

You might argue that even that relatively small span of time is of little direct consequence to most of us here now, but I just hate the thought of otherwise perfectly functional hardware eventually dying through bit-rot, or the PLD equivalent.

For that reason I would tend to support Mark's preference for a 'hardware' 74LS159 as potentially the longest-lived option for an address decoder.

I get that you like the fact that GALs etc are so easy to set up for specific ranges and to reconfigure in a matter of minutes should the need arise. It's always preferable to be able to 'rewire' a project on-screen rather than in hardware, if possible.

[Qbertni]

The lattice 16v8 datasheet states 20 years. Unfortunately if the security bit is set you can't even read and rewrite them.

[Phil__G]

Originally Posted by Qbertni

... if the security bit is set you can't even read and rewrite them.

but you can erase them and use them again, they're not throwaways when 'secured'

[Qbertni]

Yes, I meant if you need to preserve the contents on an old piece of equipment.

[Mark1960]

If they are static logic it might be easy to get an arduino or similar to read the output for every input combination and then analyse the functions.

[SiriusHardware]

True, but you have to do that -before- they die.

[ortek_service]

However, I can't really see an issue using GAL's etc. in open-source projects, where you do have access to the programming file. So can simply re-program one (or find someone else with the necessary programmer to do this).

- particularly if you are also using (E)PROM's where the standard retention time was also typically specified as being a relatively-short 10years min.

But fortunately, it seems that 10yrs was a quite-conservative specification (maybe taking into account the whole operating-temperature specification), and many are still working OK 40+ years later (Although it's still not a bad idea to take a readout-copy of any ones in commercial equipment you have, in case / when they do eventually fail).


Of course, more of a worry is where you store the readout backup-copy, as CD-R's DVD-R's etc may be < 2yrs for standard dye-ones (The original Gold ones were apparently 30yrs, but an unbranded one I bought - was 'only' £5, rather than £10 in the mid 1990's - started to all peel-off after around 10-15yrs). Flash memory cards are also only around 10yrs, and it seems SSD's are classed as being 'worn-out' when retention is down to only 2yrs - But how would you know, until it's too late. So should you re-write these every few years. Or stick with HDD's - multiple ones, to have a backup against sudden total failure.
Ensuring there's at least three backup-copies / across people online, is often recommended.

Maybe good old paper-printout is the best (as long as not thermal, and preferably acid-free paper that original stuff was but now NLA?) to ensure a long archive life (Although then might have to ensure it is kept in a shielded-from sunlight to prevent fading / fire / damp / vermin -proof safe etc).

[Phil__G]

Longevity is a real concern, its a frequent topic on other retrocomputing forums too.
Several of my 40-50 year-old software projects were recovered only through finding faded paper printouts in the loft, or by disassembling eproms where the original source is long lost. At the time, no-one would imagine these projects would be of interest 50 years on! Even stuff you've entrusted to cloud storage can disappear as ISPs come & go.
Take Karens techlib page, I've no idea who is funding that now so will it remain long-term? Consequently a few of us have taken a mirror, but there are so many top-notch-but-vulnerable projects hanging by a thread in webland. We've said it before but what we need is a group repository, one we can all post to. Not sure what the answer is but the most long-term-stable platform does seem to be github, but I've no idea how to set that up, I'm not very github-savvy