PROMPT-48 monitor code

[andre...@gmail.com]

Hi all,

 

Does anyone have, or has seen, a source code file for the PROMPT-48 resident monitor.  I believe it would be version 3.0 for the 6MHz.  I have a PDF of the list file but I was hoping someone has already done the OCR and file cleanup.

 

Thanks

craig

[Sid Jones]

Do you have a HEX file of the monitor image?

 

I’ve been cooking the odd reverse assembler (4040!) lately...

 

The HEX file would allow comparison of the assembled source for verification.

 

Regards

 

Sid

--
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 on the web visit https://groups.google.com/d/msgid/intel-devsys/212e01d9f30a%24f50e06e0%24df2a14a0%24%40gmail.com.

[andre...@gmail.com]

Hi Sid,

 

Yes, I can download the EPROMs and will send them out afterwards.

 

Regards

craig

[Jon Hales]

Hi Craig, Sid

I looked inside a Prompt 48 a couple of weeks ago. However, I didn't note the version of the code in the set of 2708s. The crystal is missing. And one of the socketed C2113s is a C2114.

This is to advise that I could dump the code if that would help. 

The double density MCS-48 Macro Assembler is disk 970010 and images of versions 3 and 4 are in Mark Ogden's disk collection (but not V2.0 which was used in 1977 for the manual listing).

I assume you are looking at the V3.0 Monitor listing in the manual for the 6MHz upgrade (9800583A). 

I'm ready to be involved with OCR of the monitor code and realise that the PDF assembler listing can be awkward to process with OCR - two attempts may be better than one.

In passing, I have a Matt Millman MCS-48 reader/programmer and recommend it. A couple of spare PCBs are available on request.

Best regards

Jon

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/273001d9f3c7%246571f970%243055ec50%24%40gmail.com.

[andre...@gmail.com]

Hi Jon,

 

Yes, the assembler listing I found is at the end of the 6MHz upgrade instruction letter.  I am REALLY glad they included that with the upgrade kit.

 

It is interesting that one of the six RAM in your PROMPT was a 2114.  If you could get the date codes on the five 2113s and your 2114 it would be interesting information.  I am interested in seeing how long Intel’s “1976 4K production problem” lasted into 1977

 

I did a little bit of starting with the pdf and trying to parse it into either excel or word or notepad but the results were pretty pitiful.  If I can take the ROM dumps and disassemble to mnemonics, it is just as fast to type in the comments and such.  It really isn’t that bad a chore to just start from scratch if necessary. 

 

Do you have the 8755 adapter board from Matt Millman also?  I have his boards on my tindie site for those who want to build either a MCS-85 minimum system or SDK-85+ kit but can’t program 8755s.  I have built one of his programmers and adapters, but haven’t personally gotten around to using it.

 

Regards

craig

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/CANPXPJmUwFfbSXWsSBOCFjEnr_6zwh7poMVdPF03RxwqFV7oeg%40mail.gmail.com.

[Jon Hales]

Craig

Here's a list of the symbols, extracted using OCR from pages 73-80, with no editing. It's not 100% correct, but editing these 8 pages is not a major task. The aim would be to use this list as a customised dictionary - to identify misread characters on the pages listing code and comments.

Of course, this is an incomplete extract of these pages, as I omitted the location references. That's a matter of adjusting the scope of the OCR operation on the same pages. The symbol table is another means to obtain an edited list of references. This has some unclear characters but not too many.

In summary, I think OCR is viable, and can probably be arranged as a series of stages. Not a small task. At this stage I can't predict how much time it would require.

Yes, I have the 8755 boards, but have yet to build one. The MCS-48 reader/programmer enabled me to receive the 8748 code from a GNT 4601 paper tape device owned by someone in a different part of the country. This has allowed me to replace the 8748 that restricted my 4601 to 5-hole operation with another that enables 8-hole operation. The task now is to see whether a library of the code versions for the several 460x machines can be gathered from other owners - to add to the manuals available on Bitsavers.org.

Regards

Jon

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/29d101d9f3d6%24c688b820%24539a2860%24%40gmail.com.

[Herbert Johnson]

On 10/1/2023 12:51 PM, Jon Hales wrote:
>
> In summary, I think OCR is viable, and can probably be arranged as a
> series of stages. Not a small task. At this stage I can't predict how
> much time it would require.

The short version of this post is: "OCR is painful. Type in the source
listing, or the necessary parts, and be done with it. Hire someone, or
ask several people to enter pieces, and be done with it. A disassembler
with some symbolic features (example given) may be an alternative. One
can learn from typing and/or disassembly.". The long version below,
makes these cases but may be too tedious for some audiences.

-----

Well, sorry to argue, but in my experiences with OCRing text *produced
by a Teletype*, is that OCR is *not* viable. It's lots of corrective
work by hand error correction and visual comparison, and a host of means
of comparing opcodes to mnemonics. I've done it, I've done it last
night, and it's a pain in the ass. The benefits to me, are to become
familiar with some particular piece of code, or some processor. that
won't appeal to everyone.

Jon and I, cannot "prove a negative", that is how much work something
might take before it's done, when done by someone else. I don't even
know how many text-pages are involved, but for 1Kbytes of code, it can't
be enormous.

"Viable" begs the question: what's the alternative? "Sometimes the hard
way, is the easiest way." The hard way, is to enter in the entire text
by human eye and hand. at least, the assembly codes, not the opcodes,
not the line numbers, not the comments. More hard is to also add the
comments, slightly harder to do it later. OCRing the comments and
cut-and-paste, I don't think works that well.

Alternative? Edit a disassembly, by changing numbers to symbol-names,
adding comments. Many disassemblers don't decode arguments back into
symbols, they resolve them as byte or word values.

But: Bill Beech and I, have for years, traded in disassemblers in C
source that include a symbol table. Need I explain the concept beyond "a
file of symbol names and values"? It's fun for some people, to adapt an
old disassembler to a new processor. I"ve moved his 8080 disassembler to
the 1802 with good results. Bill and I have moved it to other
processors, it's challenging at times, in a good way.

https://www.retrotechnology.com/restore/beechd85.zip

The base disassembler I tinker with is for the 8085. It's linked as a
ZIP file. This is earlier Bill Beech work, a two-pass, with my fixes. It
includes a symbol file option. Bill has recent versions which are three
or four passes and produce cleaner output. It's entirely my fault that I
think two passes and uneven output is acceptable. Bill of course, can
offer his recent versions, they are good work.

There are, of course, 8048 disassemblers around. Web search finds them,
they vary in quality and sophistication. But: they provide tables to
feed the 8085 disassembler code, he he.

As far as touch-typing. "who bells the cat?" 1) divide up the document
into pages, ask several people to each enter a page. Empirical
experience says that works.

2) hire a professional typist - they must still exist, it's a gig job
that anyone on the *planet* who knows English can do. 3) find a
friend/relative who has touch-typing skills and needs some money.
Results will certainly need correction, but assembling the produced
source will flag some syntax errors.

However, I've never heard any vintage computerist say "... and so I paid
my cousin [or someone in India] to type this stuff in .." It's a
theoretical choice.

But it's not my project, so these are matters for those involved to
resolve. I've provided tools and suggestions from my experiences, and
the silly idea of hiring it out.

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

[Sid Jones]

This is where you really need an obsessive/compulsive assembly language fanatic with 48+ years of wrangling reverse-assembled code into shape...

 

I wonder where you can find somebody like that?

 

Hmmm...

 

Regards

 

Sid

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/CANPXPJ%3D374mooCGhc9EKNHOezBnpb_QVQb7iEKfjLiHaFRsuQQ%40mail.gmail.com.

[Jon Hales]

Sid

That sounds exactly like you. Are you offering to become involved?

Before you can reverse-assemble, you need some code to work with (I assume).

Regards

Jon

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/0863BBD1C0AE4C0AB2D309993F19E2E4%40LM010.

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

Has anyone tried using Ghidra as a disassembler for 8048 as it is meant to be supported and allows hex file input. Ghidra allows labels and comments to be added.

 

I personally use IDA Pro for my disassembly work as it has powerful features to allow, labels, comments and scripting, unfortunately it doesn’t support the 8048, although in principle the source of the 8051 disassembler, supplied in the SDK, could be used as a starting point to add 8048 support.

 

Where I have a binary image and a source listing, I usually disassemble the binary and use the source (sometimes OCR’d) as a cross reference to match names and comments. I have also used simple scripts to load known symbols as a starting point. For more complex projects e.g. the ISIS applications, I use IDA’s library signature analysis features, have a bespoke loader for OMF85 and have scripts to auto identify plm function prologs.

 

 

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/0863BBD1C0AE4C0AB2D309993F19E2E4%40LM010.

[andre...@gmail.com]

Monday I will download the eproms and send out.

 

I should have said from the beginning that I am not desperate to have source code that I can assemble from scratch, I am just working on a prompt-48 and I needed to know what was going on in the code.  The 6MHz upgrade document answered that question.

 

But it would be nice to have the PROMPT-48 Monitor source code in the archives.

 

After dinking more with OCR followed by cutting and cursing, I just started typing in from scratch.

 

It took me a couple of hours to get to line 590.  There are some 4500 lines.

However, the first few pages are obscure instruction format descriptions and go very slowly.  Whoever at intel originally did this code, they really liked the <> symbols as they are really over used.  And they slow my typing down to a crawl.

 

If someone wants to do a section by whatever means: OCR, type from scratch, or witchcraft, I would suggest staking a claim to a section of 1000 lines so we do not duplicate effort.

For now I claim from line 0 to 999

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/CANPXPJmDuzU-KNS1F2TiKUHJsDuQc57F%3DCvrzbEx%2BpL9BpDY1Q%40mail.gmail.com.

[Sid Jones]

O...K...

 

I get bored with Sudoku these days... Just about to roll my own 8048 reverse assembler. Or, as there are a plethora of said items on the web, would this be a perverse assembler?)

 

(BTW: Is ‘dinking’ like drinking, or to quote James May, c*ck*ng around?)

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/324601d9f4ed%24e6592a50%24b30b7ef0%24%40gmail.com.

[craig andrews]

Hi Sid,

I generally have a pretty dim view of disassemblers and do not do enough 8048 reverse engineering to ever get good at disassembling.  I can go forward OK, but going backwards on an 8048 isn’t my forte.  Give me an 8080/85 and I can hold my own, but not microcontrollers.

If you are dinking around with something, you are working on something but not really making progress.. almost aimlessly or haphazardly. It is usually a children friendly term.

Regards

Craig

On Oct 2, 2023, at 5:26 AM, Sid Jones <jonest...@logicmagic.co.uk> wrote:



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

[Sid Jones]

Aha! I understand.

 

I’ll knock out a 8048 reverse assembler when I’ve finished some housework.

 

(I apologise that it won’t be to scale and I won’t have time to paint it... )

 

Regards

 

Sid (Binary? My first project was programming an 8008 system in binary...)

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/D4B9965D-DD1E-4C57-A84B-46C19F50770C%40gmail.com.

[Herbert Johnson]

Since there's interest in an 8048 disassembler, I'll make available the
one I found and modified slightly. My choice of it was entirely
arbitrary, one can search for better or create better. One could modify
the 8085 disassembler I provided (courtesy of Bill Beech) and do better.
But something beats nothing, and available now beats better-later.

https://www.retrotechnology.com/restore/8048DIS.ZIP

It's pretty simple C code and generates disassembly without determining
arguments as symbols. My changes are modest, it was originally in Turbo
C (MS-DOS). *It has not been verified by me as producing good 8048
codes. Please inform me if there are errors.*

What I mean by "arguments as symbols", for instance on an 8080, the
binary C3 01 23 would be disassembled without symbols as "JMP 2301H"
rather than an arbitrary but informative symbol "JMP L2301". A symbolic
disassembler would create the label and so allow a text editor to
replace it with a symbolic symbol like "START".

In real time, I'm doing just that, with binary from another processor
and source as a PDF.

For completeness: the prompt-48 6Mhz code source and the prompt-48 ROM
binaries are available at:

https://bitsavers.org/pdf/intel/prompt48/


Regards Herb

On 10/2/2023 11:45 AM, Sid Jones wrote:
> Aha! I understand.
> I’ll knock out a 8048 reverse assembler when I’ve finished some housework.
> (I apologise that it won’t be to scale and I won’t have time to paint

> it... Smile)

> Regards
> Sid (Binary? My first project was programming an 8008 system in binary...)

> *From:* craig andrews
> *Sent:* Monday, October 02, 2023 4:20 PM

> Hi Sid,
> I generally have a pretty dim view of disassemblers and do not do enough
> 8048 reverse engineering to ever get good at disassembling.
>

>> On Oct 2, 2023, at 5:26 AM, Sid Jones wrote:
>>
>> O...K...
>> I get bored with Sudoku these days... Just about to roll my own 8048
>> reverse assembler.

> *From:* craig andrews

>>
>> Monday I will download the eproms and send out.
>>
>> I should have said from the beginning that I am not desperate to have
>> source code that I can assemble from scratch, I am just working on a
>> prompt-48 and I needed to know what was going on in the code.  The
>> 6MHz upgrade document answered that question.
>>
>> But it would be nice to have the PROMPT-48 Monitor source code in the
>> archives.

[Herbert Johnson]

I'm working on lines 2500-2999 of the PROMPT-48 code. the first half is
already filed and initially corrected. source lines and comments only,
not line number or binary codes. - regards Herb

[Craig Andrews]

Ok, I will stop at line 2499, I think I am at 1900 now

> On Oct 2, 2023, at 11:21 AM, Herbert Johnson <hjoh...@retrotechnology.com> wrote:
>
> I'm working on lines 2500-2999 of the PROMPT-48 code. the first half is

> --
> 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 on the web visit https://groups.google.com/d/msgid/intel-devsys/57a55b78-e1e4-8cfe-ee25-a35291f650b1%40retrotechnology.com.

[andre...@gmail.com]

Hi Herb,

beginning through line 2499 which was the WRI9 label.

I have not gone back to check for errors, I plan on letting the assembler find most of them for me and fix them in real time. I am sure there are many mistakes in reading like O/0, I/1, and the like. Then there are the inevitable mistyping errors since #, @, < and > are all very un-natural keystrokes for me.

When I get another chance I will go back and do some light checking, or I will skip ahead to another block further up.

Regards
craig

-----Original Message-----
From: Craig Andrews <andre...@gmail.com>
Sent: Monday, October 2, 2023 12:21 PM
To: intel-...@googlegroups.com
Subject: Re: intel-devsys PROMPT-48 monitor code

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

I loaded the binary image into Ghidra and it does a reasonable job of disassembling the 8048 binary.
I have posted the listing it generated at https://mark-ogden.uk/hidden/Ghidra-prompt-v3.pdf.
The first few pages include labels, enumerations and some comments to illustrate how Ghidra's UI can be used to add EQUates, labels and comments.
It needs more work using Ghida's commands
D - disassemble code where it could not detect the flow
L - to modify auto generated labels to put meaningful names
E - to add enumerations to simulate the EQUs

Note there are some artefacts in the disassembly e.g. undefined MB1RT() as Ghidra tries to decompile the code as well !!

Regards
Mark

-----Original Message-----
From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of Herbert Johnson
Sent: Monday, October 2, 2023 6:22 PM
To: intel-...@googlegroups.com; Sid Jones <jonest...@logicmagic.co.uk>
Subject: Re: intel-devsys PROMPT-48 monitor code

--
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 on the web visit https://groups.google.com/d/msgid/intel-devsys/429eb8ae-9817-2054-698d-006e53e5945c%40retrotechnology.com.

[andre...@gmail.com]

I have downloaded the 4 ROMs for the Prompt-48 with 6MHz upgrade. See attached zif

-----Original Message-----
From: Craig Andrews <andre...@gmail.com>
Sent: Monday, October 2, 2023 12:21 PM
To: intel-...@googlegroups.com

Subject: Re: intel-devsys PROMPT-48 monitor code

[andre...@gmail.com]

Hi Mark,

Is this the 6MHz upgrade binary? Or the original 3MHz?
It looks like it does a pretty good job, certainly with a little more input from the list file with labels and to identify data bytes, it will get most of the way there.

Regards
craig

-----Original Message-----
From: mark.pm.ogden via intel-devsys <intel-...@googlegroups.com>
Sent: Monday, October 2, 2023 2:09 PM
To: intel-...@googlegroups.com
Subject: RE: intel-devsys PROMPT-48 monitor code

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/005e01d9f574%249ab5afb0%24d0210f10%24%40btinternet.com.

[Herbert Johnson]

On 10/2/2023 5:01 PM, andre...@gmail.com wrote:
> Hi Herb,
>
> beginning through line 2499 which was the WRI9 label.
>
> I have not gone back to check for errors, I plan on letting the assembler find most of them for me and fix them in real time. I am sure there are many mistakes in reading like O/0, I/1, and the like. Then there are the inevitable mistyping errors since #, @, < and > are all very un-natural keystrokes for me.
>
> When I get another chance I will go back and do some light checking, or I will skip ahead to another block further up.
>
> Regards craig

So, I just sent Craig, lines 2500-3000. It took me about 2.5 hours to
edit and correct to some level. I found some conveniences I'd like
others to know. I asked Craig to post the codes here in devsys; I don't
seem to be able to post attachments.

The PDF file from bitsavers, is actually already OCR'ed, but in what
experience tells me is "the usual fashion", which is not entirely
useful. OCR PDF's tend to treat source codes as a series of columns.
Thus bunches of comments OR operands OR mnemonics, are a series of text
string bundles. These are broken up into short runs of code, when the
code is broken by blank lines.

If this is unclear, bring the PDF into your PDF reader/producer (Adobe
acrobat is mine) and try to cut bits of text out of it.

So the strategy I followed was roughly as I'll describe. This, while
opening the PDF in one window and the text file under a pure text editor
in another window.

lines of comments only, could be cut from the PDT as text, and pasted
into the text file as a unit. Some corrections could be done then or later.

Lines of mostly code, would consist of a column of mnemonics and a
column of operands. I grabbed the column of operands and pasted that
into the text file. then I typed in the corresponding mnemonics. There
arent that many used so they became familiar; as did the operand syntax.

*then* I grabbed a few comment lines as a cut, then pasted them into the
END of the text file. In the text file, I cut each comment line, and
pasted it into place in the source-code.

Repeat for each "paragraph" of source code.

With PDF source and text-file source roughly in line, my eyes could read
both files in parallel and make sense of errors and placement of text.
Fast readers look at chunks of text-pages, not word-by-word. I've done a
lot of A-B page comparison by eye work.

This sounds busy, but once you get into the rhythm of it, not so bad. I
essentially slow-read the code and patched it into the text file as
chunks of patch-operands, typedin-mnemonics, cut/pasted a comments
bundle, then cut-n-pasted each comment line.

The usual tricky things are zero vs oh, one vs el, things like that.
Getting familiar with the source code, I could recall symbols and see
the consistency of mixing numbers and letters by the programmer.

So, I learned something about 8048 coding along the way.

I'm spelling this out, to be informative about the daunting task of
pulling code text from OCRed PDF source-listing files. It's not awful,
when considering all the results one gets. It's a task like other tasks,
using a set of familiar tools, that has emergent values beyond
completing the immediate task. It may look like banging rocks together,
for 21st century programmers. But this is 20th century code, so there.

Regards Herb Johnson

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

It is version 3 firmware from bitsavers, which I believe is the 6MHz version. Certainly the

Using Ghidra for this is quite straightforward and other than a couple of places for isolated code, the code flow produced was automatic. 

Regards

Mark

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of andre...@gmail.com <andre...@gmail.com>
Sent: Tuesday, October 3, 2023 12:01 am
To: intel-...@googlegroups.com <intel-...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/381c01d9f584%245499bcf0%24fdcd36d0%24%40gmail.com.

[Jon Hales]

Mark

Would there be any value in having the symbol names and their locations for use in/with Ghidra?

If so, I could provide a list in alphabetical order.

Regards

Jon

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/DU0PR08MB8347737463762A018DA9D5A5FCC4A%40DU0PR08MB8347.eurprd08.prod.outlook.com.

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

I have posted an update to my disassembly, this time as a text file

https://mark-ogden.uk/hidden/promptv3.txt

This has all of the code labels included and the code/data areas identified.

I have cleaned up the code to remove most of the Ghidra artifacts including adding a colon to labels.

What remains are the comments, EQU definitions and replacement of constants by the relevant EQU name.

There are still some Ghidra artifacts, especially the XREF info. It can safely be deleted or commented out

Mark

[Herbert Johnson]

Looking at lines 2500 forward (around 700H address), Mark's disassembly
looks pretty good. The symbolic names (addresses) look good. The
symbolic byte values are not represented, as in the PDF's

TYCSTS:
MOV R0,#USACT
ANL P2,#MSKPG
ORL P2,*MEIOU

versus Mark's

TYCSTS:
CODE:07af b8 21 MOV R0,#0x21
CODE:07b1 9a f0 ANL P2,#0xf0
CODE:07b3 8a 08 ORL P2,#0x8

but either Mark can add those symbols, or a text editor can find and
replace them. There's various decimal values in the source-listing
rather than hex values; those can be hand added or edited.

My previous methods apply to Mark's disassembly; one can cut/paste/edit
comment lines. The XREF information is easily removed as it's comments
in columns far from the body of sourcel a "delister" program removes
text by column number. Likewise the source can be stripped out. However
the diagnostic value is in the (dis)assembled listing.

If someone chooses to install Ghidra, it would be useful for Mark to
include whatever "configuration files" were in use for this 8048 run.
That may be a lot of trouble, it may be more a matter of following
procedures to install the 8048 and install whatever symbol tables were
included, etc.

But the result from Mark, is itself informative and may be adequate for
the intended result: some editable assembled listing to inform about the
monitor program.

regards and thanks, Herb

On 10/3/2023 8:27 AM, mark.pm.ogden via intel-devsys wrote:
> I have posted an update to my disassembly, this time as a text file
>
> https://mark-ogden.uk/hidden/promptv3.txt
>
> This has all of the code labels included and the code/data areas identified.
>
> I have cleaned up the code to remove most of the Ghidra artifacts
> including adding a colon to labels.
>
> What remains are the comments, EQU definitions and replacement of
> constants by the relevant EQU name.
>
> There are still some Ghidra artifacts, especially the XREF info. It can
> safely be deleted or commented out
>
> Mark

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

I have posted the pdf version with the code bytes, but without the removal of Ghidra artefacts.
https://mark-ogden.uk/hidden/promptv3.pdf

Mark

-----Original Message-----
From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of Herbert Johnson
Sent: Tuesday, October 3, 2023 3:54 PM
To: intel-...@googlegroups.com
Subject: Re: intel-devsys PROMPT-48 monitor code

--
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 on the web visit https://groups.google.com/d/msgid/intel-devsys/800f1c56-d7b2-6a9a-c660-c309b5bee606%40retrotechnology.com.

[Herbert Johnson]

Mark, sorry for any confusion. By "symbolic byte values", I meant the
byte (or word) arguments to the mnemonic assembly instructions, which
were not (symbolic) address arguments. In my example, the symbols are
USACT, MSKPG, MEIOU. The values as you disassembled are 0x21, 0xf0, 0x8;
both in your previous PDF, and in your more recent TXT.

I was not referring to the "code bytes" of address or instruction/data
columns. Those are in your TXT listing, and if not desired are not hard
to remove (delete the first NN columns of each line).

In the original PDF source listing, the three symbols I describe, are
defined as EQUates early in the source:

USACT EQU 21H ;USART CONTROL
MSKPG EQU 0F0H ;MASK FOR P2 PAGING
MEIOU EQU 08H ;MEMORY MAPPED I/O UPPER BYTE

As you described yourself in your TXT post, "What remains are the

comments, EQU definitions and replacement of constants by the relevant

EQU name." I suppose I could have referenced "equated constants", and I
otherwise missed this statement. A text editor can "replace" each
constant with its symbolic value; possibly that can be automated with a
scripted editor.

Craig posted his partial results earlier, which include the lines of
EQUates, so that's a source for that information. In the PDF listing,
there's also a symbolic dump at the end - but it's not OCRed and would
have to be manually entered. Jon Hales posted a list of symbols but not
their values.

I only pointed this out, in case it's not a complicated process to
include these equated constants, into Ghidra's tables, as you apparently
did with the label/address values. I don't know of course, and there may
be conflicts between lables and "equated constants".

There remains other symbolic constants, such as ASCII characters,
decimal values, or expressions - that's manual work, difficult to
automate. I'm aware of these issues, from my own maintenance of
disassembler programs.

Regards Herb

> To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/00cc01d9f60b%24e7d15870%24b7740950%24%40btinternet.com.

[Mark Ogden]

All

I have now completely extracted the prompt monitor code from the pdf / binary images. It is available on

https://mark-ogden.uk/hidden/prompt.a48.

The code cleanly assembles and the output binary matches the original (assuming PROMS are padded with zeros)

I have included all the comments, EQUs and conditional blocks. The line numbers match the PDF.

There may be some minor differences from the PDF listing, but none impact the assembly. The potential differences are

1) Comments may not be fully correct, I spent a lot of time cleaning them up, but is it possible OCR and typing errors remain, although there also spelling errors in the original.

2) Some variables may not be the same as the listing, because I could not determine some of the characters, the main

problem will be the letter O vs. zero and letter I vs. one

3) Some column alignment may not be fully match.

4) There may be spurious marks at the end of some comments as a result of OCR converting ink marks to various characters

5) Some constants may not have been converted to the correct label. I did a limited number of global replaces, and although they

all look correct, it is possible that an alternative equivalent label should have been used. The same applies to numeric constants which possibly should be replaced with a label.

regards

Mark

[Mark Ogden]

Jon

My online repository contains

V2.0, V3.0, V4.0 and V4.2 of the ASM48, see the separate directories under
https://mark-ogden.uk/files/intel/Intel80/asm48/

Mark

On Saturday, 30 September 2023 at 19:44:31 UTC+1 Jon Hales wrote:

Hi Craig, Sid

I looked inside a Prompt 48 a couple of weeks ago. However, I didn't note the version of the code in the set of 2708s. The crystal is missing. And one of the socketed C2113s is a C2114.

This is to advise that I could dump the code if that would help. 

The double density MCS-48 Macro Assembler is disk 970010 and images of versions 3 and 4 are in Mark Ogden's disk collection (but not V2.0 which was used in 1977 for the manual listing).

I assume you are looking at the V3.0 Monitor listing in the manual for the 6MHz upgrade (9800583A). 

I'm ready to be involved with OCR of the monitor code and realise that the PDF assembler listing can be awkward to process with OCR - two attempts may be better than one.

In passing, I have a Matt Millman MCS-48 reader/programmer and recommend it. A couple of spare PCBs are available on request.

Best regards

Jon

On Sat, 30 Sept 2023 at 18:56, <andre...@gmail.com> wrote:

Hi Sid,

 

Yes, I can download the EPROMs and will send them out afterwards.

 

Regards

craig

 

From: Sid Jones <jonest...@logicmagic.co.uk>

Sent: Saturday, September 30, 2023 6:26 AM
To: intel-...@googlegroups.com; Craig Andrews <andre...@gmail.com>

Subject: Re: intel-devsys PROMPT-48 monitor code

 

Do you have a HEX file of the monitor image?

 

I’ve been cooking the odd reverse assembler (4040!) lately...

 

The HEX file would allow comparison of the assembled source for verification.

 

Regards

 

Sid

 

From: andre...@gmail.com

Sent: Friday, September 29, 2023 8:27 PM

To: intel-...@googlegroups.com

Subject: intel-devsys PROMPT-48 monitor code

 

Hi all,

 

Does anyone have, or has seen, a source code file for the PROMPT-48 resident monitor.  I believe it would be version 3.0 for the 6MHz.  I have a PDF of the list file but I was hoping someone has already done the OCR and file cleanup.

 

Thanks

craig

--

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 on the web visit https://groups.google.com/d/msgid/intel-devsys/212e01d9f30a%24f50e06e0%24df2a14a0%24%40gmail.com.

--
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 on the web visit https://groups.google.com/d/msgid/intel-devsys/273001d9f3c7%246571f970%243055ec50%24%40gmail.com.

[Herbert Johnson]

This is good work, Mark, thanks. I read you on sources of possible
errors, it's a human-judgement issue. But such things can be fixed with
simple text-editing replacement. The assembler only needs consistency of
symbols, and that's achieved.

The essential to me (I'm not the end user here) is that comments and
code and symbols all provide intelligence to human-interpreting the
code. Perfect replication is not the goal.

>> (assuming PROMS are padded with zeros)

That's an interesting gotcha. When I produced some Intelhex-to-binary
routines, I discovered I had to pad with 0xFFH, not 0x00H. Unprogramed
PROM positions are 0xFFH, except for some very early EPROMs. So programs
looking for "the end of code" or some such, stop when they see FF's; but
not zero's. If you program a PROM with intel hex records, the
unprogrammed bits are left as FF's.

I'm curious to know, if you used additional OCR methods; or if you
relied on the previous OCRed PDF. Most traditional OCR sees assembly
listings as a series of columns of text, not rows of lines. So the
results are hard to manipulate, as I previously described. Makes me
wonder, if new, superior AI methods might produce a better OCR for this
class of work, than traditional OCR. But that's outside my skills set.
There's some Open AI products in this regard but I cannot judge them.

Regards Herb

[andre...@gmail.com]

Very, Very, Nice.  Thanks for finishing this up.

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/79629209-b8b8-4f73-9b12-f63d3e27937en%40googlegroups.com.

[Jon Hales]

Mark

Thank you for the Prompt-48 code and for information about the versions of the assembler. My records of your repository are clearly out of date.

Would it be OK for me to download your collection of Intel files from the address you noted? 

I'm aware you have an Intel80 collection on Bill's Intel_Devel Google Drive. Is this the same as on your personal web pages?

I'm planning to be at the Retro Event at the Centre for Computing History on Saturday 4 November. Do you have any plans to attend the event this year?

Best regards

Jon

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/ad8b10de-c2c6-4444-bf06-246bacf39c0en%40googlegroups.com.

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

Herb
Different PROMS/EPROMS use either 0 or 0FFH as the default unprogrammed value. The comment re zeros was because the extracted (P)ROMS on bitsavers, appeared to use 0 as an unused programmed state.

As to my method for reproducing the asm file.
1) I used Ghidra to disassemble the binary. This way the assembly instructions would at least match the original, other than the use of numeric constants rather than labels, and auto generated target labels.
2) I went through the code relabelling the target addresses to match the pdf file. Ghidra updates all the target label references, so I did not have to modify the instructions. When I finally came to assemble the code, I found a couple of errors, mainly because Ghidra allowed me to duplicate labels, as it supports namespaces. Also the SAME? Labels had to be added as these are only references by conditional IF tests.
3) For OCR I use FineReader 15, which does not have the latest AI support, however to make the extract reasonable, I manually set the page areas to be pure text, as the auto mode, often gets confused when making the listing into a table, auto merging cells, which when extracted to a text file, this leads to odd layout.
4) To improve the decode I did some manual training of the OCR, which improved some of the recognition, however a little more training would probably have produced better results.
5) For blocks of EQUs and comments, I largely copied from the OCR text, using a editor to remove the address and code text. Once copied I did a clean up to address OCR artifacts
6) For end of line comments, I used a mixture of copy from OCR and typing.
7) The conversion of the # constants from numbers (in C style hex format) to labels or hex in Intel format, was largely manually done, however I did some global replaces for some of the MOV R0,#... and MOV R1,#... references.
8) Once I had completed the initial code, I iteratively used the assembler to detect errors, fix and repeat. The bulk of the errors related to OCR issues around EQU, AND, O vs 0 and (lower case L / upper case I) vs. 1, but fortunately there were only around 30 errors to start with.

Mark

-----Original Message-----
From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of Herbert Johnson
Sent: Saturday, October 7, 2023 10:44 PM
To: intel-...@googlegroups.com; Mark Ogden <ogd...@gmail.com>
Subject: Re: intel-devsys PROMPT-48 monitor code

--
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 on the web visit https://groups.google.com/d/msgid/intel-devsys/efdccd0a-f7ff-0d8c-1d28-3ab53c0f1bcb%40retrotechnology.com.

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

All
For completeness, I have posted a new pdf listing file, assembled with V2.0 of the assembler. It also includes the missing XREF listing.
https://mark-ogden.uk/hidden/prompt.pdf
Mark

-----Original Message-----
From: mark.p...@btinternet.com <mark.p...@btinternet.com>
Sent: Sunday, October 8, 2023 1:04 PM
To: 'intel-...@googlegroups.com' <intel-...@googlegroups.com>
Subject: RE: intel-devsys PROMPT-48 monitor code

Herb
Different PROMS/EPROMS use either 0 or 0FFH as the default unprogrammed value. The comment re zeros was because the extracted (P)ROMS on bitsavers, appeared to use 0 as an unused programmed state.

As to my method for reproducing the asm file.
1) I used Ghidra to disassemble the binary. This way the assembly instructions would at least match the original, other than the use of numeric constants rather than labels, and auto generated target labels.
2) I went through the code relabelling the target addresses to match the pdf file. Ghidra updates all the target label references, so I did not have to modify the instructions. When I finally came to assemble the code, I found a couple of errors, mainly because Ghidra allowed me to duplicate labels, as it supports namespaces. Also the SAME? Labels had to be added as these are only references by conditional IF tests.
3) For OCR I use FineReader 15, which does not have the latest AI support, however to make the extract reasonable, I manually set the page areas to be pure text, as the auto mode, often gets confused when making the listing into a table, auto merging cells, which when extracted to a text file, this leads to odd layout.
4) To improve the decode I did some manual training of the OCR, which improved some of the recognition, however a little more training would probably have produced better results.
5) For blocks of EQUs and comments, I largely copied from the OCR text, using a editor to remove the address and code text. Once copied I did a clean up to address OCR artifacts
6) For end of line comments, I used a mixture of copy from OCR and typing.
7) The conversion of the # constants from numbers (in C style hex format) to labels or hex in Intel format, was largely manually done, however I did some global replaces for some of the MOV R0,#... and MOV R1,#... references.
8) Once I had completed the initial code, I iteratively used the assembler to detect errors, fix and repeat. The bulk of the errors related to OCR issues around EQU, AND, O vs 0 and (lower case L / upper case I) vs. 1, but fortunately there were only around 30 errors to start with.

Mark

-----Original Message-----
From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of Herbert Johnson

Sent: Saturday, October 7, 2023 10:44 PM
To: intel-...@googlegroups.com; Mark Ogden <ogd...@gmail.com>

Subject: Re: intel-devsys PROMPT-48 monitor code

--
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 on the web visit https://groups.google.com/d/msgid/intel-devsys/efdccd0a-f7ff-0d8c-1d28-3ab53c0f1bcb%40retrotechnology.com.

[Jon Hales]

Mark

When you listed your approach to generating the code, your list should have started at 'zero' - "relevant experience/expertise". I'm intrigued that you were able to run ASM48 v2.0, presumably on a preferred MDS emulator. Can we know which emulator you prefer?

I compared your XRef table strings with the list I had derived from the PDF - also using Finereader 15, but with minimal training.

The first discrepancy I found was at COMP1, where I had 'COMF1' and should have noticed that didn't correspond to the next two lines.

At DEL01 and DEL02, it seemed plausible these were first and second, although DELOK followed. I agree there was no 'diagonal' within the 'O' as seen earlier at D10US and D20US. So your version is quite possibly correct.

GEXTY didn't have an extra 'T' as in GETXTY.

GPT3 and GPT5 should have been read as GTP3 and GTP5.

MEPC5 which should have been MEPG5.

OR11 to OR17 should be ORI1 to ORI7

REGGO should be RETGO and REGSS should be RETSS.

RRAR should be RPAR.

When checking the apparent discrepancies (aligning my list and your's in Excel, with a conditional format on a check for matching strings), I found it helpful to view the PDF pages at 400%.

Regards

Jon

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/002401d9fa98%24615b32c0%2424119840%24%40btinternet.com.

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

Jon

Thanks for the checks.

I have fixed

1. GEXTY didn't have an extra 'T' as in GETXTY

1. GPT3 and GPT5 should have been read as GTP3 and GTP5.

1. MEPC5 which should have been MEPG5 – note it not actually used

1. OR11 to OR17 should be ORI1 to ORI7
2. REGGO should be RETGO and REGSS should be RETSS.

1. RRAR should be RPAR. – note it not actually used

 

Apart from the two unused changes, most were manual typo errors by me.

The ORIx, was an initial reading error, propagated across the subsequent ORIx

 

Updated versions of prompt.a4 and prompt.pdf have been uploaded to my site, same names as before

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/CANPXPJm%2BP%2Bs9z4od-KbQTy4VQVuuUbne2rEVbC8BQUgsJsKqaw%40mail.gmail.com.

[Jon Hales]

Mark

Thank you for providing the 'definitive' version of the listing.

I printed your cross reference table and the pages of the PDF and compared the strings line-by-line. I didn't notice any discrepancy not reported previously: hence 'definitive'.

Regards

Jon

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/022501d9fabb%240cf7e020%2426e7a060%24%40btinternet.com.

[andre...@gmail.com]

Yea, I am interested in the MDS emulator also.  Sometimes I am just not in the mood to battle my MDS (or even the iPDS) so an emulator would be nice.

 

From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of Jon Hales

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/CANPXPJm%2BP%2Bs9z4od-KbQTy4VQVuuUbne2rEVbC8BQUgsJsKqaw%40mail.gmail.com.

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

I run the ISIS II application using my modified version the John Elliott’s Thames emulator, which handles the non interactive ISIS tools without a problem.

There is actually a minor bug in the asm48 v2.0,  in that if the PRINT option is used, it gets confused, not sure whether this is due to corruption of the binary or an actual bug.

The main impact of the confusion is that the listing is not actually done, but the later bits e.g. symbols and xref are, and assume that the listing was done. This leads to a large

block of nulls.

Omitting the PRINT option writes a full listing to the default file without a problem.

The most recent version does not have the problem.

 

Note for the most recent 8080/5 development tools (ASM80, PLM80, LINK, LOCATE, LIB), I have ported these to run under windows and Linux, adding support for native file names and other improvements, e.g. adding 32 character name support to asm80.

My modified version of Thames supports long file names in a more limited way.

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/CANPXPJmG85v5u8d7%2B2z5vmWnjc-QKwR0VecH6chCOGxv0DOzgA%40mail.gmail.com.

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

I have now tracked down the bug in asm48 V2

Basically, if the print option is specified it opens the listing file twice at the same time. Closing the two causes the data to be overwritten with NULLS.

As technically ISIS should report the file is already open (ERRROR 12), which the code appears to handle, but the thames emulator didn’t previously detect.

I have now fixed the omission in thames and the code does appear to work.

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/intel-devsys/004b01d9fb73%2407d83140%24178893c0%24%40btinternet.com.