: Do we still have the 512k file size limit?
Yep. But I'll fix it.
:
: I thought that libc was bigger than this or something, and that was one of
: the limiting factors on a self hosted bcc. Did I remember this wrong?
You're right. Its kinda funny that we could get the com
> > This is why elvis, as86, and many, many other large programs have never
> > run. Elks never let programs have > 32k data segments!
> > With this fix, I plan on self-hosting bcc and as86, which now will
> > run...
>
> The reason bcc wouldn't run was because it was too large (> 64k) to eve
Al,
In regards to patch #2, are you trying to make almost all the mods I sent in,
including the elkscmd makefile stuff? I would like it if you could.
Also, I have rewritten dircon.c last night (except for the bell()) issue that you just
mentioned). I have attached it. It is better tha
:
: I agree, but of late I've had little enthusiasm to try and trim the fat
: off the larger areas of the code. In particular, the inode hashing code
: in fs (or is it specific to minixfs) is basically redundant. Firstly, we
: can do without hashing for a slight speed decrease. Also, the hashi
: Yep, it won't do anything. The only commands supported, are: m (color),
: s (save location), u (unsave location), A (up), B (down), C (right),
: D (left), K (clear EOL). Mainly because these functions were already
: existing in the dircon code so it was very easy to interface to them.
:
> email the patches for elks 0.77 and elkscmd 0.77.
: >
: > o Ported elvis to ELKS
:
: Is this based on the code that was in elkscmd?
Yep.
:
: > o changed all elkscmd srcs to use tcsetattr/tcgetattr instead of ioctl
:
: I previously held back from doing this to make the mi
Greg Haerr writes:
>
> Al,
> I spent a good portion of the weekend fixing quite a few ELKS
> bugs, trying to get a good visual editor running. It seems I have succeeded.
> Following is the list of fixes that I have performed. I will attach in the next
> email the patches for elks 0.77 and
On Mon, 12 Jul 1999, Greg Haerr wrote:
> Killed your baby? Why, it seems this one died from neglect ;-)
> try typing ESC [ H on the console. Nothing happens.
Yep, it won't do anything. The only commands supported, are: m (color),
s (save location), u (unsave location), A (up), B (down),
: You killed my baby?? Exactly how has it stopped working? It's not a very
: complete implementation, only half-a-dozen ANSI commands are supported.
Killed your baby? Why, it seems this one died from neglect ;-)
try typing ESC [ H on the console. Nothing happens.
:
: > o added
On Tue, 13 Jul 1999, David Murn wrote:
> The reason bcc wouldn't run was because it was too large (> 64k) to even
> link. This is where the fat has to be trimmed first, before anyone even
> starts to worry about running it. I've wondered if it's possible to use
> temporary files in some way, an
On Mon, 12 Jul 1999, Greg Haerr wrote:
> BTW, the ansi elks console doesn't work. I can rewrite it quickly if
> nobody minds.
You killed my baby?? Exactly how has it stopped working? It's not a very
complete implementation, only half-a-dozen ANSI commands are supported.
> o added TERM=
: It seems to work fine for me in terms of drawing, mouse movement etc. I was
: not able to move the windows around however.
:
Geez, that's half the fun of Micro-Windows! Mouse down on the caption
of a window and drag the mouse, the window moves. Mouse down on the non-caption
area, an
On Tuesday, June 29, 1999 5:26 AM, Alistair Riddoch [SMTP:[EMAIL PROTECTED]] wrote:
: Greg Haerr writes:
: >
: > Al,
: > In using ELKS v0.77, it's apparent that ^C console signals work
: > about 50% of the time. I was going to get involved in tracking this down,
: > but have some questions fi
: I have seen something like this, but it has never frozen on me. In nano-X,
: whenever I stop moving the mouse, the cursor stops moving (as expected),
: but when I start moving it in the oposite direction, it moves a few pixels
: in the same direction as before, then changes to move in the new d
: Making the contents of images.zip is not fully automatic, but most of the
: work is done by the Makefiles. I change the Makefile a bit between buidlign
: comb and root (modify size etc.)
:
I would *really* like a makefile that automatically makes your
distribution. (its a quality thin
David Murn writes:
>
> On Mon, 28 Jun 1999, Chris Starling wrote:
>
> > Is there a better, more stable way to do ELKS emulation?
>
> Is running ELKS in vmware, or dosemu an option? This is how most
> development is done I think, and it means that you can test in the real
> ELKS rather than an
Greg Haerr writes:
>
> On Monday, June 28, 1999 1:37 PM, David Murn [SMTP:[EMAIL PROTECTED]] wrote:
> : On Mon, 28 Jun 1999, Greg Haerr wrote:
> :
> : > I can't get Micro-Windows to work with the serial mouse driver.
> : > It appears there's still possibly a bug in select(). Basically, the
>
Greg Haerr writes:
>
> Al,
> I worked on getting up to date this weekend on the linux-86 devkit (v0.14.8)
> and ELKS (v0.77). After quite a few compile time problems, I got everything
> compiling and working. I'll detail the problems later, and submit a patch.
>
> I can't get Micro
On Mon, 28 Jun 1999, Greg Haerr wrote:
> On Monday, June 28, 1999 1:37 PM, David Murn [SMTP:[EMAIL PROTECTED]] wrote:
> : On Mon, 28 Jun 1999, Greg Haerr wrote:
> :
> : > I can't get Micro-Windows to work with the serial mouse driver.
> : > It appears there's still possibly a bug in select(
On Monday, June 28, 1999 1:37 PM, David Murn [SMTP:[EMAIL PROTECTED]] wrote:
: On Mon, 28 Jun 1999, Greg Haerr wrote:
:
: > I can't get Micro-Windows to work with the serial mouse driver.
: > It appears there's still possibly a bug in select(). Basically, the
: > mouse works for about 1 seco
On Monday, June 28, 1999 1:37 PM, David Murn [SMTP:[EMAIL PROTECTED]] wrote:
: On Mon, 28 Jun 1999, Greg Haerr wrote:
:
: > I can't get Micro-Windows to work with the serial mouse driver.
: > It appears there's still possibly a bug in select(). Basically, the
: > mouse works for about 1 seco
On Mon, 28 Jun 1999, Greg Haerr wrote:
> I can't get Micro-Windows to work with the serial mouse driver.
> It appears there's still possibly a bug in select(). Basically, the
> mouse works for about 1 second and then freezes.
As I read this, the first thing that pops into my head is that
On Mon, 28 Jun 1999, Chris Starling wrote:
> Is there a better, more stable way to do ELKS emulation?
Is running ELKS in vmware, or dosemu an option? This is how most
development is done I think, and it means that you can test in the real
ELKS rather than an emulator.
Davey
On Monday, June 28, 1999 12:25 PM, Chris Starling [SMTP:[EMAIL PROTECTED]] wrote:
: > This is interesting, I was just getting ready to do this myself. I'm
:running 2.2.5.
: > I would be interested in knowing whether you crash after loading the module, but
:never
: > having run an elks b
> This is interesting, I was just getting ready to do this myself. I'm
>running 2.2.5.
> I would be interested in knowing whether you crash after loading the module, but
>never
> having run an elks binary. In other words, is it just the loading or rather the
>execution
> of the emulat
: I added the line to my rc.local file to echo "i-elks:" ..blah, blah..
: "/proc/sys/fs/binfmt_misc/register" so I could try out the binaries I compile
: with bcc. However, my machine doesn't seem to be able to stay up for more than
: a day before kswapd dies and the whole system crashes. It ha
On Fri, 25 Jun 1999, Greg Haerr wrote:
> On Friday, June 25, 1999 2:12 PM, Alistair Riddoch [SMTP:[EMAIL PROTECTED]] wrote:
> : Greg Haerr writes:
> : Sounds good. Would be implemented by the compiler, or the pre-processor?
> :
> It would be implemented by the compiler, which would emit
>
On Friday, June 25, 1999 2:12 PM, Alistair Riddoch [SMTP:[EMAIL PROTECTED]] wrote:
: Greg Haerr writes:
: >
: >
: > : So form of stack check would be nice, every function call seems a little to
: > : much for a lowly 8086. How about on task switch or even interrupt (or is
: > : this too late)? I
Greg Haerr writes:
>
>
> : So form of stack check would be nice, every function call seems a little to
> : much for a lowly 8086. How about on task switch or even interrupt (or is
> : this too late)? If the chosen size for the stack is too small, it can be
> : cured by modifying the binary rathe
Greg Haerr writes:
>
>
> : > What exactly is being gained by making this modification? The stack
> : > is fixed size in both cases. Is it just that we currently pre-reserve the
>maximum
> : > combined heap/stack now, and in the future wouldn't require the heap size
> : > to be known?
> : >
: So form of stack check would be nice, every function call seems a little to
: much for a lowly 8086. How about on task switch or even interrupt (or is
: this too late)? If the chosen size for the stack is too small, it can be
: cured by modifying the binary rather than a full recompile.
:
: >
: > What exactly is being gained by making this modification? The stack
: > is fixed size in both cases. Is it just that we currently pre-reserve the maximum
: > combined heap/stack now, and in the future wouldn't require the heap size
: > to be known?
: >
:
: Thats it exactly. Currently
Chad Page writes:
>
>
> There is (was?) some stack checking done at the system call level.
> However, it's not 100% foolproof - if the program gets sp above the
> low-water mark after dipping into bss before the next system call it won't
> be detected.
>
> Now, if you had a magic #
On Fri, 25 Jun 1999, Simon Wood wrote:
> This E-Mail and any attachments hereto are strictly confidential and
> intended solely for the addressee. If you are not the intended addressee
> please notify the sender by return and delete the message. You must not
> disclose, forward or copy this E-mail
nal Message-
> From: Greg Haerr [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, June 24, 1999 9:19 PM
> To: 'Simon Wood'; [EMAIL PROTECTED]
> Subject: RE: ELKS: Application Code, Data, Heap and Stack Size??
>
>
> : Is there any checking on the Stack Size (
Greg Haerr writes:
>
>
> : The function stack_check() in arch/i86/kernel/process.c checks to see
> : whether the stack pointer is less then the brk pointer, and segfaults if it
> : is.
> :
> stack_check() is used by the kernel to see if the user process
> has run out of space, only during
Greg Haerr writes:
>
>
> : I am seriously considering adding this to the kernel, but I am not clear
> : why the linker needs to be tweaked. Surely the linker just deals with the
> : data and bss segments, and leaves the stack and heap to be sorted out at
> : load time?
> :
>
> Well one r
Greg Haerr writes:
>
> : The fixed size stack would probably be best placed just above the bss with
> : the heap above that. This would not require any mods to the linker or
> : binary format, just changes to the kernel.
> :
>
> What exactly is being gained by making this modification? T
On Thursday, June 24, 1999 4:24 PM, Chad Page [SMTP:[EMAIL PROTECTED]] wrote:
:
: There is (was?) some stack checking done at the system call level.
: However, it's not 100% foolproof - if the program gets sp above the
: low-water mark after dipping into bss before the next system call it
There is (was?) some stack checking done at the system call level.
However, it's not 100% foolproof - if the program gets sp above the
low-water mark after dipping into bss before the next system call it won't
be detected.
Now, if you had a magic # right after bss and checked th
> I am seriously considering adding this to the kernel, but I am not clear
> why the linker needs to be tweaked. Surely the linker just deals with the
> data and bss segments, and leaves the stack and heap to be sorted out at
> load time?
If you went data bss stack heap then yes it would work out
: The function stack_check() in arch/i86/kernel/process.c checks to see
: whether the stack pointer is less then the brk pointer, and segfaults if it
: is.
:
stack_check() is used by the kernel to see if the user process
has run out of space, only during a system call. If anyone really
: I am seriously considering adding this to the kernel, but I am not clear
: why the linker needs to be tweaked. Surely the linker just deals with the
: data and bss segments, and leaves the stack and heap to be sorted out at
: load time?
:
Well one reason would be that if the bss segme
: The fixed size stack would probably be best placed just above the bss with
: the heap above that. This would not require any mods to the linker or
: binary format, just changes to the kernel.
:
What exactly is being gained by making this modification? The stack
is fixed size in both c
On Thursday, June 24, 1999 10:44 AM, Eric J. Korpela [SMTP:[EMAIL PROTECTED]]
wrote:
:
: > We also need a stack, and maybe some heap space:-
: > Where does this go and how is it allocated?
:
: Is there process stack overflow checking in ELKS? I'm pretty sure
: I saw checking of the kernel
: Is there any checking on the Stack Size (to prevent it over writing
: the stack)?
:
Not by bcc. Let me know if you'd like me to add stack overflow checking.
: Psion (on SIBO) seem to place a fixed stack at the bottom of the data
: segment (which grows down towards DS:),
Alan Cox writes:
>
> > I know that the code sized is fixed when an application is compiled, as is
> > the initialised and un-initilised data.
> > This gives us minimum code and data segment sizes.
>
> Yes
>
> > We also need a stack, and maybe some heap space:-
> > Where does this go and how
Eric J. Korpela writes:
>
>
> > We also need a stack, and maybe some heap space:-
> > Where does this go and how is it allocated?
>
> Is there process stack overflow checking in ELKS? I'm pretty sure
> I saw checking of the kernel stack...
The function stack_check() in arch/i86/kernel/pr
> We also need a stack, and maybe some heap space:-
> Where does this go and how is it allocated?
Is there process stack overflow checking in ELKS? I'm pretty sure
I saw checking of the kernel stack...
Eric
> I know that the code sized is fixed when an application is compiled, as is
> the initialised and un-initilised data.
> This gives us minimum code and data segment sizes.
Yes
> We also need a stack, and maybe some heap space:-
> Where does this go and how is it allocated?
Linux 8086 take
Simon Wood writes:
>
> Hi,
> I'm afraid I'm not understanding this.
>
> I know that the code sized is fixed when an application is compiled, as is
> the initialised and un-initilised data.
> This gives us minimum code and data segment sizes.
>
> We also need a stack, and maybe some heap sp
Greg Haerr writes:
>
> On Wednesday, June 23, 1999 1:02 PM, Joseph Dunn
> [SMTP:[EMAIL PROTECTED]] wrote:
> : Hi,
> :
> : I just downloaded ver. 0.0.77. I tried compiling, but got this error:
> :
> : make[1]: Entering directory `/home/jadunn/elks/arch/i86/drivers/char'
> : bcc -0 -I../../../../i
On Wednesday, June 23, 1999 1:02 PM, Joseph Dunn
[SMTP:[EMAIL PROTECTED]] wrote:
: Hi,
:
: I just downloaded ver. 0.0.77. I tried compiling, but got this error:
:
: make[1]: Entering directory `/home/jadunn/elks/arch/i86/drivers/char'
: bcc -0 -I../../../../include -D__KERNEL__ -O \
: -0 -c -o bi
well, i never had a problem on a pentium or a pentium II class, just
sometimes my disk decide to go wacko on me (i.e. it loses it's MBR). But
other than that, I get a nothing insted of an exit. but ive never had major
problems, everything works...
adam
> -Original Message-
> From: Joseph
Al,
Which release of ELKS has all the changes that you made to
get nano-X to run? Is it 0.76 or do you need to make another distribution?
Also, where is the latest elkscmds? What are the changes?
Greg
On Fri, 21 May 1999, Sven 'Zak' Kozma wrote:
[snip]
> Unfortunately I´ve got no CPM Disk despite of all my CPM capable computers
> |-(
[snip]
Don Maslin <[EMAIL PROTECTED]> maintains the DynaSig archives, including boot
disks for many CP/M machines. if he has what you need, for a couple bucks
h
Luke writes:
>
>
>
>
> On Tue, 25 May 1999, Sven 'Zak' Kozma wrote:
>
> > Hi Greg
> >
> > >Wow, I didn't realize that ELKS once ran on z80's! What is the zcc
> >
> > Maybe ...
> >
> > >compiler that you're talking about? Is the src available? What is scc?
> >
> > Scc is a SmallC Comp
On Tue, 25 May 1999, Sven 'Zak' Kozma wrote:
> Hi Greg
>
> >Wow, I didn't realize that ELKS once ran on z80's! What is the zcc
>
> Maybe ...
>
> >compiler that you're talking about? Is the src available? What is scc?
>
> Scc is a SmallC Compiler for the z80. SmallC is a subset of C (n
Nice one! Can't wait.
On Mon, 24 May 1999, Greg Haerr wrote:
> Al,
> I have completed all the work that I can for the ELKS port of nano-X.
> We now have all the sources completely compiling on ELKS. I have written
> all the assembly routines for ELKS. I have a serial port mouse driver
On Sat, 22 May 1999 Michael Hope wrote :
>I've been thinking about porting sdcc (which is under the GPL and active
What is it, and where can I get it ...
>development) to the Nintendo Gameboy, which is a small step away from a
It might be a nice gag to call the german magazine c´t liars :-)
b
Hi Greg
>Wow, I didn't realize that ELKS once ran on z80's! What is the zcc
Maybe ...
>compiler that you're talking about? Is the src available? What is scc?
Scc is a SmallC Compiler for the z80. SmallC is a subset of C (no math,
struct/union, typedef etc.).
Zcc is a driver to coordinate
, 1999 12:07 AM
To: Jakob Eriksson; David Murn
Cc: Greg Haerr; Linux 8086
Subject: Re: ELKS video drivers...
>> Umm, are you sure? We used to run windows 3.0 on amber monochrome
>> monitors at college.
>
>I am also unsure.
>Can someone with a clue speak up?
>> Umm
CGA cards also use a 640x200 graphic mode, which is used by our hp200lx's.
Riwal Raude
[EMAIL PROTECTED]
--
From: Greg Haerr
To: 'Riley Williams'
Cc: Linux 8086
Subject: RE: ELKS video drivers...
Date: Friday 21 May 1999 19:23
On Thursday, May 20, 1999 6:27 PM, Riley
David Given writes:
>
> [...]
> >This is a kernel only release. For userland sources and binaries, and disk
> >images please see release 0.0.75.
> [...]
>
> We have pipes, and signals, and select() --- this sounds suspiciously as if we now
>have a kernel that's actually usable. All that's neede
David Given writes:
>
> [...]
> >This is a kernel only release. For userland sources and binaries, and disk
> >images please see release 0.0.75.
> [...]
>
> We have pipes, and signals, and select() --- this sounds suspiciously as if we now
>have a kernel that's actually usable. All that's neede
> > On Mon, 17 May 1999, Greg Haerr wrote:
> > > > 1. IBM MDA.
> > > no graphics support...
> >
> > Umm, are you sure? We used to run windows 3.0 on amber monochrome
> > monitors at college.
> I am also unsure.
> Can someone with a clue speak up?
MDA is text only, Hercules is the mono gr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> >I've been thinking about porting sdcc (which is under the GPL and active
>
> What is it, and where can I get it ...
sdcc is a C compiler for the Intel 8051 which uses a custom compiler, and
AS as the linker and assembler. It's got a good opt
Diversia writes:
>
> Hi all,
>
> Where can I find the newest ELKs, for I can't find it on the ftpsites
> yet...
>
> Erik (AKA Diversia)
>
It is available from the two sites mentioned in the announcement. I only
announce new releases after I have verified that I can download them.
The URLS ar
In response to...
>> > > 1. IBM MDA.
>> >no graphics support...
>
According to the IBM Tech Reference series of manuals, the Monochrome
Display & Printer Adapter was character-only. It had a 2k character buffer
and a 2k attribute buffer so that each character could be assigned its own
attri
>> Umm, are you sure? We used to run windows 3.0 on amber monochrome
>> monitors at college.
>
>I am also unsure.
>Can someone with a clue speak up?
>> Umm, are you sure? We used to run windows 3.0 on amber monochrome
>> monitors at college.
>
>I am also unsure.
>Can someone with a clu
Hi Shane.
>>> 9. Tandy 1000 range.
> I think that the Tandy 1000 was a CGA+ mode, with the idea being
> to provide 320x200x16 without a full EGA mode. So we have the
> old 640x200 standby here, too.
Having had a Tandy 1000, I can safely say that whilst it did indeed
have a CGA+ mode that
[...]
>This is a kernel only release. For userland sources and binaries, and disk
>images please see release 0.0.75.
[...]
We have pipes, and signals, and select() --- this sounds suspiciously as if we now
have a kernel that's actually usable. All that's needed now is a method of generating
int
On Fri, 21 May 1999, Angel Martin Alganza wrote:
>
> On Thu, 20 May 1999, Jakob Eriksson wrote:
>
> > You are both interested in a C compiler for the Z80.
> > I am crossposting this for all of you to read.
> > (Maybe a few Amstrad people will also be interested in ELKS,
> > an attempt to po
> > > 1. IBM MDA.
> > no graphics support...
>
> Umm, are you sure? We used to run windows 3.0 on amber monochrome
> monitors at college.
it was probably connected to either a cga or hercules card, as far as i
recll, the MDA is strictly text mode (and ansi graphics)
Hi Dieter
>> :-) Absolutely. I´m still looking for a C Crosscompiler for the z80 ...
>>
>> All I found (with help of this list) was the zcc, but I don´t think it could
>> make it ... :-(
>I found a C-Compiler for the z80 unter http://www.hitech.com.au/
Yes, it´s well known, but it´s a CPM Comp
Hello Greg
>If you really, really, really want one and can't find it, I might have one on
>a mag tape somewhere, if I could just find a system that reads mag tape...
Are you sure it´s not a Small C Compiler ? It´s lack of structs, unsigned
and even doesn´t heard of void. And without this this,
If you really, really, really want one and can't find it, I might have one on
a mag tape somewhere, if I could just find a system that reads mag tape...
Greg
On Wednesday, May 19, 1999 6:46 AM, Sven 'Zak' Kozma
[SMTP:[EMAIL PROTECTED]] wrote:
> Hi
>
> On Tue, 18 May 1999 Michael G Hughes wrote
On Thu, 20 May 1999, Jakob Eriksson wrote:
> You are both interested in a C compiler for the Z80.
> I am crossposting this for all of you to read.
> (Maybe a few Amstrad people will also be interested in ELKS,
> an attempt to port linux to intel 8088 and later the Z80.)
Is it possible to plug
On Thu, 20 May 1999, map wrote:
> Hi Zak,
>
> I found a C-Compiler for the z80 unter http://www.hitech.com.au/
Ah. Good. That was their address.
It is still available from http://mds.mdh.se/~dat95jen/z80/CPM-C.tar.gz
all in one file.
Jakob - me too me too me too me too me too me too me too m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've been thinking about porting sdcc (which is under the GPL and active
development) to the Nintendo Gameboy, which is a small step away from a
real Z80...
- -- Michael
On Fri, 21 May 1999, Sven 'Zak' Kozma wrote:
> Hi
>
> >If we start back at 0.
David,
> David Murn wrote:
> > > 1. IBM MDA.
> > no graphics support...
>
> Umm, are you sure? We used to run windows 3.0 on amber monochrome
> monitors at college.
>
It's possible be a HGC (Hercules Graphic Card). I have two of this
monitor with HGC runing Windows 3.0/Windows 3.1
On Wed, 19 May 1999, David Murn wrote:
> On Mon, 17 May 1999, Greg Haerr wrote:
>
> > > 1. IBM MDA.
> > no graphics support...
>
> Umm, are you sure? We used to run windows 3.0 on amber monochrome
> monitors at college.
I am also unsure.
Can someone with a clue speak up?
Jakob
On Wed, 19 May 1999, Sven 'Zak' Kozma wrote:
> All I found (with help of this list) was the zcc, but I don´t think it could
> make it ... :-(
zcc (which I think uses scc) was the compiler originally used to compile
ELKS for the Z80, if memory serves correctly (alan?).
If we start back at 0.0.12
Hi
>If we start back at 0.0.12 (which used to compile for Z80), then simply
Yes there´s some z80 code in there, but I don´t belive it will compile with
zcc. (maybe the arch/z80/* part)
I´m playing around with zcc 0.96
>apply patches up fixing as we go along (for 60ish versions), we should
>hav
On Mon, 17 May 1999, Greg Haerr wrote:
> > 3. CGA.
> 320x200 support doesn't really cut it.
Yes, but 640x200 is probably fine. Remember, anything Bill can do, we can
do better. :)
> > 5. MCGA.
After all, the MCGA only supported (supports?) maximum 640x200 resolution
too.
> > 9. Tan
>
> >If you really, really, really want one and can't find it, I might have one on
> >a mag tape somewhere, if I could just find a system that reads mag tape...
>
> Are you sure it?s not a Small C Compiler ? It?s lack of structs, unsigned
> and even doesn?t heard of void. And without this this,
Hi Greg.
>> 1. IBM MDA.
> no graphics support...
Does that prevent ELKS from using it?
>> 2. Hercules MDA.
> you mean the HGCA?
That card was known by so many names, it's incredible. I've met it
labelled HMDA, HGCA, HiMDA, HRGA and HRV, all being physically
identical other than the label
The MDA was a text only adapter. The HGC was the first to implement
any dot addressable graphics with the mono hardware.
FWIW, they both used the same CRTC (as does the CGA), they just program
it differently. The 6842 I believe was the CRTC.
--Perry
>
> On Mon, 17 May 1999, Greg Haerr wrote:
Sven 'Zak' Kozma schrieb:
> Hi
>
> On Tue, 18 May 1999 Michael G Hughes wrote :
>
> >>>My question is: Already have ELKS for these plataforms:
> >>> Zilog z80 (msx, cp-500, zx-spectrum...)
> >It seems that getting compilers for some of these machines is not the easyest task
On Wed, 19 May 1999, David Murn wrote:
> On Mon, 17 May 1999, Greg Haerr wrote:
>
> > > 1. IBM MDA.
> > no graphics support...
>
> Umm, are you sure? We used to run windows 3.0 on amber monochrome
> monitors at college.
It's not that the monitors wouldn't work, but that the mono card
Hello ELKS:ers and Amstraders!
You are both interested in a C compiler for the Z80.
I am crossposting this for all of you to read.
(Maybe a few Amstrad people will also be interested in ELKS,
an attempt to port linux to intel 8088 and later the Z80.)
This is from Embedded Linux Kernel Subset
lt;[EMAIL PROTECTED]>; Linux 8086
<[EMAIL PROTECTED]>
Date: Wednesday, May 19, 1999 11:23 AM
Subject: RE: ELKS video drivers...
>
>
>On Monday, May 17, 1999 8:44 PM, Ben Pfaff [SMTP:[EMAIL PROTECTED]] wrote:
>> Greg Haerr <[EMAIL PROTECTED]> writes:
>>
>>[...]
> On Monday, May 17, 1999 8:44 PM, Ben Pfaff [SMTP:[EMAIL PROTECTED]] wrote:
> > Greg Haerr <[EMAIL PROTECTED]> writes:
> >
> >[...]
> >> 11. DEC Rainbow range.
> >[...]
> >
> > Does anyone want a DEC Rainbow? There's one in the basement with a 5
> > MB hard drive (maybe 10 MB?) a
On Mon, 17 May 1999, Greg Haerr wrote:
> > 1. IBM MDA.
> no graphics support...
Umm, are you sure? We used to run windows 3.0 on amber monochrome
monitors at college.
Davey
Hi
On Tue, 18 May 1999 Michael G Hughes wrote :
>>>My question is: Already have ELKS for these plataforms:
>>> Zilog z80 (msx, cp-500, zx-spectrum...)
>It seems that getting compilers for some of these machines is not the easyest task
:-) Absolutely. I´m still looking for
In message <[EMAIL PROTECTED]> Ben Pfaff writes:
: Does anyone want a DEC Rainbow? There's one in the basement with a 5
: MB hard drive (maybe 10 MB?) and dual 5 1/4" floppies. Lots of
: software (mostly CP/M IIRC) including Zork I :-) It worked the last
: time I tried to boot it.
:
: It's my
On Monday, May 17, 1999 8:44 PM, Ben Pfaff [SMTP:[EMAIL PROTECTED]] wrote:
> Greg Haerr <[EMAIL PROTECTED]> writes:
>
>[...]
>> 11. DEC Rainbow range.
>[...]
>
> Does anyone want a DEC Rainbow? There's one in the basement with a 5
> MB hard drive (maybe 10 MB?) and dual 5 1/4" flo
>>My question is: Already have ELKS for these plataforms:
>> Zilog z80 (msx, cp-500, zx-spectrum...)
>
>Some guys thinking about it ...
It seems that getting compilers for some of these machines is not the
easyest task, I have looked at forth as a way of implimenting an OS an
> 1. IBM MDA.
no graphics support...
> 2. Hercules MDA.
you mean the HGCA?
> 3. CGA.
320x200 support doesn't really cut it.
> 4. EGA.
> 5. MCGA.
> 6. XGA.
> 7. VGA.
> 8. Assorted SVGA modes - how many are there now?
Some drivers for the ATI mach32 and mach6
> Granted, one could add drivers for specific hardware, and have the
> kernel routine detect and use it in preference to the BIOS driver if
> the relevant driver is present, but I wouldnae see such as a first
> choice for getting a working video subsystem...
Yes, get it working f
101 - 200 of 340 matches
Mail list logo
