Return-Path: Delivered-To: craig@sbc-85.com Received: from gator4254.hostgator.com by gator4254.hostgator.com with LMTP id iPFWKt+qtGjKVwMAcizydQ (envelope-from ) for ; Sun, 31 Aug 2025 15:04:47 -0500 Return-path: Envelope-to: craig@sbc-85.com Delivery-date: Sun, 31 Aug 2025 15:04:47 -0500 Received: from mail-ed1-f49.google.com ([209.85.208.49]:47613) by gator4254.hostgator.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.1) (envelope-from ) id 1usoIB-00000000upx-0Bys for craig@sbc-85.com; Sun, 31 Aug 2025 15:04:47 -0500 Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-61cb4370e7bso5474239a12.3 for ; Sun, 31 Aug 2025 13:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sort.is; s=google; t=1756670675; x=1757275475; darn=sbc-85.com; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Gv33rb74ogiZLEx3FsOz/eP9Yr/4x1aNnLwt0Wm9KS8=; b=teM+o9X++8QNTltFd2glbamWV5j7ZjhRJm5WMR4Ztq75VozSw0bPL/XotE0x0flBHf ++4tlf6QwrlMRTsQCYesH7F2Bxi/nt9yT+h/xBnd4L/djYERHJtekGFyvWOcaaL0GZDy 5iN8IR7nGL7toPaZElGeg8Pj7Dj4OJJOPl1FdTERwahhwpaDgPNFtCYP+v6BxpQGmWz0 PQnWXJdmxq682cVOcx4TcN5zRnnTX0OM9wTqisf4ehV5nfU6+8cAcnfIeyjAfu2kYG1B ZxXQa9FgFiAHTEgtS4NNHhMoXwE9dUqcvFi3NOe0nHcXtu8/jakQ+3/mBrUNKV4xBW9B OJaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756670675; x=1757275475; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Gv33rb74ogiZLEx3FsOz/eP9Yr/4x1aNnLwt0Wm9KS8=; b=RuAn9XrQJkjuD3wOOD9Ev1Izt4J145xxY/CBgjkMov0IG8LoCLIH67amOa/a4jaW2g xI9UfVxGaEFnjJlwTBLvbsG1UK8Nw7vG+ce3MZlkuhcI3+9G8e6eAJMTCzTShtGBTuxY 2hb7LMT7YYZmECUoORmR1R7TsUNTCWOFWJ1aoB8o7nF4d0X7CrbHsTQgVFzgXs+mwjq0 Hpl8Q0o5j5YfbJdg9fgoAg80sw8iZpoDRpjTjNSPKP0cuZ0NouA5bMzOSKldnf1LTGNr 81Iv8bwRBuim4cH0AVM5FUAIXBxOfVQ2kx0U3gtTZby43AhzyRR4mCmS1HtclpDiIhSf hq8g== X-Gm-Message-State: AOJu0YyW3mKDnoU+W7/UkER4VDngkpcOjMCgjhIOlUnbtVXzvaX0I+KE hXEGCKlZMpXxGRBAzJLCNsOlnZRDd5xH1EkK9VDGIRcCDdEYvLqaxzmEdQvS2VFzhyCOQiCwK9O el+noiam1LiDf65JwAN8sa83Vdq5VcQTHucJfx7lD9T1rhAtPQn3d X-Gm-Gg: ASbGncuw4haQXLSpQVZP12xb+ALChpD8WWotjiTRs0snNu3UywFuM6HsbnMgbxypDRW JbUSPX+mz9cewQ3ynnelQecK5hgx7Z7G0kPHdK/GwePe4kEp+qB7MjpxncG5QFh9MC1Kc3Vq3eg oTOj5NHKsCfbHe1mTPCV4MTFOQ3+wx2s8TW1mB9P/8xky0P4PePbmixxJ64CakQbykAnbYi1809 7ctMzP4rT7psJalV52o75chYC+TV2HYIqJqZbJgQ8Zw52IP3VY= X-Google-Smtp-Source: AGHT+IHO8R3hqM/RFEVRw+TUluvJapWkpAkGy/EuqNMeOjgRGYgbGnmu7dmCHyWqD5ECtW1FKAoKVW83AoVEZmcx5FY= X-Received: by 2002:a05:6402:2815:b0:61c:7160:734e with SMTP id 4fb4d7f45d1cf-61d26daa12dmr5265583a12.29.1756670674923; Sun, 31 Aug 2025 13:04:34 -0700 (PDT) MIME-Version: 1.0 References: <2acd01dc16b5$e6b27920$b4176b60$@sbc-85.com> <2e3301dc1aad$5930b160$0b921420$@sbc-85.com> In-Reply-To: <2e3301dc1aad$5930b160$0b921420$@sbc-85.com> From: =?UTF-8?B?U2lndXLDsHVyIMOBc2dlaXJzc29u?= Date: Sun, 31 Aug 2025 16:04:24 -0400 X-Gm-Features: Ac12FXzgwP4c-YkQ6t545cRD3ZPha0bGWXP7fe0g6nDFQ-7Hi8MSa8xMu8JPYVA Message-ID: Subject: Re: Ghidra disassembler for SC/MP To: craig@sbc-85.com Cc: 052922@sbc-85.com Content-Type: multipart/alternative; boundary="000000000000910664063daec3d7" X-Spam-Status: No, score=-4.4 X-Spam-Score: -43 X-Spam-Bar: ---- X-Spam-Flag: NO --000000000000910664063daec3d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Craig, I shot a message on the UK vintage thread you linked. Thanks, Siggi On Sun, Aug 31, 2025 at 3:27=E2=80=AFPM wrote: > Hi Siggi, > > > > 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. > > > > 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 thin= k > 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. > > > > Right now I found another bug in NIBL that I am trying to fix so it may b= e > a couple of days until I can get to your questions. > > > > Regards > > craig > > > > *From:* Sigur=C3=B0ur =C3=81sgeirsson > *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 whe= n 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 th= at > 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 wrote: > > Hi Siggi, > > > > Thanks for letting me know about your C compiler thoughts and initial wor= k > 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:* Sigur=C3=B0ur =C3=81sgeirsson > *Sent:* Tuesday, August 26, 2025 6:45 AM > *To:* 052922@sbc-85.com > *Subject:* Ghidra disassembler for SC/MP > > > > Hey there, > > > > 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 m= y > 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 b= e > 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... > > > > 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? > > > > Siggi > > --000000000000910664063daec3d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Craig,

I shot a message on the UK v= intage thread you linked.

Thanks,
Siggi<= /div>

On Sun, Aug 31, 2025 at 3:27=E2=80=AFPM <craig@sbc-85.com> wrote:

Hi Siggi,

=C2=A0

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

<= u>=C2=A0

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.=

=C2=A0

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.

= =C2=A0

Regards

craig

=C2=A0

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

=C2=A0

Hey Craig,

=C2=A0

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

  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 0xA= A
    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 w= hether a displacement of 0x80 implies E, or just -128. I rather think the l= atter, but it would be good to know for sure.
<= p class=3D"MsoNormal">Since you have hardware, I wonder if you could test t= hese cases?

=C2= =A0

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 incremente= d after the register swap, so the destination pointer register must = always be loaded with the destination less one :).

<= div>

=C2=A0

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

=C2=A0 IEN

=

=C2=A0 XPPC P3

=C2=A0

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 woul= d be lost.

The manual do= es address this, however, mentioning that interrupts are not in fact=C2=A0e= nabled until one instruction past the IEN. So the instruction sequence abov= e is pretty much mandatory for returning from interrupt :).=C2=A0=

=C2=A0

Thanks,

Siggi

=C2=A0

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

Hi Siggi,=

=C2=A0

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

<= span style=3D"font-size:11pt">=C2=A0

Anyon= e heard of the "Nibbler" by Digi-Key around 1978? - Page 2 - UK V= intage Radio Repair and Restoration Discussion Forum

=C2=A0

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

=C2=A0

=C2=A0

Regards,<= /span>

craig

=C2=A0

=C2=A0

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

<= p class=3D"MsoNormal">=C2=A0

H= ey there,

=C2=A0=

I saw your videos about the Nibbler, = and it piqued my curiosity about the SC/MP processor. The instruction and r= egister sets are pretty unique to my eye, though in a way much better put t= ogether than the initial MC6800 instruc= tion 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.<= /u>

=C2=A0=C2=A0

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

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

=C2=A0

<= p class=3D"MsoNormal">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 h= elp hang out?

=C2=A0<= /u>

Siggi

--000000000000910664063daec3d7--