>>With a help of Ed (DXForth creator) the problem is recognized; Ed wrote:
>>
>>#v+
>> 4DOS (or something associated with it) is setting PIT timer 0
>> from mode 3 to
>> mode 2 - which in turn is causing MS in DX-Forth to run slow.
>>#v-
> Nice find, didn't really expect that. Any hints in the
At 02:06 AM 4/7/2012, Zbigniew wrote:
>2012/3/11, Bernd Blaauw :
>
> > Please let us know if/when you're able to pinpoint a culprit.
> > You might want to start with a MSDOS/Win9x bootdisk (www.bootdisk.com)
> > to eliminate FreeDOS components as the culprit, and to have a proven
> > reference plat
2012/3/11, Bernd Blaauw :
> Please let us know if/when you're able to pinpoint a culprit.
> You might want to start with a MSDOS/Win9x bootdisk (www.bootdisk.com)
> to eliminate FreeDOS components as the culprit, and to have a proven
> reference platform.
With a help of Ed (DXForth creator) the p
2012/3/11, Bernd Blaauw :
> Please let us know if/when you're able to pinpoint a culprit.
> You might want to start with a MSDOS/Win9x bootdisk (www.bootdisk.com)
> to eliminate FreeDOS components as the culprit, and to have a proven
> reference platform.
Just finished first tests: under original
2012/3/11, Bernd Blaauw :
> Please let us know if/when you're able to pinpoint a culprit.
> You might want to start with a MSDOS/Win9x bootdisk (www.bootdisk.com)
> to eliminate FreeDOS components as the culprit, and to have a proven
> reference platform.
Tried it yesterday under DOS 6.22 - there
Op 11-3-2012 17:21, Zbigniew schreef:
>> but as I suggested in a off-list reply to a question
>> that Eric Auer send me, the fact that sound output is effected as
>> well, this seems kind of confirm my suspicion on how JEMM is handling
>> IN/OUT statements when in protected mode, or something alon
2012/3/11, Ralf A. Quint :
> Still not sure why 4DOS would be causing it (if using that alone,
> without JEMMEX),
OK, I'll check it out again; maybe I made some mistake, since indeed
also I can't see any connection... will repeat the tests, then let you
know.
> but as I suggested in a off-list r
At 04:47 AM 3/11/2012, Zbigniew wrote:
>Yesterday I've found another related thing: while trying to test my
>soundcard with several games, I discovered, that "Civilization" has
>quite the same issue with FreeDOS: when ran under configuration
>"JEMMEX + 4DOS" it works very slowly (I'm using Sempron
Yesterday I've found another related thing: while trying to test my
soundcard with several games, I discovered, that "Civilization" has
quite the same issue with FreeDOS: when ran under configuration
"JEMMEX + 4DOS" it works very slowly (I'm using Sempron 2 GHz as CPU),
playing the background music
Hi,
On Sat, Mar 10, 2012 at 7:47 PM, Ralf A. Quint wrote:
>
> The "pause" call is for me the most likely culprit, doubt that this
> is something that could be fixed in DX-Forth, specially if it works
> without and with other memory managers...
I do at least know that "PAUSE" is a way to cooperat
At 01:09 PM 3/10/2012, Zbigniew wrote:
>If I correctly found the relevant sections of DX-Forth's kernel.asm
>(it's included in the package), the word is defined the following way:
>
>#v+
>[..]
>; runtime for deferred words - equiv to @ EXECUTE
>
>dodef: pop bx
> jmp [bx]
>[..
Hi,
I'm not heavily familiar with Forth or DX-Forth (sadly) though I've
(barely) used it a few times. IIRC, the author (Ed) frequents
comp.lang.forth, so you could report the alleged bug to him (directly
or via newsgroup).
I don't know what would be going on in JEMMEX or 4DOS. I don't think
the
While doing exercises with Forth - using DX-Forth (
http://www.netbay.com.au/~dxforth/ ) - I noticed, that its "ms" word
delays _exactly twice_ the given number of milliseconds.
Several tries revealed, that this word works correctly only when both
XMGR memory manager is used (not JEMMEX, for insta
13 matches
Mail list logo
