Hans Lindgren schrieb:
>
> Hi all,
>
> Is there somebody out there (Grossibaer?) who have any knowledge how EMS
> works in DOS and with GEOS?
>
> I have managed to get EMM386.EXE to work with GEOS, in this case,
> Breadbox Ensemble. However the keyboard input does not work in Ensemble.
> Mouse input works excellent and Ensemble is very stable. The keyboard
> input works in FreeDOS. Any hints?

I have no idea why the keyboard isn't working. GEOS (afaik) uses the
keyboard hardware rather than getting keystrokes from DOS. So it might
be that the EMS driver somehow prevents GEOS from getting the interrupt
for a keypress. Just a guess.

EMS in general is a complex thing.
In its original way (and the only way GEOS cares of) it was an ISA card
with memory on it which could be accessed through 4 windows of 16K size
in the upper memory area. Just like a video card, which has also some MB
and is accessed through some windows in the 0xa0000 area.
The software askes the EMS driver to reserve a certain amount of memory
and then asks it to put a 16K chunk of this reserved memory in one of
the four 16K windows. The card then was routing the processors address
to the internal address of the requested memory chunk.

GEOS uses 3 of the 4 16K windows as stationary memory, to increase the
conventional memory by 48K. The fourth window is used for swapping
(select a swap memory chunk and copy data from or to it).
I think this is all GEOS does with EMS.

SInce the actual EMS drivers don't have a 'real' EMS card but a virtual
one located in normal system memory, they have to put the processor in
V86 mode. This way, the EMS driver is able to reorder system memory in 4
KB chunks without the executed code knowing what is where physically.
But as a side effect, DMA transfers (which are bound to physical
addresses and therefore do no tknow of the virtual reordering) would go
wrong. Therefore the EMS driver needs to intercept access to I/O devices
(such as the DMA controller or other bus-mastering cards), so it can
translate the virtual addresses given by the software into the physical
ones.
And since this means intercepting all I/O transfers, it might be that an
incompatibility in this code prevents GEOS from accessing the keyboard
controller.
Also, the IRQ table where GEOS enters itself for getting the keyboard
IRQ is as virtual as everything else in V86 mode. So maybe some internal
system key check kicks GEOS out of the virtual table again by accident -
while it doesn't do any harm in real mode.

If you press CTRL-ALT-DEL while the keyboard isn't working, does this
reset the system? Or does it nothing?


In any case, there seems to be still something to do for the FreeDos
developers

Grossibaer

Hi Grossibaer,

On 2004-07-11 17:19, Jens-Michael Gross wrote:

>Hans Lindgren schrieb:
>
>
>>Hi all,
>>
>>Is there somebody out there (Grossibaer?) who have any knowledge how EMS
>>works in DOS and with GEOS?
>>
>>I have managed to get EMM386.EXE to work with GEOS, in this case,
>>Breadbox Ensemble. However the keyboard input does not work in Ensemble.
>>Mouse input works excellent and Ensemble is very stable. The keyboard
>>input works in FreeDOS. Any hints?
>>
>>
>
>I have no idea why the keyboard isn't working. GEOS (afaik) uses the
>keyboard hardware rather than getting keystrokes from DOS. So it might
>be that the EMS driver somehow prevents GEOS from getting the interrupt
>for a keypress. Just a guess.
>
>

Seems to be a resonable explanation. The EMS driver in FreeDOS differs
from other EMS drivers I have tested, so far.
While others work, the FreeDOS one doesn't.

>EMS in general is a complex thing.
>In its original way (and the only way GEOS cares of) it was an ISA card
>with memory on it which could be accessed through 4 windows of 16K size
>in the upper memory area. Just like a video card, which has also some MB
>and is accessed through some windows in the 0xa0000 area.
>The software askes the EMS driver to reserve a certain amount of memory
>and then asks it to put a 16K chunk of this reserved memory in one of
>the four 16K windows. The card then was routing the processors address
>to the internal address of the requested memory chunk.
>
>GEOS uses 3 of the 4 16K windows as stationary memory, to increase the
>conventional memory by 48K. The fourth window is used for swapping
>(select a swap memory chunk and copy data from or to it).
>I think this is all GEOS does with EMS.
>

Wow, now I understand! This also explains other things I have
encountered with a software called Hiram. Hiram provides upper memory as
base memoy to DOS softwares in the same way as the EMS drivers do when
they work with GEOS. I have tested Hiram with FreeDOS, UMBPCI and GEOS
(read: Breadbox Ensemble) and it gets rock solid. The backside of this
is that Hiram works pretty ugly, and UMBPCI works with a number of
chips, mostly Intel Pentium.

>
>SInce the actual EMS drivers don't have a 'real' EMS card but a virtual
>one located in normal system memory, they have to put the processor in
>V86 mode. This way, the EMS driver is able to reorder system memory in 4
>KB chunks without the executed code knowing what is where physically.
>But as a side effect, DMA transfers (which are bound to physical
>addresses and therefore do no tknow of the virtual reordering) would go
>wrong. Therefore the EMS driver needs to intercept access to I/O devices
>(such as the DMA controller or other bus-mastering cards), so it can
>translate the virtual addresses given by the software into the physical
>ones.
>And since this means intercepting all I/O transfers, it might be that an
>incompatibility in this code prevents GEOS from accessing the keyboard
>controller.
>Also, the IRQ table where GEOS enters itself for getting the keyboard
>IRQ is as virtual as everything else in V86 mode. So maybe some internal
>system key check kicks GEOS out of the virtual table again by accident -
>while it doesn't do any harm in real mode.
>

OK, well I have also noticed problems with FreeDOS Edit, too. This
problems is not isolated to GEOS

>
>If you press CTRL-ALT-DEL while the keyboard isn't working, does this
>reset the system? Or does it nothing?
>

It does nothing.

>In any case, there seems to be still something to do for the FreeDos
>developers
>
>
Yep, I think so, too, but they doesn't, as I have been encouraged from
the EMS developers in FreeDOS to contact Breadbox to fix this problem
(in GEOS). Well, I see this as an incompatibility problem in FreeDOS as
this problem shows in only in FreeDOS, and does not show in any others
DOS:es, with GEOS or FreeDOS Edit. OTOH, I can only report the problems
to the developers, if they don't listen, I can spend my time in a better
way, the problem will bounce back to them sooner or later.

Br,
Hans

> Hans Lindgren schrieb:

> > In any case, there seems to be still something to do for the FreeDos
> > developers
> >
> >
> Yep, I think so, too, but they doesn't, as I have been encouraged from
> the EMS developers in FreeDOS to contact Breadbox to fix this problem
> (in GEOS). Well, I see this as an incompatibility problem in FreeDOS
> as this problem shows in only in FreeDOS, and does not show in any
> others DOS:es, with GEOS or FreeDOS Edit. OTOH, I can only report the
> problems to the developers, if they don't listen, I can spend my time
> in a better way, the problem will bounce back to them sooner or later.


Well, tell them that this bug affects their very own edit program. (does
it run on any other DOS without the problem you didn't describe more
detailed?)
Also tell them that they start to act like Microsoft in their behavior
to react on bugreports.
Maybe that wakes them up

Grossibaer

On 2004-07-22 18:07, Jens-Michael Gross wrote:

>>Hans Lindgren schrieb:
>>
>>
>
>
>
>>>In any case, there seems to be still something to do for the FreeDos
>>>developers
>>>
>>>
>>>
>>>
>>Yep, I think so, too, but they doesn't, as I have been encouraged from
>>the EMS developers in FreeDOS to contact Breadbox to fix this problem
>>(in GEOS). Well, I see this as an incompatibility problem in FreeDOS
>>as this problem shows in only in FreeDOS, and does not show in any
>>others DOS:es, with GEOS or FreeDOS Edit. OTOH, I can only report the
>>problems to the developers, if they don't listen, I can spend my time
>>in a better way, the problem will bounce back to them sooner or later.
>>
>>
>
>
>Well, tell them that this bug affects their very own edit program. (does
>it run on any other DOS without the problem you didn't describe more
>detailed?)
>

Edit works in FreeDOS if I use UMBPCI.SYS instead of FreeDOS EMM386.EXE.
I have also discovered that my Cnet 200 PRO PCI NIC ODI driver will not
load if FreeDOS EMM386.EXE is loaded, while it loads with UMBPCI.SYS.
FreeDOS Edit works well in IBM PCDOS 7, with IBMs EMM386 driver.

>Also tell them that they start to act like Microsoft in their behavior
>to react on bugreports.
>Maybe that wakes them up
>
>
I have made contact with Michael Devore (one of the developers) and his
biggest problem for the moment is to get Ensemble Lite to work with
FreeDOS. I have sent him a GEOS.INI file that contains all the necessary
changes to make it work with FreeDOS. Hope this will work.

>Grossibaer
>

BR,
Hans

To reply to my own posting, the stability only showed up for about the
first ten times, then it is sometimes stable and sometimes flakey.

BR,
Hans

On 2004-07-06 23:01, Hans Lindgren wrote:

>Hi all,
>
>Is there somebody out there (Grossibaer?) who have any knowledge how EMS
>works in DOS and with GEOS?
>
>I have managed to get EMM386.EXE to work with GEOS, in this case,
>Breadbox Ensemble. However the keyboard input does not work in Ensemble.
>Mouse input works excellent and Ensemble is very stable. The keyboard
>input works in FreeDOS. Any hints?
>
>BR,
>Hans
>
>
>

On 2004-07-11 17:19, Jens-Michael Gross wrote:

>Hans Lindgren schrieb:
>
>
>>Hi all,
>>
>>Is there somebody out there (Grossibaer?) who have any knowledge how EMS
>>works in DOS and with GEOS?
>>
>>I have managed to get EMM386.EXE to work with GEOS, in this case,
>>Breadbox Ensemble. However the keyboard input does not work in Ensemble.
>>Mouse input works excellent and Ensemble is very stable. The keyboard
>>input works in FreeDOS. Any hints?
>>
>>
>
>I have no idea why the keyboard isn't working. GEOS (afaik) uses the
>keyboard hardware rather than getting keystrokes from DOS. So it might
>be that the EMS driver somehow prevents GEOS from getting the interrupt
>for a keypress. Just a guess.
>
Well, you were right. I have now been in contact with the developer,
Michael Devore, and he have fixed this problem, by adding "ALTBOOT" to
the EMM386.EXE driver. Now it works excellent with GEOS - Breadbox
Ensemble. It was the driver that prevented GEOS from getting the
interrupt for keypresses.
Problem solved and credit to Michael Devore for a quick solution.

BR,
Hans

> Hans Lindgren schrieb:

> > Also tell them that they start to act like Microsoft in their
> > behavior
> > to react on bugreports.
> > Maybe that wakes them up
> >
> >
> I have made contact with Michael Devore (one of the developers) and
> his biggest problem for the moment is to get Ensemble Lite to work
> with FreeDOS. I have sent him a GEOS.INI file that contains all the
> necessary changes to make it work with FreeDOS. Hope this will work.

Good job. Persistent complaints sometimes work
I guess the FreeDos edit program is now workine too with FreeDos EMM386?

That's very good news. Now we have a DOS that could be preconfigured for
a GEOS installation, or even a complete GEOS isntall disk on a plain
system.

What are his problems with Ensemble Lite?

Grossibaer

Hi Grossibaer,

On 2004-07-29 20:02, Jens-Michael Gross wrote:

>>Hans Lindgren schrieb:
>>
>>
>
>
>
>>>Also tell them that they start to act like Microsoft in their
>>>behavior
>>>to react on bugreports.
>>>Maybe that wakes them up
>>>
>>>
>>>
>>>
>>I have made contact with Michael Devore (one of the developers) and
>>his biggest problem for the moment is to get Ensemble Lite to work
>>with FreeDOS. I have sent him a GEOS.INI file that contains all the
>>necessary changes to make it work with FreeDOS. Hope this will work.
>>
>>
>
>Good job. Persistent complaints sometimes work
>I guess the FreeDos edit program is now workine too with FreeDos EMM386?
>
>
Yes it works. As you suggested in a previous thread, it was the keyboard
interrupt which EMM386 prevented
Breadbox Ensemble to access. FreeDOS Edit works also fine, don't know
exactly the problem with that, the
NOEMS parameter seems to be problematic with Edit, but since I am not
planning to use the NOEMS parameter,
I will not dig further into that. Quite happy with using the full blown
EMS driver.

>That's very good news. Now we have a DOS that could be preconfigured for
>a GEOS installation, or even a complete GEOS isntall disk on a plain
>system.
>
Yes, this is a relief. I will wait to add this to the bootdisk, there
will be a new one later on. Now I am waiting for
Defrag, and I have also to repair some mistales I did by skipping some
files, I will add them to the new release.
The new version of EMM386.EXE will be released at the FreeDOS site if
it's not already.

>What are his problems with Ensemble Lite?
>
Michael needed this in his GEOS.INI under [system]:

fs = ntfat.geo
primaryFSD = ntfat.geo

>Grossibaer
>
BR,
Hans

> Hans Lindgren schrieb:

> > I guess the FreeDos edit program is now workine too with FreeDos
> > EMM386?
> >
> >
> Yes it works. As you suggested in a previous thread, it was the
> keyboard interrupt which EMM386 prevented
> Breadbox Ensemble to access. FreeDOS Edit works also fine, don't know
> exactly the problem with that, the
> NOEMS parameter seems to be problematic with Edit, but since I am not
> planning to use the NOEMS parameter,

NOEMS can mean several things. Depending on the implementation it can
1) disable the EMS functionality (No EMS manager reported) while still
putting the computer into V86 mode and enabling UMBs and maybe swapping
out part of the BIOS ROMs. This causes some programs to assume that they
run in real mode instead of V86 mode (mode detection done by checking
for EMS manager present). This can cause problems when programs do
things not possible in V86 mode, but also allows programs to run which
refuse to run in V86 mode normally, provided that the EMM386 driver
catches possible problems with DMA transfers or other I/O related things
that require special attention in V86 mode.
2) Working normally except that no dedicated page frame is reserved in
UMB area, so programs can use EMS only by mapping it into their normal
working space (for the EMS driver, it makes no difference whether the
memory is mapped into the page frame or elsewhere in the first MB). This
frees up 64KB additional UMB but programs need to be able to handle this
(reserving their own area where the EMS memory can be mapped to).

GEOS uses 48KB of the page frame for heap usage (virtually extending the
conventional memory by 48 KB) while requiring 16kB as mountpoint to swap
the EMS swap memory blocks in and out.


> > That's very good news. Now we have a DOS that could be preconfigured
> > for
> > a GEOS installation, or even a complete GEOS isntall disk on a plain
> > system.
> >
> Yes, this is a relief. I will wait to add this to the bootdisk, there
> will be a new one later on. Now I am waiting for
> Defrag, and I have also to repair some mistales I did by skipping some
> files, I will add them to the new release.
> The new version of EMM386.EXE will be released at the FreeDOS site if
> it's not already.

Fine. Next stop: the complete GEOS installer for new (and/or virtual)
machines.

> > What are his problems with Ensemble Lite?
> >
> Michael needed this in his GEOS.INI under [system]:
>
> fs = ntfat.geo
> primaryFSD = ntfat.geo

Oh, that one. Well, it was the same for NDO2k already.

Grossibaer

Hi Grossibaer,

On 2004-08-05 18:02, Jens-Michael Gross wrote:

>>Hans Lindgren schrieb:
>>
>>
>
>
>
>>>I guess the FreeDos edit program is now workine too with FreeDos
>>>EMM386?
>>>
>>>
>>>
>>>
>>Yes it works. As you suggested in a previous thread, it was the
>>keyboard interrupt which EMM386 prevented
>>Breadbox Ensemble to access. FreeDOS Edit works also fine, don't know
>>exactly the problem with that, the
>>NOEMS parameter seems to be problematic with Edit, but since I am not
>>planning to use the NOEMS parameter,
>>
>>
>
>NOEMS can mean several things. Depending on the implementation it can
>1) disable the EMS functionality (No EMS manager reported) while still
>putting the computer into V86 mode and enabling UMBs and maybe swapping
>out part of the BIOS ROMs. This causes some programs to assume that they
>run in real mode instead of V86 mode (mode detection done by checking
>for EMS manager present). This can cause problems when programs do
>things not possible in V86 mode, but also allows programs to run which
>refuse to run in V86 mode normally, provided that the EMM386 driver
>catches possible problems with DMA transfers or other I/O related things
>that require special attention in V86 mode.
>2) Working normally except that no dedicated page frame is reserved in
>UMB area, so programs can use EMS only by mapping it into their normal
>working space (for the EMS driver, it makes no difference whether the
>memory is mapped into the page frame or elsewhere in the first MB). This
>frees up 64KB additional UMB but programs need to be able to handle this
>(reserving their own area where the EMS memory can be mapped to).
>
>
Well, I can't complain as the EMM386 works with GEOS now, but I think
the FreeDOS guys have an odd approach, the ALTBOOT switch works
backwards compared to ho all other DOS:es works......MS DOS.....PC
DOS.....and DR DOS

>GEOS uses 48KB of the page frame for heap usage (virtually extending the
>conventional memory by 48 KB) while requiring 16kB as mountpoint to swap
>the EMS swap memory blocks in and out.
>
>
>
This is very good to know, and that explains why GEOS works so well, if
you can get at least 600 kb base memory and on top of that add 48 kb
EMS memory.

>
>
>>>That's very good news. Now we have a DOS that could be preconfigured
>>>for
>>>a GEOS installation, or even a complete GEOS isntall disk on a plain
>>>system.
>>>
>>>
>>>
>>Yes, this is a relief. I will wait to add this to the bootdisk, there
>>will be a new one later on. Now I am waiting for
>>Defrag, and I have also to repair some mistales I did by skipping some
>>files, I will add them to the new release.
>>The new version of EMM386.EXE will be released at the FreeDOS site if
>>it's not already.
>>
>>
>
>Fine. Next stop: the complete GEOS installer for new (and/or virtual)
>machines.
>
I have butchered your posting and replied to this separately, as this
comment by you is by itself
an interesting subject ;-)

>
>
>>>What are his problems with Ensemble Lite?
>>>
>>>
>>>
>>Michael needed this in his GEOS.INI under [system]:
>>
>>fs = ntfat.geo
>>primaryFSD = ntfat.geo
>>
>>
>
>Oh, that one. Well, it was the same for NDO2k already.
>
>
Refried goodies....... ;-)

BR,
Hans

On 2004-08-05 18:02, Jens-Michael Gross wrote:

>>Hans Lindgren schrieb:
>>
>>

>>>That's very good news. Now we have a DOS that could be preconfigured
>>>for
>>>a GEOS installation, or even a complete GEOS isntall disk on a plain
>>>system.
>>>
>>>
>>>
>>Yes, this is a relief. I will wait to add this to the bootdisk, there
>>will be a new one later on. Now I am waiting for
>>Defrag, and I have also to repair some mistales I did by skipping some
>>files, I will add them to the new release.
>>The new version of EMM386.EXE will be released at the FreeDOS site if
>>it's not already.
>>
>>
>
>Fine. Next stop: the complete GEOS installer for new (and/or virtual)
>machines.
>
>
This are interesting thoughts which needs to be discussed. How would
this complete installer work?

I like to see the FreeDOS bootdisk for GEOS as the Windows 95 or 98
bootdisk. I think that it is difficult to autopartition hard disks and
autoformat them, too.
This is best done by hand, IMO. My intension is to create a disk that
will work with, hopefully, any version of GEOS from 2.0 and up. It might
even work with 1.2, I don't know? I like to keep up with the FreeDOS
concept and make the GEOS bootdisk in the same spirit, free and open,
for anyone to modify. That is why I prefer batchfiles to installer
files. If I would like to, I could compile the batchfile to an exe- or
com-file, no problems, but I like transparency for those who wants it.

I can't see for the moment how this complete installer would be done
with FreeDOS, but if I can get ideas of howto, I would be happy to
receive these ideas!
And I would also happily receive ideas of how to improve the disk, in
part, or general.

BR,
Hans

I can do the installer part on the wind$$s side, as I have some basic knowledge
with the (Nullsoft Scriptable Installer System).

Defrag is really a mess at the moment. Needs days in QEmu and crash badly
the filesystem. But have a look to the upcoming versions.

Andreas

Well, I think that Grossibaer meant to have a complete installation
based on FreeDOS with GEOS. That is probably doable, but there are some
problems to get around. Like partitioning, format install of DOS and
then GEOS. To get these to play together and then some reboots now and
then......well that is an issue.

BR,
Hans

On 2004-08-05 22:47, Andreas Bollhalder wrote:

>I can do the installer part on the wind$$s side, as I have some basic knowledge
>with the (Nullsoft Scriptable Installer System).
>
>Defrag is really a mess at the moment. Needs days in QEmu and crash badly
>the filesystem. But have a look to the upcoming versions.
>
>Andreas
>
>

Hans Lindgren wrote:

> Well, I think that Grossibaer meant to have a complete installation
> based on FreeDOS with GEOS. That is probably doable, but there are some
> problems to get around. Like partitioning, format install of DOS and
> then GEOS. To get these to play together and then some reboots now and
> then......well that is an issue.
>
> BR,
> Hans

Um, if there are ports of the gnu partitioning tools then you can
automate the partitioning. Formating is easy but there are better tools
for formating like oformat.com etc... I do have some experience with
such stuff (assetet unattended installation of nt4 with temporary data
on the unformated partition and re-reading of it before formating as a
rebot is needed after partittioning under DOS). Well and then the
setupdisk could be a tiny lunix disk which has benefits in not requiring
a reboot after partitioning changes etc (this is what I do for our
current settup for xp machines).

Dom
--
C:\>