I can't pause the game

J

JKeefe

Spaceman
The manual states
To pause during play, select either the [PAUSE] key or use pipe
Click to expand...

My PAUSE key does nothing. This makes long flights kind of hairy, as occasionly it would be nice to shake out my arm during a battle, go to the bathroom without fear, answer the phone, etc.

And what the heck is pipe?
 
Pipe

JKeefe said:
The manual states


My PAUSE key does nothing. This makes long flights kind of hairy, as occasionly it would be nice to shake out my arm during a battle, go to the bathroom without fear, answer the phone, etc.

And what the heck is pipe?
Click to expand...

Pipe is the name of the key that looks like two Verticle Dashes one on top of the other. Depending on your keyboard it is in different places. On mine it's Shift Backslash
In DOS the pipe command was something that you used to send output of one file to another file for further action. Pipe

So for me, Pause is Shift + Backslash
 
Ah, there is it. I'll give it a shot and report back.

I'm amazed that I've been using computers for 15 years and there is a key that I didn't know existed...
 
K1nG Gr4H4m said:
Don't worry, I've been using a pc since 1987 and I still don't know what the Scroll Lock key does.
Click to expand...

You had to be there, I guess.
You didn't have the Key pad on those old keyboards. Some had no function keys at all, some had 83, 84, 86, 87, 88 or 89 keys, not 101 or 104.

If you wanted to scroll up or down in your Command Line univers, you had to enable Scroll Lock. That let you buffer data so you could scroll up and down. But if you buffered teh data, you took away RAM from the programme. I remember having to stay within 32K for the first programming efforts. When we hit 64K I thought it was a miracle of science. Now I routinely run with a half MB of RAM.

BUT, as I understand it, They have yet to break that first 64K requirement. The main functions of the shells are still executed in that first 64K of RAM the rest is still extended or expanded memory of some sort. At least I don't THINK they've broken that barrier yet. It used to be a function of the processor.
 
I'm not sure why SDL advertises it can use the pause key, but it for some reason doesn't respond to the pressing of said pause key.

oh well...any ideas for keys to use to pause... is the 'p' key to pick target near your crosshair useful? or should that be bound to pause
 
hellcatv said:
I'm not sure why SDL advertises it can use the pause key, but it for some reason doesn't respond to the pressing of said pause key.

oh well...any ideas for keys to use to pause... is the 'p' key to pick target near your crosshair useful? or should that be bound to pause
Click to expand...


Traditionally P is pause
H is for toggle hostiles.
T is toggle Targets, INCLUDING Nav points
N is toggle Nav points
E is or was Examine, AND I always liked that one. You Examined what was in your view screen. But you have all sorts of things bound to E. ECM among them, But you need something to grab what's in front of you. What's V tied to? Or G? To "Grab" the target in "View."
 
E is still examine - you get you view of the target hull and shilelds, it just looks different now.

@Hallcat - don't you dare take away my p key. :) I use it all of the time and find it extremely helpful.
1. It lets me retarget a jump point that I am afterburning towards after I have targetted a hostile to check his distance or view him to see if he is shooting.
2. It lets me swing the nose around at the baddie who is in my face hitting me with full guns. I start shooting at him and target him at the same time with p.

Now, I use a programmable HOTAS, so I care more about the functionality than the exact keypress. If you want to make crosshair target CTRL+SHIFT+ALT+PRINTSCREEN, that's fine with me - two seconds in my joystick file and it as if nothing has changed. But for those who need the keyboard, I suggest keeping p as crosshair target and shifting pause to SHIFT+P or something similar. Keep the pipe, too.

Better yet, find out why PAUSE doesn't work. :)

FYI, I checked SHIFT+PIPE, and I can pause just fine. EDIT - I mean SHIFT+BACKSLASH.
 
i thought that 640 limit was done away with after windows 9x, for MS' part at least.

but then again, i don't know what's going on completely. i can imagine some strange x86 requirement.

i do know for sure that the 9x os-on-os thing is gone (so the dos backbone is removed) in the NT-style (xp/2k/2k3) os's.

and i thought the 640k limit was a dos issue, not an x86 issue.

-scheherazade
 
scheherazade0xf said:
i thought that 640 limit was done away with after windows 9x, for MS' part at least.

but then again, i don't know what's going on completely. i can imagine some strange x86 requirement.

i do know for sure that the 9x os-on-os thing is gone (so the dos backbone is removed) in the NT-style (xp/2k/2k3) os's.

and i thought the 640k limit was a dos issue, not an x86 issue.

-scheherazade
Click to expand...


To be honest, NT IS a shell routine running in the OE on a form of Disk Operating System. That it's NT File System doesn't change a thing, It's still a form of DOS and it still communicates with NT via a command.com of sorts. It is architecture dependent and Yes, Mac has the same type of issue. Doze 9x still has it's DOS 7x and NT has Command, which is command line access to NTFS. It shakes people up when they hear that DOS is still there, but if you think about it, it always will be.

That we are still operating the basic command.com inside the first 64K is mindblowing. The way we do it is a whole nuther story. Look at a Linux Kernel. Why do you have to keep the kernel size down? You need to fit it into that first 64K You can put modules on that let it blow out, but those modules are operating in a shell. Pick your central Kernel components properly and you can have a rock-solid OS. Choose poorly and it will be as unstable as Doze 95.

Think about it.
 
Look at a Linux Kernel. Why do you have to keep the kernel size down? You need to fit it into that first 64K
Click to expand...
My linux kernel is 1.6 megabytes (not including the modules). It would be very difficult to create a linux kernel that would fit into 64k ;)

Since I didn't know exactly how things worked, I did some reading. In an attempt to clarify it for myself, a summary of the boot process follows.

There is indeed a 640k limit in PCs still today. When things first start running the CPU is in real mode, and data outside the first megabyte of address space can't be read. 640k of that is set aside for main memory. We have to load the kernel before it can run, and we have to deal with that 640k limit. I'll summarize how this is done below.

The first thing that runs is the BIOS, which does some tests and stuff. If one is booting from a floppy, the BIOS then loads the first part of the kernel directly.

Kernels all used to be small enough (half a meg) to fit into that 640k. The first part was loaded in after the first 64k block (where data from the BIOS is stored during bootup). This first bit (bootsect.S) loads the rest into the 640k. The code (now setup.S) moves the kernel down and overwrites the 64k block with the BIOS related data (after which the BIOS can't do anything more), switches to protected mode (where all RAM is available), passes control to the beginning of the block and we're off.

Of course, kernels grew larger than 640k, so they were compressed (made into a zImage). The compressed kernel was loaded into the 640k, it is moved to where the BIOS was, startup code (setup.S) switches to Protected mode and control is passed to the beginning of the block, all as before.Now however instead of the kernel, ready to run, the code there (head.S) is unzipping code that decompresses the rest of the kernel into high mem, and passes control to it, and we're off.

Eventually, kernels got so big that they couldn't fit into 640k even when compressed. Kernels larger than 640k when compressed are bzImages. Data is read in 64k at a time, and a helper routine uses a special BIOS call to move the chunks into protected memory. The startup code (setup.S) transitions to Protected mode and passes control to the unzipper at the start of the bzimage (which is sitting in the first part of high memory), which decompresses the kernel, first into low mem until it fills up then into high mem and things run from there. Control then passes to the start of the kernel at the bottom of low mem Typically things run thus: and we're off.

Obviously, not many people boot from floppies nowadays. When booting from the hard drive, things run slightly differently.

The first thing that runs is of course still the BIOS. It runs some tests, then loads the contents of the first 512 byte sector (MBR), which is the bootsector of some bootloader. The bootsector then either loads another bootsector - typically from the start of the active partition - (chain loading) or a second stage boot loader. Once you choose which OS to boot (or if there is only one), the bootloader loads the corresponding kernel (or chainloads another bootloader that loads the kernel). If the kernel fits into 640k, it's loaded into into low mem, bzImages are loaded into high mem via BIOS calls.

The bootloader then then passes control to the startup part of the kernel (setup.S). From here, things proceed similarly to how they do when booting from a floppy. If the kernel is not compressed, the startup code transitions to protected mode and hands off to the main kernel. If it is a compressed kernel, the startup code transitions to protected mode and control passes to the unzipper (which is at the beginning of low mem for a zImage, or at the beginning of high mem for a bzImage). The zImage unzipper unzips the kernel to high mem and gives it control. The bzImage unzipper unzips the kernel into low mem then high mem, and gives it control. And we're off :)

Conclusion:
So while the PC does have some strange 640k limits still today (not really 64k), kernels are hardly expected to fit into 640k: several kludges have developed to get them loaded. And needless to say, once the processor has left real mode for protected mode, all pretense of a 640k limit can be dispensed with. I might be missing something, but I see no evidence of a 64k limit anywhere.
 
re keybindings:
The function currently bound to p (targetting whatever is in front of you) is something I associate with y, as several space games use that key and it is conveniently next to t. Also, y is not currently bound to anything in the Remake (though it is bound in vanilla Vetgastrike)

I'm leaning towards moving Target what's in front of you from p to y. Then pause *could* be bound to p, though I don't mind using pipe (it's less likely to be hit accidentally)
 
You must log in or register to reply here.
Back
Top