Hola Aitor,
I remember you starting a thread complaining how lame MS-DOS is, and Tom
replying (and I agreeing) the improvements that MS introduced in DOS in
their version 2.0. The thread was fun, true, BUT a waste of bandwith and
time, in my opinion.
Because I don't remember this, it must have b
At Fri, 30 Jul 2004 8:55am +0200, Roberto Mariottini wrote:
> As for FreeCOM, the bug showed up on the PC (P3 650 MHz) trying to use
> filename completion. The beep started, then the computer freezed, while
> continuing to beep. I had to press Ctrl-Alt-Del to shut it up.
>
> Ciao
It's odd that
On Fri, 30 Jul 2004 10:55:57 +0300, you wrote:
Hi Lucho,
I'm trying to be moderate. I didn't like anger or quarrels. I enjoy
reading the mailing list, picking out the bugs and learning more from
all of you. IMO we should be happy and fun working together.
>And what have we achieved? An eagle, ca
Steve Nickolas wrote:
At Fri, 30 Jul 2004 8:55am +0200, Roberto Mariottini wrote:
As for FreeCOM, the bug showed up on the PC (P3 650 MHz) trying to use
filename completion. The beep started, then the computer freezed, while
continuing to beep. I had to press Ctrl-Alt-Del to shut it up.
Ciao
I
As for FreeCOM, the bug showed up on the PC (P3 650 MHz) trying to use
filename completion. The beep started, then the computer freezed, while
continuing to beep. I had to press Ctrl-Alt-Del to shut it up.
It's odd that my Celeron/700 doesn't have that problem, so I don't think
it's CPU speed...
Below is the correct function. I forgot the inversion. Sorry for my
mistake.
void delay(unsigned milliseconds) /* 1 - 1985 */
{
unsigned i;
for (i = 0; i <= milliseconds * 33; i++)
{
while (inp(0x61 & 0x10) /* refresh bit toggles with each refresh
On Fri, 30 Jul 2004, Luchezar Georgiev wrote:
void delay(unsigned milliseconds) /* 1 - 1985 */
{
unsigned i;
for (i = 0; i <= milliseconds * 33; i++)
{
while (inp(0x61 & 0x10) /* refresh bit toggles with each
refresh */
; /* so we wait 30 µs but the
first time */
while (inp(0x61 & 0x1
Hello Luchezar,
> Sure. Borland's delay() uses timer 0. Why not rely on the referesh toggle
> bit instead?
maybe because that's a *really* undocumented input bit ?
I searched right now, but couldn't find it anywhere.
so let me ask:
what kind of 'refresh' is that ?
does this work on compaq/dell
Below is the really correct function. I misplaced the inversion and
omitted the parentheses. Sorry again for my mistakes! To err is human, to
forgive divine!
void delay(unsigned milliseconds) /* 1 - 1985 */
{
unsigned i;
for (i = 0; i <= milliseconds * 33; i++)
{
Hi!
> "inp()" and 0x40:0x6c are both CPU-heavy; isn't there some nicier=20
> method???
You can "HLT" between every two 40[6c] readouts - if you know that there
is no "CLI" state. However, why is it a problem to have CPU-heavy beep?
For example boot menu delay in kernel does not "HLT" either and
Hi Tom,
maybe because that's a *really* undocumented input bit ?
The RBIL documents it. PORTS.A, table 393 says about bit 4: toggles with
each refresh request.
I searched right now, but couldn't find it anywhere.
so let me ask: what kind of 'refresh' is that ?
DRAM refresh.
does this work on comp
On Fri, 30 Jul 2004, Eric Auer wrote:
You can "HLT" between every two 40[6c] readouts - if you know that there
is no "CLI" state. However, why is it a problem to have CPU-heavy beep?
For example boot menu delay in kernel does not "HLT" either and nobody
except me ever mentioned the "HLT" energy sav
Hello Steffen,
> The boot menu is used in a DOS session one time at maximum.
and - hopefully - FreeCOM also isn't bping all the time ;)
>> INT 15 - BIOS - WAIT (AT,PS)
>>AH = 86h
>>CX:DX = interval in microseconds
>> Return: CF clear if successful (wait interval elapsed)
>>
use the timer ticks
Or just do
mov ax,0E07h
int 10h
or
mov al,7
int 29h
which always produces the loadest possible beep (because BIOS does it :-)
and end this thread, please.
Finita la comedia! ;-)
Lucho
---
Micheal wrote:
...
All you guys almost had me convinced to bite the bullet and force EMM386
ALTBOOT to be work like MS since it's likely (but not guaranteed) it
won't affect too many applications, and then another idea is
introduced. Well, maintainer decides these things and that's Tom. If
y
Don't forget that FreeCOM is also supposed to be able to run over a serial
line via CTTY. In that case the beep should happen on the terminal and not
on the PC where FreeCOM actually runs.
So I vote for
putchar('\007');
no BIOS, no int29, no delay timing, no direct hardware, just keep it
simp
Hello Bart,
> Don't forget that FreeCOM is also supposed to be able to run over a serial
> line via CTTY. In that case the beep should happen on the terminal and not
> on the PC where FreeCOM actually runs.
> So I vote for
>putchar('\007');
> no BIOS, no int29, no delay timing, no direct ha
At Fri, 30 Jul 2004 4:07pm +0200, tom ehlert wrote:
> Hello Bart,
>
> > Don't forget that FreeCOM is also supposed to be able to run over a serial
> > line via CTTY. In that case the beep should happen on the terminal and not
> > on the PC where FreeCOM actually runs.
>
> > So I vote for
>
> >
Steve Nickolas escribió:
At Fri, 30 Jul 2004 4:07pm +0200, tom ehlert wrote:
Hello Bart,
Don't forget that FreeCOM is also supposed to be able to run over a serial
line via CTTY. In that case the beep should happen on the terminal and not
on the PC where FreeCOM actually runs.
So I v
Hello Bart and Tom,
Don't forget that FreeCOM is also supposed to be able to run over a
serial line via CTTY. In that case the beep should happen on the
terminal and not on the PC where FreeCOM actually runs.
So I vote for
putchar('\007');
no BIOS, no int29, no delay timing, no direct hardwar
Yes, FreeCOM has to work over serial lines. In embeded this is used.
Alain
Luchezar Georgiev escreveu:
Hello Bart and Tom,
Don't forget that FreeCOM is also supposed to be able to run over a
serial line via CTTY. In that case the beep should happen on the
terminal and not on the PC where FreeCOM
On Fri, 30 Jul 2004 12:12:21 -0400 (EDT), you wrote:
Hi Uso,
>I would agree. I don't like beeping on tab completion, personally.
I vote "no beep".
We have same taste :-)
Rgds,
Johnson.
---
This SF.Net email is sponsored by OSTG. Have you
22 matches
Mail list logo
