Date: Sun, 22 Jun 1997 21:12:17 -0800 (AKDT) From: Steve Howe <un_x@anchorage.net> Cc: freebsd-hackers <hackers@FreeBSD.ORG> Subject: Re: direct access Message-ID: <Pine.BSF.3.95q.970622201506.17548B-100000@aak.anchorage.net> In-Reply-To: <199706230209.LAA14132@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> > i wanted to port a hex/block editor from DOS. > This is not a very useful thing to do. There are several quite good hex > editors already in the ports collection. I use 'beav' more often than hehe! it's useful to me, hehe, it's mine! and i like it! :) > > it can read/write 1 RAM blocks > > 2 Port Addresses > > 3 Hard/Floppy Drives > > 4 Files > A user process on any Unix system cannot easily edit 1, 2 or 3. that's what i'm finding out. but i want all the direct access and speed i can get. how low-level can i get? i'd like the "driver" level. is there specific documentation (other than source) about it? what's /dev/io all about? i have all the libraries i need for coding, all i need is a few simple low-level i/o routines moved to UN*X, namely VGA-i/o, RAM-i/o, PORT-i/o, and DISK-i/o. for example, i need char i/o to the vga screen. i need to put a colored char on the screen at a fixed position, and read the color and char at a position. thanks to r.nordier, i got ncurses going, but it is too slow - i have to "refresh" too often. i want access to the lowest level. my code already exixt, except at the lowest level of i/o. i have alot of hardware diagnostics i would like to run on my freebsd boxes. > > unsigned char * p = (unsigned char *)0x000b8000; > You cannot directly access the physical address 0x000b8000. is that an absolute? no peek-ing or poke-ing ... at all? > This virtual:physical mapping provides numerous benefits - processes > can be moved around in memory with impunity simply by changing their > mappings and copying the physical pages. The mapping process also > allows for virtual addresses not to be mapped to a physical address, > and when an access occurs, the kernel catches the trap and can take > such steps as copying the page in from disk, or performing a mapping > as required. > What is a "device editor"? hehe. something that allows you to perform visual i/o on any device in a system - ? :) > You don't want to edit display memory; that will make the console > driver unhappy. With the appropriate level of privilege you can use a > binary editor on the disk devices in /dev and thus edit raw disk data. > "editing" device ports doesn't seem to be terribly useful to me. as far as ram goes, i like to watch whats going on in physical ram to learn about systems. as far as drives go, file recovery - searching for deleted HD data, which i desperatley need, as far as ports go, the code i'd like to port, detects and debugs certain devices. > ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ > ]] Genesis Software genesis@gsoft.com.au [[ > ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ > ]] realtime instrument control. (ph) +61-8-8267-3493 [[ > ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ ------------------------------------------------- FingerPrint BA09868C 1B995204 58410FD3 A5E7B2DA http://www.geocities.com/siliconvalley/way/7747 -------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970622201506.17548B-100000>