FYSOS under QEMU
Rod Pemberton
I'm still seeing some errors with FYSOS under QEMU.
With 2 Dec 2007 FYSOS and QEMU 0.8.2 compiled for Windows 98:
...
Did not find a floppy drive.
...
Could not calculate which partition/disk was booted from. Please choose an
initial drive to use:
In the control window, I'm getting:
qemu: unsupported keyboard cmd=0xaf
qemu: unsupported keyboard cmd=0xa1
qemu: unsupported keyboard cmd=0xed
I'm running with this line:
qemu -L . -m 128 -no-kqemu -net none -std-vga -boot a -fda a.img -localtime
Rod Pemberton
Benjamin David Lunt
Hi Rod,
I have not ever tried QEmu. However, I have always wanted
to. Maybe now is a good time to try? I will get back to you
on this.
Ben
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
news:fjvdqc$86s$1...@aioe.org...
Benjamin David Lunt
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
news:fjvdqc$86s$1...@aioe.org...
>
> I'm still seeing some errors with FYSOS under QEMU.
>
> With 2 Dec 2007 FYSOS and QEMU 0.8.2 compiled for Windows 98:
>
> ...
> Did not find a floppy drive.
> ...
> Could not calculate which partition/disk was booted from. Please choose
> an
> initial drive to use:
Hi Rod,
Page 40 & 41 of the FDC 82077AA specs, section 8.2, specify the
way the fdc should be initialized after a reset.
"Following a reset of the 82077AA, the Configuration Control
Register (CCR) should be reinitialized"..."Since polling is
enabled after a reset of the 82077AA, four SENSE INTERRUPT STATUS
commands need to be issued afterwards to clear the status flags
for each drive. The flowchart in Figure 8-3 illustrates how"...
"As a note, if the CONFIGURE command is issued within 250 ms of
the trailing edge of reset (@ 1Mbps), the polling mode of the
82077AA can be disabled before the polling initiated interrupt
occurs. Since polling stops when the 82077AA enters the command
phase, it is only time critical up to the first byte of the
CONFIGURE command. If disabled in time, the system software no
longer needs to issue the four SENSE INTERRUPT STATUS commands
to clear the internal interrupt flags normally caused by polling."
I don't know the workings of Qemu enough to know, but here are
my ideas why my fdc detection isn't working:
1. Maybe Qemu doesn't support this polling technique after
reset, therefore doesn't have 4 interrupts in the queue.
2. Maybe the timing is off and my code for the configure
command is exectuted before the 250us has elapsed.
(doubt this one is the cause)
3. Well, I think it is the 1st one above :-)
[I will see if I can send this post to the Qemu team too.]
> In the control window, I'm getting:
>
> qemu: unsupported keyboard cmd=0xaf
> qemu: unsupported keyboard cmd=0xa1
> qemu: unsupported keyboard cmd=0xed
#define KEY_CMD_VERSION 0xAF // Controller version
#define KEY_CMD_FIRM_VER 0xA1 // Controller firmware version
#define KEY_CMD_LEDS 0xED // set the state of the LED's
I am not suprised by the first two, but am suprised
that it doesn't support the third command.
> I'm running with this line:
>
> qemu -L . -m 128 -no-kqemu -net none -std-vga -boot a -fda
> a.img -localtime
Thanks Rod, I appreciate the help.
Ben
Benjamin David Lunt
"Benjamin David Lunt" <zf...@frontiernet.net> wrote in message
news:tsS8j.461$7d1...@news01.roc.ny...
>
>
> [I will see if I can send this post to the Qemu team too.]
>
Well, the dev-list for QEmu seems to be down. Maybe I will
try later or hopefully, one of the developers is a regular
reader here.
Ben
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Forever Young Software
http://www.frontiernet.net/~fys/index.htm
To reply by email, please remove the zzzzzz's
Esra Sdrawkcab
> "Benjamin David Lunt" <zf...@frontiernet.net> wrote in message
> news:tsS8j.461$7d1...@news01.roc.ny...
>>
muy comments are --()
Number of bits used for physical addresses: 36
Found coprocessor type: TODO at 0 Mhz
CMOS: 128 bytes, 2nd CRC: notfound (00)
Found Advanced Configuration and Power Interface (ACPI)
Updating hardware information...
ACPI: DSDT: AML code size 8311 [ACPI: unknown sig: [424D454F]]
Found PnP BIOS v1.0
Found PnP ISA card: Unknown vendor type and/or name
ID String: Sound Blaster 16
Vendor ID: tBA03;0 serial number: -1
Device 0: id: ZA@ function: 003 rev: 176 Compatible id: 03B0
Found PnP ISA card: Unknown vendor type and/or name
ID String: Game Port
Vendor ID: tBA2?;0 serial number: -1
Device 0: id: ZA@ function: 047 rev: 176 Compatible id: 2FB0
Found VESA v2.0 compatible video card:
IBM SVGA BIOS, (C) 1993 Internat
Modes found: 32 Modes supported: 31
Keyboard passed 0xAA test
Keyboard passed 0xAB test
Controller version: 0
Controller firmware version: 0
Found PS2 Keyboard with id: AB 41
-- (slows detecting the (virtual floppy))
Found Floppy Disk Controller at 0x03F0 with type 82078SL or 82078-1
Found 1.44M Floppy drive (3F0) (0)
Found UNKNOWN Floppy drive (3F0) (1)
Found Floppy Disk Controller at 0x0370 with type 82078SL or 82078-1
Found UNKNOWN Floppy drive (370) (0)
Found UNKNOWN Floppy drive (370) (1)
Found a FAT12 file system
--(1.5 min pause)
Found ATA Disk Controller at 0x01F0
--(cant paste next line retyped- )
Warning. ATA device did not report ata(pi) version. Assume version 3+
(Y,N)?
--(tried replying Y but no response, rebooted and tried N - same)
Hope this helps
Benjamin David Lunt
"Esra Sdrawkcab" <ad...@127.0.0.1> wrote in message
news:kEV8j.7718$ov2....@newsfe5-win.ntli.net...
> Benjamin David Lunt wrote:
>> "Benjamin David Lunt" <zf...@frontiernet.net> wrote in message
>> news:tsS8j.461$7d1...@news01.roc.ny...
>>>
> loaded latest into a VPC 2004 session:
> muy comments are --()
Hi Esra,
I will have a look at these things. Thank you. It is always nice
to have a fellow user send in the debug.txt file (or post it like you
did). I will look into these things and get back to you.
Thanks,
Benjamin David Lunt
>> "Benjamin David Lunt" <zf...@frontiernet.net> wrote in message
>> news:tsS8j.461$7d1...@news01.roc.ny...
>>>
> loaded latest into a VPC 2004 session:
> muy comments are --()
> ACPI: DSDT: AML code size 8311 [ACPI: unknown sig: [424D454F]]
Fixed.
> Found PnP BIOS v1.0
> Found PnP ISA card: Unknown vendor type and/or name
> ID String: Sound Blaster 16
> Vendor ID: tBA03;0 serial number: -1
> Device 0: id: ZA@ function: 003 rev: 176 Compatible id: 03B0
> Found PnP ISA card: Unknown vendor type and/or name
> ID String: Game Port
> Vendor ID: tBA2?;0 serial number: -1
> Device 0: id: ZA@ function: 047 rev: 176 Compatible id: 2FB0
These two, I have added the 'code' that is returning the unknown
vendor type and/or name. If you don't mind, please send the latest.
> -- (slows detecting the (virtual floppy))
> Found Floppy Disk Controller at 0x03F0 with type 82078SL or 82078-1
> Found 1.44M Floppy drive (3F0) (0)
> Found UNKNOWN Floppy drive (3F0) (1)
> Found Floppy Disk Controller at 0x0370 with type 82078SL or 82078-1
> Found UNKNOWN Floppy drive (370) (0)
> Found UNKNOWN Floppy drive (370) (1)
> Found a FAT12 file system
> --(1.5 min pause)
For some reason, VPC has always detected a second controller
and unknown floppy drives. I have done quite a bit of work
to see why it does this, but haven't found out yet. My fdc code
works as expected on real hardware, Bochs, and QEmu, so I am
thinking that it is a quirk in VPC.
> Found ATA Disk Controller at 0x01F0
> --(cant paste next line retyped- )
> Warning. ATA device did not report ata(pi) version. Assume version 3+
> (Y,N)?
> --(tried replying Y but no response, rebooted and tried N - same)
I think this has to do with my code detecting the DMA mode of
the controller. It has been known to freeze at this point. I have
commented out the dma_check. Please try again.
Thanks for your help. It is much appreciated.
Ben
Rod Pemberton
"Benjamin David Lunt" <zf...@frontiernet.net> wrote in message
news:tsS8j.461$7d1...@news01.roc.ny...
>
> #define KEY_CMD_FIRM_VER 0xA1 // Controller firmware version
> #define KEY_CMD_LEDS 0xED // set the state of the LED's
>
> I am not suprised by the first two, but am suprised
> that it doesn't support the third command.
>
Yeah, me too, since I'm using 0xED in my OS and QEMU doesn't complain...
Probably something else prior.
Rod Pemberton
Rod Pemberton
> It is always nice
> to have a fellow user send in the debug.txt file (or post it like you
> did).
I wanted to. I just couldn't figure out what option I need to redirect
output sent to the new window QEMU opens. And, I still haven't found it...
Both, 12/2 and 12/15 also say "fdc: 000". Although one screen of text
flashes by quickly, the second is slower. If there are lines you're
interested I could type them in.
Rod Pemberton
Alexei A. Frounze
wrote:
> For some reason, VPC has always detected a second controller
> and unknown floppy drives. I have done quite a bit of work
> to see why it does this, but haven't found out yet. My fdc code
> works as expected on real hardware, Bochs, and QEmu, so I am
> thinking that it is a quirk in VPC.
How about using BIOS' int 11h or its Data Area to figure out how many
floppies you have? Would that fix the problem with VPC?
Alex
Benjamin David Lunt
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
Well, if it would detect the floppy and get to the command prompt, you
could then use another utility to extract the debug.txt file from the
image and send it to me to see why it didn't detect the floppy.
The chicken before the egg thing, right.
I will look into it some more and let you know. If you do find
a why to get QEmu to redirect, or copy the text to the clipboard
please send it to me.
Thanks.
Benjamin David Lunt
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
QEmu doesn't complain that you are using 0xED?
Uhhm. Makes me wonder...
Ben
Benjamin David Lunt
"Alexei A. Frounze" <alexf...@gmail.com> wrote in message
news:efa7c0bb-1a94-46b3...@d4g2000prg.googlegroups.com...
Hi Alex,
I have code to do this. If you set the attribute in the system
file (system.sys), then it uses the BIOS just as you state above
instead of probing the hardware. However, where is the fun in
that :-)
Ben
Rod Pemberton
Sigh, it'd been six months. So, I created another image. No, it's not
complaining. My OS still boots DOS first - then takes control from DOS
(maybe affects things?). Anyway, it only uses 0xED to set/clear the led's
for Num,Caps,Scroll and clears all three after initing the keyboard but
before enabling it.
Rod Pemberton
Rod Pemberton
> If you do find
> a why to get QEmu to redirect,
Nope...
> or copy the text to the clipboard
> please send it to me.
Nope...
I typed in what I could capture. I'm still not sure how to capture the
screen output with QEMU. I was able to stop and start the emulation with
their "debugger" capturing much of the text. Anyway, some text is missing,
for Dec 15 image after my signature. Oh, the 12/15 adds the "fdc: 000"
line. I tried to keep the fixed font spacing correct... The speed and CPU
type under QEMU are wrong. That may be due to QEMU. Should I post one from
a normal PC boot also?
Rod Pemberton
Checking for a 386+ processor...
Loading system files...
Loading: kernel.sys...decompressing(bz2)(file crc passed)
Loading: system.sys...moving
(can't catch text between "moving" and "Build")
Build: Dec 15 2007
A20 line enabled via technique 0 (A20 already set by BIOS.)
Memory size in megs: 128
Found processor type: TODO at 477Mhz
Processor: GenuineIntel
type: 06 00
model: 03 00
stepping: 03
APIC ID: 00
log_procs: 08
clflush: 00
brand: (00) Brand not supported by CPU
x87 FPU: yes
VME: no
MSR: yes
APIC on chip: yes
ACPI (temp): no
THERMO: no
MMX: yes
SSE: yes
SSE2: yes
Has Cache and TLB Information structure
Found coprocessor type: TODO at 0 Mhz
CMOS: 128 bytes, 2nd CRC: found (00)
Found Advanced Configuration and Power Interface (ACPI)
Updating hardware information...
ACPI: DSDT: AML code size 2062
ACPI:DSDT table doesn't crc... org_crc 5B. calculated crc 00
ACPI APIC type 0 found...
ACPI APIC type 1 found...
Found VESA v2.0 compatible video card:
Bochs/Plex86 VBE(C) 2003 http://
Modes found: 38 Modes supported 38
Keyboard passed 0xAA test
Keyboard passed 0xAB test
Found PS2 Keyboard with id: AB 83
Found PS2 Wheel Mouse (0x00 0x02 0x64) (0x03)
fdc: 000
Did not find a floppy drive.
Found ATA Disk Controller at 0x0170
Found ATA drive: QEMU CD-ROM (Optical Disk) 0x170 drv: 0
Found logical drive A: active: Y at: 0 Sectors: 0
Could not calculate which partition/disk was booted from. Please choose an
ini
tial drive to use:
Drive was invalid, please choose again:
Rod Pemberton
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
>
> "Benjamin David Lunt" <zf...@frontiernet.net> wrote in message
> news:dH09j.496$7d1...@news01.roc.ny...
>
> > If you do find
> > a why to get QEmu to redirect,
> Nope...
>
> > or copy the text to the clipboard
> > please send it to me.
> Nope...
>
> I typed in what I could capture.
[deleted, other post]
> Should I post one from a normal PC boot also?
Not sure how to save that... I didn't see a debug.txt on the floppy or util
for it, or was that for QEMU? The normal boot had reams of data, including
probably three pages of complaints about 1A functions... but, no debug.txt.
Rod Pemberton
Benjamin David Lunt
Hi Rod,
Thanks for catching the text. I still believe that it is
QEmu that does not support the Polling feature just after
reset. However, I am going to do a few tests.
Also, I will post a new image specifically for QEmu, another
specifically for VPC, and then another for Bochs and real
hardware.
The image for QEmu will not have the polling code.
The image for VPC will detect the floppy using the CMOS.
Thanks again,
Ben
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
news:fk2vl7$9hs$1...@aioe.org...
Benjamin David Lunt
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
Hi Rod,
That's my fault. To do some tests with the floppy, I had it
skip a bunch of code to make the boot faster. It skipped the
"write debug.txt file" code.
Sorry. Watch for the three images soon.
Thanks again for all your help.
Ben
Benjamin David Lunt
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
>
>>
>> QEmu doesn't complain that you are using 0xED?
>>
>> Uhhm. Makes me wonder...
>>
>
> Sigh, it'd been six months. So, I created another image. No, it's not
> complaining. My OS still boots DOS first - then takes control from DOS
> (maybe affects things?). Anyway, it only uses 0xED to set/clear the led's
> for Num,Caps,Scroll and clears all three after initing the keyboard but
> before enabling it.
I will look into this too. Thanks.
Wolfgang Kern
Rod Pemberton answered Benjamin David Lunt:
[...KEYBD LEDs..]
> Sigh, it'd been six months. So, I created another image. No, it's not
> complaining. My OS still boots DOS first - then takes control from DOS
> (maybe affects things?). Anyway, it only uses 0xED to set/clear the led's
> for Num,Caps,Scroll and clears all three after initing the keyboard but
> before enabling it.
I remember the troubles I had with my first attempt to toggle LEDs when
CAPS,NUM,SCRL pressed ... ~20 years ago ;)
I took me many hours to figure out that the 'ED' command takes some time.
Because this keys shall not wait for the break-code, I had it as part of
the IRQ routine. And this caused some weird behaviour.
After I reenabled all IRQs before the LED-cmd, the problem vanished.
The cmd-acknowledge bytes are then read in time to satisfy the hardware.
And if keys are set to repeat-mode and held down the LED will blink, and
the timer can be used for err-time-out or msg: "why hold this key down?".
The problem with emulation may be the timing, perhaps depending
on RealMachine vs. Virtual KeyRepeatRates ... IIRC 'ED' takes 2..5mS.
Or the reported problem with a missing support comes from the usually
read, but ignored, cmd-ackn in an active keyboard-routine ... ?
After initialising or mode changes the ackn-bytes wont enter my buffer.
__
wolfgang
Benjamin David Lunt
"Wolfgang Kern" <now...@never.at> wrote in message
news:fk3ibd$6ch$3...@newsreader2.utanet.at...
Hi wolfgang,
Noted. Thanks.
Ben
Benjamin David Lunt
>
> Also, I will post a new image specifically for QEmu, another
> specifically for VPC, and then another for Bochs and real
> hardware.
>
> The image for QEmu will not have the polling code.
> The image for VPC will detect the floppy using the CMOS.
I have posted two of the three images.
The first image works on Bochs, VMWare, and real hardware.
The third image works on VPC 2007 (and maybe 2004) except
that sometimes it doesn't recognize a keystroke.
The second image, the QEMU image, I haven't posted yet.
After doing a lot of testing, QEMU (or my code) doesn't
like the READ_ID command, which I use quite a bit, nor
does it like the way I wait for an (fdc) interrupt. However,
since my code works just fine on Bochs, VMWare, VPC, and
real hardware, I have to assume it is an error with QEMU,
though I am not one to guarantee my code is correct while
QEMU is wrong. I will do some more work and hopefully post
a QEMU image later today.
By the way, the first image should write a debug.txt file
to the floppy now. The floppy is a FAT12 floppy, so you
should be able to boot the floppy, wait for the debug.txt
file to be written, then reboot to your host OS, and copy
paste the debug.txt file. Either post it here or send
it to my email address. For the sake of not using up
usenet space, maybe you should send it to my email.
Instructions below.
On another note, I spent most of yesterday afternoon
working on the USB code. I rewrote part of it and it is
now much faster and more efficient. With a little more
work, it should support external hubs.
Thanks for your help.
Benjamin David Lunt
> The second image, the QEMU image, I haven't posted yet.
> After doing a lot of testing, QEMU (or my code) doesn't
> like the READ_ID command, which I use quite a bit, nor
> does it like the way I wait for an (fdc) interrupt. However,
> since my code works just fine on Bochs, VMWare, VPC, and
> real hardware, I have to assume it is an error with QEMU,
> though I am not one to guarantee my code is correct while
> QEMU is wrong. I will do some more work and hopefully post
> a QEMU image later today.
I have found why QEMU doesn't work.
In QEMU: FDC.CC
case 0x08:
/* SENSE_INTERRUPT_STATUS */
FLOPPY_DPRINTF("SENSE_INTERRUPT_STATUS command (%02x)\n",
fdctrl->int_status);
/* No parameters cmd: returns status if no interrupt */
#if 0
fdctrl->fifo[0] =
fdctrl->int_status | (cur_drv->head << 2) | fdctrl->cur_drv;
#else
/* XXX: int_status handling is broken for read/write
commands, so we do this hack. It should be suppressed
ASAP */
fdctrl->fifo[0] =
0x20 | (cur_drv->head << 2) | fdctrl->cur_drv;
#endif
fdctrl->fifo[1] = cur_drv->track;
It is known to the developers that it doesn't work. :-)
After reset, the status0 byte should return 0xC0 for the first drive,
0xC1 for the second, 0xC2 for the third, and 0xC3 for the forth.
However, it returns 0x20 for the first, where my code ignores the
remaining three since the first didn't return correct.
This is why my floppy code doesn't work with QEmu. Has anyone
ever run another Guest on QEmu where the floppy works? Obviously
someone has, but with floppies a scarse item these days, maybe it
has just been ignored.
Anyway, until this is fixed in QEmu, I won't post an image that
works with it.
Thanks for your help. I will watch the QEmu site to see if a fix
is ever made. I tried to post a message to the dev-list, but it
has been down for a few days, at least as long as I have tried it.
Alexei A. Frounze
I don't remember all the details, but here's what I ended up doing:
ISR()
{
// Read key scan code
sc = inportb (PORT_KBD_A);
b = inportb (PORT_KBD_B);
outportb (PORT_KBD_B, b | 0x80);
outportb (PORT_KBD_B, b & 0x7F);
switch (sc)
{
case 0xE0:
case 0xE1:
// handle extended codes
case 0xFA: // ignore ACK after LED state
update
goto lend;
}
// some more code handling, specifically for Pause and Print Screen
lend:
AcknowledgeIRQ(...);
} // IRET follows
KbdServiceThread()
{
...
for(;;)
{
// receive a message with a request from other thread
ReceiveMessage (&message);
switch (message.RequestType)
{
case REQUEST_SET_LED:
while (inportb (PORT_KBD_STATUS) & 2) Sleep (1);
outportb (PORT_KBD_A, 0xED);
while (inportb (PORT_KBD_STATUS) & 2) Sleep (1);
outportb (PORT_KBD_A, message.Data & 7);
...
break;
...
}
// respond to the received message
SendMessage (message.SourceThread, &message);
}
}
Benjamin David Lunt
>
> "Benjamin David Lunt" <zf...@frontiernet.net> wrote in message
> news:tsS8j.461$7d1...@news01.roc.ny...
>>
>>
>> [I will see if I can send this post to the Qemu team too.]
>>
>
> Well, the dev-list for QEmu seems to be down. Maybe I will
> try later or hopefully, one of the developers is a regular
> reader here.
The list is back up. I have subscribed to it and hope to get
some feedback and maybe we can get this fixed.
Ben
Rod Pemberton
>
> I have posted two of the three images.
>
> The first image works on Bochs, VMWare, and real hardware.
>
> The third image works on VPC 2007 (and maybe 2004) except
> that sometimes it doesn't recognize a keystroke.
>
12/16 fysos0 locks up detecting my Ethernet PCI card. Fysos used to do
this. But, at some point in time you disabled something, and fysos made it
to the boot prompt. So, you must've reenabled something more than just the
code to save debug.txt. IIRC, 12/15 and 12/02 versions didn't display PCI
detection information.
Rod Pemberton
Wolfgang Kern
Alexei A. Frounze wrote:
[...KEYBD LEDs..]
[...]
> I don't remember all the details, but here's what I ended up doing:
Yeah, even I use machine code, yours look almost idendical to mine.
I'm not too familiar with C, so I have to ask:
what is the duration of sleep(1) ?
may other code perform during sleep ?
does sleep create error on timeout ?
__
wolfgang
____________
Benjamin David Lunt
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
Oh Yes. Sorry. I have the PCI stuff enable for the USB. I forgot
to disable the PCI NIC code. Sorry.
Thanks,
Ben
Alexei A. Frounze
> Alexei A. Frounze wrote:
>
> [...KEYBD LEDs..]
> [...]
>
> > I don't remember all the details, but here's what I ended up doing:
>
> Yeah, even I use machine code, yours look almost idendical to mine.
> I'm not too familiar with C, so I have to ask:
> what is the duration of sleep(1) ?
That particular sleep() is mine and it takes a number of system timer
ticks.
1 timer tick = 1/22050th or 1/10th of second (depending on the
configuration) = 45 microseconds or 10 milliseconds. Now that you
asked this question, 45 microseconds is probably not the best duration
here. :)
> may other code perform during sleep ?
Yes, other threads, but I've omitted the other details of
synchronization.
> does sleep create error on timeout ?
No. My sleep() doesn't return early.
Alex
Alexei A. Frounze
wrote:
> 1 timer tick = 1/22050th or 1/10th of second (depending on the
Typo: 1/100th.
Alex
Rod Pemberton
> > may other code perform during sleep ?
>
> Yes, other threads, but I've omitted the other details of
> synchronization.
>
Was multitasking why you use sleep()? e.g., as a yield_cpu() or
yield_timeslice()...
I just loop forever...without delay. There shouldn't be that much delay
even for an ancient (guessing late '80's) keyboard like I'm using, right?
The LED response seems to be fine. Darn, I figured this would be a real
quick delay. I assumed there'd be no need for a timeout and I didn't even
consider the possibility there might be a long delay, or problem, etc...
Sigh, need to check timings of all port based while loops in OS. I'd rather
not transfer cpu execution to something else at that spot in my OS -
possibly splitting sequential writes to a port (?)... What if I transfered
control in the middle of the port accesses for LED enable, and an LED
disable came in right in the middle of the LED enable... I'm not sure I'd
want to multitask/thread/whatever there.
Rod Pemberton
Wolfgang Kern
Alexei A. Frounze wrote:
>> 1 timer tick = 1/22050th or 1/10th of second (depending on the
> Typo: 1/100th.
close to... ;)
PIT divider set to 2E9Bh 11931 dec 100.00670520 Hz
or 2E9Ch 11932 dec 99.99832384 Hz
I'd like to see once an exact nanoSecond timer in all PCs.
__
wolfgang
Wolfgang Kern
Alexei A. Frounze wrote:
[...KEYBD LEDs..]
>>> I don't remember all the details, but here's what I ended up doing:
>> Yeah, even I use machine code, yours look almost identical to mine.
>> I'm not too familiar with C, so I have to ask:
>> what is the duration of sleep(1) ?
> That particular sleep() is mine and it takes a number of system timer
> ticks.
> 1 timer tick = 1/22050th or 1/10th of second (depending on the
> configuration) = 45 microseconds or 10 milliseconds. Now that you
> asked this question, 45 microseconds is probably not the best duration
> here. :)
Who cares if it works well ? :)
>> may other code perform during sleep ?
> Yes, other threads, but I've omitted the other details of
> synchronization.
Ok.
>> does sleep create error on timeout ?
> No. My sleep() doesn't return early.
I see, my delay is also used as error indication:
_________
mov cl,[main_timer] ;my PIT is always set to 1mS
add cl,5 ;+5 mS
L0:
in al,64h
test al,4
jz/jnz .. ;outahere
cmp cl,[main_timer]
jnz L0
KBD_ERR:
... ;reset keybd and if this fails cry:
"someone pulled my keyboard cable"
instead of M$'s:
"Fatal hardware Error, press ALT-CTRL-DEL to reboot" :)
_________
but please don't ask me how to do this in C :)
btw: do you support USB-KEYBD ?
PS/2 keyboards may be soon unavailable I'm afraid, so I'll
add the 'new' routines with the next release, but haven't
checked if my solutions (just ideas yet) will work.
__
wolfgang
Wolfgang Kern
Rod Pemberton wrote:
>>> may other code perform during sleep ?
>> Yes, other threads, but I've omitted the other details of
>> synchronization.
> Was multitasking why you use sleep()? e.g., as a yield_cpu() or
> yield_timeslice()...
> I just loop forever...without delay. There shouldn't be that much delay
> even for an ancient (guessing late '80's) keyboard like I'm using, right?
> The LED response seems to be fine. Darn, I figured this would be a real
> quick delay. I assumed there'd be no need for a timeout and I didn't even
> consider the possibility there might be a long delay, or problem, etc...
> Sigh, need to check timings of all port based while loops in OS. I'd
rather
> not transfer cpu execution to something else at that spot in my OS -
> possibly splitting sequential writes to a port (?)... What if I
transfered
> control in the middle of the port accesses for LED enable, and an LED
> disable came in right in the middle of the LED enable... I'm not sure I'd
> want to multitask/thread/whatever there.
My solution on this matter is a one mSec based time-sliced job queu.
And because all hardware threads got a busy flag they wont/can't
intercept itself, except for external termination or any error.
Of course it may happen that the user pressed CAPS while another
thread try to turn LEDs off.
In this rare case the LED flashes almost invisible just once.
A better example is disk RD/WR on overlapping areas where I decided
to give WR the higher priority, so the reading thread will always
receive actualised data. But this is also rare to happen anyway.
I hate to waste time by waiting, so I do something meanwhile. Often
just update the mouse-cursor or send/receive data in the background.
__
wolfgang
Rod Pemberton
> > 12/16 fysos0 locks up detecting my Ethernet PCI card. Fysos used to do
> > this. But, at some point in time you disabled something, and fysos made
> > it
> > to the boot prompt. So, you must've reenabled something more than just
> > the
> > code to save debug.txt. IIRC, 12/15 and 12/02 versions didn't display
PCI
> > detection information.
>
> Oh Yes. Sorry. I have the PCI stuff enable for the USB. I forgot
> to disable the PCI NIC code. Sorry.
>
12/17 fysos0
makes it to bootprompt - yes
seems to write/read to floppy for long time after detection - yes
debug.txt on floppy - NO
"debug.txt" somewhere in "new" image - not that I can tell...
binary compare of image before and "new" image after boot - identical...
There are a bunch of mini-register dumps that say stuff like "Unhandled INT
1A Service exception" and "Unhandled instruction in v86 mode causing a
GPF"... RBIL indicates the ones I can see are PCI or PnP BIOS calls.
Was/is debug.txt saving enabled? What do I need to send to you? floppy
detection (fdc 000 111 222), what I can catch of v86, PCI or PnP version?
Rod Pemberton
Alexei A. Frounze
> "Alexei A. Frounze" <alexfrun...@gmail.com> wrote in messagenews:8d127e58-83e3-4016...@d21g2000prf.googlegroups.com...
>
> > > may other code perform during sleep ?
>
> > Yes, other threads, but I've omitted the other details of
> > synchronization.
>
> Was multitasking why you use sleep()? e.g., as a yield_cpu() or
> yield_timeslice()...
Exactly.
> I just loop forever...without delay. There shouldn't be that much delay
> even for an ancient (guessing late '80's) keyboard like I'm using, right?
> The LED response seems to be fine. Darn, I figured this would be a real
> quick delay. I assumed there'd be no need for a timeout and I didn't even
> consider the possibility there might be a long delay, or problem, etc...
> Sigh, need to check timings of all port based while loops in OS. I'd rather
> not transfer cpu execution to something else at that spot in my OS -
> possibly splitting sequential writes to a port (?)... What if I transfered
> control in the middle of the port accesses for LED enable, and an LED
> disable came in right in the middle of the LED enable... I'm not sure I'd
> want to multitask/thread/whatever there.
Well, I intended to implement in it poor man's soundblaster :) based
on the PC speaker and pulse-width modulation to solve the problem of
the sound drivers in some way different from not having any sound at
all. :) I don't think looping heavily somewhere would be such a good
idea, especially when there's real-time audio streamed. :) And you
can't lose any timer interrupts either or the sound will be choppy. My
DOS-based implementation worked/sounded OK only when there was no disk
I/O at the time, during which the BIOS was apparently disabling all
the interrupts.
Alex
Alexei A. Frounze
> I see, my delay is also used as error indication:
> _________
> mov cl,[main_timer] ;my PIT is always set to 1mS
> add cl,5 ;+5 mS
> L0:
> in al,64h
> test al,4
> jz/jnz .. ;outahere
> cmp cl,[main_timer]
> jnz L0
> KBD_ERR:
> ... ;reset keybd and if this fails cry:
> "someone pulled my keyboard cable"
> instead of M$'s:
> "Fatal hardware Error, press ALT-CTRL-DEL to reboot" :)
> _________
>
> but please don't ask me how to do this in C :)
Don't ask me to do that in Basic :)
> btw: do you support USB-KEYBD ?
I don't even know what that is.
> PS/2 keyboards may be soon unavailable I'm afraid, so I'll
> add the 'new' routines with the next release, but haven't
> checked if my solutions (just ideas yet) will work.
I'm afraid by the time I get around to put together a tiny demo of
almost completed pieces, this will all be completely irrelevant and
nothing to show on. :)
Alex
Alexei A. Frounze
If one puts all those keyboard-port requests onto one queue, no
problems, they'll all get handled in the order of occurrence on the
queue. If it's a problem of sharing a state of a single device (e.g.
each application wants it's own Caps Lock state just like the keyboard
layout in Windows), then you need to virtualize that, which again
comes back to elimination of direct access to that device from
multiple competing places.
Alex
Esra Sdrawkcab
> I will have a look at these things. Thank you. It is always nice
> to have a fellow user send in the debug.txt file (or post it like you
> did). I will look into these things and get back to you.
>
OK, trying later version, it gets further
--(screencap, missed a lot)
Type: Video
PORT INFO:
Type: Keyboard
PORT INFO:
Type: Mouse
ON BOARD DEVICE INFO:
Device 01 Type: SCSI Controller (Enabled)
To Be filled by O.E.M.
TODO: SMBIOS code 11: Free form strings
TODO: SMBIOS code 12:
TODO: SMBIOS code 13: BIOS Language Specs
TODO: SMBIOS code 18: Memory Error Info
TODO: SMBIOS code 16: physical memory array
TODO: SMBIOS code 19: Memory Array Mapped Address
TODO: SMBIOS code 17: Memory Device
TODO: SMBIOS code 20: Memory Device Mapped Address
TODO: SMBIOS code 17: Memory Device
TODO: SMBIOS code 20: Memory Device Mapped Address
TODO: SMBIOS code 17: Memory Device
TODO: SMBIOS code 20: Memory Device Mapped Address
TODO: SMBIOS code 17: Memory Device
TODO: SMBIOS code 20: Memory Device Mapped Address
TODO: SMBIOS code 23:
TODO: SMBIOS code 32:
--(end screencap, it din't pick up last line:)
Press a key or two
--(no response)
--(reboot)
Serial Number: 0000000007C0A97B
SysCall/SysRet instructions allowed: no
XD bit of PAE allowed: no
64-bit extentions allowed: no
Number of bits used for virtual addresses: 48
Number of bits used for physical addresses: 36
Found coprocessor type: TODO at 0 Mhz
CMOS: 128 bytes, 2nd CRC: notfound (00)
Found Advanced Configuration and Power Interface (ACPI)
Updating hardware information...
ACPI: DSDT: AML code size 8311
ACPI: OEM BIOS
Found PnP BIOS v1.0
Found PnP ISA card: Unknown vendor type and/or name (tBA03;0)
ID String: Sound Blaster 16
Vendor ID: tBA03;0 serial number: -1
Device 0: id: ZA@ function: 003 rev: 176 Compatible id:
03B0D041
Found PnP ISA card: Unknown vendor type and/or name (tBA2?;0)
ID String: Game Port
Vendor ID: tBA2?;0 serial number: -1
Device 0: id: ZA@ function: 047 rev: 176 Compatible id:
2FB0D041
Found VESA v2.0 compatible video card:
IBM SVGA BIOS, (C) 1993 Internat
Modes found: 32 Modes supported: 31
--(missing cap of last line again!)
Did not find a keyboard or keyboard error
--(stuck - I'd hit pause to try to do more screen capture)
--(another partial capture)
clflush: 00
brand: (00) Brand not supported by CPU
x87 FPU: yes
VME: yes
MSR: yes
APIC on chip: no
ACPI (temp): yes
THERMO: no
MMX: yes
SSE: yes
SSE2: yes
Has Cache and TLB Information structure
Serial Number: 0000000007C0A97B
SysCall/SysRet instructions allowed: no
XD bit of PAE allowed: no
64-bit extentions allowed: no
Number of bits used for virtual addresses: 48
Number of bits used for physical addresses: 36
Found coprocessor type: TODO at 0 Mhz
CMOS: 128 bytes, 2nd CRC: notfound (00)
Found Advanced Configuration and Power Interface (ACPI)
Updating hardware information...
ACPI: DSDT: AML code size 8311
ACPI: OEM BIOS
--()
Found coprocessor type: TODO at 0 Mhz
CMOS: 128 bytes, 2nd CRC: notfound (00)
Found Advanced Configuration and Power Interface (ACPI)
Updating hardware information...
ACPI: DSDT: AML code size 8311
ACPI: OEM BIOS
Found PnP BIOS v1.0
Found PnP ISA card: Unknown vendor type and/or name (tBA03;0)
ID String: Sound Blaster 16
Vendor ID: tBA03;0 serial number: -1
Device 0: id: ZA@ function: 003 rev: 176 Compatible id:
03B0D041
Found PnP ISA card: Unknown vendor type and/or name (tBA2?;0)
ID String: Game Port
Vendor ID: tBA2?;0 serial number: -1
Device 0: id: ZA@ function: 047 rev: 176 Compatible id:
2FB0D041
Found VESA v2.0 compatible video card:
IBM SVGA BIOS, (C) 1993 Internat
Modes found: 32 Modes supported: 31
Keyboard passed 0xAA test
Keyboard passed 0xAB test
Controller version: 0
Controller firmware version: 0
Found PS2 Keyboard with id: AB 41
Found Floppy Disk Controller at 0x03F0 with type 82078SL or 82078-1
--()
Device 0: id: ZA@ function: 003 rev: 176 Compatible id:
03B0D041
Found PnP ISA card: Unknown vendor type and/or name (tBA2?;0)
ID String: Game Port
Vendor ID: tBA2?;0 serial number: -1
Device 0: id: ZA@ function: 047 rev: 176 Compatible id:
2FB0D041
Found VESA v2.0 compatible video card:
IBM SVGA BIOS, (C) 1993 Internat
Modes found: 32 Modes supported: 31
Keyboard passed 0xAA test
Keyboard passed 0xAB test
Controller version: 0
Controller firmware version: 0
Found PS2 Keyboard with id: AB 41
Found Floppy Disk Controller at 0x03F0 with type 82078SL or 82078-1
Found Floppy Disk Controller at 0x0370 with type 82078SL or 82078-1
Did not find a floppy drive.
Found ATA Disk Controller at 0x01F0
Found ATA drive: Virtual HD (Hard Disk) 0x1F0 drv: 0
Found a FAT16 file system
Found ATA Disk Controller at 0x0170
Found ATA drive: Virtual CD (Optical Disk) 0x170 drv: 0
Found logical drive A: active: Y at: 63 Sectors:
4,185,153
Found logical drive B: active: Y at: 0 Sectors:
0
Could not calculate which partition/disk was booted from. Please
choose an in
tial drive to use:
--(lock up)
Wolfgang Kern
Alexei A. Frounze wrote:
[..about..]
>> I hate to waste time by waiting, so I do something meanwhile. Often
>> just update the mouse-cursor or send/receive data in the background.
> If one puts all those keyboard-port requests onto one queue, no
> problems, they'll all get handled in the order of occurrence on the
> queue. If it's a problem of sharing a state of a single device (e.g.
> each application wants it's own Caps Lock state just like the keyboard
> layout in Windows), then you need to virtualize that, which again
> comes back to elimination of direct access to that device from
> multiple competing places.
This can be covered by the focus change, a user cannot type in one
box and copy paste in another with the mouse at the very same time. :)
An interesting idea to have two open text-files with different
CAPS/NUMLOCK settings. Even it would just confuse the poor user,
an additional option could make sense sometime.
I think it's a good idea to not let the user talk direct to the
hardware. But LED-key respond shouln't be delayed (max.20 ms).
Until now I heard no complains about my chosen method, but whenever
my OS may support games, then I'd have to think over this again.
__
wolfgang
Wolfgang Kern
Alexei A. Frounze wrote:
...
>> but please don't ask me how to do this in C :)
> Don't ask me to do that in Basic :)
:)
>> btw: do you support USB-KEYBD ?
> I don't even know what that is.
>> PS/2 keyboards may be soon unavailable I'm afraid, so I'll
>> add the 'new' routines with the next release, but haven't
>> checked if my solutions (just ideas yet) will work.
> I'm afraid by the time I get around to put together a tiny demo of
> almost completed pieces, this will all be completely irrelevant and
> nothing to show on. :)
Just fine as long you are satisfied by your own work.
I work since 20 years on my OS and even I could sell a few niche-
applications with it, it still is a lot of work to just be near up
to date. Not to mention that my ToDo-list become longer every day.
I once decided to skip x186 and x386, that helped a bit.
But I can't skip the 64's, even it would be somehow wise.
We Europeans may never learn how to sell half-done products,
quality got its price and takes time ...
Look at Vista, best back-seller of the year ?
Downgrades to XP are already available!
And you asked me some time ago 'why XP and not Vista',
seems I did well by taking the lesser evil, my XP works just fine,
it crashes only twice a month and needs only two hours to reinstall.
__
wolfgang
Benjamin David Lunt
"Esra Sdrawkcab" <ad...@127.0.0.1> wrote in message
news:HvP9j.17077$1j1...@newsfe7-gui.ntli.net...
> Benjamin David Lunt wrote:
>
>> I will have a look at these things. Thank you. It is always nice
>> to have a fellow user send in the debug.txt file (or post it like you
>> did). I will look into these things and get back to you.
>>
>
> OK, trying later version, it gets further
Thank you.
...
> TODO: SMBIOS code 20: Memory Device Mapped Address
> TODO: SMBIOS code 23:
> TODO: SMBIOS code 32:
...
I am aware of the SMBIOS TODO's. I need to get to them.
> --(no response)
No response to a keypress, huh.
> Found PnP ISA card: Unknown vendor type and/or name (tBA03;0)
I need to look through the PnP ISA specs again. That chars
in the ()'s look like a binary number instead of a character
string.
> Did not find a keyboard or keyboard error
This is all under VPC 2004, correct?
I will look into this some more.
Thanks,
Ben
Benjamin David Lunt
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
>
>
> 12/17 fysos0
> makes it to bootprompt - yes
> seems to write/read to floppy for long time after detection - yes
Depending on a setting in the system.sys file, it will read 65 sectors
to detect the filesystem on the disk. It also has to detect what type
of disk, 1.44meg, 1.20meg, 720 meg, etc., but reading specified sectors.
If the sector is not found, then that eliminates certain sizes.
> debug.txt on floppy - NO
This has got me wondering. It did make it to the prompt about
"This is where I recommend you stop. Please remove the
floppy disk, reboot your" ...
Yes? If not, did it make it to
"Press a key or two to continue..."
> "debug.txt" somewhere in "new" image - not that I can tell...
> binary compare of image before and "new" image after boot - identical...
> There are a bunch of mini-register dumps that say stuff like "Unhandled
> INT
> 1A Service exception" and "Unhandled instruction in v86 mode causing a
> GPF"... RBIL indicates the ones I can see are PCI or PnP BIOS calls.
Yep, INT 1Ah is the BIOS PCI services. However, I don't have any code
that should access the BIOS PCI services. I wonder if this is raw
data that just happens to have an INT 1Ah instruction in the data.
> Was/is debug.txt saving enabled? What do I need to send to you? floppy
> detection (fdc 000 111 222), what I can catch of v86, PCI or PnP version?
fdc 000, 111, & 222 weren't displayed this time, where they? If so,
either I didn't upload the latest image as I may have thought, or you
aren't using the latest. I deleted those lines from the code.
Thanks for your help. I will await your answers, and sorry it
takes me about 24 hours to respond. I am back being busy again.
Ben
Rod Pemberton
>
> "Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
> news:fk8cah$hlo$1...@aioe.org...
> >
> >
> > 12/17 fysos0
> > makes it to bootprompt - yes
> > seems to write/read to floppy for long time after detection - yes
>
> Depending on a setting in the system.sys file, it will read 65 sectors
> to detect the filesystem on the disk. It also has to detect what type
> of disk, 1.44meg, 1.20meg, 720 meg, etc., but reading specified sectors.
> If the sector is not found, then that eliminates certain sizes.
>
> > debug.txt on floppy - NO
>
> This has got me wondering. It did make it to the prompt about
>
> "This is where I recommend you stop. Please remove the
> floppy disk, reboot your" ...
>
> Yes? If not, did it make it to
>
> "Press a key or two to continue..."
>
I don't recall seeing either one. It ended with a "dos prompt." There is a
status (25th) line saying a message would go there and displaying the time.
> Yep, INT 1Ah is the BIOS PCI services. However, I don't have any code
> that should access the BIOS PCI services. I wonder if this is raw
> data that just happens to have an INT 1Ah instruction in the data.
>
Perhaps secondary related to the first one that failed and scrolled by too
fast to read...
> > Was/is debug.txt saving enabled? What do I need to send to you? floppy
> > detection (fdc 000 111 222), what I can catch of v86, PCI or PnP
version?
>
That's the first time I've seen all of them, but I hadn't booted recent
images on real hardware, just QEMU...
> fdc 000, 111, & 222 weren't displayed this time, where they? If so,
> either I didn't upload the latest image as I may have thought, or you
> aren't using the latest. I deleted those lines from the code.
>
> Thanks for your help. I will await your answers, and sorry it
> takes me about 24 hours to respond. I am back being busy again.
>
I'll dl again and post the debug.txt if it gets written - probably before
morning. I'll reboot later... ;) If not, Merry Christmas et. al., and we
can try again whenever you get a chance, this year or sometime next...
Rod Pemberton
Rod Pemberton
> Well, I intended to implement in it poor man's soundblaster :) based
> on the PC speaker and pulse-width modulation to solve the problem of
> the sound drivers in some way different from not having any sound at
> all. :) I don't think looping heavily somewhere would be such a good
> idea, especially when there's real-time audio streamed. :) And you
> can't lose any timer interrupts either or the sound will be choppy. My
> DOS-based implementation worked/sounded OK only when there was no disk
> I/O at the time, during which the BIOS was apparently disabling all
> the interrupts.
>
Have you looked at what Jim Leonard, a.k.a. Trixter, did for 8088
corruption? IIRC, from some posts to comp.lang.asm.x86 he had to solve a
number of issues involving "interleaving" disk access, video, sound, and
interrupts.
http://www.oldskool.org/pc/8088_Corruption
Rod Pemberton
Rod Pemberton
> I'm afraid by the time I get around to put together a tiny demo of
> almost completed pieces, this will all be completely irrelevant and
> nothing to show on. :)
>
Had the same thoughts and feelings a few years ago about my OS. I've
decided to plod on anyway. Some technologies become standardized and
accepted for long time periods: floppy, PS/2 and probably USB. You can code
for the "best of the best" or most used or most preferred PC hardware and
ignore the rest at first... No reason to code for Hercules, XGA, raster
video, 286, 386, serial mice, parallel ports, possibly things like short
lived video interfaces: AGP, expensive or custom hardware: SCSI, 3D video,
etc. etc. Once enough stuff works you can go commercial or open source to
fill in the rest...
In fact, I've made a short timeline of PC hardware and PC standards for OS
developers. It's not complete, and maybe some errors, but I haven't seen
anything else like it. I'm thinking about posting it somewhere... Perhaps
on the FAQ site... Perhaps on OSDEV... Guys? Thoughts?
Rod Pemberton