> Okay, thanks. Sorry for the ignorant question. I only just now learned
> that some 8085 assemblers do not use 8085 syntax. (Zasm uses Z80
> syntax, for anyone as confused as I was.)
>
A lot of people used to Z80 seem to prefer Z80 syntax
>
> I’m intrigued by Fuzix OS. Am I understanding correctly that you are
> running a custom-built 8085 machine with a self-hosting OS that is
> comparable to UN*X circa 1983? Would I be wrong to presume running
>
It's not self hosting yet but that is the goal - the compiler will indeed
run on
the machine itself but I need to improve make, clean up and simplify the
build
system and a load of other stuff to finally get it self hosting.
Fuzix on a stock Model T is out of the question due to the lack of a
> Memory Management Unit? And am I right in thinking that the circuit
> surgery needed to add an MMU to a Model T is prohibitively invasive? I
> haven’t thought about MMUs since college, but I recall them being
> deeply intertwingled with the fundamental design of the system. (Then
> again, I’m pretty sure the professor also never taught us that you
> could make an MMU from just a latch, a MUX, and an AND gate.)
>
It needs memory banking. It's possible that with sufficient donuts someone
could
persuade it to run on some banked Rex type device that also had a fast disk
device
(SD card or similar in it). At that point though I'm not really sure it's
a model T any
more ! An MMU is not needed - in fact there were a bunch of ports to
machines
without an MMU in the early days (eg PC/IX on 8086) and if you got it badly
wrong
a user crashed the machine. That was considered acceptable back then.
>
> You mentioned the Fuzix assembler might be useful for the Model T
> community. What about the Fuzix C Compiler? The webpage mentions that
> the compiler’s 8085 code runs several times faster on than the 8080
> and that the 8085’s undocumented instructions “make a huge difference
> when executing high level languages.” That sounds nifty. When John
> makes his list of development environments and their pros and cons, is
> fcc one that should be considered as a cross-compiler?
>
Someone would need to write a crt0.S (the C runtime startup) and figure how
to
get from binary images to something useful on the model T, and you'd need to
put together some kind of minimal C library. 8085 output is a lot faster
and smaller
in the C case than 8080. Things like getting a value off the stack become
ldsi #offset
lhlx
not
lxi h,offset
dad sp
mov e,m
inx h
mov d,m
xchg
for example
> One last question: It looks like you already have fcc running on an
> 8085 system. How reasonable would it be to try to port it to run on a
> Model T? (Okay, perhaps “reasonableness” isn’t the right metric as the
> fact that I want to compile C on my Tandy 200 already demonstrates a
> lack of sound judgment. :-)
>
You need about a 48-56K memory area for the application and you need a
better disk device than a floppy. I think in theory you could run it under
CP/M
on some of the expansions but it would involve a fair bit of work.
Probably you'd want to generate a C library for CP/M then compile it with
fcc to get an fcc to run on CP/M but there's a list of "except that..."
involved
in that CP/M has no nice way for a program to run another and pass a load
of arguments, then get control back, and disk I/O is 128 byte blocks, and
has no subdirectories and so on.
So I suspect it's an RFC 1925 rule 3 item.
(3) With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead.
