It has been a little while, but I had some time recently
to work with my code. I have an updated release at
http://www.frontiernet.net/~fys/fysos.htm
for those who are interested.
Thanks to Volker Ruppert for updating the Bochs CVS to
support a USB flash thumb drive, I have implemented
USB flash drives into FYSOS.
I also found a bug in my FDC code where I was not waiting
long enough after a controller reset and a test on a friends
machine wasn't detecting a floppy drive. It was
long enough for all other tested machines, just not this
one.
I have added a little more CPU detection, a some what updated
FYSFS spec (http://www.frontiernet.net/~fys/fysfs.htm),
my LEAN FS implementation, as well as more advancements in
my USB code. I have been using a hardware USB analyzer
(the Beagle from http://www.totalphase.com/products/beagle/usb12/)
and have been making good progress. It is a nice little
analyzer. Anyway, my USB code is growing well.
I may drop my implementation of the ZenFS file system due
that it has been a while since I have heard from Mark and
his site is down. Has anyone else done any work with this
file system?
Anyway, I just wanted to comment and say thanks to all
of those who have helped, whether you know you have or not :-)
Thanks, and enjoy your week,
Ben
You should try running it under VMWare. I don't know whose bug it is, but
the keyboard input isn't working right. In particular, keyboard mappings
seem to be totally fncked up.
What I press and what I see in the command line:
1->u
q->y
a->\n
z->[
F1->4
F2->5
F3->3
F4->-
F5->2
F6->0
F7->nothing?
F8->9
F9->esc?
F10->8
F11->nothing?
F12->6
space bar->`
And every character is duplicated. I don't know if you reprogram the
keyboard entirely and something goes haywire after that.
Alex
>> It has been a little while, but I had some time recently
>> to work with my code. I have an updated release at
>> http://www.frontiernet.net/~fys/fysos.htm
>> for those who are interested.
>>
Hi Alex,
> You should try running it under VMWare. I don't know whose bug it is, but
> the keyboard input isn't working right. In particular, keyboard mappings
> seem to be totally fncked up.
> What I press and what I see in the command line:
> 1->u
> q->y
> a->\n
> z->[
> F1->4
> F2->5
> F3->3
> F4->-
> F5->2
> F6->0
> F7->nothing?
> F8->9
> F9->esc?
> F10->8
> F11->nothing?
> F12->6
> space bar->`
> And every character is duplicated. I don't know if you reprogram the
> keyboard entirely and something goes haywire after that.
This happens about 1 in 100 times for me. I have been working
on the problem, but yet to find out what it is. I'm looking
at my mapping code, thinking that I map to a non existent map,
though I haven't found it yet.
Thanks for the comment, I will work on this next.
Ben
> You should try running it under VMWare. I don't know whose bug it is, but
> the keyboard input isn't working right. In particular, keyboard mappings
> seem to be totally fncked up.
> What I press and what I see in the command line:
> 1->u
> q->y
> a->\n
> z->[
> F1->4
> F2->5
> F3->3
> F4->-
> F5->2
> F6->0
> F7->nothing?
> F8->9
> F9->esc?
> F10->8
> F11->nothing?
> F12->6
> space bar->`
> And every character is duplicated. I don't know if you reprogram the
> keyboard entirely and something goes haywire after that.
Hi Alex,
I made some modifications. Please check it again.
Thanks,
Ben
And some modifications have led to some results. Now the keyboard input is
totally non-functional. :) For every key I'm pressing I'm seeing no echo at
all. So, as someone Russian would've said these days jokingly, "To the
furnace your keyboad code!" :)
Alex
Uhhm. What are you running it on? Real hardware? VMWare?
If so, what type of hardware, or what version of VMWare.
Would you please give some more detail of the platform you
are using.
Thanks again,
Ben
P.S. It isn't a USB keyboard is it? My USB keyboard code is
not totally functional yet.
Old VMWare: Workstation 5. OS type: other: MS-DOS.
I could also try real hardware. Maybe next week, when I've moved completely
to the new place.
> If so, what type of hardware, or what version of VMWare.
> Would you please give some more detail of the platform you
> are using.
>
> Thanks again,
> Ben
>
> P.S. It isn't a USB keyboard is it? My USB keyboard code is
> not totally functional yet.
I don't think this has anything to do with USB, it's notebook's keyboard,
which, I believe is PS/2, and VMWare doesn't care as it gets all the
keyboard input from Windows and emulates the keyboard protocol independently
of what physical keyboard is.
Alex
Okay Alex, I made a few fixes and now I hope it works.
Please try it.
Thanks,
Ben
Same problem as I reported initially.
Can you tell what you're doing with the keyboard?
Alex
Curious, do you think VMWARE expects keycodes to be mode 2 w/xt-at
translation but maybe the keyboard is being set to a different mode?
Rod Pemberton
On the other hand, do you absolutely need to reprogram it? Is it necessary?
Alex
Hi guys,
I only support set 1. I have code to support 2 and 3, but have not
implemented them. Ya, I could modify my code to not change to set 1.
Give me the afternoon and I should post a new release supporting
set 2 and 3.
Thanks,
Ben
I don't know. What does the BIOS do Alexei? I brought it because many OS
writers use set 1 or set 3 for simplicity (as Ben confirmed, he's using set
1...) and my finely tuned "intuition alarm" (Yes, I've got one! :-) ) said
VMWARE probably only recognized set 2 with XT to AT translation (either for
DOS compatibility and/or blocked from being reprogramming by Windows).
Rod Pemberton
I've never bothered to reprogram it. Why fixing what's not broken and works
just fine? :)
Alex
Sigh... AT to XT translation... Unfortunately, my poorly tuned "detail
alarm" seems to have blown completely lately. ;)
> > (either for DOS compatibility and/or blocked from being reprogramming
> > by Windows).
>
> I've never bothered to reprogram it. Why fixing what's not broken and
works
> just fine? :)
>
Good question. I wonder what others say.
I reprogrammed the keyboard because one of the keyboard controller registers
does the device enable and interrupt enable for both the keyboard and PS/2
mouse.
I don't know for sure what the BIOS does (my _guess_ is set 2 AT to XT, but
I'm _not_ in the mood to go look it up...). Part of my OS philosophy was to
not depend on the BIOS or to the BIOS as little as possible.
There are some very good reasons of why to *only* use set 2 w/AT to XT
translation in "7.4 Use" here:
http://homepages.cwi.nl/~aeb/linux/kbd/scancodes-7.html
Rod Pemberton
>> It has been a little while, but I had some time recently
>> to work with my code. I have an updated release at
>> http://www.frontiernet.net/~fys/fysos.htm
>> for those who are interested.
Okay guys, I believe that my code now supports sets 1 and 2.
Please try it and see.
The only thing is, don't press the PrtScreen or Pause keys.
It would be what you think it to be.
I may need to rewrite how I get a scan code from the keyboard
so that I can correctly get those two keys as well as the
ACPI keys, etc.
Thanks,
Ben
[about KEYBD translation]
>> I've never bothered to reprogram it. Why fixing what's not broken and
>> works just fine? :)
> Good question. I wonder what others say.
> I reprogrammed the keyboard because one of the keyboard controller
> registers does the device enable and interrupt enable for both the
> keyboard and PS/2 mouse.
This both are easy to separate by D4/D5 command prefix ...
> I don't know for sure what the BIOS does (my _guess_ is set 2 AT to XT,
> but I'm _not_ in the mood to go look it up...).
> Part of my OS philosophy was to not depend on the BIOS or to the
> BIOS as little as possible.
The BIOS checks the keybd-type, but then work on native scan codes.
> There are some very good reasons of why to *only* use set 2 w/AT to XT
> translation in "7.4 Use" here:
> http://homepages.cwi.nl/~aeb/linux/kbd/scancodes-7.html
Right, all KeyBDs I ever had in hand during the last 15 years
work the same way and I just let them send this scan-codes:
Make(Release codes have bit 7 set)
01 : ESC
02 : 1
03 : 2
...
0a : 9
0b : 0
....
e0 46 :CTRL+Pause = Break
e1 1d 45 e1 9d c5 :Pause (release code implied)
Looks like they all work in PS/2-mode SET1.
Isn't this a bit different to SET2, or more worse to SET3 ?? ;)
And as all of my keyboards got less than 256 keys, I assigned
one single byte (ASCII or else) for all except ALT/CTRL/SHIFT
which go together with make/break,LED-status and block-info-bits
(NUM/CRSR,ASCII/else) to other bytes.
So finally I get one dword from my keybd-handler which reflects
all what's going on and let me react or ignore as desired.
The ASCII-table can be easy swapped for local requirements and
I think to once add UniCode (at least UTF8) support as well.
__
wolfgang
Alex, Rod,
I re-wrote the code to accept multiple keyboard sets, more
than the three there are now, though who knows if there
ever will be more. Doubt it.
Anyway, the code now should use all three sets with no
problem.
I parse the key sequences and find the Print Screen sequence
okay, though Bochs doesn't send it correctly, whether Windows
is interfering or Bochs isn't sending it right.
Anyway, please try the new version, dated 2 Aug 2007 16:40,
and let me know if it runs on the VMWare you mentioned.
Thanks,
Ben
Sorry,
I forgot to remove a bit of testing code and you could not
get further than the keyboard init stuff. Try the new
one please. 2 Aug 2007 18:13
Thanks again for your help.
Ben
aaaaaaaaaaaaaaaaaaaaaaaaaa!
It's all I get, no matter what I press. Even less, no exclamation mark.
Please download VMWare server and play with it. There's a free version.
Alex
Hi Alex,
Okay, I will. The code works on Bochs, and on all hardware I tried
it on. One of the machines has a USB keyboard that the hardware
is emulating as a PS2 with set 1 only.
Okay, I will find VMWare and see what I can find.
Thanks,
Ben
I've moved on to other things. Zen FS was a small part in my larger
project, which is still ongoing, to answer the question "With what we
know today, if we were to start again with a clean slate, how would we
design an operating system and computing environment?" To this end I
created Zen FS because I felt the existing solutions were an evolution
of antiquated designs too constrained by this legacy (plus they didn't
meet some of my security requirements). However in designing Zen FS I
discovered that I was really attacking the wrong problem. While it is
true that existing file systems are antiquated designs (Sun's new and
conspicuously named ZFS being an exception...), what's more antiquated
is the very idea of a hierarchical file system. The relational
database guys have known this for over 35 years, but somehow the file
system community never caught on.
So to bring this back to your implied question, no, there's been no
more work on Zen FS. Maybe one day the rest of my project will see
the light of day on this forum, but when it does it will use a form of
relational data store, something which is not Zen FS (though perhaps
derived from it). You all have permission to use Zen FS if you want,
for any purpose, and I won't be releasing any new versions, so
consider it stable. I still consider it the second-best design out
there. Sun's ZFS is better overall, but there's less documentation,
and requires a much more complex implementation, which is something
you might want to take into account on a hobby project.
Mark
PS: Do you have a copy of Zen FS v5? I let my domain expire without
backing up that data :\ v3 is available on archive.org, but I can't
find any copies of the v5 spec.
Hi Mark,
That's what I had figured happened. :-)
>
> PS: Do you have a copy of Zen FS v5? I let my domain expire without
> backing up that data :\ v3 is available on archive.org, but I can't
> find any copies of the v5 spec.
Yes, version 0.1pre5.
http://www.frontiernet.net/~fys/incoming/zenfs_v01pre5.pdf
Thanks again. I may keep my implementation and later go more
in detail with it and see what I come up with.
Ben
Hey Alex,
I don't think I got the correct VMWare Server software. It doesn't
seem to be what I thought it was. Do you have a link to the
VMWare software download you are talking about?
Thanks,
Ben
I wanted VMware Workstation instead, correct :-)
Okay, I have FYSOS up and going in VMware and also am having
keyboard problems. I can enable my debug print items and
have a look.
Thanks,
Ben
Alex,
Using VMware 6.0.0 build-45731, I like it's interface, but
I think I have found a few problems.
When you start image, do you get the following line or
lines printed to the screen?
8<
v86: Unknown/Unhandled 'INT n' service call: INT 6Dh. Terminating v86
session
v86: EAX = 0x00004F01 EBX = 0x00000000 ECX = 0x00000120 EDX = 0x00000000
ESI = 0x00000000 EDI = 0x00000010 Not supported.
>8
(create a parallel port in the "add hardware" section and have it
output to a file.)
I think that VMware's v86 emulation is broken. I am getting some
strange errors that look like compiler errors. The questionable
code runs on Bochs and the six or so actual machines I have tested
it on, just fine.
Anyway, I will work on the keyboard part soon.
Thanks,
Ben
Sorry about that. I jumped to a conclusion before I looked over
all the possibilities. I do that once in a while. Sorry about
that.
It was a simple source line missing in my v86 code.
It will teach me, right :-)
I would still like to know if it printed all those lines for you
though, Alex.
Thanks again,
Ben
> aaaaaaaaaaaaaaaaaaaaaaaaaa!
> It's all I get, no matter what I press. Even less, no exclamation mark.
> Please download VMWare server and play with it. There's a free version.
Hi Alex,
Sorry to keep bothering you. When VMware boots and displays
the "bios" screen at POST, try hitting F2, Esc, or F12. Nothing
happens over here. My code isn't even booted yet, and the keyboard
doesn't work.
Let me know what you find.
Thanks,
Ben
Please do. Will be interesting to see. And you can also try Virtual PC/
Server from Microsoft. That'd extend your testbed even further.
Alex
Yeah, I got a bunch of messages like that. Never bothered to
understand though.
Alex
Normally, you need to click on the window to give the VM the keyboard
access and I believe there's a keyboard shortcut for that too. And
then you need to release the keyboard by pressing ctrl+alt, unless
that has changed.
Alex
Bochs, QEMU, VMWare, VPC/Server...
I can understand testing a couple in case someone wanted to try the OS
without installing it. But, why do you need his OS to work under so many
emulators when he knows his code runs on six different real PC's? The
emulators are far more likely to have bugs than the PC's themselves...
Rod Pemberton
I can give you a few examples, where the emulator *may* in fact prove
the code wrong or unreliable:
- if there's a cache (e.g. TLB) and it's bigger in the emulator than
on the real hardware, a missing cache entry flush in the code may be
revealed in the emulator but go unseen on the hardware.
- if the code is using an instruction whose implementation may be
buggy due to the quality of the documentation (e.g. intel manuals) or
hardware (e.g. intel CPUs), failure in either environment will give
you a hint that the code is not good and may have issues executing on
other emulators or CPUs. If you don't care about that, OK, but if you
do... I'm amazed at how intel has managed to fnck up their
documentation and CPUs. To be fair, AMD, too. The instruction
description and/or pseudo code is often vague yet the actual CPU
behavior even in seemingly well documented cases is different from
what's in the document. And this isn't in the errata either, meaning
they don't know about this bug or if they do they don't care letting
others know about it. We all know how the software is unreliable,
let's now add unreliable hardware to the mix and watch the magic. :)
Alex
P.S. Sometimes I think why should I care about the quality of our
software and underlying circuitry if sooo many other non-IT products
are already crap and we're kind of used to that...
I even read that in the docs too. I don't know why I didn't
put 2 and 2 together. I guess that is what I get for burning
the candle at both ends.
Yep, ctrl+alt releases the keyboard and mouse. Let me
run my debug version on it and see what I find.
Thanks.
Thanks, this is fixed now.
Hi Rod, Alex,
> I can give you a few examples, where the emulator *may* in fact prove
> the code wrong or unreliable:
>
> - if there's a cache (e.g. TLB) and it's bigger in the emulator than
> on the real hardware, a missing cache entry flush in the code may be
> revealed in the emulator but go unseen on the hardware.
> - if the code is using an instruction whose implementation may be
> buggy due to the quality of the documentation (e.g. intel manuals) or
> hardware (e.g. intel CPUs), failure in either environment will give
> you a hint that the code is not good and may have issues executing on
> other emulators or CPUs. If you don't care about that, OK, but if you
> do... I'm amazed at how intel has managed to fnck up their
> documentation and CPUs. To be fair, AMD, too. The instruction
> description and/or pseudo code is often vague yet the actual CPU
> behavior even in seemingly well documented cases is different from
> what's in the document. And this isn't in the errata either, meaning
> they don't know about this bug or if they do they don't care letting
> others know about it. We all know how the software is unreliable,
> let's now add unreliable hardware to the mix and watch the magic. :)
>
> Alex
> P.S. Sometimes I think why should I care about the quality of our
> software and underlying circuitry if sooo many other non-IT products
> are already crap and we're kind of used to that...
I have Microsoft VirtualPC loaded on one of these machines and
have run fysos through it. The keyboard worked fine, though with
the changes I made, I better check again.
I too very much prefer emulators. It is so much faster development
that on hardware. Plus if it is a good emulator, it will catch
errors where real hardware may ignore it. I log a good log file
after a debug run.
However, on Rod's point of view, I do not like that when my code
runs fine on all the emulators, I take it to real hardware and
Boom.
The emulators are written to the specs and the hardware may not
be, therefore you write your code to work on the emulator because
it may be correct, then the hardware crashes.
I have not tried Qemu yet, though I have on Bochs (my preferred
choice since I have put a bit of work into it :), MS Virtual PC,
and now VMware.
Thanks guys for your comments. I will let you know what I find
about the keyboard and VMware.
Ben
Okay Alex, try the new one.
I think I may have found out why it didn't work before.
This is just a hunch, but I think that VMware doesn't support
set 1, and the "get_current_set" command (0xF0), function 0x00.
It supports set 3, so why wouldn't it support set 1. It
may be my code though. Also, I can use command 0xF0
and set to 1, 2, or 3, but if I use 0, to get the current
set, the keyboard times out and doesn't send the set number.
Again, this could be my code, but my code works in Bochs
and real hardware. One of the machines I have doesn't
support function 0x00 of command 0xF0 either.
Again, this is just my current explanation. It could be my
code. I am going to draw up a little app, create a DOS 5.0a
disk and run it on that machine, plus make a new emulation
using the same DOS disk in VMware to see what it does. This
will eliminate my code from being the error (or point out
that it is :-).
Anyway, try the new image at the link above and see if it
works on your version of VMware. I have set the keyboard
to use set 2. Setting the keyboard to set 3 also works
in VMware Workstation 6.0, but doesn't work if I set it
to set 1.
Ben
Not to put you on the spot or anything, but if you've found some and can
legally release the info (i.e., not "owned" by an employer...), I'm sure a
few would thank you... Although there are probably some mentioned in
AMD/Intel errata, I haven't seen a "public" mention of serious x86 bugs
since the '94 Hamarsoft Bugs list or FDIV bug. And, there are always those
who would like to have a better understanding of how various x86 cpu's
actually work, and not just the way it is typically programmed.
Has anyone searched various programs, like Bochs, QEMU, Softx86, DOSBox,
Dosemu, for undocumented cpu errors or DOS calls? What about Mach's MDOS,
MAME's i86 (internal x86 emulator), or Minde (by Vassili Karpov aka malc)?
I've occasionally seen various DPMI hosts mention cpu bugs in there source.
Rod Pemberton
Yep, works now.
3 issues:
- barks at sequences sent by the arrow keys (doesn't like E0 or
somesuch)
- help is too long and I'm not sure if there's a way to see all of it,
not just the end
- it did find the HDD and probably recognized the FAT(32) but dir c:,
dir d:, dir e: didn't show anything about that disk.
Anyway, at least controllable now.
Alex
It depends on what one thinks is serious and on one's software where
the bug can occur. I hope no military, transport, medical or
construction software hits them... Looks like either those life-
critical devices aren't using intel/AMD x86 CPUs. If they are, I hope
the developers get better documentation and better tested chips,
though I have reasons to doubt it. And if they get what's in stock...
personally, I would not bet a buck about the resulting quality and
reliability. I'd rather stick with simpler hardware that hasn't
undergone many changes recently (got no new features/functions) and
has been thoroughly tested over a long period of time. There're a few
good sayings: "an old friend is better than two new ones" and "not
everything that glitters is gold".
> And, there are always those
> who would like to have a better understanding of how various x86 cpu's
> actually work, and not just the way it is typically programmed.
Well, they can get different versions of the manuals and see what
changed, not always towards the good. They will be amazed at what
happened to the documentation and how the documentation reflects the
hardware.
> Has anyone searched various programs, like Bochs, QEMU, Softx86, DOSBox,
> Dosemu, for undocumented cpu errors or DOS calls? What about Mach's MDOS,
> MAME's i86 (internal x86 emulator), or Minde (by Vassili Karpov aka malc)?
> I've occasionally seen various DPMI hosts mention cpu bugs in there source.
>
> Rod Pemberton
It's probably more true about all those DPMI hosts than about other
software because that's a long story and back in the DOS days there
were more x86 CPU brands than today, so it may very well be easier to
spot those bugs.
Alex
Hi Alex,
> Yep, works now.
Thanks for helping me out on that. I will still look into why
VMware doesn't like the get the current set command and why it
doesn't like set 1. *or*, if it is my code.
> 3 issues:
> - barks at sequences sent by the arrow keys (doesn't like E0 or
> somesuch)
Looking at that right now...Had a 'goto' where a 'break' should have
been.
> - help is too long and I'm not sure if there's a way to see all of it,
> not just the end
I have been meaning to create pipes so that you can do things like
dir | more
like DOS did. For now, here is the string it prints:
"\r\n ATTRIB Displays or changes file attributes."
"\r\n CD Displays the name of or changes the current directory."
"\r\n CLS Clears the screen."
"\r\n COPY Copies one or more files to another location."
"\r\n DATE Displays or sets the date."
"\r\n DEL Deletes one or more files."
"\r\n DIR Displays a list of files and subdirectories in a
directory."
"\r\n ECHO Displays messages, or turns command echoing on or off."
"\r\n EXIT Quits the CMD.EXE program (command interpreter)."
"\r\n FC Compares two files, and displays the differences between
them."
"\r\n FDISK Allows viewing and/or changing of the partition(s) on a
physical disk."
"\r\n FIND Searches for a text string in a file or files."
"\r\n FORMAT Format a logical disk drive."
"\r\n GUI Start the Graphical User Interface."
"\r\n HELP Provides Help information for commands."
"\r\n LABEL Label a logical disk drive."
"\r\n MD Creates a directory."
"\r\n MOVE Moves one or more files from one directory to another
directory."
"\r\n NETSTAT View the current status of the local network."
"\r\n NETVIEW View the current connected hosts on the local network."
"\r\n PATH Displays or sets a search path for executable files."
"\r\n PAUSE Suspends processing of a batch file and displays a
message."
"\r\n PING Ping a network name or ip address."
"\r\n PLAY Play an audio file given on command line."
"\r\n PLAYCD Play an audio cd, drive given on command line."
"\r\n PROMPT Changes the command prompt."
"\r\n RAMDISK Create a ram disk."
"\r\n REPAIR Repair a device/file system/etc."
"\r\n RD Removes a directory."
"\r\n REM Records comments (remarks) in batch files or CONFIG.SYS."
"\r\n REN Renames a file or files."
"\r\n SET Displays, sets, or removes environment variables."
"\r\n SETTINGS Allow modification of system.sys file."
"\r\n SHUTDOWN Shutdowns the machine."
"\r\n SORT Sorts input."
"\r\n TERM Local terminal using network or serial."
"\r\n TIME Displays or sets the system time."
"\r\n TREE Graphically displays the directory structure of a drive or
path."
"\r\n TRUENAME Displays the TRUENAME of a given filename."
"\r\n TYPE Displays the contents of a text file."
"\r\n VER Displays the version."
"\r\n VOL Displays a disk volume label and serial number."
"\r\n XCOPY Copies files and directory trees.";
Some work, some do not. Some work mostly, some work partly. :-)
> - it did find the HDD and probably recognized the FAT(32) but dir c:,
> dir d:, dir e: didn't show anything about that disk.
> Anyway, at least controllable now.
I think there is a bug in my FAT32 code. I had it working a while
back, changed something in my FAT12/16 code and then the FAT32 didn't
work any more. Must be a constant or a struct. I will have a look.
Thanks for your help. I do appreciate it.
Ben
Believe it or not, I've actually tried that. :)
I've noticed that. :) Thanks.
> > - it did find the HDD and probably recognized the FAT(32) but dir c:,
> > dir d:, dir e: didn't show anything about that disk.
> > Anyway, at least controllable now.
>
> I think there is a bug in my FAT32 code. I had it working a while
> back, changed something in my FAT12/16 code and then the FAT32 didn't
> work any more. Must be a constant or a struct. I will have a look.
You could use my imginit.exe to create a sample HDD image file with
various FAT partitions and put there some stuff with imgcpy.exe or use
some similar tools. Likewise, you could try my FAT test with your
code. I believe adapting it would be straightforward.
> Thanks for your help. I do appreciate it.
You're welcome.
Alex
That really surprises me. I programmed Stratus Continuums for a few years.
They're a fault tolerant machine with two of everything operating in
parallel - drives, network, power supplies, cpu's, main memory, etc. -
everything. I had a class with them just after they stopped developing for
the PA-RISC and started developing for the x86. I got to talk with various
employees. For fault tolerance, they were using two Intel chips which were
checked for sync by custom circuitry. My understanding is that the
circuitry compared the state of all cpu pins on a per clock basis. If they
were different, fault. When they first started using x86 chips,
occasionally the two cpu's would fault. They had also done this with the
PA-RISC without experiencing faults. But, when the x86's were done executing
a code section, they always had the same result, i.e., no computational
errors. Intel engineers worked very hard to find the problem. It was
supposedly a slight timing variation in one of the cpu pipelines.
Obviously, this dealt with the external effects of the cpu, but, being in
the fault tolerant processing business, I'm sure Stratus did just as extreme
and intensive internal register and instruction tests. Since they worked
closely (and probably still do) with Intel, the implication that the x86
cpu's have many problems is quite striking to me. I can understand not
using them for military. (Although, AMD or Intel probably have products for
the market.) For military, you want them to be radiation hardened, use
static memory for cache and registers, have error correction internally, and
have other special features.
Rod Pemberton
I have a fat32 image, though to continue with the thought
of another thread, I should test it with an image made
by imginit.exe for multiple test beds. I think I have a
few small things to do with my FAT12/16 code also, so maybe
it is a good idea to get back to it and test it.
Thanks.
Ben
> You could use my imginit.exe to create a sample HDD image file with
> various FAT partitions and put there some stuff with imgcpy.exe or use
> some similar tools. Likewise, you could try my FAT test with your
> code. I believe adapting it would be straightforward.
Hi Alex,
Since you use VMware and you make fat partitions with the above
mentioned tool, do you have VMware using these created partitions
as virtual disks? If so, how.
I read through the manual and tried everything I could think of
to get VMware to use my .img file(s).
I thought that I would have to find the format of the virtual
files it uses and modify my .img file to make it work.
Just thought I would ask if you had a way that you were doing
this.
I will see if I can find something on their forum too.
Thanks,
Ben
Yes and no. :) The 1.44MB/3.5" floppy disk images are the same thing
in both places (my tools and VMWare and pretty much everywhere else)
-- there's nothing stored in them but the raw sector data.
The HDD images, however, are different: mine are also raw sector data
and it's expected that the sectors per track and tracks per cylinder
are maxed out (that is, the geometry is: 63x256xCylinderCount). These
raw images are used in the test. This geometry is hardcoded in the
tool, see: image.c/BIOS_GetDriveParameters() and imginit.c/main() and
variables of type tImageDescriptor and tExtendedPartition.
I did run FATCMD under VMWare with VMWare's HDD images, which I
created with help of DOS. I did not convert the images.
> I read through the manual and tried everything I could think of
> to get VMware to use my .img file(s).
>
> I thought that I would have to find the format of the virtual
> files it uses and modify my .img file to make it work.
I think the format should be out there on the web. If it's not, I
believe you can create a VHD image file whose format has been both
published by MS and supported by VMWare (in the opposite order :).
> Just thought I would ask if you had a way that you were doing
> this.
Nothing special. It was enough for me to use my "simple" images to
find most of the bad bugs and some of the few compatibility issues
(mostly FAT32) were resolved by running DOS 7 and scandisk after
running my code.
> I will see if I can find something on their forum too.
Sure.
Alex
Hi Alex,
As you know, VMware Workstation will read a 1.44meg floppy
image just fine, however, I was hoping there was a way
to get it to read a HDD image that wasn't created within.
I went looking and VMware will send you a link to the
.vmdk format specs if you fill out this little form first.
I got it last night and will have a look this evening.
Thanks,
Ben
I use VMWare Player and I have 2 config files, kielder.vmx
and kielder.raw. kielder.vmx is the main config file,
kielder.raw describes the format of the hard drive image.
To change boot order you have to go into the VM's bios.
VMWare has several hard drive formats, such as sparse
and flat images and are specified in the raw file. I use
a flat image.
I create my unpartitioned/unformatted images with
bximage.exe that comes with Bochs, it can be run from
the desktop.
A few sites like allbootdisks.com have MS-DOS floppy
images which I use for to partition my images with fdisk
and format.
Google for some of the keywords in the raw file should
give some explanation of the fields.
kielder.vmx looks like...
config.version = "8"
virtualHW.version = "4"
displayName = "KielderOS"
guestOS = "winxppro"
memsize = "64"
ide0:0.present = "true"
ide0:0.deviceType = "disk"
ide0:0.fileName = "kielder.raw"
floppy0.present = "true"
floppy0.fileName = "floppy.img"
floppy0.fileType = "file"
floppy0.startConnected = "false"
usb.present = "false"
sound.present = "false"
uuid.location = "56 4d 58 ff 2a ff de a4-c4 cf 49 e2 e4 ab 6f 77"
uuid.bios = "56 4d 58 ff 2a ff de a4-c4 cf 49 e2 e4 ab 6f 77"
checkpoint.vmState = ""
ide0:0.redo = ""
tools.remindInstall = "TRUE"
logging = "FALSE"
kielder.raw looks like...
# Disk DescriptorFile
version=1
CID=b4e6f8e8
parentCID=ffffffff
createType="monolithicFlat"
# Extent description 65520 = 63 * 16 * 65
RW 65520 FLAT "harddrive.img" 0
# The Disk Data Base
#DDB
ddb.toolsVersion = "0"
ddb.adapterType = "ide"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "16"
ddb.geometry.cylinders = "65"
ddb.virtualHWVersion = "4"
--
Marv
Congrats Ben! I just tried the Aug 5 image. My main machine boots (which
always hung before) and makes it to command prompt.
'type' of some .txt file you had there works. 'dir' works. 'test16.exe' ran.
'test32.exe' ran.
ctrl-alt-del complained about E0...
I'm sure it's normal, but it didn't recognize my C: (FAT32) or D: (FAT16 on
same drive).
Of course, the old 32Mb machine gives an error message saying it needs 48mb.
Another problem I noticed was that install.com doesn't write exactly the
same image as rawrite.
Test1:
1) install.com - wrote image to disk, under Win98SE
2) rawread.exe - read disk to image, under Win98SE
3) fc/b - both images _aren't_ the same
Test2:
1) rawrite.exe - wrote image to disk, under Win98SE
2) rawread.exe - read disk to image, under Win98SE
3) fc/b - both images are the same
Also, the boot image on disk, doesn't seem to be recognized as a DOS disk.
dir A: "Not ready reading drive A. Abort, Retry, Fail." That's what I
usually use to tell the disk is "blank", unless I've labelled it Linux...
Rod Pemberton
Thanks Marv, I will have a look.
Thanks.
> 'type' of some .txt file you had there works. 'dir' works. 'test16.exe'
> ran.
> 'test32.exe' ran.
I forgot I had those two in the image. :-) They are the start of the
multitasking. Currently, FYSOS is a single tasking, multithreading OS.
> ctrl-alt-del complained about E0...
Yep, I haven't worked on that combination yet.
> I'm sure it's normal, but it didn't recognize my C: (FAT32) or D: (FAT16
> on
> same drive).
It should have recognized the FAT16 with no problem, and the FAT32
at least should have been enumerated. I am currently working on the
FAT stuff to get all three types complete.
> Of course, the old 32Mb machine gives an error message saying it needs
> 48mb.
Yep. :-) Unfortunetly, FYSOS requires at least 48meg.
> Another problem I noticed was that install.com doesn't write exactly the
> same image as rawrite.
>
> Test1:
> 1) install.com - wrote image to disk, under Win98SE
> 2) rawread.exe - read disk to image, under Win98SE
> 3) fc/b - both images _aren't_ the same
>
> Test2:
> 1) rawrite.exe - wrote image to disk, under Win98SE
> 2) rawread.exe - read disk to image, under Win98SE
> 3) fc/b - both images are the same
UUhhmm. I wonder why. I will get rawread/rawwrite (John Fine's, correct)
and have a look.
> Also, the boot image on disk, doesn't seem to be recognized as a DOS disk.
> dir A: "Not ready reading drive A. Abort, Retry, Fail." That's what I
> usually use to tell the disk is "blank", unless I've labelled it Linux...
And it shouldn't be. It is formatted with the LEAN FS. Unless something
changes, I have the LEAN FS as my default FS on all volumes including
floppies that I do not intend on taking to a DOS/Linux machine.
Thanks for the tests. I will have a look at their results.
Ben
Nope, his is Partcopy. I bet it will work and give me the
same results though. How long is your text file if you redirect
the outcome? If not to long, could you send it to me? Address
above, remove the zzzz's.
Thanks Rod.
Ben
I wasn't writing the last cylinder to the disk. Your compare
file should start at offset 163800h and go to 167FFFh with
differences, yes?
Now the install writes the last cylinder. I will include the
new install.com with the next release.
Thanks for catching it,
Ben
Yes basically, 163800h to 167e74h are different.
It used to hang with the PCI device enumeration. Obviously, you fixed
something?
Also, are you still using "unreal" mode? If so, alot or little? Was the
A20 the only thing that had problems in "unreal" mode?
Rod Pemberton
> my LEAN FS implementation, as well as more advancements in
you want we send you a file with the result of the test, but thatæ„€
not possible since you use a strange filesystem.
I apologize. I forgot to include the FAT parameter in my
last build. I have uploaded the image as a FAT12 FS, or you could
simply use GETIMG from
http://www.frontiernet.net/~fys/mtools.htm
or your favorite tool and send me the image of the LEAN FS
disk you used before.
Thanks for testing FYSOS. I will anticipate your findings.
Ben
I take that back. For some reason the FAT12 and FAT16 boots
don't work. Something is wrong here. I must have done something
to break the build. Sorry for the waste of your time. I will
look into it.
Ben
Okay. Found a small, but disastrous bug. Now fixed, and have
the FAT12 image posted.
Thanks again, and sorry for the inconvenience.
Ben
Hi octavio,
Sorry for the late reply. The keyboard was not detected, huh?
I wonder if it is due to the portable's hardware's emulation of
a PS2 keyboard. I have a portable (a "laptop", here in the states)
and will try it there.
I am guessing since the keyboard was not detected, it didn't
go any further and you meant to say that "no new file was
written"?
Thanks,
Ben
Dl'd next version of FYSOS.
0) Sigh, didn't answer questions above...
1) Install.com says "successfull", extra 'l'
2) Install.com updates it's track count +2. However, I hear the floppy
heads move twice per +2... How about +1 to match floppy sounds?
3) Found my FAT32 partitions. 'dir' works.
4) Do you have plans to add a cursor?
5) ctrl-alt-del still doesn't work. No wierd error message now.
I didn't take a close look, but dir seemed to list everything in lower case.
Is it just lower case or LFN?
Rod Pemberton
Hi Rod,
>> Also, are you still using "unreal" mode? If so, alot or little? Was the
>> A20 the only thing that had problems in "unreal" mode?
>
> Dl'd next version of FYSOS.
>
> 0) Sigh, didn't answer questions above...
I use real mode to boot and load the loader file.
Then I jump to the loader file, do a few things
in real mode, then move to unreal mode to load a
list of files including the kernel above the
1 meg mark. Once this is done, and I have a few
other items done via the BIOS, I move to pure pmode.
I don't go back to unreal mode at all. I do, however,
have a working v86 task which I use to change
the screen mode and a few other items.
> 1) Install.com says "successfull", extra 'l'
:-) It use to be "successfully". Dropped the 'y', forgot the 'l'.
> 2) Install.com updates it's track count +2. However, I hear the floppy
> heads move twice per +2... How about +1 to match floppy sounds?
I hear two head movements per 2 count increments. I am not sure,
but I think it is the OS's read/write ahead cache. It doesn't
write the first cylinders worth of data to the floppy since it
is only 18k, but then on the second cylinder it is more than 32k,
so it then writes them both. I have not tried it, but I would bet
in Pure DOS, the install would increment once per "noise".
> 3) Found my FAT32 partitions. 'dir' works.
Good.
> 4) Do you have plans to add a cursor?
Yes :-). I have it already coded. I just have it turned off for
the moment.
> 5) ctrl-alt-del still doesn't work. No wierd error message now.
I have re-written my keyboard code and now should be able to easily
"catch" the scan code for ctrl-alt-del. I just haven't done it yet.
> I didn't take a close look, but dir seemed to list everything in lower
> case.
> Is it just lower case or LFN?
LFN. I would bet that all of the filenames on the FAT32 disk
have LFN lowercase names. Try making a file with a mixed case
filename and see what happens. Uummm, I haven't tried FYSOS to
create a file yet, why not? It never came around I guess. Use
your host OS to create a mixed case filename, then try again.
Thanks for the comments,
Ben
I merged in a new topic at the top and replies to the prior post after it...
Thanks for the AOD FAQ cleanup. "fys" is you, correct? If you couldn't
tell, I was converting from C somewhat poorly... The following might be too
"advanced" for the front page of the FAQ, but I think it is important.
I noticed that your example switches to register A. If you're wondering why
I was using port D, this Riemersa's article indicates that:
1) the BIOS doesn't reset the RTC
2) the RTC to should be set to register D after any read or write
3) the RTC could be corrupted if read or writes to RTC without NMI
disabled
"Periodic Interrupts with the Real Time Clock" by Thiadmer Riemersa
http://www.compuphase.com/int70.txt
The "why" behind 2) wasn't explained other than to say the CMOS shouldn't be
allowed to become corrupt.
This guy quotes the "Model 30-286" instruction manual:
http://groups.google.com/group/comp.sys.ibm.ps2.hardware/msg/dec4674214e2393e?hl=en
In it, the manual says the index should be left set to register D - again no
explanation. It also says disabling NMI should have a jmp for I/O delay...
Also, this thread indicates that Linux 2.4.20 had problems with the RTC
under kernel bug and/or powerfail conditions. Their solution was to set the
index to register D:
" /*
* The yet supported machines all access the RTC index register via
* an ISA port access but the way to access the date register differs ...
+ * Modified 18-JUL-2003
+ * Willy Tarreau <wi...@w.ods.org>, Richard Johnson <rjohn...@analogic.com>
+ * Leave index register at status register D so a power failure doesn't
+ * corrupt checksummed CMOS. Keep NMI bit enabled (in case it really
exists).
*/ "
http://groups.google.com/group/fa.linux.kernel/msg/1c707e749cf6e94f?hl=en
http://groups.google.com/group/fa.linux.kernel/msg/f4eeadee2e92223?hl=en
In summary, possible changes:
1) register D
2) I/O delay on NMI disable
3) cli prior to NMI disable
> I use real mode to boot and load the loader file.
> Then I jump to the loader file, do a few things
> in real mode, then move to unreal mode to load a
> list of files including the kernel above the
> 1 meg mark. Once this is done, and I have a few
> other items done via the BIOS, I move to pure pmode.
> I don't go back to unreal mode at all. I do, however,
> have a working v86 task which I use to change
> the screen mode and a few other items.
>
Was A20 on my machine the only thing that problems in unreal mode?
> > 2) Install.com updates it's track count +2. However, I hear the floppy
> > heads move twice per +2... How about +1 to match floppy sounds?
>
> I hear two head movements per 2 count increments. I am not sure,
> but I think it is the OS's read/write ahead cache. It doesn't
> write the first cylinders worth of data to the floppy since it
> is only 18k, but then on the second cylinder it is more than 32k,
> so it then writes them both. I have not tried it, but I would bet
> in Pure DOS, the install would increment once per "noise".
>
Ancient C64 "creepies" I guess. You hear the hardware doing something the
software didn't show it was doing...
> Try making a file with a mixed case
> filename and see what happens. Uummm, I haven't tried FYSOS to
> create a file yet, why not? It never came around I guess. Use
> your host OS to create a mixed case filename, then try again.
>
I really didn't test much.
The two machines I've got assembled right now are my main machine and the
one with 32Mb... I've got no problem with all out testing on the 32Mb
machine. Unfortunately, I don't think have any larger memory modules
(packed away at the moment) and not sure if I could find that style of
memory today. I'm sure your code is reliable enough, but I'd rather not
take too many chances with my main machine at the moment. My critical files
are backed up, but a simple fs corruption could still cause me some problems
(been there, done that, didn't like it... It was early Linux btw...). I'm
extremely slowly acquiring parts to build a new machine. So, the main
machine will eventually become a nice little test machine.
Rod Pemberton
Okay.
> Thanks for the AOD FAQ cleanup. "fys" is you, correct? If you couldn't
> tell, I was converting from C somewhat poorly... The following might be
> too
> "advanced" for the front page of the FAQ, but I think it is important.
>
> I noticed that your example switches to register A. If you're wondering
> why
> I was using port D, this Riemersa's article indicates that:
[ Snipped info about why we should use port D. To see the info ]
[ and the links, see previous post. ]
I did not know this. Thanks. I will research the information you
posted.
>> I use real mode to boot and load the loader file.
>> Then I jump to the loader file, do a few things
>> in real mode, then move to unreal mode to load a
>> list of files including the kernel above the
>> 1 meg mark. Once this is done, and I have a few
>> other items done via the BIOS, I move to pure pmode.
>> I don't go back to unreal mode at all. I do, however,
>> have a working v86 task which I use to change
>> the screen mode and a few other items.
>>
>
> Was A20 on my machine the only thing that problems in unreal mode?
I think so.
I don't blame you. I don't test FYSOS on my flagship either.
I currently only have three machines up and going. The rest
or stored away due to a recent move. As soon as I get everything
settled I will get them back out.
Thanks for your comments,
Ben
I found just a tidbit more about the delay. For the NMI delay, the link
below says that this should be used:
mov al,0ffh
out 4fh,al
instead of:
jmp $+2
saying it causes some cpu's flush I/O... I'm not sure if the rational is
completely correct, but it's definately easier to code in C.
http://groups.google.com/group/comp.sys.ibm.ps2.hardware/msg/481f6ccd4f909b06?hl=en
Rod Pemberton
Hi Rod,
> I found just a tidbit more about the delay. For the NMI delay, the link
> below says that this should be used:
>
> mov al,0ffh
> out 4fh,al
>
> instead of:
>
> jmp $+2
>
> saying it causes some cpu's flush I/O... I'm not sure if the rational is
> completely correct, but it's definately easier to code in C.
Don't know about CPU I/O flush, probably so, but haven't read about it.
The reason you shouldn't use
jmp $+2
now a days is that the CPU simply optimizes it out and doesn't take
a single cycle at all. i.e.: no delay what-so-ever.
My notes say to use the following...well I can't find that particular
note at the moment. However, it says to use port EBh or something like
that for IO delay. Port does nothing but cycle the bus.
Anyway, I will update the NMI code on the aodfaq as soon as I can
get around to it.
Thanks for your comments.
Ben
P.S. Since here in the States, last Monday was a holiday, I decided
to do some more work on FYSOS. I got back to my DOS emulation code.
FYSOS now will emulate a lot of DOS apps. FYSOS emulates everything.
The BIOS is not called, except for the video mode change.
It still needs some work, but I spent a bit of time on it. Now, if
I can get another holiday... :-)
I also added some features to the LEAN FS and sent them to the
author. As soon as he replies with an approval, the LEAN FS will
support Extended Attributes.
Ben
Cool...
Is this 16-bit or 32-bit? Mixed? How the performance vs. ...? say DOSBOX?
Reminds me a bit of what Paul Edwards claims PDOS should do. I haven't
tried his OS since I couldn't find binaries a while ago. Maybe he has some
now - I don't know. Haven't seen a post from him in a while either...
Unfortunately, Freedos-32 seems stalled. No updates in almost two years
now. I think it was trying or partially succeeded exec'ing DJGPP DPMI apps.
If I ever get there and if I continue in the direction I've been going (I'm
considering a serious change or two, maybe three...ugh.), mine should run
the 32-bit portion of DJGPP and OW DPMI applications...
Anyway, if you happen to have a link to anything more about safely setting
the RTC index, please post. I'm still a bit unsure about some of the
sources and have no way to actually test NMI. So, I've been coding stuff I
can't confirm works, other than it won't hang...
Rod Pemberton
V86. All of the system code is 32-bit pmode, and the DOS app is ran
in virtual x86 mode. FYSOS catches all INT's, PUSHF/POPF's, all things
pertaining to the system. It also catches all port I/O that is no
permissable. You know, a typical Virtual x86 machine.
All hardware IO is done via the 32-bit kernel. Really, as far as the
user is conserned, there is no difference between a DOS app being emulated
and a true FYSOS 32-bit pmode app. The user doesn't have to switch
between "sessions" or the other.
I have not ran DOSBOX so I do not know. I am sure that FYSOS is
considerably
slower since I have not optimized anything and I check for more errors and
make sure that passed data is correct.
> Reminds me a bit of what Paul Edwards claims PDOS should do. I haven't
> tried his OS since I couldn't find binaries a while ago. Maybe he has
> some
> now - I don't know. Haven't seen a post from him in a while either...
I saw a post for PDOS about 3 months ago, IIRC. Haven't seen must
else though.
> Unfortunately, Freedos-32 seems stalled. No updates in almost two years
> now. I think it was trying or partially succeeded exec'ing DJGPP DPMI
> apps.
I like the LEAN FS that goes along with it though. It is still a
linked cluster chain type FS, but I still like it. Matter of opinion
I guess. I think it will be my default FS for FYSOS.
> If I ever get there and if I continue in the direction I've been going
> (I'm
> considering a serious change or two, maybe three...ugh.), mine should run
> the 32-bit portion of DJGPP and OW DPMI applications...
Good.
> Anyway, if you happen to have a link to anything more about safely setting
> the RTC index, please post. I'm still a bit unsure about some of the
> sources and have no way to actually test NMI. So, I've been coding stuff
> I
> can't confirm works, other than it won't hang...
I will.
Thanks,
Ben
(1) Keyboard Make/Break Scan Codes
(2) 8042 Keyboard Controller
(3) Make/Break System Scan Code
(4) INT 09h
BRANCH TO SECOND TIER OF STEPS
(5) Check Shift/Toggle State Flags / Internal Function Requests
(6) 16-bit Character Codes
BRANCH TO THIRD TIER OF STEPS
(7) INT 16h
(8) 84-key Filter?
(9) DOS or Applications Software
Don't know if this helps at all but I pulled it out of a
Phoenix Technical Reference Series, System BIOS For IBM (R)
PC/XT(TM)/AT(R) Computers And Compatibles (published 1987,
1988, 1989, Chapter 8, pp. 121-160).
Chapter 8 seems dedicated to the keyboard and INT 09h/16h.
"The ROM BIOS contains two keyboard-related services, a
Keyboard ISR and a Keyboard DSR:
* Keyboard ISR
The BIOS Keyboard Interrupt Service Routine (ISR) is invoked
via hardware INT 09h each time a key is pressed. The BIOS
Keyboard ISR processes keyboard data and converts it into
information that is useful to the system. In most cases, this
conversion results in the Keyboard ISR placing a two-byte
character code into a keystroke buffer located at 40:1Eh in
low memory.
* Keyboard DSR
The BIOS Keyboard Device Service Routine (DSR) is invoked via
software INT 16h. The BIOS Keyboard DSR provides an interface
through which the operating system or application software can
interface with the keystroke buffer. The Keyboard DSR contains
functions that read the BIOS keyboard buffer, write to the buf-
fer, return the status of the buffer, and so on."
If the problem hasn't been fixed yet, and perhaps there's some
way to help out, just ask.
--
Jim Carlock
North Carolina Swimming Pool Builders
http://www.aquaticcreationsnc.com/
Hi Jim,
The above is pretty close to what I do. The problem I was having
before is that different keyboard hardware acts differently and
I wasn't waiting long enough for one item, I used a different
enable/disable for another keyboard, etc. Also, I was using
scan code set 1, when the keyboard only supported set 2, or visa
versa.
I had working code, it just wasn't "generic" enough to work on all
keyboards. It may still not.
Anyway, the above is just about what I do. I have the ISR
send the key codes, then the DSR as you call it above, translate
it to scan codes, shift states, etc. This is were I will also
handle the Ctrl-Alt-Del sequence. I haven't got around to it,
but a simple, "call reboot_routine" will be close to all I need.
Anyway, thanks for the comments,
Ben
I wondered how you handled the coding of the keyboard. The text
in the previous post about the "ISR/DSR" came straight from the
Phoenix BIOS Manual and was not my creation. I could not find a
link to your source code or the binary code. Is that available?
--
Jim Carlock
Swimming Pool, Spa And Water Feature Builders
http://www.aquaticcreationsnc.com/
The binary as at
http://www.frontiernet.net/~fys/fysos.htm
while the source is not yet available. I know, I'm just that way :-)
My code reads a single byte at a time. It keeps a buffer of previous
bytes. Once a valid sequence of codes have come across the wire, it
calls the DSR, the routine to change the key code to scan codes, calls
the ctrl-alt-del routine, etc. If a byte comes across the wire that
breaks the current sequence, it barfs a message, resets the buffer
and makes ready for a new sequence of bytes.
When I say, breaks the current sequence, I mean that the current
sequence of bytes is not a know valid sequence for set 1, 2, or 3
depending on which set I am expecting sequences for.
Hope this helps,
Ben
Set 2 XT to AT? What happens if the sequence is interleaved?
E.g., Numlock on and typing Up-Arrow followed by a Shift _before_ the
Up-arrow sequence completes. I get various unstable responses:
// E0 2A E0 48 E0 48 E0 AA 2A E0 C8 AA
// E0 2A E0 48 E0 48 E0 AA 2A AA E0 C8
// E0 2A E0 48 E0 2A E0 48 E0 48 E0 AA 2A AA E0 C8
What about shift 2A/AA reversal?
E0 2A E0 48 E0 C8 E0 AA
2A E0 AA E0 48 E0 C8 E0 2A AA
Rod Pemberton
Hi Rod,
I thought I would have some time to do something with this, then
reply with results. At the moment I don't, so just a reply
is all you get :-)
I will look into this as soon as I get the time. This weekend
maybe.
Thanks,
Ben
...
> Set 2 XT to AT? What happens if the sequence is interleaved?
> E.g., Numlock on and typing Up-Arrow followed by a Shift _before_ the
> Up-arrow sequence completes. I get various unstable responses:
> // E0 2A E0 48 E0 48 E0 AA 2A E0 C8 AA
> // E0 2A E0 48 E0 48 E0 AA 2A AA E0 C8
> // E0 2A E0 48 E0 2A E0 48 E0 48 E0 AA 2A AA E0 C8
> What about shift 2A/AA reversal?
>
> E0 2A E0 48 E0 C8 E0 AA
> 2A E0 AA E0 48 E0 C8 E0 2A AA
My solution is to ignore the break code and set the KEY-pressed flag
on received and completed make-codes only, but optionally (for games)
a KEY-released flag can be activated as well. I never had any problems
with my keybd, except my fingers became a bit glumpsy with age :)
__
wolfgang
Thanks. Again, sorry to Ben, this applied to my keyboard as I was
developing my OS drivers.
Rod Pemberton
Really sorry! I rewrote the post and removed part of it that should've been
left in. This didn't apply to your OS. It was my experience with my
keyboard when writing my OS. I was wondering if you saw something similar
when developing your drivers.
Rod Pemberton