Peek/Poke Low-Level parallel-port/memory/video-buffer/keyboard-buffer?
ForNext Jones Jr.
Using PC CC 5.0 (and possibly some sort of addon) can I get past the
barriers that Windows XP puts between me and the bare metal? On my
old Commodore 64 I could POKE things into the keyboard buffer and
exit, making the C64 think someone typed a command. I could PEEK
and POKE any part of memory, including the screen buffer, and I
could directly control I/O such as the printer or serial port.
(I needed add-on hardware to get a real parallel or serial port,
but you get the idea...)
Can I get this kind of control with PowerBasic Console Compiler 5.0?
How about FreeBasic?
A buddy at work says that I will never get past the barriers that
Windows puts up and that I should switch to Linux and learm Python.
Stefan Pendl
<nob...@home.com> wrote:
>
>
>
>Using PC CC 5.0 (and possibly some sort of addon) can I get past the
>barriers that Windows XP puts between me and the bare metal? On my
>old Commodore 64 I could POKE things into the keyboard buffer and
>exit, making the C64 think someone typed a command. I could PEEK
>and POKE any part of memory, including the screen buffer, and I
>could directly control I/O such as the printer or serial port.
>(I needed add-on hardware to get a real parallel or serial port,
>but you get the idea...)
>
>Can I get this kind of control with PowerBasic Console Compiler 5.0?
>
Windows does not use static memory allocation like the C64 has used.
There are Windows API calls available to simulate keyboard events and
to access the display memory of a window or the screen.
You need to understand that things have changed in a way, that made
PEEK and POKE obsolete.
---
Stefan Pendl
Windows XP Pro SP 3
Celeron M 1.3 GHz
752 MB DDR RAM
Marc 'BlackJack' Rintsch
> Using PC CC 5.0 (and possibly some sort of addon) can I get past the
> barriers that Windows XP puts between me and the bare metal? On my old
> Commodore 64 I could POKE things into the keyboard buffer and exit,
> making the C64 think someone typed a command. I could PEEK and POKE any
> part of memory, including the screen buffer, and I could directly
> control I/O such as the printer or serial port. (I needed add-on
> hardware to get a real parallel or serial port, but you get the idea...)
>
> Can I get this kind of control with PowerBasic Console Compiler 5.0?
Not really and it's not a matter of the chosen programming language. PCs
usually don't use memory mapped IO, so there is a difference between
accessing memory and hardware registers. The "screen buffer" isn't in
main memory but in many cases in memory on the graphics card.
The ability to POKE into any part of the memory would be a bad thing.
The operating system is not in ROM anymore. If it is not protected, any
software could accidentally crash the whole system or even worse, any
virus can plant code into the core of the operating system. Ouch.
> A buddy at work says that I will never get past the barriers that
> Windows puts up and that I should switch to Linux and learm Python.
Although switching to Linux and Python may be a good advice, Linux puts
up those barriers too. That's the job of an operating system. Don't see
it as blocking you from accessing the bare metal but as a service to keep
that low level stuff away from you and offering you a higher level and
more comfortable API that works across platforms.
Ciao,
Marc 'BlackJack' Rintsch
Guy Macon
Stefan Pendl wrote:
>
>ForNext Jones Jr. <nob...@home.com> wrote:
>
>>Using PC CC 5.0 (and possibly some sort of addon) can I get past the
>>barriers that Windows XP puts between me and the bare metal? On my
>>old Commodore 64 I could POKE things into the keyboard buffer and
>>exit, making the C64 think someone typed a command. I could PEEK
>>and POKE any part of memory, including the screen buffer, and I
>>could directly control I/O such as the printer or serial port.
>>(I needed add-on hardware to get a real parallel or serial port,
>>but you get the idea...)
>>
>>Can I get this kind of control with PowerBasic Console Compiler 5.0?
>
>Windows does not use static memory allocation like the C64 has used.
>
>There are Windows API calls available to simulate keyboard events and
>to access the display memory of a window or the screen.
>
>You need to understand that things have changed in a way, that made
>PEEK and POKE obsolete.
It is, however, possible to bypass the restrictions that Windows
puts on direct I/O to parallel or serial ports For example,
Inpout32.dll from logix4u.net is a ring 0 kernel mode driver
that allows your ring 3 application direct access to the parallel
port without the usual privileged instruction exception.
http://logix4u.net/
http://logix4u.net/Legacy_Ports/Parallel_Port/Inpout32.dll_for_Windows_98/2000/NT/XP.html
I haven't tried it, but Winio from internals.com looks good and
promises direct I/O port and physical memory access under Windows
9x/NT/2000/XP. Look here:
http://www.internals.com/
http://www.internals.com/utilities_main.htm
http://www.internals.com/utilities/winio.zip
http://www.google.com/search?q=%22internals.com%22+WinIo
As Stefan Pendl pointed out above, it isn't trivial to find out
what is where in memory, and the adresses change from run to run.
--
Guy Macon
<http://www.GuyMacon.com/>
Joe Forster/STA
http://sta.c64.org/scbeta.html . They let you open up direct access to
the hardware ports under the NT-based Windows family.
Michael Mattias
> <nob...@home.com> wrote:
>
>Using PC CC 5.0 (and possibly some sort of addon) can I get past the
>barriers that Windows XP puts between me and the bare metal? On my
>old Commodore 64 I could POKE things into the keyboard buffer and
>exit, making the C64 think someone typed a command. I could PEEK
>and POKE any part of memory, including the screen buffer, and I
>could directly control I/O such as the printer or serial port.
>(I needed add-on hardware to get a real parallel or serial port,
>but you get the idea...)
Windows provides API facilities to "make the computer think someone typed a
command;" you don't need to POKE memory as you had to do under MS-DOS.
Similarly, there are API facilities to control printers and serial ports...
although in these cases the compiler itself provides intrinisic support for
doing a lot of things with printers and serial ports.
That is, between improvements in the operating system from MS-DOS to
WIndows, and compiler taking advantage of same, it's not necessary to be
POKE'ing bytes anymore.
If you have specific "things you want to accomplish" which you formerly
(currently?) accomplish under MS-DOS by PEEK'ing and POKE'ing, just post
those questions either here or better still on the PB Peer Support Forums
and someone will get you started doing these things "the modern way."
MCM
nem
> Not really and it's not a matter of the chosen programming language.
> PCs usually don't use memory mapped IO, so there is a difference
> between accessing memory and hardware registers. The "screen buffer"
> isn't in main memory but in many cases in memory on the graphics card.
PCs use port-based I/O, an antiquated concept that seemed like a good idea
in the '70s. Regarding video memory, PC video cards traditionally had their
own RAM which mapped into the CPU's address space. Modern PCs have an
onboard video system that simply takes some of the system RAM for itself.
3D accelerator cards meanwhile have separate RAM.
> The ability to POKE into any part of the memory would be a bad thing.
> The operating system is not in ROM anymore. If it is not protected,
> any software could accidentally crash the whole system or even worse,
> any virus can plant code into the core of the operating system. Ouch.
Another difference is that modern PCs do not use the BIOS for much of
anything except the boot phase. Windows has it's own drivers for everything
right down to the keyboard. That's because the BIOS resides in the first
megabyte of memory, and cannot be accessed without switching out of
protected mode.
In most cases, Windows has severe restrictions on what ports and memory
areas an application can access. Windows 95/98 were less stringent about
this than NT, which was why the latter could not run many games, although
that changed with XP.
Nope, PCs nowadays aren't like the simple little world of 8-bit machines
where you could do anything you wanted.
Leif Bloomquist
news:4ZGdndXSI6s...@giganews.com...
> exit, making the C64 think someone typed a command. I could PEEK
> and POKE any part of memory, including the screen buffer, and I
> could directly control I/O such as the printer or serial port.
At work we used to get around this "problem" in NT Embedded by using WinRT.
C/C++ only though, and a huge pain to learn and use.
http://www.pds-site.com/Bsquare/WinRT/default.htm
I suppose if you were desperate you would write some sort of DLL using WinRT
that FreeBasic could use but that's quickly turning into a Rube Goldberg
machine.
> A buddy at work says that I will never get past the barriers that
> Windows puts up and that I should switch to Linux and learm Python.
If you need direct hardware access stick with DOS or go for QNX, VxWorks
etc. Or "just" write a Windows device driver...
-Leif
Jim Brain
> "ForNext Jones Jr." <nob...@home.com> wrote in message
> news:4ZGdndXSI6s...@giganews.com...
>
>> exit, making the C64 think someone typed a command. I could PEEK
>> and POKE any part of memory, including the screen buffer, and I
>> could directly control I/O such as the printer or serial port.
>
> At work we used to get around this "problem" in NT Embedded by using WinRT.
> C/C++ only though, and a huge pain to learn and use.
access, but I would switch the question around.
Let's say the OP can bypass the "barriers". What, then? Poke the
values into the keyboard controller (which is not always possible, it
depends on the keyboard controller IC used)? That will only work if the
current KB driver is watching that controller. What about newer KBs
(USB)? There's not really an IO port to stuff keypresses. What about
the Windows Message Loop? Well, you need to synthesize a complete
Windows Message indicating a keypress and then either get Windows to
route it to the correct window, or route it yourself.
Even if I have a few of the details wrong, you get where I am going. I
think it is a BAD(tm) idea to do peeks and pokes today. Heck, it was
largely a bad idea back in 1982. Direct HW access made applications
machine (and even version) specific.
In short, I think peeks and pokes were the wrong answer long ago, and
are even more wrong now, but there was no alternative back then, so we
used them. Now, there are alternatives.
>> A buddy at work says that I will never get past the barriers that
>> Windows puts up and that I should switch to Linux and learm Python.
I don't think Linux and Python will help. While Linux will let you
twiddle the raw IO a bit easier, you'll still fall into the same trap.
It's even worse with Linux, as it's a true Multi-User OS, so there's no
guarantee the app that needs keystrokes stuffed is being run by the
local user.
Jim, ranting because having direct access to the C64 makes creating
compatible enhancements (like C=Key) so much harder, Brain
Stefan Pendl
>Leif Bloomquist wrote:
>> "ForNext Jones Jr." <nob...@home.com> wrote in message
>> news:4ZGdndXSI6s...@giganews.com...
>>
>>> exit, making the C64 think someone typed a command. I could PEEK
>>> and POKE any part of memory, including the screen buffer, and I
>>> could directly control I/O such as the printer or serial port.
>>
>
>Let's say the OP can bypass the "barriers". What, then? Poke the
>values into the keyboard controller (which is not always possible, it
>depends on the keyboard controller IC used)? That will only work if the
>current KB driver is watching that controller. What about newer KBs
>(USB)? There's not really an IO port to stuff keypresses. What about
>the Windows Message Loop? Well, you need to synthesize a complete
>Windows Message indicating a keypress and then either get Windows to
>route it to the correct window, or route it yourself.
>
There is the keybd_event Windows API, which emulates a key press.
Other programming languages might have something native to get around
the API call.
winston19842005
Brain" <br...@jbrain.com> wrote:
...
>
> In short, I think peeks and pokes were the wrong answer long ago, and
> are even more wrong now, but there was no alternative back then, so we
> used them. Now, there are alternatives.
>
Back then the TI-99's Basic got a lot of negative feedback because it did
NOT include PEEK or POKE. Instead, it included CALL routines for most things
(and supported assembly routines linkable by name with parameters).
In Extended Basic, PEEK and POKE (through LOAD) or in TI BASIC, the addition
of the Editor Assembler cartridge added PEEK and POKE (again through LOAD)
gave this ability, which wasn't over-used in the programs of the day...
Si Ballenger
Do a google search for userport.zip and see if it will give you
the hardware access you need. I know it will enable direct
read/write access to the parallel port addresses on an XP
machine.
Groepaz
giveio.sys can certainly do it, been there, done that... :)
--
http://www.hitmen-console.org
http://www.pokefinder.org
http://ftp.pokefinder.org
Every programmer knows the answer: $2b or (not $2b) is $ff.
Guy Macon
Michael Mattias wrote:
>
>>ForNext Jones Jr. <nob...@home.com> wrote:
>>
>>Using PC CC 5.0 (and possibly some sort of addon) can I get past the
>>barriers that Windows XP puts between me and the bare metal? On my
>>old Commodore 64 I could POKE things into the keyboard buffer and
>>exit, making the C64 think someone typed a command. I could PEEK
>>and POKE any part of memory, including the screen buffer, and I
>>could directly control I/O such as the printer or serial port.
>>(I needed add-on hardware to get a real parallel or serial port,
>>but you get the idea...)
>
>Windows provides API facilities to "make the computer think someone typed a
>command;" you don't need to POKE memory as you had to do under MS-DOS.
>
>Similarly, there are API facilities to control printers and serial ports...
>although in these cases the compiler itself provides intrinisic support for
>doing a lot of things with printers and serial ports.
>
>That is, between improvements in the operating system from MS-DOS to
>WIndows, and compiler taking advantage of same, it's not necessary to be
>POKE'ing bytes anymore.
That's all fine and good if you are working with standard hardware,
but what about a PCI or ISA card you designed yourself? Even standard
hardware can be a problem; the other day I needed to do some tests on
the low level interface to the Trusted Platform Module on my PC.
I just rebooted into MS-DOS and wrote some quick and dirty code, but
I would have had a heck of a time trying to do that through the Windows
API.