Vorticon

Ah... I guess I have to break things up a bit. Thanks for looking into it. For my own edification, which reference did you use to figure out the error meaning?

I'm getting a strange "BACK-END ERROR 8" at the end of compilation of a unit. There is no reference in the manual for such an error. Anyone here knows what it means?

Unfortunately turning range checking off, changing the arrays base index to 0 and using a packed array of bytes for the board representation only resulted in a minimal saving in overall processing time. Oh well...

It's alive! Ok still very dim-witted, but alive... This is just a test window with the computer playing against itself, and it just nearly checkmated itself in 3 moves! Still having trouble detecting check mate situations as well as getting out of check threats. This test pretty much exercises the entire code base, and at least I know the piece movements are correct and that the board is being updated accurately. I have so far only implemented basic pawn strategies, general piece capture incentives and king check maximization, but everything else is remains very much random movement.

Hi Dan. Download the attached zip file and extract it somewhere. Start up your Arduino IDE, connect the Arduino Uno making sure you've got the proper COM port configured in the IDE Load the src.ino file from the src directory in the file you just downloaded. Press CTRL-U and it will compile and transfer the binary to the Arduino. You might get a low memory message which you can safely ignore. If you get an error pointing at the DS32xx line, you will need to go into the IDE under under Tools --> Manage Libraries and search for the appropriate DS32xx file and install it. Restart the IDE and the process should work now. Install a FAT32 formatted SD card into the Arduino SD shield, connect the Arduino to your CC40, power it up first then the CC40 and off you go Hopefully this helps. HEXTIr-libmerge.zip

Success! Works perfectly and passes the FOPSTEST. Nicely done

Sounds like you've ruled out the most serious etiologies (anatomical malformations, increased intra-cranial pressure, brain turmors, glaucoma, hypertension). What remains is more difficult to tackle and multi-factorial. Have you seen an endocrinologist to rule out hypermetabolic states like thyroid or adrenal issues? How about a glucose fasting test? Have you had an EEG? Barring any apparent organic causes, I would certainly consider an elimination diet looking for food triggers. A dietitian can be of great help here. I really do hope you get to the bottom of this and get better.

The problem is only in the main rpi shell (I assume bash). Once you are in an application, the latter responds correctly to the backspace code being sent.

Yup

I downloaded the latest sreid version from Github, and while it compiles fine on the arduino, I get an IO Error 255 for any file ops on the CC40...

I tried FCTN-S and CTRL-Q and while they do erase characters, the cursor itself moves to the right instead of to the left. It took me a while to realize that That's an old behavior legacy Basic's... Is there a way to configure the tipi telnet to move the cursor to the left when backspacing?

I meant on the TI itself

Do you use FCTN-9 or the back arrow?

Quick question: How do I set up backspace in telnet?

Excellent news! I'll test it out. With that issue out of the way, I believe the storage problem for the CC40 is now resolved. I am very grateful for the work by all involved. The lack of storage for the CC40 has been a vexing situation for decades... Time to start thinking about new programs for it

So there is not true byte type as in Turbo Pascal in UCSD, but you can essentially create one. Clever! Did not think of that This is truly very valuable information and extremely relevant to my project because it's all about accessing and handling arrays. It should be fairly trivial to make the changes since only the declarations change, not the handling of the arrays. I'm going to run some tests and see what kind of speed gains I get.

Just integers 1-16. I don't believe UCSD pascal supports byte types though.

Nice font indeed. Thanks!

Thanks for the tips! I'll see if I can optimize the code with that info.

Ah ok makes sense. The array tmpboard, while declared as [11..88] of integer, only has a subset of valid locations within that range specified in the validloc set. What threw me off was the fact that while I have multiple similar constructs throughout the code, I never previously had allowed the index i to go outside the 11..88 range, unlike this case, which is why I never got into trouble previously. Thanks for the clarification. PS: Execution error 1 (index out of range) has been the bane of my existence with this project. Absolutely a nightmare to debug in a large multi-unit project...

I have a little puzzler I'd like perhaps some insight on. Can someone please tell me why the following code does not work if turn>2 then begin if ((i-11) in validloc) and (tmpboard[i-11]=6) then cscore:=cscore+30; end; whereas if I reformat it as below the error goes away? Makes little sense to me as the inner begin/end pair should not be needed.... if turn>2 then begin if ((i-11) in validloc) then begin if (tmpboard[i-11]=6) then cscore:=cscore+30; end; end; As a background, the index of the tmpboard array has a range of 11 to 88 which is contained in the validloc set. So if i-11 goes out of range, then the second half of the if statement in the first code snippet should not get executed, and yet it does...

I unfortunately only have the standard TI controller, so I made a disk with the Editor/Filer and Compiler combined which frees up a disk drive for the Utilities or Assembler/Linker disks. EDT-COMP.dsk

There are no integral graphics commands to UCSD Pascal and the TI implementation does not include things like GCHAR, HCHAR or VCHAR, so you will have to roll your own. The initial chess position is stored in the chessboard array with each piece having an assigned numerical value: King=1, Queen=2, Rook=3, Knight=4, Bishop=5 and Pawn=6 for white. Add 10 to the value for black. When generating a move, the array contents are scanned in order to locate pieces and make calculations, and the array is updated with each turn. Temporary mirror arrays are also created to test potential moves against the evaluation function before committing to any particular response. The computer actually pre-calculates a limited set of player responses during its position evaluation depending on the ply depth and if the player indeed plays these moves, then the response time is immediate since no evaluation is required. However, since the evaluation function attempts to maximize the computer's score while minimizing the player's, I'm not sure if it will frequently succeed in predicting a good player's move We shall see! Given the complexities I have encountered, I am utterly amazed how some brilliant programmers have managed to create complete chess programs under 1K (in assembly)... They may not play well, but still!

Yeah, castling was a different challenge altogether Recursion definitely plays a big part in this program, something UCSD Pascal is quite capable of. It's hard for a computer to figure out which pieces are blocked without checking each possibility unfortunately (see my previous post). And indeed, the first few moves are computed faster than subsequent ones because there are fewer valid movement options. The main issue here is that UCSD Pascal is quite slow compared to say assembly or forth, but on the plus side it's a very easy language to work with and very structured which is important for complex projects like this one. As I stated before, this is more of an academic exercise than anything else

The king in check search is actually incorporated into a broader potential piece capture routine and is just a secondary outcome. Each piece on the board goes through all its valid displacements, and if it hits the king then a check situation exists otherwise if it's an opposing piece then it's a potential capture. That routine creates a base score for any given position where the total material value of the pieces as well as the values of the pieces threatened by capture and any king checks are taken into account on both sides of the board then subtracted from each other. That base score will later be modified based on certain development criteria. As for the displacement scheme, the internal representation of the chessboard is designed in a way that each piece has a limited set of displacement deltas and not absolute displacements (stored in a matrix), which are added to its current position to generate all possible reachable positions. For example, the king and knight have 8 displacement deltas, whereas the rook and bishop have 28. The queen simply recycles the displacements deltas of the rook and bishop combined. In essence this scheme is kind of a mask. The chessboard is an array [11..88] of integer, and any final position (current position + displacement delta) that falls outside of that range or lands on a friendly piece is not valid. The displacement delta is repeated to create rays, a process which stops at an invalid position. Chessboard representation 18 28 38 48 58 68 78 88 17 27 37 47 57 67 77 87 16 26 36 46 56 66 76 86 15 25 35 45 55 65 75 85 14 24 34 44 54 64 74 84 13 23 33 43 53 63 73 83 12 22 32 42 52 62 72 82 11 21 31 41 51 61 71 81 For example, the king displacement deltas starting straight forward and moving clockwise are 1,11,10,9,-1,-9,-10,-11 and these will work from any starting position on the board.