intel ROM resident assembler, text editor

[Herbert Johnson]

I'm trying to resolve some prior discussion and work, about some Intel
8080 ROM-resident codes as recovered from various ROMS. Um, there will
be a quiz later about this, because someone today asked me about this
work. I advised them to post their request here.

The devsys thread titled "ROM Edit and ASM80" from March 23, 2023,
covers the disassembly of V1.1 ROM EDIT and Assembler; and possibly
ASM80 V1.2 ROM images as well, from Bill Beech. The works discussed are
by Bill Beech and Mark Ogden, with annoying commentary by myself Herb
Johnson who acquired some V1.1 ROM images at some point, did some
disassemblies:

https://www.retrotechnology.com/restore/mon80_proms.html

see "Intel V4.0 monitor, disassembly" which leads to the ASM and EDIT
V1.1 ROMS as well. IN another section later on the page, "Intel 8080 IPB
(Multibus) from MDS-210; V1.1 monitor", I find a set of ROM which also
contain a V1.1 editor and assembler (I don't determine if it's the same
code).

I'm befuddled about the outcome of the thread. There is a V1.1 version
of the EDIT and ASM ROMs, which is disassembled by myself, by Bill
Beech, and by Mark Ogden. Google tells me Mark's V1.1 results are here:

https://github.com/ogdenpm/intel80tools/tree/master/src/edasm_1.1

Bill can point to his versions, he posted one of them in the devsys
thread. My version is on the HTML page above.

On a V1.2 version: Bill introduces the ROM images in the discussion, and
shows some of his V1.1 work as he and Mark exchange results. Bill says
"The V2.0/1.2 ROM images were contained in a bunch of 2716 EPROMs I got
on an iSBC 464 ROM board." There may be a bit error in one of the ROMs.
The bit error may have been worked around in the course of the
discussion, or not - the thread ends without clear resolution.

So it would be of interest, to know if the V1.2 versions were
successfully recovered from Bill's ROMs or from other resources. I'd be
glad to add that info to my Web page. And my correspondent may be
interested in all these outcomes.

Regards Herb Johnson

--
Herb Johnson, New Jersey USA
http://www.retrotechnology.com or .net
preserve and restore 1970's personal computing
email: hjohnson @ retrotechnology dot com
or try later at herbjohnson @ comcast dot net

[William Beech]

Herb,

I have "000000_ROM_ASM80_V1.1_77" and "000000_ROM_EDIT_V1.1_77" in the
ROM images I am preparing for my web page.  This is a ROM set we
discussed awhile back.

I was looking at the V4.0 Monitor just yesterday!  I believe the upper
half of the binary is the V4.0 monitor.  The lower half appears to be a
disassembler?  I am working that one right now.

I remember the discussion about some of this and I believe the ball is
in my court to figure it out.  It will take me a couple of days to
figure it out.  More when I finish with this ROM.

Bill

[William Beech]

Herb,

I may be mistaken and the first half of the ROM contains an assembler
and editor.  I am working that now.

Bill


On 12/13/2024 4:55 PM, Herbert Johnson wrote:

[mark.p...@btinternet.com]

The asm/edit 1.1 were reverse engineered back to PL/M some time ago and are on my Intel80Tools GitHub site. 

I seem to recall it was the v1.2 that had bit rot which prevented sensible reverse engineering.

Mark

Regards

Mark Ogden

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of William Beech <nj...@nj7p.info>
Sent: Saturday, December 14, 2024 7:45:05 PM
To: intel-...@googlegroups.com <intel-...@googlegroups.com>
Subject: Re: intel-devsys intel ROM resident assembler, text editor

 

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/55cebde0-6940-492a-9556-b52a68e4815d%40nj7p.info.

[Herbert Johnson]

Bill Beech and Mark Odgen have stated the previous status of the V1.1
and V1.2 items (assembler, editor), as I recalled. We all did some
work-arounds on the bit-rot, to second-guess the missing V1.2 codes
based on the V1.1 codes. That is my recollection. I don't recall if the
V1.2 codes were resolved further to something "clean".

Also, Bill Beech's results are ASM disassembly; Mark Ogden resolved
code to PL/M 80 source. Not the same thing, if a PL/M assembly output
(or a binary output) is not included. Of course I'll take what's given,
I would like to reference current works.

Don't work hard during the holiday season!

regards Herb

On 12/14/2024 4:02 PM, Mark Ogden wrote:
> The asm/edit 1.1 were reverse engineered back to PL/M some time ago and
> are on my Intel80Tools GitHub site.
> I seem to recall it was the v1.2 that had bit rot which prevented
> sensible reverse engineering.
> Mark
>
>
> Regards
> Mark Ogden

> ------------------------------------------------------------------------
> *From:* William Beech <nj...@nj7p.info>
> *Sent:* Saturday, December 14, 2024 7:45:05 PM

>
> I may be mistaken and the first half of the ROM contains an assembler
> and editor.  I am working that now.
>
> Bill

> On 12/13/2024 4:55 PM, Herbert Johnson wrote:
>> I'm trying to resolve some prior discussion and work, about some Intel
>> 8080 ROM-resident codes as recovered from various ROMS. Um, there will
>> be a quiz later about this, because someone today asked me about this
>> work. I advised them to post their request here.

[mark.p...@btinternet.com]

Herb

Not sure what you meant by the comment on the PL/M version. The makefile included builds the rom binary from the PL/M source and can verify against the original ROMs

Mark

Regards

Mark

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of Herbert Johnson <hjoh...@retrotechnology.com>
Sent: Saturday, December 14, 2024 9:32 pm

To: intel-...@googlegroups.com <intel-...@googlegroups.com>
Subject: Re: intel-devsys intel ROM resident assembler, text editor

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/1deeffd8-11a0-46bd-9906-12254acc3ba7%40retrotechnology.com.

[William Beech]

Herb et. al,

Yes, that is how I remember it.  I have not run across the 1.2 bit-rot
ROMs as yet.  We will work that problem after I have all the other code
up on the site.

Bill

[William Beech]

Mark and Herb,

And then I can generate a disassembly without bit-rot.  Again, I will look into it after I gather all the other ROMs I have work on.

Thanks!

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/VI1PR05MB44135FF068BD2BE3873EE3CEFC392%40VI1PR05MB4413.eurprd05.prod.outlook.com.

[Herbert Johnson]

What I meant by "not the same thing". It's not simple to compare PL/M 80
source with 8080 ASM source to cross check *at the source level*. As
Mark and I pointed out, one can compare binaries and that verifies a
final binary result. I questioned if a PL/M-80 compiler could also
generate an ASM source of some sort - I simply haven't run PL/M-80 in
decades.

None of these are complaints, it's all good work to resurrect sources
from binary ROMS and files. - regards herb

On 12/14/2024 6:11 PM, 'mark.p...@btinternet.com' via intel-devsys
wrote:

> Herb
> Not sure what you meant by the comment on the PL/M version. The makefile
> included builds the rom binary from the PL/M source and can verify
> against the original ROMs
> Mark
>
> Regards
> Mark

> ------------------------------------------------------------------------
> *From:* Herbert Johnson
> *Sent:* Saturday, December 14, 2024 9:32 pm

> Also, Bill Beech's results are ASM disassembly; Mark Ogden  resolved
> code to PL/M 80 source. Not the same thing, if a PL/M assembly output
> (or a binary output) is not included. Of course I'll take what's given,
> I would like to reference current works.

[mark.p...@btinternet.com]

Herb
By using the CODE option on the PL/M-80 compiler it generates an interleaved source/asm listing.
As I note in my source, there were two instances where the compiler didn't generate the exact same code, which is most likely due to the compiler version used, which may have been an internal version. The code is however fully equivalent.
The rest of the code matches.
Regards
Mark

-----Original Message-----
From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of Herbert Johnson
Sent: 15 December 2024 14:44
To: intel-...@googlegroups.com
Subject: Re: intel-devsys intel ROM resident assembler, text editor

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/7012d28d-ef87-4eed-8b2f-d49aca197dbc%40retrotechnology.com.

[Sid Jones]

The PLM compilers didn't do 'intermediate' assembler source files.

Which was a nuisance when I wanted to 'borrow' some maths functions from the
PLM library for a Z80 based job.

Made up a dummy invocation file that called the functions, extracted the
hex, did some nifty reverse assembly (by hand, IIRC) and created the
equivalent assembler source.

Must have had a lot more patience back then... Hmm. I wonder if I've still
got them...

Regards

Sid

https://groups.google.com/d/msgid/intel-devsys/000201db4f0b%2445cc40d0%24d164c270%24%40btinternet.com.

[mark.p...@btinternet.com]

Sid

The CODE option does generate assembler from the generated object code but it will not assemble direct as the listing includes the object code as hex and uses the PL/M symbol names which may not be valid in the assembler. The code is however relatively easy to edit into valid asm format. I have done this several times

Even with the older Fortran cross compiler provides the assembly listing although some reformatting is needed to make it usable. 

I accept if you are using compiled code without original source code some disassembly/decompilation is required. 

Mark

Regards

Mark Ogden

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of Sid Jones <jonest...@logicmagic.co.uk>
Sent: Sunday, December 15, 2024 4:40:52 PM
To: intel-...@googlegroups.com <intel-...@googlegroups.com>

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/D025352EBA5140EDA54C767753D72396%40LM010.

[William Beech]

Herb,

I believe you can set a switch on PL/M to generate ASM source in the
PL/M listing.  But I would work from the binary as you point out.

This is all great good fun!

Bill

[Herbert Johnson]

I added Mark's description about the CODE option to my (corrected) Web
page section about his work. My posted comment here prompting his
response was confusing:

> Also, Bill Beech's results are ASM disassembly; Mark Ogden resolved
> code to PL/M 80 source. Not the same thing, if a PL/M assembly output
> (or a binary output) is not included.

I simply meant that a PL/M source is hard to compare to an ASM source.
The binary results (if compiled or assembled) should be the same. Mark
makes the point on how they could or did diverge. My confusion generated
informative comments.

Sid's comments about dissembling compiled PL/M is informative, but I
don't have a place for it on my Web pages. I'll point it out another
time if I have a context for it.

regards Herb

> On 12/15/2024 11:40 AM, Sid Jones wrote:
>> The PLM compilers didn't do 'intermediate' assembler source files.

>> Made up a dummy invocation file that called the functions, extracted the
>> hex, did some nifty reverse assembly (by hand, IIRC) and created the
>> equivalent assembler source.
>

>> -----Original Message-----
>> From: mark.pm.ogden via intel-devsys
>

>> By using the CODE option on the PL/M-80 compiler it generates an
>> interleaved source/asm listing.
>> As I note in my source, there were two instances where the compiler
>> didn't
>> generate the exact same code, which is most likely due to the compiler
>> version used, which may have been an internal version. The code is
>> however >> fully equivalent. The rest of the code matches.
>> Regards
>> Mark

[William Beech]

Mark,

I am trying to work on the ROM ASM80 V1.2 and ROM EDIT80 V2.0.  I have your PLM80 source for the V1.1 ROMs.  Remember, the ROM images I have had bit rot, so I am trying to figure that out.  I have your ctools and intel80tools installed.  Assume all the tools are in the PATH. 

Could you give me a simple explanation of how to build your PLM80 source for V1.1 from the makefile.  What make do you use?

Thanks!

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/AM0PR05MB440435E79D66D68D2F96FB08FC3A2%40AM0PR05MB4404.eurprd05.prod.outlook.com.

[mark.p...@btinternet.com]

Bill

The tools are all included except for Perl which you should install as  it is used to unpack the source. I may remove this dependency at some point. 

If you are in the edasm directory invoking

..\..\make should work

Regards

Mark Ogden

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of William Beech <nj...@nj7p.info>
Sent: Sunday, December 29, 2024 7:10 pm
To: 'mark.p...@btinternet.com' via intel-devsys <intel-...@googlegroups.com>

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/901c1a61-e328-424c-ae20-79021fc40fe4%40nj7p.info.

[William Beech]

Thanks!

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/VI1PR05MB4413E2FE9CC1BEFDD7C5068DFC082%40VI1PR05MB4413.eurprd05.prod.outlook.com.

[William Beech]

You make that so easy.  Back to the bit rot ROM images.

Thanks!

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/VI1PR05MB4413E2FE9CC1BEFDD7C5068DFC082%40VI1PR05MB4413.eurprd05.prod.outlook.com.

[William Beech]

Mark,

Right you are.  My DD disk images are correct, but my SD images are not.  I will fix my tools to create a proper SD image.

Is it okay if I point to your GitHub repositories "intel80tools" and "c-ports" from my pages?  I want to show how to use your work to actually generate disk images for ISIS-II on my new pages.

Thanks!

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/VI1PR05MB4413E2FE9CC1BEFDD7C5068DFC082%40VI1PR05MB4413.eurprd05.prod.outlook.com.

[mark.p...@btinternet.com]

Bill

I have no problem with you referencing my GitHub sites. You may also find my disktools repo of interest as mkidsk will create Isis images and imd format files including interleave and skew for the imd format. It also creates PDS variants.

Note applying interleave and skew to image files is unlikely to be of any use as ISIS OS reads/writes assuming normal sequential sector ids, the disc controller reads the physical formatted ids to locate where to write a sector. This info is recorded at format time.

For disk emulators using a sequential layout would not impact ISIS behaviour.

Likewise ISIS knows nothing about recording formats e.g. M2FM, providing the interface messaging from ISIS to the disk controller is replicated the actual disk type and recording format can be anything, assuming it at least has sufficient capacity. 

Mark

Regards

Mark

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of William Beech <nj...@nj7p.info>

Sent: Saturday, January 11, 2025 9:56:15 PM

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/a458b573-338a-4386-bea5-425b167470d4%40nj7p.info.

[roger arrick]

Random note concerning single-density ISIS-II disks. 

If my memory is correct there is a tiny difference between how the MDS800 and MDSII formats a disk and a 'standard' single density disk.  Something in the address mark field or one of the other fields between sectors.   I remember running into a situation where I could not read a disk formatted on one by the other but don't remember the specifics.   Maybe Herb documented that but I didn't.  Not talking m2mfm here, talking about single density stuff.

--  Roger Arrick -- Tyler, Texas, USA -- Ro...@Arrick.com --

---

From: 'mark.p...@btinternet.com' via intel-devsys <intel-...@googlegroups.com>
Sent: Saturday, January 11, 2025 4:28 PM

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/AM0PR05MB440455EF45B026B9968992DFFC1D2%40AM0PR05MB4404.eurprd05.prod.outlook.com.

[William Beech]

Mark,

I have mentioned your work on some of my new pages.  I will link to some of your repo's as well.

I had my own makimg-isis program working before I found your work.  I also have a makimg-cpm program for that OS.  And I have done some work on versions for Xenix.  So I will probably stay with my tools for that operation.  But I want to show how to make an ISIS-II image from your source files for at least the ISIS-II V4.3W variant.  All I was doing was just copying the CUSP files from the original disk and then creating a new disk image. 

Again, I appreciate all the hard work you have put into this.

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/AM0PR05MB440455EF45B026B9968992DFFC1D2%40AM0PR05MB4404.eurprd05.prod.outlook.com.

[William Beech]

Roger,

I believe we are talking about the IBM 3740 format here.  That requires the skew of all tracks be 6.  The SD formats of ISIS are not compatible.  But M2FM and MFM are also different. 

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/DM6PR14MB344902C4CEA526078D4B8CC4D81E2%40DM6PR14MB3449.namprd14.prod.outlook.com.

[roger arrick]

The MDS800 and MDS-II single-density systems have no trouble reading 'standard' IBM single density 8" disks.  CP/M is distributed on such a disk and will boot in an MDS800 without modification, that their stock BIOS.  But there was some issue I had at one time interchanging SD disk files between my MDS-II and the Xerox 820 and I don't remember the specifics.  Possibly it was a diskette that was low-level formatted in the MDS-II but had trouble reading on the Xerox.  In the last year I ran across some info somewhere, maybe a forum, where someone described a difference in an address field or something, I should have saved that.

BTW, I have a CPM utility on my Xerox 820 to read ISIS directories.  It was on one of the early CPM user-group disks.  And another to read DEC RX01 directories/files.  These are both Single-Sided Single-Density disks with 26 sectors of 128 bytes per track, and 77 tracks - normal stuff.

--  Roger Arrick -- Tyler, Texas, USA -- Ro...@Arrick.com --

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of William Beech <nj...@nj7p.info>

Sent: Saturday, January 11, 2025 8:16 PM

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/24ea32c2-90dd-4b40-9cc4-7ea1a7114345%40nj7p.info.

[Herbert Johnson]

My recollection in the Compupro/Morrow world, is that at one time there
was some shift in how ??? density was formatted. Consequently there was
a utility to read a track and rewrite it correctly to fix the
discrepancy. Almost all the Compupro/Morrow floppy controllers were
Western Digital FDC chip based, I'll explain that ...

> MDS800 and MDSII formats ... Xerox 820

It's quite possible that Intel's bit-slice controller on the MDS800,
produced a format that was inconsistent with a Western Digital FDC
chip on the MDS-II or on a Xerox 820. Once the WD chips were the norm,
and those chips replicated (Intel's versions, etc.) they were all of a
kind and these problems mostly dissipated.

Web search may find more details. These are difficult things to run to
ground.

Regards Herb

On 1/11/2025 9:57 PM, roger arrick wrote:
> The MDS800 and MDS-II single-density systems have no trouble reading
> 'standard' IBM single density 8" disks.  CP/M is distributed on such a
> disk and will boot in an MDS800 without modification, that their stock
> BIOS.  But there was some issue I had at one time interchanging SD disk
> files between my MDS-II and the Xerox 820 and I don't remember the
> specifics.  Possibly it was a diskette that was low-level formatted in
> the MDS-II but had trouble reading on the Xerox.  In the last year I ran
> across some info somewhere, maybe a forum, where someone described a
> difference in an address field or something, I should have saved that.
>

> --  Roger Arrick -- Tyler, Texas, USA -- Ro...@Arrick.com --
>

> ------------------------------------------------------------------------
> *From:* William Beech <nj...@nj7p.info>

> *Sent:* Saturday, January 11, 2025 8:16 PM

>
> I believe we are talking about the IBM 3740 format here.  That requires
> the skew of all tracks be 6.  The SD formats of ISIS are not
> compatible.  But M2FM and MFM are also different.
>
> Bill
>
>
> On 1/11/2025 5:43 PM, roger arrick wrote:
>> Random note concerning single-density ISIS-II disks.
>>
>> If my memory is correct there is a tiny difference between how the
>> MDS800 and MDSII formats a disk and a 'standard' single density disk.
>> Something in the address mark field or one of the other fields between
>> sectors.   I remember running into a situation where I could not read
>> a disk formatted on one by the other but don't remember the
>> specifics.   Maybe Herb documented that but I didn't.  Not talking
>> m2mfm here, talking about single density stuff.
>>
>> --  Roger Arrick

--

[William Beech]

Herb/Roger,

All the Compupro FDCs I have use the Intel 8272 or NEC-765 controllers,
not any WD controllers.

The iSBC-201 will read standard IBM 3740 format disks correctly.

I vaguely remember some problem of this sort in the deep dark past in
dealing with controllers made from logic chips vs the LSI controllers
from Intel and WD.

Bill

[mark.p...@btinternet.com]

Bill

If you haven’t already read it, see the recipe.pdf file in the disktools doc directory. This explains how to create custom ISIS disks. If you have a copy of my ISIS disk archives and provide a link to it, this will also pull files including boot tracks, ISIS and applications from the archive. The distools.pdf file in the same directory also includes additional information on mkdisk along with the various interleave/skew options for various disks.

 

Mark

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/bde354a3-21eb-4344-8533-7c5604507341%40nj7p.info.

[William Beech]

Mark,

I have read the file.  I need to think about what you have there and what I need for the other OSs I support.  I need to look at your code and see if I can get it to support CP/M-80 disks to start.  Then look at Xenix.

Thanks for the information.

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/006b01db64cd%243747d790%24a5d786b0%24%40btinternet.com.

[mark.p...@btinternet.com]

Bill

I use cpmtools for cp/m, there are so many variants of the disk format, it didn’t seem sensible to create my own app. The only limitation I see with cpmtools is support for writing the boot tracks, especially if track 0 is formatted differently e.g. FM vs. MFM.

There are similar issues with Xenix, for creating fresh disk images, you would need to specify multiple parameters. There are several elements that are not documented particularly well which don’t impact reading the disk but may impact whether it will work on a real system.

Note my unidsk tool can extract files from some xenix disks and I have my own utility unirmx that handles more formats and which I may roll into unidsk at some point

Mark

Regards

Mark

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of William Beech <nj...@nj7p.info>

Sent: Sunday, January 12, 2025 7:36:33 PM

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/b6053f22-1b29-40c7-b9cb-bdfa03db9ee0%40nj7p.info.

[William Beech]

Mark,

There are variances between different manufacturers of OSs regarding disk format.  And CP/M had the most variants, for sure. I will look into these tools.  All my tools, like yours, use an ASCII file to control the layout of the disk. 

Still thinking on it!

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/AM0PR05MB44049C8F98ED760B9F3D25F6FC1F2%40AM0PR05MB4404.eurprd05.prod.outlook.com.