ELKS CVS imported into Git with all history

ELKS CVS imported into Git with all history

[Jody]

Hello everyone on the ELKS list; check this out:

http://elks.git.sourceforge.net/git/gitweb.cgi?p=elks/elks;a=summary

Took me a few hours to get right, but there it is, for better or worse. 
You're welcome. ;-)  Now I'm going to bed.

Jody Bruchon

howto start

[kqt4at5v]

My dad gave me his old Tandy 1000TX
It is in good working order and I would like to run ELKS
I see from recent list posts that things are a changing
I have read the FAQ and downloaded elks.tar.xz but I find no images.zip
Before I go off screwing things up could someone offer some brief starter instructions

Richard

Re: howto start

[kqt4at5v]

So I have a boot image to burn to floppy
My pc has a 1.44MB floppy and my Tandy has a 720KB floppy
I can burn the boot image to floppy and it will boot my pc but the Tandy 
tells me it is an invalid boot disk
I am sure y'all have run into this before so what is the cure

Richard

Re: howto start

[Jody]

On 2/7/2012 7:08 AM, kqt4at5v@gmail.com wrote:
> So I have a boot image to burn to floppy
> My pc has a 1.44MB floppy and my Tandy has a 720KB floppy
> I can burn the boot image to floppy and it will boot my pc but the 
> Tandy tells me it is an invalid boot disk
I believe this is a problem with lots of 720KB floppies being written in 
1.44MB drives. You'll have to format the disk as a 720KB disk, THEN 
write the image to it, and even then it has a chance of not working. I 
assume that you are using a 1.44MB disk; make sure it's formatted as a 
720KB disk, not a 1.44MB disk.

Jody

Re: howto start

[David Given]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

Jody wrote:
[...]
> I believe this is a problem with lots of 720KB floppies being written in
> 1.44MB drives. You'll have to format the disk as a 720KB disk, THEN
> write the image to it, and even then it has a chance of not working. I
> assume that you are using a 1.44MB disk; make sure it's formatted as a
> 720KB disk, not a 1.44MB disk.

The disk head on a 1.44MB drive is half the size of the head on a 720kB
drive. If you format a 720kB disk in a 1.44MB drive it just formats
every other track on the disk.

This is fine if the disk was previously unformatted, but if it had been
formatted with something else then the wide 720kB head will pick up the
new formatted track *and* the old data from the other half of the 720kB
track and get confused. [*]

To make it work reliably you may well need to scrounge up a 720kB drive
to put in the PC, or else find a way to use a 1.44MB drive for the
Tandy. (There's a reason why everyone hates floppies...)



[*] It may be technically feasible to make the 1.44MB drive duplicate
the data to both halves of the 720kB track, but this will require magic
hackery to write tracks with the 'wrong' track ID, and I don't know how
to do that.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: howto start

[David Given]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

Kirn Gill wrote:
> A 1.44MB disk can be low-level formatted using the Linux "fdformat"
> program to have the physical layout of a 720KB disk.

Whoops, sorry --- you're absolutely right. 720kB heads *are* the same
width as 1440kB heads (they use different numbers of sectors per track).
I was confusing it with 40-track vs 80-track, which is a different but
equally obselete era. Ignore what I said earlier.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: howto start

[kqt4at5v]

On Tue, 7 Feb 2012, Jody wrote:

>
>
> On 2/7/2012 7:08 AM, kqt4at5v@gmail.com wrote:
>> So I have a boot image to burn to floppy
>> My pc has a 1.44MB floppy and my Tandy has a 720KB floppy
>> I can burn the boot image to floppy and it will boot my pc but the Tandy 
>> tells me it is an invalid boot disk
> I believe this is a problem with lots of 720KB floppies being written in 
> 1.44MB drives. You'll have to format the disk as a 720KB disk, THEN write the 
> image to it, and even then it has a chance of not working. I assume that you 
> are using a 1.44MB disk; make sure it's formatted as a 720KB disk, not a 
> 1.44MB disk.
>
> Jody

Well I have a working boot disk Tandy can read
I tried covering the hd hole in a 1.44MB disk and formating it in the Tandy then writing the boot file on the pc, but still no cigar
The only thing that worked so far is writing a old 720KB disk on the pc using 'dd if=Image of=/dev/fd0u720'
Y'all recon if I put a 1.44MB drive in the Tandy it would recognize it
Anyway now to a root file
I tried just a make in elkscmd and got a number of errors complaining about missing header files
The header files do exist in elks/include/linuxmt/ but some source files a compiled without the extra include directory option, -I
What is the reasoning for some with -I and some not
I thought it best to ask before I started hacking the make file

Richard

Re: howto start

[kqt4at5v]

When I run make in elkscmd I get

make[2]: Leaving directory `/mnt/g3/home/rray/work/elks/tmp/elkscmd/sys_utils'
make[2]: Entering directory `/mnt/g3/home/rray/work/elks/tmp/elkscmd/ash'
./mkinit 'bcc -c -0 -O -ansi -DSHELL -I. -D_MINIX -D_POSIX_SOURCE "-DELKS_VERSION=\"0.1.3-pre1\"" init.c' builtins.c cd.c dirent.c error.c eval.c exec.c expand.c input.c jobs.c mail.c main.c memalloc.c miscbltin.c mystring.c nodes.c options.c parser.c redir.c show.c signames.c syntax.c trap.c output.c var.c
bcc -c -0 -O -ansi -DSHELL -I. -D_MINIX -D_POSIX_SOURCE "-DELKS_VERSION=\"0.1.3-pre1\"" init.c
init.c:1: CPP-FATAL error: Cannot open input file
make[2]: *** [init.o] Error 1

There is no init.c in elkscmd/ash directory

Richard

Re: ELKS CVS imported into Git with all history

[Harley Laue]

On 02/05/2012 11:14 PM, Jody wrote:
> Hello everyone on the ELKS list; check this out:
>
> http://elks.git.sourceforge.net/git/gitweb.cgi?p=elks/elks;a=summary
>
> Took me a few hours to get right, but there it is, for better or 
> worse. You're welcome. ;-)  Now I'm going to bed.
>
> Jody Bruchon
Just a curious question, is there a reason you decided to have elks, 
elkscmd, and elksnet in the same repo instead of splitting them into 
their own git repos?

Re: ELKS CVS imported into Git with all history

[Jody Bruchon]

On 02/07/12 09:49, Harley Laue wrote:
> On 02/05/2012 11:14 PM, Jody wrote:
>> Hello everyone on the ELKS list; check this out:
>>
>> http://elks.git.sourceforge.net/git/gitweb.cgi?p=elks/elks;a=summary
>>
>> Took me a few hours to get right, but there it is, for better or 
>> worse. You're welcome. ;-)  Now I'm going to bed.
>>
>> Jody Bruchon
> Just a curious question, is there a reason you decided to have elks, 
> elkscmd, and elksnet in the same repo instead of splitting them into 
> their own git repos?
The simplest reason is that it was far easier to do it all in one shot 
(IOW: I'm lazy); additional thoughts include:

* It's all one big project (i.e. ELKS the kernel is useless without 
commands to run)
* It seems that these components are tightly tied to each other (really, 
what use is elkscmd without the ELKS kernel?)
* elksnet is minuscule and shouldn't have its own repository; if 
anything, I feel it should be merged into elkscmd.
* I'm a minimalist and a pragmatist, and while the command sources 
should be split from the kernel sources, I see no reason to dump them 
into different repos; without an obvious and practical good reason to 
add that extra complication, I won't.

Of course, if I'm wrong in that choice, we should talk about why. 
Honestly, at this stage, ELKS is in very real danger of dropping into 
irrelevance and left to rot forever. I could care less if every command 
had its own git repo, so long as people are working on the project!

Additionally, I'd like to assemble a list of open-source compilers that 
can build for 8086 and either are targeted to other 16-bit CPUs or can 
be relatively easily retargeted (I use that term loosely with compilers. 
If anyone has suggestions for alternative compilers, please email me 
with them, and I'll build a list and examine the merits of each against 
the others. The only ones I know of are tcc (by Fabrice Bellard), SDCC 
(targets Z80 but maybe we can retarget it)...and the venerable Bruce's C 
Compiler (bcc) which we already use. I dug up the original (non-Dev86) 
source for it and the 6809 target parts are in that version, so maybe I 
can figure out how to retarget it if I can dig up a 6809 emulator somewhere.

Jody Bruchon

Re: ELKS CVS imported into Git with all history

[David Given]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

On 07/02/12 21:38, Jody Bruchon wrote:

> Additionally, I'd like to assemble a list of open-source compilers that
> can build for 8086 and either are targeted to other 16-bit CPUs or can
> be relatively easily retargeted (I use that term loosely with compilers.
> If anyone has suggestions for alternative compilers, please email me
> with them, and I'll build a list and examine the merits of each against
> the others.

I 'maintain' the Amsterdam Compiler Kit, the compiler written by Andy
Tanenbaum and Ceriel Jacobs. It's here:

http://tack.sourceforge.net

It compiles, poorly, for a bunch of different architectures; it contains
 its own runtime libraries and toolchains and is a turnkey solution to
producing (static) binaries for small devices. Plus it supports a
variety of different languages, including K&R C, ANSI C, Pascal and
Modula-2.

Alas, there's no 6809 support other than an assembler. (And possibly
linker support, too.)

(The scare quotes around 'maintain' are because I haven't touched it for
ages --- the compiler architecture is interesting but painfully limited
and rather less useful than I thought it would be, and there's very
nearly no interest. But it *is* a working compiler.)

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "Never attribute to malice what can be adequately explained by
│ stupidity." --- Nick Diamos (Hanlon's Razor)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: ELKS CVS imported into Git with all history

[Kirn Gill]

On Tue, Feb 7, 2012 at 16:38, Jody Bruchon <jody@jodybruchon.com> wrote:
> Additionally, I'd like to assemble a list of open-source compilers that can
> build for 8086 and either are targeted to other 16-bit CPUs or can be
> relatively easily retargeted (I use that term loosely with compilers. If
> anyone has suggestions for alternative compilers, please email me with them,
> and I'll build a list and examine the merits of each against the others. The
> only ones I know of are tcc (by Fabrice Bellard), SDCC (targets Z80 but
> maybe we can retarget it)...and the venerable Bruce's C Compiler (bcc) which
> we already use. I dug up the original (non-Dev86) source for it and the 6809
> target parts are in that version, so maybe I can figure out how to retarget
> it if I can dig up a 6809 emulator somewhere.
>
> Jody Bruchon
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I think that, going forward, we should consider adding support for
more modern 32-bit architectures into ELKS. After all, the "E" is
"Embeddable", and a lot of embedded systems today are based on
low-cost 386 clones and ARM chips, with the occasional MIPS system
here and there. System memory is usually within a range between a few
hundred KiB to a few MiB. Think of JavaCards, systems where .NET Micro
Edition or J2ME would be used, that sort of thing. After all, the
"CPU" targets in ELKS already stand at "8086", "80286", "80386", and
"80486" - someone already had some plans in this direction - and code
that's flexible enough to support all the main features of each would
probably be highly portable to nearly any 16-bit or 32-bit system.

As for interesting 16-bit systems, I think the 65C816 and the 80286
(in protected mode) are worth checking out. 286 PM increases the
segmentation to 4KiB offsets, identical to the 6809 and the 65C816.
However, the 6809's only has 20-bit addressing overall, whereas the
65C816 and the 286 have 24-bit addressing - having 16MiB of RAM to
play with isn't bad, either. This makes the PC/AT and the Apple IIgs
as first-to-mind targets.
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ELKS CVS imported into Git with all history

[Juan Perez-Sanchez]

On 2/7/12, Jody Bruchon <jody@jodybruchon.com> wrote:
> Additionally, I'd like to assemble a list of open-source compilers that
> can build for 8086 and either are targeted to other 16-bit CPUs or can
> be relatively easily retargeted (I use that term loosely with compilers.
> If anyone has suggestions for alternative compilers, please email me
> with them, and I'll build a list and examine the merits of each against
> the others. The only ones I know of are tcc (by Fabrice Bellard), SDCC
> (targets Z80 but maybe we can retarget it)...and the venerable Bruce's C
> Compiler (bcc) which we already use. I dug up the original (non-Dev86)
> source for it and the 6809 target parts are in that version, so maybe I
> can figure out how to retarget it if I can dig up a 6809 emulator somewhere.

Other alternative compilers:

   open watcom => http://www.openwatcom.org
     Free open source, in active development, complete implementation,
     produces highly optimized code, targets only x86 cpu's.

   gcc-86 =>
       http://git.etherboot.org/?p=people/dverkamp/gcc.git
       http://git.etherboot.org/people/hpa/i86-gcc.git/
       http://www.spinics.net/lists/linux-8086/msg00228.html
       http://raisama.net/gcc-8086/
       http://www.delorie.com/djgpp/16bit/gcc/
     Free open source, unofficial, no development, only tiny memory model,
     produces optimized code, multiple targets.

At these moment, I consider more urgent:

  1. Make ELKS work as expected.
  2. Make C code ansi compliant.
  3. Change assembly code to C wherever possible.
  4. Rearrange files such that at the upper level directories there are only
     C, architecture independent code, and below arch/, all assembly and only
     architecture dependent code.

All these ease targeting other cpu's. I'll try to contribute on these.

Re: ELKS CVS imported into Git with all history

[Harley Laue]

On Tue, 07 Feb 2012 16:38:33 -0500
Jody Bruchon <jody@jodybruchon.com> wrote:

> On 02/07/12 09:49, Harley Laue wrote:
> > On 02/05/2012 11:14 PM, Jody wrote:
> >> Hello everyone on the ELKS list; check this out:
> >>
> >> http://elks.git.sourceforge.net/git/gitweb.cgi?p=elks/elks;a=summary
> >>
> >> Took me a few hours to get right, but there it is, for better or 
> >> worse. You're welcome. ;-)  Now I'm going to bed.
> >>
> >> Jody Bruchon
> > Just a curious question, is there a reason you decided to have
> > elks, elkscmd, and elksnet in the same repo instead of splitting
> > them into their own git repos?
> The simplest reason is that it was far easier to do it all in one
> shot (IOW: I'm lazy); additional thoughts include:

I can understand where you're coming from with that :)

> * It's all one big project (i.e. ELKS the kernel is useless without 
> commands to run)

I've personally never found that a very compelling argument. The same
could be said about glibc, bash, etc to the Linux kernel. Having also
studying the BSD source repos, I'm not terribly against it either to be
honest.

> * It seems that these components are tightly tied to each other
> (really, what use is elkscmd without the ELKS kernel?)

Well, I was just able to compile sash, bc, byacc, & file_utils and run
them unaltered on an x86_64 Linux box. Granted some seem more tightly
tied in (ash, elvis, and rc I also tried without any luck.) I guess my
argument for this being split, if you want to call it an argument, is
this is more like busybox (or the GNU tools) and the kernel is its own
thing which may or may not use this as its interface. Basically the
kernel should be able to run any program the user may want, not
necessarily tied to elkscmd.

> * elksnet is minuscule and shouldn't have its own repository; if 
> anything, I feel it should be merged into elkscmd.

Agreed. Probably elksutils would be a candidate to merge in as well.

> * I'm a minimalist and a pragmatist, and while the command sources 
> should be split from the kernel sources, I see no reason to dump them 
> into different repos; without an obvious and practical good reason to 
> add that extra complication, I won't.

I did this back in 2009 with and it was only four commands to export
each partial repo. (One for elks, elkscmd, elksnet, & elksutils.)
*shrugs*

> Of course, if I'm wrong in that choice, we should talk about why. 
> Honestly, at this stage, ELKS is in very real danger of dropping into 
> irrelevance and left to rot forever. I could care less if every
> command had its own git repo, so long as people are working on the
> project!

I completely agree that I'd love to see people working on the project
above all else. I just thought I'd bring this up at an early stage so
if needed/wanted it could still be easily changed without much hassle
to anyone who's still interested in the source.

> Additionally, I'd like to assemble a list of open-source compilers
> that can build for 8086 and either are targeted to other 16-bit CPUs
> or can be relatively easily retargeted (I use that term loosely with
> compilers. If anyone has suggestions for alternative compilers,
> please email me with them, and I'll build a list and examine the
> merits of each against the others. The only ones I know of are tcc
> (by Fabrice Bellard), SDCC (targets Z80 but maybe we can retarget
> it)...and the venerable Bruce's C Compiler (bcc) which we already
> use. I dug up the original (non-Dev86) source for it and the 6809
> target parts are in that version, so maybe I can figure out how to
> retarget it if I can dig up a 6809 emulator somewhere.

SDCC may be an option, but it would need quite a bit of work to do the
retarget. I've used this compiler for the Z80 and it works quite well
and is the only one of the three mentioned that is still actively
maintained/updated (and supports a few other 8 & 16 bit processors.)
Another possibility might be to add 8086 support to LLVM. I doubt LLVM
would be interested in having the support built in, but SDCC may
actually accept patches to target 8086-80286 processors. Another
possibility that looks to already support i86 is ACK (The Amsterdam
Compiler Kit.) It looks to be pretty up-to-date and maintained as well.