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.

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. 9front repo: https://code.9front.org/hg/plan9front/file/5003ea45cc4d/sys/src/games/blit tape: https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/v8jerq.tar… 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: 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”). 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.

On Dec 18, 2019, at 11:43 AM, Julius Schmidt &lt;aiju(a)phicode.de&gt; 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 &lt;aap(a)papnet.eu&gt; >>> >>> 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 &lt;emu(a)e-bbes.com&gt; 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. > > > >