This FAQ is intended to answer questions that may not be covered in sufficient depth (or at all) by the user's guide.
MUL.AB #-1, #-1produce +1 for large core sizes?
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.
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.
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 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.
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 (
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.
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.
MUL.AB #-1, #-1produce +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.
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.
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.
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.