CoreWin FAQ

This FAQ is intended to answer questions that may not be covered in sufficient depth (or at all) by the user's guide.

Will my computer run CoreWin?

CoreWin will run on any 32-bit Windows operating system (Win95 or later). It requires at least 800x600 screen resolution. Just double-click on CoreWin.exe to start it.

When is the Linux version coming out?

At some point, I may upgrade my old copy of Delphi to a version that supports Kylix (Delphi 7 or later). But that may not be soon. If someone already has such a version, and would like to volunteer to help, I wouldn't mind trying to port it.

Are you going to make CoreWin open source?

Probably...eventually. Right now I'm having too much fun working with CoreWin to want to share it. (I know, I'm being totally selfish.) Perhaps in another year or so I might want to move on to something else, and I'll be willing to let someone else help carry it forward. But then there's another obstacle: CoreWin is written in Delphi, which is not exactly a ubiquitous development platform. I'm not sure how "open" CoreWin can ever be, unless it gets ported to a completely different IDE, and I'm not going to be the one who tackles that job. If there are any Delphi developers out there who would like to help out, let's talk.

CoreWin declared a draw before the time limit expired. What happened?

CoreWin has an early-draw detection feature. If every process of every warrior is an Imp (MOV 0, 1 or MOV #N, 1), no processes can ever die, so the battle is called a draw immediately. This feature can be disabled in the Options dialog.

How exactly do the read/write limits work?

Every address in Redcode is either a read address or a write address. Basically, a write address is any address at which the core contents are (or could be) changed, and everything else is a read address. For instance, in a MOV $X,$Y instruction, X is a read address but Y is a write address. All compares, jumps, and SPL use read addresses, because nothing is changed in core. The address that's decremented by a DJN is a write address. Each of the indirect addressing modes involves two addresses, which may be classified differently: in a SUB >X,}Y instruction, both of the intermediate addresses (X and Y) are write addresses, because they're being incremented; the final addresses (X+[X.B] and Y+[Y.A]) are read and write addresses, respectively. Under R/W limits, each write address is calculated modulo the write limit (W), so that the address is "folded" into the range -W/2+1 to +W/2, relative to the current instruction. Writes outside this range wrap around to the other side, just like a small core-within-core. (Reads act the same way, using the read limit R.) So if, for example, the read limit is 800, the allowable range for reads is -399 to +400. A MOV 403, -1 instruction would move the contents of address -397 to address -1.

In the case of indirect addressing, the limit is applied to both the location of the intermediate address (inc/dec modes use the write limit, remember) and the final address, both in relation to the instruction being executed. Again, let's assume a read limit of 800. A MOV @500, -1 would wrap to a MOV @-300, -1, and if the instruction at -300 contained (say) -150, the final source would wrap again to address +50.

If you really start to play around with read/write limits, there's one more wrinkle you should know about. If the size of the core is not an exact multiple of the read limit (or the write limit, or both), the folding of addresses in the core-within-core is not smooth, and your instructions may not behave as you expect. CoreWin's implementation of read/write limits guarantees that "local" addresses (within the allowable read/write range) behave normally. Also, positive addresses wrap around to the negative side smoothly (+(R/2)+N will always be equal to -(R/2)+N). However, negative addresses will not wrap to the positive side smoothly (-(R/2)-N to +(R/2)-N) unless the core size is an exact multiple of R.

What good is a breakpoint that never halts execution?

If you set a breakpoint's Frequency parameter to zero, the breakpoint will never halt execution no matter how many times it's conditions are satisfied. This can be useful when you want to track where an instruction is copied to, or from, or how many times. Set a movable breakpoint with a frequency of zero on any instructions you wish to track. Then, at any time during the battle, open the Breakpoints dialog box from any Core View window. It will show the location of all the breakpoints throughout core, including all the copies of the ones you're interested in.

Why doesn't MUL.AB #-1, #-1 produce +1 for large core sizes?

Remember, numbers in Core War are always positive; -1 is really just another way of writing CORESIZE-1. So, anytime the core size is greater than 2^16 (=65536), -1 times -1 will overflow the 32-bit numbers that CoreWin uses, and the results will not be what you expect. In general, you need to be careful using the MUL instruction when you are writing warriors for large core sizes.

I checked out that KOTH site you sent me to, and it's years out of date. Does anyone actually play Core War anymore?

Absolutely yes! Don't be fooled - the KOTH site (Core War's ancestral home) may not have been updated recently, but the materials there are still informative, and it hosts several very active hills. And there are many other, more current, sites maintained by the members of the Core War community. Core War is thriving and growing! And we welcome new players.

I give up. What's the significance of CoreWin's silver rose icon?

One of my favorite science fiction/fantasy series is Roger Zelazny's Amber novels. The protagonist is a man named Corwin, and his emblem is the silver rose.

What questions are not answered by this FAQ?

You tell me! If you have a question that doesn't seem to be addressed anywhere, by all means send it to me. My contact information is on the home page.