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(a)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(a)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…
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(a)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:
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.