Compiling a list of SC/MP Project Boards

[Timbucus]

Originally Posted by Phil__G

Agreed, I've built three Slothie (Ian Rolfe) issue 6 boards, two with original components and one with the Martin.cz 2764/6264 carrier, all work perfectly as designed.
The Cherry key mods were done by Ian Lockhart ( ijl_Bitsa on here ) and I dont know why but so far Ian hasnt yet released the gerbers. Perhaps he's waiting for a few more to be built to confirm that everything is correct?

I know he had a LOT of boards made so will be hoping to sell his off before anything else.

The other think with the Slothie boards is that they are a little different in dimensions to the original MK14 but, the extra features like the expansion connector routing make it so much better.

[SiriusHardware]

Do we know whether the issue VII (By Ian Lockhart, ijl_Bitsa) whose name and handle I had forgotten until now) still has the system buses and control signals routed to the rear connector? It would seem unlikely that it would not, so certainly the issue VII, with some improvements (notably a better keyboard) probably represents a step forward from the issue VI - as we might hope it would.

But if IL is indeed looking to sell the many issue VII PCBs he had made, where is he offering them? I note he is located in California so presumably the issue VII PCB, if actually available to buy, would be quite easy for prospective owners to get hold of Stateside?

At one point IL contacted me via PM to offer me an issue VII PCB but I feel such a strong sense of loyalty to my issue VI, having observed the whole process of its development under what we now know were very difficult personal circumstances, that I did not want it to be usurped even by a nominally superior successor. I'm actually as fond of my issue VI as I am of my original SoC issue II, which is really saying something.

We should say that Chris Oddy's MK14E also has the buses and control signals routed to the rear connector, but I think his 'standard' MK14 replica, based as it is on the original Science Of Cambridge issue V PCB, probably does not, unless anyone knows differently?

[sigurasg]

I recently discovered the SC/MP, and because it's so different form the microprocessors I knew from the era, I wrote an SC/MP language spec for Ghidra (https://github.com/sigurasg/GhidraSCMP/). This allows disassembly and perhaps decompilation of SC/MP code - though the decompiler isn't doing too well on KITBUG .

There are however a couple of open questions I have after doing this:
- How does auto-indexing with E behave. Does it always pre-decrement or always post-increment, or does it depend on the value of E?
- Do ILD/DLD/JMP et al with a displacement of 0x80 also substitute E?

I wonder if anyone here would know the truth of the matter, and/or have the hardware to run some code and discover the truth of how the SC/MP behaves in these cases?

Siggi

[Realtime]

The issue VII does have the extra signals routed to the rear connector allowing VDU, etc to be connected. Iss VII is a tidier version of Iss VI, for example via sizes have been increased, tracking tidied up and of course includes the Cherry keys but to all intents it is the same circuit with the same ROM, RAM and logic. Got to say the Cherry keys are very nice to use .

[sigurasg]

Originally Posted by sigurasg

I wonder if anyone here would know the truth of the matter, and/or have the hardware to run some code and discover the truth of how the SC/MP behaves in these cases?

So I found this emulator that does seem to answer my questions. So until and unless I learn better, this is the way my the language spec bends.

[SiriusHardware]

Sigurasg, thanks for joining - as a new joiner your posts will be held for moderation and not seen by us until some time after you originally post them. (This will wear off after you have made a few posts).

To answer your question about the -0x80 displacement and certain instructions, I think the 0x80 = 'E' offset specifically does not apply when the instruction is any kind of jump instruction but I'm not sure about ILD / DLD as they are memory load / store instructions which it usually does apply to. There are others here who are much more active SC/MP coders who may be able to confirm one way or another.

This is a perennial question actually, I think even the first version of Karen's PIC14 code didn't get this entirely right, but was corrected by her in the current version of the PIC14 code.

[sigurasg]

Originally Posted by SiriusHardware

To answer your question about the -0x80 displacement and certain instructions, I think the 0x80 = 'E' offset specifically does not apply when the instruction is any kind of jump instruction but I'm not sure about ILD / DLD as they are memory load / store instructions which it usually does apply to. There are others here who are much more active SC/MP coders who may be able to confirm one way or another.

Actually there are other edge cases to ponder for emulation, and technically for reversing aso. What happens for example on:

XPAL PC
XPAH PC

Does PC increment after the exchange operation or before it? What happens in the case when incrementing PC carries into the high byte?
By the behavior of the XPPC instruction, it looks like incrementing PC occurs after instruction execution, so I'd expect

XPAL PC

to execute from the resultant PC + 1 (modulo 0x1000).
I'd also expect PC carry to modify the high byte of PC post-exchange on

XPAH PC

.

Originally Posted by SiriusHardware

This is a perennial question actually, I think even the first version of Karen's PIC14 code didn't get this entirely right, but was corrected by her in the current version of the PIC14 code.

Ah, cool.
I looked up the code (as amended by Phil G) and while I'm no PIC assembly guru, it looks to me that all the effective address computations deal with displacement 0x80 the same way - by substituting E. It also looks like the auto index address mode pre-increments or post-decrements depending on the value of E. So the two emulators are in concordance on both points. Whether they're both correct or both incorrect, I don't know .

I think the only way to conclusively answer how the SC/MP processor deals with these cases it by running code on the real hardware.

I wonder if anyone here has hardware and would be willing to run some test programs on it?

[SiriusHardware]

Quite a few of us here have small systems with real SC/MPs in - I am at work just now (mid afternoon in the UK) - I don't know if any of the rest of the SCAMPers can answer this for you more immediately?

Edit: if you are champing at the bit, here is another emulator of an SC/MP system , the Science of Cambridge MK14, this time online. You may find you need to alter the display settings and crank the emulation speed up to maximum to get it to run in a usable fashion, but it is handy for testing out little blocks of SC/MP code.

http://www.dougrice.plus.com/dev/seg_mk14.htm

For information, the usable RAM on an MK14 runs from address 0x0F12 to about 0x0FF0 - ram bytes before and after those lower and upper limits are used in various ways by the MK14's monitor program. Any test code you try to write and run, place it somewhere between those limits (most user programs start at 0F12 but if you are wanting to test the effects of negative displacements you might want to position it higher up in the range).

[sigurasg]

Originally Posted by SiriusHardware

Quite a few of us here have small systems with real SC/MPs in - I am at work just now (mid afternoon in the UK) - I don't know if any of the rest of the SCAMPers can answer this for you more immediately?

Thanks, there's no great urgency. I think I also need to figure out how to write code for the SC/MP, and especially to figure out how test programs can signal back results.

Originally Posted by SiriusHardware

Edit: if you are champing at the bit, here is another emulator of an SC/MP system , the Science of Cambridge MK14, this time online. You may find you need to alter the display settings and crank the emulation speed up to maximum to get it to run in a usable fashion, but it is handy for testing out little blocks of SC/MP code.

http://www.dougrice.plus.com/dev/seg_mk14.htm

For information, the usable RAM on an MK14 runs from address 0x0F12 to about 0x0FF0 - ram bytes before and after those lower and upper limits are used in various ways by the MK14's monitor program. Any test code you try to write and run, place it somewhere between those limits (most user programs start at 0F12 but if you are wanting to test the effects of negative displacements you might want to position it higher up in the range).

Nice. Thanks. Lemme play with this a bit, see what I can come up with for test programs.

[Mark1960]

The PC is incremented before the instruction is fetched. After reset PC is 0000 but is incremented before the first instruction is read from 0001.

The same for XPAL PC, the accumulator is exchanged with the low byte of the PC, then the PC is incremented before fetching the instruction.

[SiriusHardware]

Sigurasg, you may notice the online emulator offers you a choice of 'old' or 'new' versions of the O/S - early MK14s came with an operating system which was byte for byte identical to the national 'SCMPKB' ROM used in their 'Introkit' system when that system had the added-on keypad and display.

The old / original O.S. was quite laborious, requiring five keystrokes per data byte entered. A little while after the original release of the MK14 a 'new' OS was offered as an upgrade which is the one referred to as the 'new' or 'V2' O/S on that emulator's website.

From your point of view the most valuable thing it did was to greatly improve the user interface so that once you were in code entry mode, it only took three keystrokes to enter each byte into memory. If you value your sanity you will choose the 'new' / V2 O.S. when using that online emulator - I notice the 'quick manual' explaining how to enter code does so on the assumption that you will be using the 'new' / V2 monitor.

With regard to examining the results arising, place the bytes 90 FE (a jump which jumps back to itself) at the end of any test code you write so it just goes into a controlled tight loop after running your test code, then RESET the machine and use the monitor to go and look at the contents of the memory area your test code was attempting to change.

The RAM is static and the OS does not test / clear the memory when coming up out of reset, so any RAM location contents changed by your test code will retain the values your code placed there.

[sigurasg]

Maybe I should start a new thread on this topic?

[Timbucus]

Yes I was wondering if we asked a moderator to split off the thread at #103 maybe called SC/MP emulation.

Nice to see you using the SCRUMPI 3 emulator from Paul - hopefully you have seen the history of this machine on the Assembly Manual link at the bottom of the site http://scrumpi.uk

[sigurasg]

Originally Posted by Timbucus

Yes I was wondering if we asked a moderator to split off the thread at #103 maybe called SC/MP emulation.

Thanks, I've started a new thread. My apologies for the hijack, please split off my diversion if that's the done thing(TM) here.

Originally Posted by Timbucus

Nice to see you using the SCRUMPI 3 emulator from Paul - hopefully you have seen the history of this machine on the Assembly Manual link at the bottom of the site http://scrumpi.uk

I had not seen that, thanks!