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]

On Sat, 22 Nov 2008 02:46:41 +0000, ForNext Jones Jr.

Post by 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?

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

[unknown]

Post by Stefan Pendl

Post by 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?

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.

[Joe Forster/STA]

Also see the drivers in the "Windows NT/2000/XP tweak package" at
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]

Post by Stefan Pendl
On Sat, 22 Nov 2008 02:46:41 +0000, 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...)

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

[unknown]

Post by Michael Mattias

Post by 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...)

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.

[Marc 'BlackJack' Rintsch]

Post by 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?

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.

Post by ForNext Jones Jr.
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

[Leif Bloomquist]

Post by ForNext Jones Jr.
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.

Post by ForNext Jones Jr.
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]

Post by Leif Bloomquist

Post by ForNext Jones Jr.
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.

There are a couple of premade device drivers that allow direct IO
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.

Post by Leif Bloomquist

Post by ForNext Jones Jr.
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]

Post by Jim Brain

Post by ForNext Jones Jr.
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.

---
Stefan Pendl

Windows XP Pro SP 3
Celeron M 1.3 GHz
752 MB DDR RAM

[winston19842005]

On 11/23/08 2:40 AM, in article dO7Wk.392332$***@attbi_s22, "Jim
Brain" <***@jbrain.com> wrote:
...

Post by Jim Brain
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...

[unknown]

On Sat, 22 Nov 2008 02:46:41 +0000, ForNext Jones Jr.

Post by 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.

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]

Post by Stefan Pendl
On Sat, 22 Nov 2008 02:46:41 +0000, ForNext Jones Jr.

Post by 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.

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.

giveio.sys can certainly do it, been there, done that... :)