From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 2185a980 for ; Wed, 18 Dec 2019 10:50:43 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 9A9ED9BC42; Wed, 18 Dec 2019 20:50:42 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 942DF9BC14; Wed, 18 Dec 2019 20:49:54 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=phicode.de header.i=@phicode.de header.b="SLb0zB3L"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id B7FF29BC14; Wed, 18 Dec 2019 20:49:51 +1000 (AEST) X-Greylist: delayed 399 seconds by postgrey-1.36 at minnie.tuhs.org; Wed, 18 Dec 2019 20:49:48 AEST Received: from phicode.de (www.phicode.de [136.243.147.240]) by minnie.tuhs.org (Postfix) with ESMTPS id ED8519B92E for ; Wed, 18 Dec 2019 20:49:48 +1000 (AEST) Comment: DomainKeys? See http://domainkeys.sourceforge.net/ DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=phicode.de; b=JfNASOskTAbMrKWD8CyeTLDM63b/BoyXUFpQAqhq2YJGXfFi94AubuF5hScqpu0lD3Gv9pV4ULfDJovurogBT/KRXMzO5Yw7IXRmNRDP7i1S/ZKU+V++Fhh7Sb4YB/Ea4HO0UQxiYl5zQoliUHEQkxc/PUGt9IZLazrQKRFBk44=; h=Received:Received:Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:User-Agent:MIME-Version:Content-Type:Content-ID; DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=phicode.de; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version :content-type:content-id; s=default; bh=aAqFLGq9G7DOdViEyc2UvbGs GMc=; b=SLb0zB3LvN0b1sBY2/UZN1rAqEToDpQIm1zhxvrH/m+sRqdt2kCWLiP2 WjiodUU9bft4jzkrqGZZ1huqlaLVHHLAo4Kt9feKqDohjBOcmpgLWU79StVt8OAP xqhPCLEaoY5kH/JFjMIwfHddQa5K2w14htkju9AzTsO4NOqHyEg= Received: (qmail 32486 invoked from network); 18 Dec 2019 10:43:06 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 18 Dec 2019 10:43:06 -0000 Date: Wed, 18 Dec 2019 11:43:05 +0100 (CET) From: Julius Schmidt To: Paul Ruizendaal In-Reply-To: <766B1E87-501A-4675-91A5-DCDA35FFEB98@planet.nl> Message-ID: References: <6be1d013-2323-9850-03fd-c4014c4a69e7@e-bbes.com> <766B1E87-501A-4675-91A5-DCDA35FFEB98@planet.nl> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-209129325-1345636128-1576665551=:7981" Content-ID: Subject: Re: [TUHS] Blit source X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---209129325-1345636128-1576665551=:7981 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: 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 >>> >>> On 15/12/19, Paul Ruizendaal wrote: >>>> I’m aware of this emulator: >>>> 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 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. > > > > > ---209129325-1345636128-1576665551=:7981--