Mail Archives: djgpp/2009/01/10/19:00:33
"Rugxulo" <rugxulo AT gmail DOT com> wrote in message
news:59d15676-685a-4ad8-a43a-7715035abbaa AT f3g2000yqf DOT googlegroups DOT com...
> > On the other hand, since the patches to support "i386-moss" don't do
much
> > and moss.exe starts up an ELF a.out, it might be possible to use another
> > target, i.e., "i386-generic-ELF," which is supported by more recent GCC
and
> > Binutils. The good news in regard to the library is that he was only
using
> > the handful of calls I mentioned previously (if I didn't make a
mistake).
>
> What's the difference (or advantage) to using generic ELF instead of
> what's currently used?
Binutils supports i386-moss, but GCC stops i386-moss support at 3.3.6. His
changes look trivial. I don't know if they are. But, even if they are,
you can't use a recent GCC without figuring out how to patch it or using a
different target. It'd be nice to support newer versions. It might be
useful to support older versions too... Is it?
Apparently, you'd prefer older GCC's? Or, what are you interested in using
moss for? Older systems? Smaller systems?
> I do think his DPMI support needs improvement
Well, like I said, that's what'd I'd start with if anything... I'm
familiar. The raw should be similar to what I've in my OS too. I don't
know anything about VCPI. I've got a basic idea of how XMS works, but have
never used it.
> I definitely wouldn't prefer to use raw exclusively, and I'm
> pretty sure you don't have to.
IMO, DPMI can handle everything needed, for DOS at least.
> You're using Win98 and can boot to DOS mode, so just unzip BasicLinux
> on top of your FAT partition. It's only 20 MB unpacked, so it's not
> much (only 4 MB or so .ZIP'd).
Loop on DOS? I thought there was only one that did that... ZipSlack?
> Then just unpack the prebuilt Linux GCC
> cross-compiler on top of that: "cd / ; tar xvzf /tmp/moss-0.90-bin-
> linux.tar.gz ; export PATH=/usr/local/i386-moss/bin:$PATH"
Ok.
Oh, you mean it's using FAT directly. UMSDOS? or newer VFAT? I don't like
the idea of Linux writing to my FAT partitions. I've used it with FAT12 and
FAT16 without problems, but I'm leary, especially with an old version of
Linux writing to my FAT32 partition...
BTW, I thought I got GCC to compile for i386-moss, but it wouldn't install.
I later found a complete moss GCC build installed *OUTSIDE* my DJGPP
directories using *LINUX* directories like /USR/LOCAL/BIN etc. - and they
run on DOS - and they seem to be correct. Man, I don't know what I did...
Canadian cross?... One of the failures was a success! I think I may need
to recompile a few more times until I get a feel for what is correct and
what isn't. I remember being surprised when the one compile said it was
i386-moss to i386-moss and couldn't find ucontext.h...
> I don't think QEMU does share files (although there is some
> experimental USB crud that I never tried). At least it won't write,
> but it can read from host OS:
>
> qemu -m 128 -L . -fda myflop.img -hda myhard.img fat:/armslurp/moss -
> boot a
QEMU 0.8.2 works on Win98SE, but QEMU 0.9.1 needs some help. I posted a
patch here. IIRC, it didn't fix cdrom images. But, (since I didn't/don't
have email to send to them) I don't think ever got to the QEMU team:
http://groups.google.com/group/alt.os.development/msg/b4dc0fc1a7d501fc?hl=en
> Sad that the whole point of DPMI was Windows compatibility
Was it? My understanding was all of these methods VCPI, XMS, DPMI, were
ways to get past the 1Mb barrier created by the 20-bit address range of the
8086 cpu - 16-bit real mode. I.e., they chose to use 16 or 32-bit protected
mode on post 8086 cpu's instead of 16-bit real mode - allowing 24-bit
(80286) and 32-bit addresses (80386) - while still being able to use 16-bit
DOS and BIOS with a 20-bit address space. The 20-bit address space was
required for certain applications - which are always mentioned but never
really identified. Supposedly, CP/M required the A20 wrap, i.e., it
requires a 20-bit address space to work properly. I don't know what else
did.
> Windows has had so many issues with it over time.
IMO, none of them are designed to be controlled by an OS. AFAIK, they are
designed to give dedicated applications control of a larger address space
through the larger address space available to protected mode on later cpu's.
If someone was designing them to work with a more developed OS than DOS,
many of the features would've been disabled or removed, IMO. Much of what's
in them has to do with OS setup, protected mode OS maintenance, and memory
allocation.
> Old Cyrix chips (e.g. early 586s or whatever) couldn't even use unreal
> mode, which is yet another blow to such a weirdly useful hack.
Really? I've got 5V Cyrix... DX2-50 (?, I think...) packed away around
here somewhere. I got it cheap, right after Cyrix's reputation was damaged.
I never had any problems with it. I basically gave the cpu away a number of
years later to a co-worker at the time. I installed it for him too. But,
he returned it about a month later saying his kids complained one of their
games was "flaky" with it. He did say it was much faster. I don't recall
what cpu he had. IIRC, the Cyrix was only supposed to be run in recent (at
the time) motherboards that had a more powerful 5V cpu supply line. I told
him about this in advance so he could check. He was an EE (audio) with many
years of audio design experience and said his PS was sufficient, which was
probably true in general. But, he had an older system so the 5V line itself
might not have been powerful enough. At the time, I took him at his word
since he designed power amplifiers and he should've been able to check
easily. One of his "specialties" was using many high power MOSFET's in
parallel per audio channel to boost the current without causing MOSFET
failures. The MOSFET's were cheaper to use than other solutions, but only
if the circuit was designed to operate them reliably without "blowing up".
Today, an audio EE would probably just use an IGBT.
Rod Pemberton
- Raw text -