Vorticon

Figuring out when the king is in check as well as potential captures turned out to be computationally intensive. Basically for each board position sent for scoring, the computer cycles through all the pieces on the board, performs all possible displacements for each piece and checks if the end-square happens to be the king (taking into account the playing side of course) as well as any other potential captures and assigning a base score to the position. Sooo, response time just went from a little under 5 minutes to 9.5 minutes on the first level, and there is still a lot to do with the evaluation function. Oh boy... I have a feeling this is going to end up being an academic exercise at best 😛

Glad this got sorted out! Nice work.

There seems to be a major bug with pcode tool. Edit a TEXT file with the pcode tool using Notepad Save your changes and exit Notepad Now try to edit another TEXT file on the same disk. It appears to be completely blank and the size of that file now shows as 4 blocks, as if the tool had just created a new file. The original contents of the file are completely lost unfortunately. Attempting to edit that file from the pcode environment shows it to be filled with "k's. I am attaching the disk I am using. Try editing the MOVEGEN.TEXT file first, then try to edit the PHOENIX.TEXT file and see what happens. Thankfully I had backed up my disk prior to using pcode tool! Phoenix.dsk

Since the pcode tool is essentially an Editor/Filer, I can leave that disk out and replace it with the Utilities disk so I can use the Library facility when I make changes to one of the units without having to swap disks and re-initialize the system every time. I don't suppose pcode tool supports the large disk images created by apersson? My understanding is that only images up to 720 blocks are supported.

That would be cool indeed. I'm one of those people who still use CP/M on a fairly regular basis

Works perfectly with the F18A in 80 columns. Love it! Below is Turbo Pascal 3 and Wordstar.

I played with the p-code tool, and overall it works great. I was able to replicate the issue of not being able to edit a text file imported from Windows although it does show up in the directory under the p-code system. However, if I edit an existing text file on the diskette, then the edits do show up. So I suspect that the creation of a new p-code text file is buggy. One way around this issue is to create a nub of a text file under the pcode system on either a new disk or an existing disk then continue the editing process in Notepad using the p-code tool facility. I tested that and it does work. I do hope the author will get around to correcting that bug at some point though. One point: there seems to be an issue with accessing the right mouse button menu for the files on disk. Sometimes it works and sometimes not. So yeah, the tool is still a bit rough on the edges, but even as is I have found it to be incredibly useful. I wish I knew about it previously! Does anyone know the AA handle for Antoon Jansen, the author?

Here's the translated p-code tools document into English. P-code_tools.doc

With the exception of integer math, the latest version of the compiler has removed most of the original limitations. I was able to compile Stratego, a large and complex program in XB, without issues which is frankly quite an achievement.

I definitely plan on implementing an opening library, but I'm not sure I need AMS for that. Too early to worry about it yet

It actually takes 44 minutes, but that's with only a dummy evaluation function. I won't know for sure how much a proper function will add to the processing time until it's complete. The processing time does not increment linearly with each level obviously.

I finally picked this project up again after 4 years as I got tired of feeling guilty over it every time I saw the stack of printouts and notes I conspicuously kept around In any case, it took me almost a week to go over the code again and gain a good understanding of what the hell I was trying to do, although having taken copious notes did help quite a bit. I corrected several bugs along the way and made a few optimizations and now the move generator works as it should down to a depth of 6 ply and I am ready to tackle the position evaluation function, really the heart of the whole project and will determine how well the computer opponent will play. My goal is simple: Phoenix Chess should be able to beat Video Chess at its highest level 100% of the time, otherwise why bother with another chess program! The main issue with coding something like that in UCSD Pascal is that execution speed is quite slow: the program is expected to have 35 levels, and the first level already takes an average of 4 minutes per move. Obviously this will get longer with each level. Anyone wants to take bets on how long level 35 will take? 😄 But hey, this is primarily an educational experience as far as I am concerned so that's fine.

Can you post them by any chance?

The cart version has a couple of subtle bugs with scoring and play. This was corrected with the disk version. JetPac.dsk

Here are all the pcode disks and documentation in one zip file. Also includes the Turtle Graphics disk by apersson. UCSD Pascal.zip

Here are all the UCSD pascal disks and documentation in one zip file. Perhaps this could go in the Development Thread for ease of use. UCSD Pascal.zip

I think you cannot go wrong with either MAME or Classic99 when it comes to pcode. Your main issue is really going to be how to transfer back the files to the TI. I use Fred Kaal's DSK2PC to transfer the disk images created in the emulator coupled with a USB to serial cable and an RS232 card upgraded with the HDX system (you can also use an unmodified RS232 card but with more limited options). This set up lets you create a real disk on the TI side which is usable with the pcode system. Make sure that you check the disk image for bad blocks with the Filer, correct those with Examine, then Crunch the disk before transferring. This process has worked for up to DSSD disks with the standard TI disk controller. Here's the link for more info Alternatively, I understand that there was a terminal emulator with file transfer capabilities made for the pcode system on the TI, so you could connect the PC and TI with a null modem cable with a USB to serial adapter on the PC end and transfer the files one by one that way. Finally, the Transfer command in the Filer could theoretically also transfer a file via the RS232 and a null modem set up but I'm not sure if this will work with binary files or just text source files. The transfer settings can be changed with the MODRS232 facility on the Utility disk (REMIN/REMOUT), then with Transfer you can enter something like this: REMIN,#4:TEST.CODE . I have not tried this.

🖕. Oops, I meant 😄. Damn autocorrect!

Having a mask on all day long as well the requisite distancing will make for a very tiring and awkward day to say the least. Not to mention that this is likely an unsafe situation given that we will be cooped up in one room for the duration and I am willing to bet anything that not everyone will comply with the masking policy. If Hal wants to go for it, that's up to him... Personally I don't need any more exposures than I already get at the hospital every day.

So I've picked up again my chess program in UCSD Pascal and have been working on it over the past week under emulation in Classic 99. Previously, I had been able to transfer the program work disk to the TI using Fred Kaal's DSK2PC utility coupled with an HDX-modified RS232 card. This time however, when I tried that, some of the files transferred fine and some were truncated with the latter giving a disk error when attempting to edit them. The only change was that some of the files are now larger. The directory appears fine however with the correct entries and program size. This is really problematic as I need to test the program on real hardware and also need print the source listings for debugging purposes. Any suggestions? How do people transfer files to the pcode system from a PC? I do have the PC99 emulator as well, and I vaguely remember that it had some facility to access and extract pcode files, which would be helpful for the printout part at least... Update: On a hunch, I checked the disk image for bad blocks using the Filer and it had a bunch of bad blocks at the end. I used the Examine option to correct that then crunched the disk. With that done, the disk image transferred perfectly to the pcode system with no corrupted file and I was able to print my source files as well as run the program. Lesson learned

Yeah the Faire is out this year as far as I am concerned. First time I would have missed it in nearly 20 years... I don't think it would be safe to hold it anyway or that the Evanston library would even allow such a gathering. There is always next year though

This is a wise decision. Looking forward to next year's meeting. If you already know the dates, please post it here so I can make the necessary scheduling arrangements for work. An online meeting sounds great. While it is unlikely I will have anything to present (one never knows ) , I am happy to help in any capacity.

This is essentially the same setup as in the Coleco Adam computer which has 64k of RAM on top of the 16k VDP RAM. I was actually able to add graphics capabilities to Turbo Pascal 3 under CP/M on the Adam using that setup and embedding z80 assembly code into graphic modules.

Practically identical with the exception of placing a colon instead of a comma before the list of parameters or variables. For example: CC40: OPEN #1, "100.test", OUTPUT TI 99/4A: OPEN #1: "DSK1.test", OUTPUT CC40: PRINT #1, I TI 99/4A: PRINT #1: I So unless the program is using direct access to files via assembly language routines, it should be trivial to convert the file I/O from the TI to the CC40.

Now that is awesome! No more copying and pasting in Classic 99. Just load the binary.