[Unix-jun72] ocr'd e03
newsham at lava.net
Thu May 1 03:38:58 AEST 2008
> I'm new to this (just discovered it - way cool!), so as an experiment I
> opened the scanned pdf and cut and pasted e03-01,02,03,04 into gimp,
> shrunk them to 3000x3000 and sent them to the tesseract web site. It
> does an amazing job. A little emacs work and the source looks good.
> Anyway, I know e03 is assigned to someone else, but they where not in
> the svn. should I check them in? (I just did it as an experiment, and
> I don't want to step on anyone;)
yes, please. I'll drop a note to the person this was assigned to
and start talkign to current assignees who havent yet had a chance
to do work to see if any of it should be reclaimed.
> I'm also curious how we boot strap this. In the end I assume we need a
> binary image which one of the sims can read. I have 0.5 a mind to write
> a quick and dirty assembler which outputs a binary file...
It seems like we can build this using the V7 assembler, or an earlier
one such as the "as" in the 1972 bits that are around, using the
apout emulator. I'm probably going to stick with the V7 assembler
for now due to the "mount" issues I ran across in the 1972 assembler.
For quick and dirty bootstrapping I was thinking of writing out
a simh script with a bunch of "deposit" commands to put the image
directly in memory. At some point later we can figure out if it
would be possible to reconstruct the original boot process (documented
in the 1ed manuals).
> But I suppose it would be better to use the original as/as2. Can this
> be run with apout? (I'd be curious to hear how people are doing it).
Yup. I've already tried it on some of the completed sections. The
one problem I ran across is that the "ux" section defines "mount"
as a label where the 1972 "as" predefines the "mount" system call.
This problem doesnt exist in the 7ed assembler because it doesnt
predefine the system calls. So I wrote up a "sys.s" (in svn) with
the system call definitions and I left out the definition for "mount"
(which isnt referenced in the kernel code).
> I'm happy to keep plugging through the remaining un-ocr'd pages if no
> one screams, sending email first of course.
Great. I'll poke at current assignees to see which section would be
More information about the TUHS