Return-Path: Delivered-To: craig@sbc-85.com Received: from gator4254.hostgator.com by gator4254.hostgator.com with LMTP id cNjmOWREtGiNqAAAcizydQ (envelope-from ) for ; Sun, 31 Aug 2025 07:47:32 -0500 Return-path: Envelope-to: 052922@sbc-85.com Delivery-date: Sun, 31 Aug 2025 07:47:32 -0500 Received: from mail-ed1-f46.google.com ([209.85.208.46]:52589) by gator4254.hostgator.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.1) (envelope-from ) id 1ushT2-00000000B6s-1hFp for 052922@sbc-85.com; Sun, 31 Aug 2025 07:47:32 -0500 Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-61ded2712f4so556022a12.1 for <052922@sbc-85.com>; Sun, 31 Aug 2025 05:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sort.is; s=google; t=1756644441; x=1757249241; 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=9FaMffcPSsPvxnujDoqW7e7VH6Wt/zCjPmWHKghQuBY=; b=m3vF836jkjxrjOcxmOfR6hQdOjNc2KZkBcMcBz7cSO3WJ5y4ds/JFN5hKr0f/0OjAe YDNT7wx8XdzuetKefijXPpm4nmYoaTD/kR3r8tfEw0vun2nIua6SNltElZ54rj1EayUR Ud85+exVZJx0GN/MWX0tfEbUrD+Fzi8d4LHCjxc6xOewTt1Qk74g9tLiE/JpSzsxxNHk H9Qzaq4BKAAd9vNTuVyhA3Q9Sr7uGG19HdK3tUGUq5LtVeKAmKtQWhg3njJRqBUSF9Vb Q3uUIBjyCpbRqaCT2X/UkPNFHvfqm23fXIv2y5loFxjRHVk2QkIcntLbH54WtwjNazWM uYnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756644441; x=1757249241; 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=9FaMffcPSsPvxnujDoqW7e7VH6Wt/zCjPmWHKghQuBY=; b=WWQz35CW9FxYZUMkvtLpv4hHRDHGDquCIDZeK79vY3QuhXcf5Y3W45m+buSne+jLWa GzURF4eboZ+ig7WNZuiCYUA68hYATKT6/J0IoVDZ1ABdufTjkGmxn2lQ82T0QryGDLiz 8gO5Ps7QWg2Q9JeW1Q6/CcMmoinESIMBp/QxUvMRCEZri9utEOVrywjJWRTwymqIfTir jn1AFBLtkMZwZSNy+QqavP/EYrZ6lisxPxSGOOIazPWDLhK2t8O+gzOgJRpUB3FbszOU 54hBWnSw2YlQ+qGuHZTgS3QkMFGDIslaNhh4Lpy2bThEfiS7z8KEjWmjYACpCN7SkZdW 7kFA== X-Gm-Message-State: AOJu0YwrDWi4lp1NAm8HyjjARpfIJNDeFYbOHyIi9yXm4a39TrtaLCnJ ogNf+3NZQ7litZPC6ZzMcV+QR2ANnCWcpRuKfKud1rWYakKNqNsQby2psfJw0txuT/w3GP+2Mzy IMOI5Wgg6BBDEc2qJ/Gy4Dagyo9VBT6TJzpQLuq+Q+z0Dh93qYD2Y X-Gm-Gg: ASbGncsFd6KpV2i0SYVSz1yGk3BRuX/OvJPwBx8k44+B0tnOa+Vgy3RuViye5aEC578 pkG/WLYExRGqRsj8QSlr2vT7oBS/tQoK01BXWZf47ZF9PAVfRt4umzpq2r3wybf1H92vcaGn8jx pvDYc7DBRhh4k1T36FqU5a+pBMfVXTFuTPsvSOiJV0zuSj79ra09bcrQXeY+Z+0Tt1WI/6M75I4 TNqdoBKAeTy/JPRBfL7FRLYoBVp2+85bHFY3F2y2j8iqRrlh4E= X-Google-Smtp-Source: AGHT+IE/KFroDsXezYRB8VOmAXgStWb7bD2OqfTxYTcLgyqq0RSHZaqx8U4+rFQvcbpxsrQUNH90lBoQlCWfAsTeQFg= X-Received: by 2002:a05:6402:13cf:b0:61c:4d37:6aa8 with SMTP id 4fb4d7f45d1cf-61d26eb4a9cmr4560410a12.35.1756644440308; Sun, 31 Aug 2025 05:47:20 -0700 (PDT) MIME-Version: 1.0 References: <2acd01dc16b5$e6b27920$b4176b60$@sbc-85.com> In-Reply-To: <2acd01dc16b5$e6b27920$b4176b60$@sbc-85.com> From: =?UTF-8?B?U2lndXLDsHVyIMOBc2dlaXJzc29u?= Date: Sun, 31 Aug 2025 08:47:08 -0400 X-Gm-Features: Ac12FXw1ZTY6aSy8tMMy1FcE3lUyatBU0fRB6gTndz3raRFchotLHiwM5kjqzoo Message-ID: Subject: Re: Ghidra disassembler for SC/MP To: craig@sbc-85.com Cc: 052922@sbc-85.com Content-Type: multipart/alternative; boundary="000000000000dc8e53063da8a7ac" X-Spam-Status: No, score=-4.4 X-Spam-Score: -43 X-Spam-Bar: ---- X-Spam-Flag: NO --000000000000dc8e53063da8a7ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 ju= st -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 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 > --000000000000dc8e53063da8a7ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Craig,

I've just about complete= d the language spec, only there are a couple of questions outstanding.
T= he processor manual is essentially silent on these two points:
  • 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 cle= ar to me which memory locations this code touches:
    LDI 0x10
    XAE
    LD= I 0xAA
    ST @E(P2)
    LDI 0xF0
    XAE
    LDI 0x55
    ST @E(P2)
  • Is = there a JMP E?
    The addressing form used for ILD/DLD/JMP et al is very si= milar 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 t= o know for sure.
    • Since you have hardware, I wonder if you= could test these cases?

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

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

    =C2=A0 IEN
    =C2=A0 = XPPC P3

    but what if an interrupt is taken right af= ter IEN? In this case P3 would take the value of the PC in the interrupt ha= ndler, and the original PC would be lost.
    The manual does address= this, however, mentioning that interrupts are not in fact=C2=A0enabled unt= il one instruction past the IEN. So the instruction sequence above is prett= y much mandatory for returning from interrupt :).=C2=A0

    Thanks,
    Siggi

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

    Hi Siggi,

    =C2=A0

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

    =C2=A0

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

    = =C2=A0

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

    =C2=A0

    =C2=A0=

    Reg= ards,

    craig

    =C2=A0

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

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

    =C2=A0

    Hey there,

    =C2=A0=C2=A0

    In any case, to understand the proc= essor better, I wrote a Ghidra/Sleigh language spec for it. This is very earl= y stage code, but the spec does seem to disassemble SC/MP code without issu= e.

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

    =C2=A0

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

    = =C2=A0

    Siggi

    --000000000000dc8e53063da8a7ac--