stepho

I thought I knew IBM PC history and Atari history quite well but that was a new one for me. Found some more info at http://forum.6502.org/viewtopic.php?f=3&t=5256

The 8-bit machines died only because technology moved on. Bit size increased to 16/3/64-bits to allow bigger programs and the handling of bigger numbers. Speed increased hugely. Memory size increased hugely. Power usage decreased hugely. We love our old machines but it would be silly to expect them to still be mainstream. The other thing to consider is that the video stream was a relentless task master running at (relatively) high speed. Pauses in almost everything else are not noticeable by the user but if the video stream ever paused then the user would notice it. There is no way to pause or skip sections of it while the machine deals with other things (calculations, disk, keyboard, etc). Everything else is either done at slow speeds (eg sound can be updated between screen frames) or is not timing critical. Therefore, the video must get top priority. Even in the 16/32-bit era, the PC, Mac, Amiga, etc had special buses for the video (eg PC had VL or AGP buses and the Amiga had the Copper chip). PCIe and Thunderbolt buses are still designed to specifically handle video streams.

Not in significant numbers and not backed by the government like they were in the UK. Mostly it was the Apple II or the Microbee (Z80 CPM machine).

Combat's tank

As a full-time software engineer, I've always used "port" to mean that I take a code base and do whatever it takes to make it run on a different system. That might mean anything from a tweak here or there, or some replacement libraries, or even change the language (eg, I've ported projects from C to python). Whatever it takes to work on the new system, even if it means changing parts of the spec. I think "port" comes from the idea of porting/carrying/moving something around. Related to shipping ports, import/exports, porters, etc.

You mean he now has a PAL interface? (for plausible deniability, I *could* be talking about a TV standard)

Sadly, our manufacturing department did the equivalent to me for a short run of custom Raspberry Pi hats. An IDC 2x10 way connector shroud was put in backwards, so they cut an extra notch. I saw the original notch but not the "corrected" notch and promptly let the blue magic smoke out of the RPi. It was too hard to remove the shroud and do it properly but at least I went back and filled in the original (but wrong) notch with plastic filler to stop a repeat. And we gave manufacturing an earful for the next run

Put a small dollop of paint on the socket near where pin 1 should be. Take care to keep the paint out of the electrical bits.

It is good practice to enclose any macro formulae in brackets. Eg: #define TOTAL_LEN 3+4 #define TOTAL_AREA TOTAL_LEN * TOTAL_LEN Gives an area of 3+(4*3)+4 = 19 . #define TOTAL_LEN (3+4) #define TOTAL_AREA ((TOTAL_LEN) * (TOTAL_LEN)) Gives an area of (3+4)*(3+4) = 49 . Some of those brackets are redundant but defensive programming puts multiple layers of defence so that certain classes of bugs just don't happen, regardless of how the earlier macros are defined or how the final macro is used. Every numeric macro is defined with enclosing brackets. Every numeric macro encloses each child macro with brackets. Apologies if I'm ranting

In C, the normal way to put in a newline is: char *message = "hello, world!\n"; and let the compiler translate \n into whatever is required for your system ($9B for Atari 8 bit system). If the compiler doesn't do this then the next thing to try is: char *message = "hello, world!\x9b";

Yep, that was common back then. Compilers and assemblers were hard to come by, expensive or ran on expensive development systems. So many hackers just did it by hand. I was never able to memorise all the opcodes myself but I know others who could disassemble a ROM just by eyeballing it. As in, he could look at a hex dump of a ROM, tell you what instructions were being called and (after a bit of thinking) tell you that it was a 16 bit multiple routine.

I used to program 8051's in EFTPOS machines in the 1990's. Generally nice enough CPU's, although they had a few quirks - just like the 6502 has a few quirks. The big problem for using it in a general purpose machine is that code and RAM are in separate 64 kbyte address spaces. Which means code cannot execute from RAM. Which makes it hard to load programs from tape or disk. There are ways around it (eg use RAM chips to simulate ROM and then bank switch the RAM chips between the code address space and the RAM address space) but life is harder. But they make excellent CPU's for embedded systems running from ROM. And having 64 kB for code and another 64 kB for RAM sure is a lot nicer than 64 kB for everything and also run faster due to less wait states (wait states for code and RAM can overlap).

Except I forgot to dot the "i"

Combine a couple of them

Doh! What was I thinking!

EPROM type M27C512 matches the pinout shown by Oriskanytinterent . But I have no idea if that matches your actual chip.

Presumably your engine speeds up when there are less pieces (kind of like Space Invaders when there is only 1 alien left). Could you search another ply for every X pieces removed from the board? And/or adjust quiescence for pieces removed.

My 2c worth... I like the tops of the pawns being a bit dimmer. Gives them a slightly 3D look (like the top of a shaded sphere). The random element is a good thing. Technically, it makes it play a weaker game. But if we find a sequence of moves that win then we can replay those moves to win anytime - as boring as that would be. A self learning AI would learn and avoid those moves in the future but of course we understand that is another level of difficult above the current target. A slight random element is a good fall back to prevent repeatable play.

I do remember when I was studying this about 40 years ago that the scoring of each potential board (ie the leaf nodes) was considered vital. In particular, scoring a group of pieces in relationship to other pieces rather than statically. See https://books.google.com.au/books?id=dzTY5Nf-IvMC&pg=PA221&lpg=PA221&dq=degroot%27s+law+of+chess&source=bl&ots=gbIBynajKz&sig=ACfU3U12wgwzvvnklFPq1Nu3UBiZSjHY2Q&hl=en&sa=X&ved=2ahUKEwjFlcSpkdjoAhUAH7cAHecDCyIQ6AEwAHoECA4QKQ#v=onepage&q=degroot's%20law%20of%20chess&f=false DeGroot's Law of Chess said something like "Better chess players play better chess because they are better at playing chess". By which he meant that better chess players could evaluate (ie score) a potential board better then lesser players. I also remember some early AI software in the 1980's that took everything it knew and tried to form relationships. It even did things like counted how many black and red squares there were after each move - just in case it changed. Of course it soon gave up on that but it showed that it was willing to look at anything. A later version of the same software could win mail based strategy games against humans by finding relationships that nobody else ever thought to look for. But that was only after playing thousands of games against itself to find the patterns. Wish I could remember the name of the software. True 6507 based AI is unlikely but perhaps an "expert system" with canned rules for scoring boards is possible. Something like, a pawn near an enemy queen is good, a knight near the enemy queen is real good, 2 bishops fencing in an enemy non-pawn piece is good. Just had a thought. The code, constants and strategies never change due to the ROM based nature of the 2600. But what if we allowed the cartridge a form of NVM (like some carts do for high scores) and allowed it to tweaked some of the weighted values in the board scoring mechanism. Over time it would get better, depending on what methods lost or won (was it Shannon who did this with a matchbox tic-tac-toe game? damn, my memory is getting worse). Many of the bigger programs did this (playing against itself thousands of times). Of course, this is a much more complex program than you have now and I'm truly impressed with what you have so far. (by the way, I suck at chess)

Re: bad things Reminds me of the chess game in "Saturn 3". Kirk Douglas sacrifices his queen to win against the android.

Babbling? It's turning into a politician - except for the intelligence part.

But if you get rid of the wife then what will you do during a blackout?

When I want to turn bit 7 off I usually write it as: n = rndp & ~(1<<7) Turning it on is like: n = rndp | (1<<7) And testing it is like: if( rndp & (1<<7) != 0 ) the != 0 is not strictly necessary.

Yes, you are correct.

Mathematicians like to use radians (a full circle is 0 to 2*pi radians) because it makes exotic formulae a little bit simpler. Normal people use degrees (a full circle is 360 degrees) for historical reasons (ancient Babylonians used it, therefore we use it). Easy to convert between them: radians = degrees * pi / 360.0 degrees = radians * 360.0 / pi