You know, I just had a thought folks. Maybe FreeDOS should have been a 64 bit version right from the start. Why couldn't a 386 mode OS be written that looked and behaved like real mode DOS be written? You'd need some kind of low order shell to have backward compatibility with real mode stuff. but WIndows XP and 7 do this. But otherwise it would allow access to all the RAM and drive space and likely good task switching too for things like browsers, which I hear was a pain in the ass for FreeDOS. I might straighten out some issues like the one we discussed here.
How hard would it be? A lot would just have to be recompiled with right compiler. Whatever happened to the source code for VAX-VMS? Who owns that now? It might have a lot of the work already done. I might be public domain or cheap. Looked it up. Interesting? I wonder how much? http://en.wikipedia.org/wiki/OpenVMS Ported to Intel Itanium http://en.wikipedia.org/wiki/Itanium Doable I guess but how many person years for a 64 bit FreeDOS? Who's up for it? I don't think I have time left in my life for such a project. Charlie B. On 3/26/14, Charles Belhumeur <chbelhumeur2...@gmail.com> wrote: > Is there a reason you have to use that specific mouse hardware? > > Or is this just hobby wanking to kill time and learn some stuff? > (I've done my share back in the day.) > > I guess I should make this point for all the FreeDOS community. > This is kind of characteristic of DOS back in the old days. I've seen > other problems posted here like this where this or that piece of hardware, > driver, app etc. Back in the day it happened all the time. There were > even > proprietary versions of DOS like COMPAQs with different hardware calls. > We also has a mish mash of third party hardware extensions with everyone > trying to one up the other with this or that tweak. The shit wasted > decades > of our lives. The way we solved these problems was forget about that piece > of hardware, driver, app, etc that didn't get along with your working > system. > Find another "IBM compatible" clone that worked and use that. We didn't > have > any alternative platforms and were just happy to have a box where the > drives, > display, mouse and keyboard worked and we could get one with "comput"in". > Sound cards when they came along were just a nightmare for awhile. A whole > new set of protocols to try to get good old "duh" simple minded DOS to > accept. > > And you developed some experience and expertise in this along with your > user > group. This brand usually didn't get along with this or that. Don't > stack the drivers > that way etc..I don't think anyone ever got a TV tuner card to run > right in an IBM clone > with DOS or for very long if it did. The 1940s analog tech really > didn't being in digital box. > > But I digress. The point I'm making is DOS is a "duh" dumb as a stick > OS. That's > the appeal if any these days, the simplicity. So trying to get modern > sophisticated hardware, drivers, apps, etc to get along with good old > simple DOS is going to be difficult > at best and likely impossible in some cases. We all learned the hard > way back in the > day where there comes a point when you have to say... OK I've spent > enough hours trying > to get this to work. Its time to try something else or forget about > this project. > > For example, its possible your problem is somewhere in dumbing down 32 or 64 > bit > USB to 16 bit DOS a byte is being lost. Maybe 16 or even 48 bits is > being discarded > entirely in the cast from higher to lower words. Depends on the > compiler and how it was > coded in the source code. Its likely its all 64 bit to the CPU and > gets cast by the real > mode its running in to 16 bit. Might be real tricky and laborious > coding getting a > USB bus into a Pentium chip to keep all the bytes, register shifts, > bitwise ops and the > like. Maybe need specs on the Pentium to write correctly. > > Good luck! Everyone keep in mind what I say about DUH DOS and the modern > stuff. > > Charlie B. > (loving it and hating it since I took my first CS class in 1981 > writing BASIC on DEC PDP-11) > (paper only IO in those days, DECWriter terminals. Look up pics > specs of the sys) > > On 3/25/14, Christoph Nuscheler <christoph.nusche...@t-online.de> wrote: >> Hello, >> >> I'm writing straight away to the development list, because I think I'll >> have to do some coding to fix my problem: >> >> My system is a Pentium MMX PC/104 board. Its BIOS does a pretty good job >> in providing PS/2 access to USB keyboards and mice in DOS. For example, >> a wireless KeySonic ACK-540RF keyboard/touchpad combo works absolutely >> flawlessly using CuteMouse. >> >> However, connecting the Ortek PKB-1760 wireless keyboard/trackball combo >> to the system causes problems: CuteMouse recognizes the PS/2 mouse >> without issues, but the behaviour is totally off: >> Horizontal motion (X) of the trackball moves the cursor vertically (Y). >> Vertical motion (Y) of the trackball does nothing. >> Clicking the buttons stepwise moves the cursor to the right (+X). >> The touch scroll bar does nothing. (It doesn't need to, anyway.) >> >> Note: I tried several if not all of the command line switches. Also I >> ran the original Microsoft and Logitech mouse drivers which produced the >> same result. >> >> So I suspect, instead of the normal PS/2 protocol sequence: >> >> 1st byte 2nd byte 3rd byte >> +---------------+ +---------------+ +---------------+ >> |?|?|Y|X|1|M|R|L| |X|X|X|X|X|X|X|X| |Y|Y|Y|Y|Y|Y|Y|Y| >> +---------------+ +---------------+ +---------------+ >> >> the trackball produces something non-standard like this: >> >> 1st byte 2nd byte 3rd byte 4th byte >> +---------------+ +---------------+ +---------------+ +---------------+ >> |?|?|?|?|?|?|?|?| |?|?|Y|X|1|M|R|L| |X|X|X|X|X|X|X|X| |Y|Y|Y|Y|Y|Y|Y|Y| >> +---------------++---------------+ +---------------+ +---------------+ >> >> >> What I want to try out: Modify the CuteMouse source code so it discards >> the first byte, and reads a fourth byte from PS/2. >> >> I already got my JWasm set up to build CuteMouse. I claim to know my way >> around X86 assembly, but reading and comprehending someone other's code >> is a different story. ;-) >> >> I would be grateful for any hints in modifying the PS/2 routines in >> CuteMouse. >> >> Thanks, >> >> Christoph >> >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and >> their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/13534_NeoTech >> _______________________________________________ >> Freedos-devel mailing list >> Freedos-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-devel >> > ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
