Re: [TUHS] Blit source

Re: [TUHS] Blit source

[Norman Wilson]

Mike Haertel:

  That's amusing, considering that the 5620 stuff was in /usr/jerq on
  Research systems!  Apparently the accident became institutionalized.

=====

I remember the name Jerq being tossed around to mean 5620
when I was at 1127.  That doesn't mean it was historically
accurate, but it is consistent with the directory names, and
the latter are probably where I got my mistaken idea of the
history.

Thanks to Rob, who certainly should know, for clearing it up.

Norman Wilson
Toronto ON

Re: [TUHS] Blit source

[Paul Ruizendaal]

> If 5620s were called Jerqs, it was an accident. All the software with that
> name would be for the original, Locanthi-built and -designed 68K machines.
> 
> The sequence is thus Jerq, Blit, DMD-5620

Maybe the “Jerq” name had a revival. If the processor switch came with some upheaval it is not hard to see how that revival could have happened.

The Dan Cross tar archive with the source code has two top level directories, one named “blit" with the 68K based source and another one named “jerq" with the Bellmac based source. The tar archive seems to have been made in the summer of 1985, or at least those dates are on the top level directories.

I am of course not disputing that the original name was Jerq. There are many clues in the source supporting that, among which this funny comment in mcc.c:

int	jflag, mflag=1;	/* Used for jerq. Rob Pike (read comment as you will) */

Re: [TUHS] Blit source

[Norman Wilson]

I sense a hint of confusion in some of the messages
here.  To lay that to rest if necessary (and maybe
others are interested in the history anyway):

As I understand it, the Blit was the original terminal,
hardware done by Bart Locanthi (et al?), software by
Rob Pike (et al?).  It used an MC68000 CPU.  Western
Electric made a small production run of these terminals
for use within AT&T.  I don't think it was sold to the
general public.

By the time I arrived at Bell Labs in late 1984, the
Standard Terminal of 1127 was the AT&T 5620, locally
called the Jerq.  This was a makeover with hardware
redesigned by a product group to use a Bellmac 32 CPU,
and software heavily reworked by a product group.
This is the terminal that was manufactured for general
sale.

I'm not sure, but I think the Blit's ROM was very basic,
just enough to be some sort of simple glass-tty or
perhaps smartass-terminal* plus an escape sequence to
let you load in new code.  The Jerq had a fancier ROM,
which was a somewhat-flaky ANSI-ish terminal by default,
but an escape sequence put it into graphics-window-manager
mode, more or less like what had run a few years earlier
on the Blit.

By then the code used in Research had evolved considerably,
in particular allowing the tty driver to be exported to
the terminal (those familiar with 9term should know what
I mean).  In 1127 we used a different escape sequence to
download a standalone program into the terminal and
replace the ROM window manager entirely, so we could run
our newer and (to my taste anyway) appreciably better code.
The downloaded code lived in RAM; you had to reload it
whenever the terminal was power-cycled or lost its connection
or whatnot.  (It took a minute or so at 9600bps, rather
longer at 1200.  This is not the only reason we jumped at
the chance to upgrade our home-computing scheme to use
9600bps over leased lines, but it was an important one.)

The V8 tape was made in late 1984 (I know that for sure
because I helped make it).  It is unlikely to have anything
for the MC68000 Blit, only stuff for the Mac-32 Jerq.
Likewise for the not-really-a-release snapshots from the
9/e and 10/e eras.  The 5620 ROM code is very unlikely to
be there anywhere, but the replacement stuff we used should
be somewhere.

Norman Wilson
Toronto ON

Re: [TUHS] Blit source

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

Your naming isn't right, although the story otherwise is accurate.

The Jerq was the original name for the 68K machines hand-made by Bart. The
name, originally coined for a fun demo of the Three Rivers Perq by folks at
Lucasfilm, was borrowed with permission by us but was considered unsuitable
by Sam Morgan as we reached out to make some industrially, by a company
(something Atlantic) on Long Island. So "Blit" was coined. The Blit name
later stuck unofficially to the DMD-5620, which was made by Teletype and,
after some upheavals, had a Western Electric BellMac 32000 CPU.

If 5620s were called Jerqs, it was an accident. All the software with that
name would be for the original, Locanthi-built and -designed 68K machines.

The sequence is thus Jerq, Blit, DMD-5620. DMD stood for dot-mapped rather
than bit-mapped, but I never understood why. It seemed a category error to
me.

-rob

[-- Attachment #2: Type: text/html, Size: 1037 bytes --]

Re: [TUHS] Blit source

[Mike Haertel]

Norman wrote:
> The V8 tape was made in late 1984 (I know that for sure
> because I helped make it).  It is unlikely to have anything
> for the MC68000 Blit, only stuff for the Mac-32 Jerq.

The V8 tape has the Blit stuff in /usr/blit, and the 5620 stuff
in /usr/jerq.  The Blit stuff looks somewhat older, and doesn't
have exactly the same graphics library functions as the 5620.

It would be interesting to see a chronology of the evolution of
these window systems.

Rob wrote:
> If 5620s were called Jerqs, it was an accident. All the software with that
> name would be for the original, Locanthi-built and -designed 68K machines.

That's amusing, considering that the 5620 stuff was in /usr/jerq on
Research systems!  Apparently the accident became institutionalized.

	Mike

Re: [TUHS] Blit source

[Angelo Papenhoff]

On 18/12/19, Mike Haertel wrote:
> The V8 tape has the Blit stuff in /usr/blit, and the 5620 stuff
> in /usr/jerq.  The Blit stuff looks somewhat older, and doesn't
> have exactly the same graphics library functions as the 5620.

My theory on that is that the up-to-date version of the code was kept in
/usr/jerq. When the 68k implementation became legacy, the code was
copied to /usr/blit and /usr/jerq became the directory for the new
development. And just to make it more interesting V10 has a 630
directory presumably for the 68k based 630 MTG.

Anyway, both the 68k and 32000 blit stuff is on the v8 tape (at least
binaries) and both work. 68k is running fine under emulation, 32000 is
running fine on real hardware (if you have the right ROM).

aap

Re: [TUHS] Blit source

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

On Wed, Dec 18, 2019 at 7:27 PM Rob Pike <robpike@gmail.com> wrote:

> [snip]
>
The sequence is thus Jerq, Blit, DMD-5620. DMD stood for dot-mapped rather
> than bit-mapped, but I never understood why. It seemed a category error to
> me.
>

The first time I saw a terminal of that lineage, it was a gnot (Gnot?
GNOT?) running Plan 9; this would likely have been 1993 or 1994; I was in
high school and visited a college-student friend of mine who was interning
at the labs and Dennis Ritchie had one on his desk. As an aside, he kindly
spared me a few minutes; I confess I was too star-struck and embarrassed to
ask him to autograph my copy of K&R that I had brought along. Dennis was a
kind, humble person and I was always quite struck by that in comparison to
some other academic and industry super-stars I've met.

Anyway, my question is what was the evolutionary story of the gnot? I
recall being told that it had a 68020, a datakit interface, and some amount
of RAM that was small but non-trivial; perhaps 4MB? It seemed clearly
evolved from the series of earlier terminals presently under discussion.

And the next step in the evolution was a MIPS-based terminal; I can't
recall the name, though.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 1832 bytes --]

Re: [TUHS] Blit source

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

The Gnot had a 68040 (which had an MMU that paged properly) and an INCON
interface, which was a kind of Datakit for the home. Twisted pair. Half a
megabit if I remember right, but I probably don't.

Two bits per pixel. The "render extension" in X Windows originated there,
after an epiphany I had while watching Hoop Dreams. True story.

The MIPS machine you refer to was called a Magnum, made by somebody for
Microsoft as a porting engine for Windows to non-Intel.

-rob


On Thu, Dec 19, 2019 at 4:13 PM Dan Cross <crossd@gmail.com> wrote:

> On Wed, Dec 18, 2019 at 7:27 PM Rob Pike <robpike@gmail.com> wrote:
>
>> [snip]
>>
> The sequence is thus Jerq, Blit, DMD-5620. DMD stood for dot-mapped rather
>> than bit-mapped, but I never understood why. It seemed a category error to
>> me.
>>
>
> The first time I saw a terminal of that lineage, it was a gnot (Gnot?
> GNOT?) running Plan 9; this would likely have been 1993 or 1994; I was in
> high school and visited a college-student friend of mine who was interning
> at the labs and Dennis Ritchie had one on his desk. As an aside, he kindly
> spared me a few minutes; I confess I was too star-struck and embarrassed to
> ask him to autograph my copy of K&R that I had brought along. Dennis was a
> kind, humble person and I was always quite struck by that in comparison to
> some other academic and industry super-stars I've met.
>
> Anyway, my question is what was the evolutionary story of the gnot? I
> recall being told that it had a 68020, a datakit interface, and some amount
> of RAM that was small but non-trivial; perhaps 4MB? It seemed clearly
> evolved from the series of earlier terminals presently under discussion.
>
> And the next step in the evolution was a MIPS-based terminal; I can't
> recall the name, though.
>
>         - Dan C.
>
>

[-- Attachment #2: Type: text/html, Size: 2767 bytes --]

Re: [TUHS] Blit source

[arnold]

Rob Pike <robpike@gmail.com> wrote:

> The Gnot had a 68040 (which had an MMU that paged properly) and an INCON
> interface, which was a kind of Datakit for the home. Twisted pair. Half a
> megabit if I remember right, but I probably don't.
>
> Two bits per pixel. The "render extension" in X Windows originated there,
> after an epiphany I had while watching Hoop Dreams. True story.

I'd like to hear this story in full, please.

Thanks!

Arnold

Re: [TUHS] Blit source

[Chet Ramey]

On 12/19/19 1:54 AM, Rob Pike wrote:

> Two bits per pixel. The "render extension" in X Windows originated there, 
> after an epiphany I had while watching Hoop Dreams. True story.

That's a great movie. I would be very interested in hearing the story of
how it sparked that epiphany.

(And if you liked Hoop Dreams, you might be interested in "Benji", an ESPN
30 for 30 documentary about another Chicago high school basketball player
but from a very different angle. Unless, of course, you've already seen
it.)

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[TUHS] Blit source

[Paul Ruizendaal]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

I’m looking for source code of the original Blit as described here:
http://doc.cat-v.org/bell_labs/blit/blit.pdf <http://doc.cat-v.org/bell_labs/blit/blit.pdf>

It does not seem to be on the v8 tape. I found the following on the web:
http://www.brouhaha.com/~eric/retrocomputing/att/5620/software/ <http://www.brouhaha.com/~eric/retrocomputing/att/5620/software/>
but that seems to be from much later and for the 5620.

Then there is this, which seems to be the Blit's graphics routines or a derivtive thereof:
https://stuff.mit.edu/afs/athena/astaff/project/Sdev/S/src/fun/blit/ <https://stuff.mit.edu/afs/athena/astaff/project/Sdev/S/src/fun/blit/>
(although it seems larger than the 8KB mentioned in the paper).

I’m aware of this emulator:
https://github.com/aap/blit <https://github.com/aap/blit>
which uses a rom dump; it appears a good base for h/w documentation.

Did the sources of these rom contents survive?












[-- Attachment #2: Type: text/html, Size: 1909 bytes --]

Re: [TUHS] Blit source

[Angelo Papenhoff]

On 15/12/19, Paul Ruizendaal wrote:
> I’m aware of this emulator:
> https://github.com/aap/blit <https://github.com/aap/blit>

This is only a port to unix I did. The original one was written by aiju.
The upstream version (which is in fact more up to date) is part of the 9front repo:
https://code.9front.org/hg/plan9front/file/5003ea45cc4d/sys/src/games/blit
Aiju reverse engineered the hardware from the source code on the second tape:
https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/v8jerq.tar.bz2

I don't know how complete it is and I think the compiler is also not
included, but I'm not too sure how it all worked.

aap

Re: [TUHS] Blit source

[emanuel stiebler]

On 2019-12-15 21:45, Paul Ruizendaal wrote:
> I’m looking for source code of the original Blit as described here:
> http://doc.cat-v.org/bell_labs/blit/blit.pdf

Thanks for trying again. It pops up on this list every few years, but
still no schematics (2002, 2012) ...

Cheers

Re: [TUHS] Blit source

[Paul Ruizendaal]

> Date: Sun, 15 Dec 2019 22:17:53 +0100
> From: Angelo Papenhoff <aap@papnet.eu>
> 
> On 15/12/19, Paul Ruizendaal wrote:
>> I’m aware of this emulator:
>> https://github.com/aap/blit <https://github.com/aap/blit>
> 
> This is only a port to unix I did. The original one was written by aiju.
> The upstream version (which is in fact more up to date) is part of the 9front repo:
> https://code.9front.org/hg/plan9front/file/5003ea45cc4d/sys/src/games/blit
> Aiju reverse engineered the hardware from the source code on the second tape:
> https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/v8jerq.tar.bz2

Thanks! The “blit” directory in that archive indeed appears to be what I’m looking for. Hopefully it has enough to enable rebuilding from source.
> 
> I don't know how complete it is and I think the compiler is also not
> included, but I'm not too sure how it all worked.

From a quick inspection there appears to be a subdirectory “m” with motorola tools. It appears to have a M68K pcc-based compiler. It also has this README file:

===
the source for /usr/blit/lib/ccom has been lost.
the source here (Mip and Mcc) is for a compiler that does not generate
the correct symbol tables for joff and pi.
we wish we had the source, but we don't, so the binary is precious.
please handle it with care.

if you decide you need to recompile ccom, contact us.
we may have found a solution by then...
===

The “bin” directory has that ccom binary. It suggests that there once was a M68K compiler that derived from the Ritchie PDP11 compiler. I assume that the source for that has stayed missing ever since 1985.

> On 16 Dec 2019, at 07:25, emanuel stiebler <emu@e-bbes.com> wrote:
> 
> On 2019-12-15 21:45, Paul Ruizendaal wrote:
>> I’m looking for source code of the original Blit as described here:
>> http://doc.cat-v.org/bell_labs/blit/blit.pdf
> 
> Thanks for trying again. It pops up on this list every few years, but
> still no schematics (2002, 2012) …

It would seem that the circuit was intentionally simple and straightforward: a M68K cpu, ram, rom, two 6850 UARTS and the circuit to drive the display. The key aspects of the video circuitry (and mouse circuitry) are discussed in this paper:
https://9p.io/cm/cs/doc/87/archtr.ps.gz ("Hardware/Software Tradeoffs for Bitmap Graphics on the Blit”).

It would seem to me that doing a version of the Blit that runs on a FPGA board and generates 720p HDMI output would not be impossible to do, if the software can be configured to deal with a different geometry (e.g. 1024x720 instead of 800x1024). Whether that would be much different from running the emulator on a PC remains unclear, of course.

Re: [TUHS] Blit source

[emanuel stiebler]

On 2019-12-16 12:06, Paul Ruizendaal wrote:

> It would seem that the circuit was intentionally simple and straightforward: a M68K cpu, ram, rom, two 6850 UARTS and the circuit to drive the display. The key aspects of the video circuitry (and mouse circuitry) are discussed in this paper:
> https://9p.io/cm/cs/doc/87/archtr.ps.gz ("Hardware/Software Tradeoffs for Bitmap Graphics on the Blit”).
Thanks!
> It would seem to me that doing a version of the Blit that runs on a FPGA board and generates 720p HDMI output would not be impossible to do, 
It actually pretty simple, all this stuff is avalable on AMIGA emulators
for FPGAs ...

> if the software can be configured to deal with a different geometry (e.g. 1024x720 instead of 800x1024). Whether that would be much different from running the emulator on a PC remains unclear, of course.

It is on my list of things to do, but not on the first page ;-)
Still waiting, that schematics & sources show up ...

Re: [TUHS] Blit source

[Paul Ruizendaal]

Further to the below, I’ve now tried to build the Blit toolchain (on a contemporary OS). Other than the usual little issues, it does not take too much effort to get running.

Rebuilding the rom contents using the pre-existing libraries builds the exact same bits, however here is also where the good stuff ends: this only assembles two files, compiles vitty.c and the rest is library; rebuilding the libraries is different.

The roms rely on four libaries (libsys, libj, liblayer and libc) and none of the four rebuild to the exact same bytes or size. In several cases the archives do not even have the exact same files in them. In general, the regenerated object files often appear to be a little smaller (even when compiled with optimization off). So far I cannot tell whether this is because the compiler is different, or because the underlying source code is different. Probably a bit of both.

So, it would seem that an adapted rom can be compiled, but how functional it would be remains to be seen.

The note about the missing compiler remains intriguing. First a correction: I associate “ccom” with the DMR compiler, as it lives in a directory by that name; I had not realized that pcc also names its main binary ccom. Beyond that it would seem that two different versions of this 68K compiler were floating around and maybe the surviving one puts different debug info in the symbol table.



>> Date: Sun, 15 Dec 2019 22:17:53 +0100
>> From: Angelo Papenhoff <aap@papnet.eu>
>> 
>> On 15/12/19, Paul Ruizendaal wrote:
>>> I’m aware of this emulator:
>>> https://github.com/aap/blit <https://github.com/aap/blit>
>> 
>> This is only a port to unix I did. The original one was written by aiju.
>> The upstream version (which is in fact more up to date) is part of the 9front repo:
>> https://code.9front.org/hg/plan9front/file/5003ea45cc4d/sys/src/games/blit
>> Aiju reverse engineered the hardware from the source code on the second tape:
>> https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/v8jerq.tar.bz2
> 
> Thanks! The “blit” directory in that archive indeed appears to be what I’m looking for. Hopefully it has enough to enable rebuilding from source.
>> 
>> I don't know how complete it is and I think the compiler is also not
>> included, but I'm not too sure how it all worked.
> 
> From a quick inspection there appears to be a subdirectory “m” with motorola tools. It appears to have a M68K pcc-based compiler. It also has this README file:
> 
> ===
> the source for /usr/blit/lib/ccom has been lost.
> the source here (Mip and Mcc) is for a compiler that does not generate
> the correct symbol tables for joff and pi.
> we wish we had the source, but we don't, so the binary is precious.
> please handle it with care.
> 
> if you decide you need to recompile ccom, contact us.
> we may have found a solution by then...
> ===
> 
> The “bin” directory has that ccom binary. It suggests that there once was a M68K compiler that derived from the Ritchie PDP11 compiler. I assume that the source for that has stayed missing ever since 1985.
> 
>> On 16 Dec 2019, at 07:25, emanuel stiebler <emu@e-bbes.com> wrote:
>> 
>> On 2019-12-15 21:45, Paul Ruizendaal wrote:
>>> I’m looking for source code of the original Blit as described here:
>>> http://doc.cat-v.org/bell_labs/blit/blit.pdf
>> 
>> Thanks for trying again. It pops up on this list every few years, but
>> still no schematics (2002, 2012) …
> 
> It would seem that the circuit was intentionally simple and straightforward: a M68K cpu, ram, rom, two 6850 UARTS and the circuit to drive the display. The key aspects of the video circuitry (and mouse circuitry) are discussed in this paper:
> https://9p.io/cm/cs/doc/87/archtr.ps.gz ("Hardware/Software Tradeoffs for Bitmap Graphics on the Blit”).
> 
> It would seem to me that doing a version of the Blit that runs on a FPGA board and generates 720p HDMI output would not be impossible to do, if the software can be configured to deal with a different geometry (e.g. 1024x720 instead of 800x1024). Whether that would be much different from running the emulator on a PC remains unclear, of course.

Re: [TUHS] Blit source

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 4728 bytes --]

The 68000 compiler was pcc and was under fairly continuous development
during this project. So there may be no "missing version" of the compiler
but just version skew between source and existing artifacts.

-rob


On Wed, Dec 18, 2019 at 2:55 PM Paul Ruizendaal <pnr@planet.nl> wrote:

> Further to the below, I’ve now tried to build the Blit toolchain (on a
> contemporary OS). Other than the usual little issues, it does not take too
> much effort to get running.
>
> Rebuilding the rom contents using the pre-existing libraries builds the
> exact same bits, however here is also where the good stuff ends: this only
> assembles two files, compiles vitty.c and the rest is library; rebuilding
> the libraries is different.
>
> The roms rely on four libaries (libsys, libj, liblayer and libc) and none
> of the four rebuild to the exact same bytes or size. In several cases the
> archives do not even have the exact same files in them. In general, the
> regenerated object files often appear to be a little smaller (even when
> compiled with optimization off). So far I cannot tell whether this is
> because the compiler is different, or because the underlying source code is
> different. Probably a bit of both.
>
> So, it would seem that an adapted rom can be compiled, but how functional
> it would be remains to be seen.
>
> The note about the missing compiler remains intriguing. First a
> correction: I associate “ccom” with the DMR compiler, as it lives in a
> directory by that name; I had not realized that pcc also names its main
> binary ccom. Beyond that it would seem that two different versions of this
> 68K compiler were floating around and maybe the surviving one puts
> different debug info in the symbol table.
>
>
>
> >> Date: Sun, 15 Dec 2019 22:17:53 +0100
> >> From: Angelo Papenhoff <aap@papnet.eu>
> >>
> >> On 15/12/19, Paul Ruizendaal wrote:
> >>> I’m aware of this emulator:
> >>> https://github.com/aap/blit <https://github.com/aap/blit>
> >>
> >> This is only a port to unix I did. The original one was written by aiju.
> >> The upstream version (which is in fact more up to date) is part of the
> 9front repo:
> >>
> https://code.9front.org/hg/plan9front/file/5003ea45cc4d/sys/src/games/blit
> >> Aiju reverse engineered the hardware from the source code on the second
> tape:
> >>
> https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/v8jerq.tar.bz2
> >
> > Thanks! The “blit” directory in that archive indeed appears to be what
> I’m looking for. Hopefully it has enough to enable rebuilding from source.
> >>
> >> I don't know how complete it is and I think the compiler is also not
> >> included, but I'm not too sure how it all worked.
> >
> > From a quick inspection there appears to be a subdirectory “m” with
> motorola tools. It appears to have a M68K pcc-based compiler. It also has
> this README file:
> >
> > ===
> > the source for /usr/blit/lib/ccom has been lost.
> > the source here (Mip and Mcc) is for a compiler that does not generate
> > the correct symbol tables for joff and pi.
> > we wish we had the source, but we don't, so the binary is precious.
> > please handle it with care.
> >
> > if you decide you need to recompile ccom, contact us.
> > we may have found a solution by then...
> > ===
> >
> > The “bin” directory has that ccom binary. It suggests that there once
> was a M68K compiler that derived from the Ritchie PDP11 compiler. I assume
> that the source for that has stayed missing ever since 1985.
> >
> >> On 16 Dec 2019, at 07:25, emanuel stiebler <emu@e-bbes.com> wrote:
> >>
> >> On 2019-12-15 21:45, Paul Ruizendaal wrote:
> >>> I’m looking for source code of the original Blit as described here:
> >>> http://doc.cat-v.org/bell_labs/blit/blit.pdf
> >>
> >> Thanks for trying again. It pops up on this list every few years, but
> >> still no schematics (2002, 2012) …
> >
> > It would seem that the circuit was intentionally simple and
> straightforward: a M68K cpu, ram, rom, two 6850 UARTS and the circuit to
> drive the display. The key aspects of the video circuitry (and mouse
> circuitry) are discussed in this paper:
> > https://9p.io/cm/cs/doc/87/archtr.ps.gz ("Hardware/Software Tradeoffs
> for Bitmap Graphics on the Blit”).
> >
> > It would seem to me that doing a version of the Blit that runs on a FPGA
> board and generates 720p HDMI output would not be impossible to do, if the
> software can be configured to deal with a different geometry (e.g. 1024x720
> instead of 800x1024). Whether that would be much different from running the
> emulator on a PC remains unclear, of course.
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 6018 bytes --]

Re: [TUHS] Blit source

[Julius Schmidt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4651 bytes --]

I also noticed that the ROM binaries differed from the source code, when I 
was writing the Blit emulator, by comparing disassembled binaries with the 
source. In particular, the compiled code makes reference to I/O registers 
025 and 027 that are not referenced in the source any more. (I think there 
were some more differences I didn't bother to write down)

Julius Schmidt (aiju)

On Wed, 18 Dec 2019, Paul Ruizendaal wrote:

> Further to the below, I’ve now tried to build the Blit toolchain (on a contemporary OS). Other than the usual little issues, it does not take too much effort to get running.
>
> Rebuilding the rom contents using the pre-existing libraries builds the exact same bits, however here is also where the good stuff ends: this only assembles two files, compiles vitty.c and the rest is library; rebuilding the libraries is different.
>
> The roms rely on four libaries (libsys, libj, liblayer and libc) and none of the four rebuild to the exact same bytes or size. In several cases the archives do not even have the exact same files in them. In general, the regenerated object files often appear to be a little smaller (even when compiled with optimization off). So far I cannot tell whether this is because the compiler is different, or because the underlying source code is different. Probably a bit of both.
>
> So, it would seem that an adapted rom can be compiled, but how functional it would be remains to be seen.
>
> The note about the missing compiler remains intriguing. First a correction: I associate “ccom” with the DMR compiler, as it lives in a directory by that name; I had not realized that pcc also names its main binary ccom. Beyond that it would seem that two different versions of this 68K compiler were floating around and maybe the surviving one puts different debug info in the symbol table.
>
>
>
>>> Date: Sun, 15 Dec 2019 22:17:53 +0100
>>> From: Angelo Papenhoff <aap@papnet.eu>
>>>
>>> On 15/12/19, Paul Ruizendaal wrote:
>>>> I’m aware of this emulator:
>>>> https://github.com/aap/blit <https://github.com/aap/blit>
>>>
>>> This is only a port to unix I did. The original one was written by aiju.
>>> The upstream version (which is in fact more up to date) is part of the 9front repo:
>>> https://code.9front.org/hg/plan9front/file/5003ea45cc4d/sys/src/games/blit
>>> Aiju reverse engineered the hardware from the source code on the second tape:
>>> https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/v8jerq.tar.bz2
>>
>> Thanks! The “blit” directory in that archive indeed appears to be what I’m looking for. Hopefully it has enough to enable rebuilding from source.
>>>
>>> I don't know how complete it is and I think the compiler is also not
>>> included, but I'm not too sure how it all worked.
>>
>> From a quick inspection there appears to be a subdirectory “m” with motorola tools. It appears to have a M68K pcc-based compiler. It also has this README file:
>>
>> ===
>> the source for /usr/blit/lib/ccom has been lost.
>> the source here (Mip and Mcc) is for a compiler that does not generate
>> the correct symbol tables for joff and pi.
>> we wish we had the source, but we don't, so the binary is precious.
>> please handle it with care.
>>
>> if you decide you need to recompile ccom, contact us.
>> we may have found a solution by then...
>> ===
>>
>> The “bin” directory has that ccom binary. It suggests that there once was a M68K compiler that derived from the Ritchie PDP11 compiler. I assume that the source for that has stayed missing ever since 1985.
>>
>>> On 16 Dec 2019, at 07:25, emanuel stiebler <emu@e-bbes.com> wrote:
>>>
>>> On 2019-12-15 21:45, Paul Ruizendaal wrote:
>>>> I’m looking for source code of the original Blit as described here:
>>>> http://doc.cat-v.org/bell_labs/blit/blit.pdf
>>>
>>> Thanks for trying again. It pops up on this list every few years, but
>>> still no schematics (2002, 2012) …
>>
>> It would seem that the circuit was intentionally simple and straightforward: a M68K cpu, ram, rom, two 6850 UARTS and the circuit to drive the display. The key aspects of the video circuitry (and mouse circuitry) are discussed in this paper:
>> https://9p.io/cm/cs/doc/87/archtr.ps.gz ("Hardware/Software Tradeoffs for Bitmap Graphics on the Blit”).
>>
>> It would seem to me that doing a version of the Blit that runs on a FPGA board and generates 720p HDMI output would not be impossible to do, if the software can be configured to deal with a different geometry (e.g. 1024x720 instead of 800x1024). Whether that would be much different from running the emulator on a PC remains unclear, of course.
>
>
>
>
>

Re: [TUHS] Blit source

[Angelo Papenhoff]

On the topic of ROMs: It seems like there are different ROM versions for
the 5620, one working with the blit code in v8 (I had a real one
hooked up to my laptop running v8 under simh) and the other not.
Unfortunately it seems that the compatible ROMs have not been dumped yet
so the simh-based 5620 emulator that has been around for a while now
does not work with the v8 blit stuff.

It would be cool if a 5620 owner could dump their ROM or the existing
version could be patched.

aap

Re: [TUHS] Blit source

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

It may be worth getting in touch with the folks at LCM+L. I believe they
have a working 5620.

        - Dan C.


On Wed, Dec 18, 2019, 5:42 PM Angelo Papenhoff <aap@papnet.eu> wrote:

> On the topic of ROMs: It seems like there are different ROM versions for
> the 5620, one working with the blit code in v8 (I had a real one
> hooked up to my laptop running v8 under simh) and the other not.
> Unfortunately it seems that the compatible ROMs have not been dumped yet
> so the simh-based 5620 emulator that has been around for a while now
> does not work with the v8 blit stuff.
>
> It would be cool if a 5620 owner could dump their ROM or the existing
> version could be patched.
>
> aap
>

[-- Attachment #2: Type: text/html, Size: 1077 bytes --]

Re: [TUHS] Blit source

[Paul Ruizendaal]

The “hardware / software tradeoffs” paper I linked yesterday has an interesting discussion about the mouse, including many details of how it worked. It says that the Blit originally used a tablet but was later redesigned to use a mouse. You may be seeing a few remains of the the tablet interface.

I noticed that the rom images are dated Dec 1982. The build process' output file “romterm” is dated Nov 1983. Some of the libraries have source files with dates into 1984. It would seem that the surviving rom images are for a fairly early iteration of the system.


> On Dec 18, 2019, at 11:43 AM, Julius Schmidt <aiju@phicode.de> wrote:
> 
> I also noticed that the ROM binaries differed from the source code, when I was writing the Blit emulator, by comparing disassembled binaries with the source. In particular, the compiled code makes reference to I/O registers 025 and 027 that are not referenced in the source any more. (I think there were some more differences I didn't bother to write down)
> 
> Julius Schmidt (aiju)
> 
> On Wed, 18 Dec 2019, Paul Ruizendaal wrote:
> 
>> Further to the below, I’ve now tried to build the Blit toolchain (on a contemporary OS). Other than the usual little issues, it does not take too much effort to get running.
>> 
>> Rebuilding the rom contents using the pre-existing libraries builds the exact same bits, however here is also where the good stuff ends: this only assembles two files, compiles vitty.c and the rest is library; rebuilding the libraries is different.
>> 
>> The roms rely on four libaries (libsys, libj, liblayer and libc) and none of the four rebuild to the exact same bytes or size. In several cases the archives do not even have the exact same files in them. In general, the regenerated object files often appear to be a little smaller (even when compiled with optimization off). So far I cannot tell whether this is because the compiler is different, or because the underlying source code is different. Probably a bit of both.
>> 
>> So, it would seem that an adapted rom can be compiled, but how functional it would be remains to be seen.
>> 
>> The note about the missing compiler remains intriguing. First a correction: I associate “ccom” with the DMR compiler, as it lives in a directory by that name; I had not realized that pcc also names its main binary ccom. Beyond that it would seem that two different versions of this 68K compiler were floating around and maybe the surviving one puts different debug info in the symbol table.
>> 
>> 
>> 
>>>> Date: Sun, 15 Dec 2019 22:17:53 +0100
>>>> From: Angelo Papenhoff <aap@papnet.eu>
>>>> 
>>>> On 15/12/19, Paul Ruizendaal wrote:
>>>>> I’m aware of this emulator:
>>>>> https://github.com/aap/blit <https://github.com/aap/blit>
>>>> 
>>>> This is only a port to unix I did. The original one was written by aiju.
>>>> The upstream version (which is in fact more up to date) is part of the 9front repo:
>>>> https://code.9front.org/hg/plan9front/file/5003ea45cc4d/sys/src/games/blit
>>>> Aiju reverse engineered the hardware from the source code on the second tape:
>>>> https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/v8jerq.tar.bz2
>>> 
>>> Thanks! The “blit” directory in that archive indeed appears to be what I’m looking for. Hopefully it has enough to enable rebuilding from source.
>>>> 
>>>> I don't know how complete it is and I think the compiler is also not
>>>> included, but I'm not too sure how it all worked.
>>> 
>>> From a quick inspection there appears to be a subdirectory “m” with motorola tools. It appears to have a M68K pcc-based compiler. It also has this README file:
>>> 
>>> ===
>>> the source for /usr/blit/lib/ccom has been lost.
>>> the source here (Mip and Mcc) is for a compiler that does not generate
>>> the correct symbol tables for joff and pi.
>>> we wish we had the source, but we don't, so the binary is precious.
>>> please handle it with care.
>>> 
>>> if you decide you need to recompile ccom, contact us.
>>> we may have found a solution by then...
>>> ===
>>> 
>>> The “bin” directory has that ccom binary. It suggests that there once was a M68K compiler that derived from the Ritchie PDP11 compiler. I assume that the source for that has stayed missing ever since 1985.
>>> 
>>>> On 16 Dec 2019, at 07:25, emanuel stiebler <emu@e-bbes.com> wrote:
>>>> 
>>>> On 2019-12-15 21:45, Paul Ruizendaal wrote:
>>>>> I’m looking for source code of the original Blit as described here:
>>>>> http://doc.cat-v.org/bell_labs/blit/blit.pdf
>>>> 
>>>> Thanks for trying again. It pops up on this list every few years, but
>>>> still no schematics (2002, 2012) …
>>> 
>>> It would seem that the circuit was intentionally simple and straightforward: a M68K cpu, ram, rom, two 6850 UARTS and the circuit to drive the display. The key aspects of the video circuitry (and mouse circuitry) are discussed in this paper:
>>> https://9p.io/cm/cs/doc/87/archtr.ps.gz ("Hardware/Software Tradeoffs for Bitmap Graphics on the Blit”).
>>> 
>>> It would seem to me that doing a version of the Blit that runs on a FPGA board and generates 720p HDMI output would not be impossible to do, if the software can be configured to deal with a different geometry (e.g. 1024x720 instead of 800x1024). Whether that would be much different from running the emulator on a PC remains unclear, of course.
>> 
>> 
>> 
>> 

Re: [TUHS] Blit source

[Paul Ruizendaal]

[-- Attachment #1: Type: text/plain, Size: 3017 bytes --]


> On Dec 16, 2019, at 7:25 AM, emanuel stiebler <emu@e-bbes.com> wrote:
> 
> On 2019-12-15 21:45, Paul Ruizendaal wrote:
>> I’m looking for source code of the original Blit as described here:
>> http://doc.cat-v.org/bell_labs/blit/blit.pdf
> 
> Thanks for trying again. It pops up on this list every few years, but
> still no schematics (2002, 2012) ...
> 
> Cheers

Have you seen the 5620 schematics on bitsavers?

http://bitsavers.org/pdf/att/5620/schematic/5620_logic.pdf <http://bitsavers.org/pdf/att/5620/schematic/5620_logic.pdf>

Of course it is not the Blit schematics, but it looks like a close derivative. When comparing the Hardware & Software Tradeoffs paper with the schematics and the theory of operation notes at the back, it would seem to me that much of it is (near) identical to the 68K Blit.

- The video timing circuit was probably identical (also see the figures at the back with exact timing specifications).
- The memory grid was probably (near) identical - maybe changed slightly for the option to use 256Kx1 drams.
- The arbitration circuit may have been redesigned, but it looks like the bus arbitration of the M68K was not all that different from the Bellmac. A memory cycle takes 11 ticks of the 32.7 MHz pixel clock, or about 335ns. This is consistent with the numbers mentioned in the Blit papers (e.g. the display using about 30% of memory bandwidth, etc.).
- The mouse movement circuit appears unchanged from the Blit paper, with a two-phase motion signal counted for the first 4 bits in a PAL and the rest in a TTL counter

Some things are of course different (beyond the different CPU). The 5620 has an I/O expansion port and a bit of non-volatile memory, neither of which is mentioned in the Blit papers. The memory map is totally different and the protection for null pointer dereference appears gone.

The 2x 6850 UART appears to be replaced by a single 2681 programmable DUART. The button signals are routed through the additional parallel I/O bits that this chip provides, which also takes care of interrupt generation. According to the Blit papers there were several other versions of the Blit before the final design was arrived upon. Maybe earlier designs used a 2681 DUART as well, or its close cousin SCN68681. Maybe the earlier version of button.c could work with both. If this is true, it would stand to reason that the various features of the 2681/68681 were replicated with the two 6850’s and some supporting circuitry. This hypothesis seems to fit with some of aiju’s observations in the “mmap” information file included with the Blit emulator (e.g. accessing register 25 and 27, the timer/counter and its use for sound generation).

The Blit promotional video that AT&T put on youtube in 2012 has a brief shot (at 0:45) of the logic board. This appears to show two 24 pin packages in the bottom center of the board, which are in all likelihood the 6850’s. There is no 40 pin package (i.e. no 2681/68681 chip) on that board.


[-- Attachment #2: Type: text/html, Size: 4055 bytes --]