Return-Path: Delivered-To: craig@sbc-85.com Received: from gator4254.hostgator.com by gator4254.hostgator.com with LMTP id kPdGEzqitGhQ+AAAcizydQ (envelope-from ) for ; Sun, 31 Aug 2025 14:27:54 -0500 Return-path: Envelope-to: 052922@sbc-85.com Delivery-date: Sun, 31 Aug 2025 14:27:54 -0500 Received: from c-73-240-244-150.hsd1.wa.comcast.net ([73.240.244.150]:58211 helo=BasementDesk) by gator4254.hostgator.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.1) (envelope-from ) id 1usniU-00000000GtF-0E12; Sun, 31 Aug 2025 14:27:54 -0500 From: To: =?utf-8?Q?'Sigur=C3=B0ur_=C3=81sgeirsson'?= Cc: <052922@sbc-85.com> References: <2acd01dc16b5$e6b27920$b4176b60$@sbc-85.com> In-Reply-To: Subject: RE: Ghidra disassembler for SC/MP Date: Sun, 31 Aug 2025 12:27:53 -0700 Message-ID: <2e3301dc1aad$5930b160$0b921420$@sbc-85.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2E34_01DC1A72.ACD29CB0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIowkLBtNLZ0Wq7e5VK+2cQ6wLy5wJ5Xlz5AcHKRbCzwfvwcA== Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_2E34_01DC1A72.ACD29CB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Siggi, =20 I agree that the sc/mp documentation leaves much to be desired when = compared to intel or others. They rarely say how things are left after = certain instructions execute. =20 I am new to the SC/MP and am just learning assembly myself. I can try = these things when I get there but right now I am hand assembling. I = think the UK vintage sc/mp is where most of the knowledge base is. = Especially phil G who is maintaining the PIC SC/MP emulator code. =20 Right now I found another bug in NIBL that I am trying to fix so it may = be a couple of days until I can get to your questions. =20 Regards craig =20 From: Sigur=C3=B0ur =C3=81sgeirsson =20 Sent: Sunday, August 31, 2025 5:47 AM To: craig@sbc-85.com Cc: 052922@sbc-85.com Subject: Re: Ghidra disassembler for SC/MP =20 Hey Craig, =20 I've just about completed the language spec, only there are a couple of = questions outstanding. The processor manual is essentially silent on these two points: 1. Auto-indexing with E. Auto-indexing is documented to pre-decrement and post-increment = depending on the displacement. It's not clear to me how it behaves when = the displacement is E, however. So it's not clear to me which memory locations this code touches: LDI 0x10 XAE LDI 0xAA ST @E(P2) LDI 0xF0 XAE LDI 0x55 ST @E(P2) 2. Is there a JMP E? The addressing form used for ILD/DLD/JMP et al is very similar to the EA = form, but it's not clear whether a displacement of 0x80 implies E, or = just -128. I rather think the latter, but it would be good to know for = sure. Since you have hardware, I wonder if you could test these cases? =20 I also had a surprise with the XPPC instruction, which doesn't behave at = all like what I expected. Looking at existing code, though, it's clear = that the PC is incremented after the register swap, so the destination = pointer register must always be loaded with the destination less one :). =20 Lastly I had a momentary kerfuffle regarding interrupts. Since the = processor has no RETI, it's necessary to use at least two instructions = to return from interrupt, namely: IEN XPPC P3 =20 but what if an interrupt is taken right after IEN? In this case P3 would = take the value of the PC in the interrupt handler, and the original PC = would be lost. The manual does address this, however, mentioning that interrupts are = not in fact enabled until one instruction past the IEN. So the = instruction sequence above is pretty much mandatory for returning from = interrupt :).=20 =20 Thanks, Siggi =20 On Tue, Aug 26, 2025 at 2:19=E2=80=AFPM > wrote: Hi Siggi, =20 Thanks for letting me know about your C compiler thoughts and initial = work with the disassembler. The most active SC/MP group is in the UK = vintage radio repair forum. Here are links to a couple of threads that = have most of the SC/MP crowd. =20 Anyone heard of the = = "Nibbler" by Digi-Key around 1978? - Page 2 - UK Vintage Radio Repair = and Restoration Discussion Forum =20 Compiling a list of SC/MP Project Boards - UK Vintage Radio Repair and = Restoration Discussion Forum = =20 =20 =20 Regards, craig =20 =20 From: Sigur=C3=B0ur =C3=81sgeirsson >=20 Sent: Tuesday, August 26, 2025 6:45 AM To: 052922@sbc-85.com =20 Subject: Ghidra disassembler for SC/MP =20 Hey there, =20 I saw your videos about the Nibbler, and it piqued my curiosity about = the SC/MP processor. The instruction and register sets are pretty unique = to my eye, though in a way much better put together than the initial = MC6800 instruction set = . The SC/MP will have no problem with reentrant programming = and it should be relatively easy to e.g. write a C compiler for it. =20 In any case, to understand the processor better, I wrote a Ghidra/Sleigh = language spec for it. This is = very early stage code, but the spec does seem to disassemble SC/MP code = without issue. As I haven't implemented the semantics for most of the instructions, the = Ghidra decompiler is still pretty useless. I'm not sure how good it will = ever do, as the SC/MP instruction set is somewhat unorthodox. My = GhidraMC6800 language spec does quite well with the MC6800, so perhaps = Ghidra will figure it out... =20 Is there some kind of forum or mailing list you know of where SC/MP = nerds who might appreciate this and/or might be willing to help hang = out? =20 Siggi ------=_NextPart_000_2E34_01DC1A72.ACD29CB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Siggi,

 

I agree that the = sc/mp documentation leaves much to be desired when compared to intel or = others.=C2=A0 They rarely say how things are left after certain = instructions execute.

 

I am new to the SC/MP = and am just learning assembly myself.=C2=A0 I can try these things when = I get there but right now I am hand assembling.=C2=A0 I think the UK = vintage sc/mp is where most of the knowledge base is.=C2=A0 Especially = phil G who is maintaining the PIC SC/MP emulator = code.

 

Right now I found = another bug in NIBL that I am trying to fix so it may be a couple of = days until I can get to your questions.

 

Regards

craig

 

From:<= /b> = Sigur=C3=B0ur =C3=81sgeirsson <siggi@sort.is>
Sent: = Sunday, August 31, 2025 5:47 AM
To: = craig@sbc-85.com
Cc: 052922@sbc-85.com
Subject: Re: = Ghidra disassembler for SC/MP

 

Hey = Craig,

 

I've just about completed the language spec, only = there are a couple of questions outstanding.
The processor manual is = essentially silent on these two points:

  1. Auto-indexing with E.
    Auto-indexing is documented to = pre-decrement and post-increment depending on the displacement. It's not = clear to me how it behaves when the displacement is E, however.
    So = it's not clear to me which memory locations this code touches:
    LDI = 0x10
    XAE
    LDI 0xAA
    ST @E(P2)
    LDI 0xF0
    XAE
    LDI = 0x55
    ST @E(P2)
  2. Is there a JMP E?
    The addressing form used for = ILD/DLD/JMP et al is very similar to the EA form, but it's not clear = whether a displacement of 0x80 implies E, or just -128. I rather think = the latter, but it would be good to know for = sure.

Since you have = hardware, I wonder if you could test these = cases?

 

I = also had a surprise with the XPPC instruction, which doesn't behave at = all like what I expected. Looking at existing code, though, it's clear = that the PC is incremented after the register swap, so the = destination pointer register must always be loaded with the destination = less one :).

 

Lastly I had a momentary kerfuffle = regarding interrupts. Since the processor has no RETI, it's necessary to = use at least two instructions to return from interrupt, = namely:

  = IEN

  XPPC = P3

 

but what if an interrupt is taken right after IEN? In = this case P3 would take the value of the PC in the interrupt handler, = and the original PC would be lost.

The manual does address this, however, mentioning that = interrupts are not in fact enabled until one instruction past the = IEN. So the instruction sequence above is pretty much mandatory for = returning from interrupt :). 

 

Thanks,

Siggi

 

On = Tue, Aug 26, 2025 at 2:19=E2=80=AFPM <craig@sbc-85.com> = wrote:

Hi Siggi,

 

Thanks for letting me know about your C = compiler thoughts and initial work with the disassembler.  The most = active SC/MP group is in the UK vintage radio repair forum.  Here = are links to a couple of threads that have most of the SC/MP = crowd.

 

Anyone heard of the "Nibbler" by = Digi-Key around 1978? - Page 2 - UK Vintage Radio Repair and Restoration = Discussion Forum

 

Compiling a list of SC/MP Project Boards - UK Vintage = Radio Repair and Restoration Discussion = Forum

 

 

Regards,

craig

 

 

From:<= /b> = Sigur=C3=B0ur =C3=81sgeirsson <siggi@sort.is>
Sent: Tuesday, August = 26, 2025 6:45 AM
To: 052922@sbc-85.com
Subject: Ghidra = disassembler for SC/MP

 <= /o:p>

Hey = there,

 <= /o:p>

I saw your = videos about the Nibbler, and it piqued my curiosity about the SC/MP = processor. The instruction and register sets are pretty unique to my = eye, though in a way much better put together than the initial MC6800 instruction set. = The SC/MP will have no problem with reentrant programming and it should = be relatively easy to e.g. write a C compiler for = it.

  =

In any = case, to understand the processor better, I wrote a Ghidra/Sleigh language spec for it. This is very = early stage code, but the spec does seem to disassemble SC/MP code = without issue.

As I = haven't implemented the semantics for most of the instructions, the = Ghidra decompiler is still pretty useless. I'm not sure how good it will = ever do, as the SC/MP instruction set is somewhat unorthodox. My = GhidraMC6800 language spec does quite well with the MC6800, so perhaps = Ghidra will figure it out...

 <= /o:p>

Is there = some kind of forum or mailing list you know of where SC/MP nerds who = might appreciate this and/or might be willing to help hang = out?

 <= /o:p>

Siggi

------=_NextPart_000_2E34_01DC1A72.ACD29CB0--