Idiot building a MK14 thread

[Phil__G]

Its ok I already PM'd Colin immediately after his post but I dont think he's seen it yet

[SiriusHardware]

Probably hammering up the road to Stonehaven as we speak....

[SiriusHardware]

I should probably scale back my original statement about the book being 'The manual the MK14 should have come with'. It is not a replacement for the manual - for instance it doesn't have the large number of example programs and routines in it that the original manual does, but it does have a lot of stuff in which SHOULD have been in the original manual, such as the greatly expanded (almost fully English) descriptions of what each instruction does, the section on subroutine calls and how to use them, the section on Input / Output which covers how to write to the display, how to read from the keypad and has more detailed information about the I/O portion of the 8154 I/O chip, and the section about interrupts, DMA and multiprocessing.

[Timbucus]

That book was going to be the manual as SoC commissioned Williamson to write it along with his prototype paying him about £5K I believe in embarrassment when they dropped his design.

Not sure who wrote the manual - maybe the used some early portions of the draft that Williamson wrote?

David Johnson-Davies wrote the Further Applications Programs one and he believed Nick Toop wrote the VDU and Cassette ones.

I wonder how much input Tony Amendt had as he was the NS liaison to SoC (see comment on this entry https://www.old-computers.com/museum...sp?c=1147&st=1

I cant find the reference but Steve Furbur also said he wired the first prototype somewhere.

[SiriusHardware]

Maybe they used some early portions of the draft that Williamson wrote?

Possibly, although it is in some ways very up to date - for example when reminding the reader how to enter code, it is the key sequence for the 'new' OS which is used. In the memory map table the 0200-07FF area is shown as unused and available for additional hardware, especially memory, to be mapped into. On the same page there is a weary footnote to the effect that if you have an 'old' MK14 there are some mods you will have to do to free up that area - so some portions of the book were written with an assumed base level of an issue V MK14 (which would have been supplied by then with the new OS as standard).

[ortek_service]

Originally Posted by SiriusHardware

Agree.

Is there a 'classic' temperature sensing IC with a parallel interface? There must have been one at one time before all of these fangly-dangly modern serial buses came along.

Or failing that, a temperature sensor IC or module with a conventional (asynchronous) serial interface: There is example code in the manual for sending and receiving asynchronous serial data.

IIRC, Colin has an Arduino, so may be used to using the dev tools for creating programs on that. And there's probably example code out there to interface it to a DS18(B)20 and output this a serial data, for feeding into the MK14. - I've got someone's veroboard-constructed project module (with a DS18B20 + a 3 digit LED display and a couple of 74HC595 Serial to parallel converters), that appears to be for plugging on top of an arduino, as a shield for it -

[SiriusHardware]

I don't know, there' something quite disheartening about the idea of having to use a microprocessor module which is considerably more powerful and has more functionality than the MK14 itself as a peripheral for the MK14, it raises the question, why not just set the MK14 aside and use the Arduino for the actual job. (as has obviously been done by whoever made that DS1820 Arduino shield).

It's been said before that the MK14 was very much the Arduino of its day, especially if you had the PROM programmer so you could program it to do dedicated tasks straight from power-on, but most actual Arduinos now have a considerably greater amount of (reprogrammable) code memory and RAM and a multitude of serial bus interfaces and onboard timers and more i/o ports, etc - so the use of an Arduino as an MK14 peripheral interface feels a little bit top heavy.

It's certainly true that you could quite easily use an Arduino to read a one-wire temperature sensor and output the readings to the MK14 as parallel data, there is an already existing 'Onewire' comms library for the Arduino.

[Timbucus]

Originally Posted by SiriusHardware

Possibly, although it is in some ways very up to date - for example when reminding the reader how to enter code, it is the key sequence for the 'new' OS which is used. In the memory map table the 0200-07FF area is shown as unused and available for additional hardware, especially memory, to be mapped into. On the same page there is a weary footnote to the effect that if you have an 'old' MK14 there are some mods you will have to do to free up that area - so some portions of the book were written with an assumed base level of an issue V MK14 (which would have been supplied by then with the new OS as standard).

Ah interesting which means we still do not know who wrote the code - as it came so late rather than with the first MK14 (the early manual was criticised) then maybe Nick was there and had a hand in it as he did join quite early I think.

I wonder how much input Tony Amendt had as he was the NS liaison to SoC

As a further point chatting to a friend of mine who used SC/MP chips commercially in fruit machines at the time he mentioned a discussion with Dave Brown also a NS rep but not for Sinclair who claimed to have designed the MK14

[ortek_service]

Originally Posted by SiriusHardware

I don't know, there' something quite disheartening about the idea of having to use a microprocessor module which is considerably more powerful and has more functionality than the MK14 itself as a peripheral for the MK14, it raises the question, why not just set the MK14 aside and use the Arduino for the actual job. (as has obviously been done by whoever made that DS1820 Arduino shield).
>>
>>
It's certainly true that you could quite easily use an Arduino to read a one-wire temperature sensor and output the readings to the MK14 as parallel data, there is an already existing 'Onewire' comms library for the Arduino.

Well I was thinking it might be a useful starting point, until more-familiar the SC/MP assembler / useful to have something working to 'scope, whilst debugging SC/MP-code to do it directly on the SC/MP.
(I had heard from an experienced embedded programmer, that the Dallas/Maxim 1-wire protocol wasn't always too easy and he'd had to resort to 'scoping the comms on the Maxim PC interface to it to work out some rather-critical timing that the datasheet wasn't too clear on).

[SiriusHardware]

I seem to remember having to bit-bang the one-wire protocol for my own Arduino DS18B20 project, or maybe I just did that so that I gained a better understanding of it. Unfortunately I can't find that Arduino code now, it may have been on a Linux netbook where the Linux installation got completely smashed up when I let it try to update its Linux distro to a newer version - that's always a fatal mistake for me.

Pre-built libraries are great for getting things up and running quickly but they rather absolve you of the need to know exactly what you are doing. (Which is of course the philosophy of Arduino, to enable people to use microcontrollers and peripheral ICs without necessarily having to understand them at register level).