Re: [Tack-devel] [Spam] MINIX 1.5 and ACK

[David G. <dg...@co...>]

I know Minix 2 does have some networking support (with the usual Minix
architecture of having network drivers in the kernel but the TCP/IP
subsystem is a userspace server), but have never used it. See
https://minix1.woodhull.com/hints.html#nethints. There's a reference there
to someone running a HTTP server on a 286 with Minix 2.0.3, so 64kB
segments does obviously work... somehow.

On Mon, 1 Apr 2019 at 12:47 Christian Groessler <ch...@gr...> wrote:

> I've looked at your github page.
>
> I'm not hooked on exactly Minix version 1.5. Because I'd like to have
> TCP/IP as well. Is there a version (Minix 2.0?) which supports IP and still
> works on systems with 64K segments?
>
> And I'd like to have it self-hosting. So finding the ACKPACK sources would
> be good. I'm expecting work to be done there for Z8000.
>
> regards,
> chris
>
>
> On 3/31/19 1:44 PM, David Given wrote:
>
> This is the Z8000 code generator and assembler in the current version of
> the ACK.
>
> Bear in mind that ACKPACK probably *didn't* have the Z8000 code generator
> integrated into it, given that there doesn't appear to have been a Minix
> port for it and the compiler support looks fairly unfinished. So there's
> definitely work to do.
>
> Incidentally, re Minix: I also have this:
> https://github.com/davidgiven/minix2 It's a Minix 1.7 and 2.0
> distribution wrapped in some useful scripts for easy development on Linux
> --- a single script will build a bootable image from source, start it in
> qemu to do builds, unpack it again afterwards, etc. It doesn't have Minix
> 1.5 or 1.2 in it because I haven't figured out how to boot them in qemu
> yet. It's got all the source *except* the ACKPACK compiler, which wasn't
> in the standard distributions. It'd be awesome to get source for everything.
>
> On Sun, 31 Mar 2019 at 00:36 Christian Groessler <ch...@gr...>
> wrote:
>
>> Hi,
>> On 3/22/19 9:26 PM, David Given wrote:
>>
>> I had a play with the code. The Z8000 code generator builds and runs and
>> generates code, but of course I have no idea whether it generates working
>> code. The assembler does not; in common with a lot of the very old
>> architectures it's runs in assembler/linker mode, where it generates
>> non-relocatable binaries rather than .o files which can be linked together.
>> This would need fixing. (I've done it before and it's not a lot of work.)
>>
>>
>> You "played" with which code exactly?
>>
>>
>> Of course, it still needs a plat with a syscall library, startup code etc
>> before it'll do anything useful.
>>
>>
>> I'm aware of that, but that I'm considering to be part of porting Minix
>> to the M20.
>>
>>
>> What OS does the M20 run?
>>
>>
>> It typically runs "PCOS", a proprietary Olivetti OS. There's also
>> CP/M-8000 available for it.
>>
>> For PCOS, there is a rather old gcc version available at
>> ftp://ftp.groessler.org/pub/chris/olivetti_m20/misc/z8kgcc/ . CP/M comes
>> with it's own C compiler.
>>
>>
>> But for porting Minix 1.5 to the M20 I'd like to use (ideally) the same
>> ACK compiler version which was used for the other versions (8086 PC, M68K
>> Atari, Amiga).
>>
>>
>> regards,
>> chris
>>
>>
>>
>>
>> On Fri, 22 Mar 2019, 18:54 Christian Groessler, <ch...@gr...>
>> wrote:
>>
>>> Not in the way the 8086 did with its segment registers.
>>>
>>> But the CPU has output pins which indicate if a memory access is an
>>> instruction fetch or data access. And the M20 implements (at least) one
>>> segment where this is used. So address X points to different physical
>>> memory, depending on whether it's an instruction or data access.
>>>
>>> regards,
>>> chris
>>>
>>>
>>> On 3/22/19 5:48 PM, David Given wrote:
>>>
>>> Did the Z8000 do split I/D? The 8086 cheated because both code *and* data
>>> got different 64kB address spaces, so you could have 64kB of code and still
>>> have 64kB of data. I don't think you could fit the compiler into a single
>>> 64kB space.
>>>
>>> There is a Z8000 code generator in the ACK but it's based on the old
>>> _old_ code generator model and was last touched in the 1990s, so I don't
>>> know whether it works or what the code quality is like. Plus, of course,
>>> then you need to make it fit.
>>>
>>>
>>> On Fri, 22 Mar 2019 at 14:05 Christian Groessler <ch...@gr...>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 3/11/19 8:13 AM, Jacobs, C.J.H. via Tack-devel wrote:
>>>> > Good question! I survived, and I produced those binaries back then.
>>>> But this was a very long time ago,
>>>> > and my memory has never been any good... nor are my archiving
>>>> skills... When I find some time, I’ll
>>>> > see if I can do some digging. From what I remember, the only real
>>>> problem was getting the compiler front-end
>>>> > to fit in 64K instruction space and 64K data space. For that, we took
>>>> out the C preprocessor (which was/is built-in
>>>> > into the C frontend) and made it a separate pass, and we also took
>>>> out the floating-point library. Other than that,
>>>> > I don’t remember exactly, but I think it was just a little bit of
>>>> tweaking.
>>>>
>>>>
>>>> It would be great if you would find this version.
>>>>
>>>> I'm toying with the idea to port Minix 1.5 to the Olivetti M20, a Z8000
>>>> based computer. The Z8000 has 64K segments as well.
>>>>
>>>> regards,
>>>> chris
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Tack-devel mailing list
>>>> Tac...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/tack-devel
>>>>
>>>