Crap 0.1 first assembly project

Show us what you're working on, (preferably with screenshots).
Post Reply
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 45, 320 days left!

Well things are starting to come together, finally got my arse in gear and set up a virtual sd card image so I can start organizing the project files properly. It also makes backups simple as now I just copy and paste the image at the end of the day with a script.

For the curious if you are on arch linux... assuming you want to manually create the virtual card/image. And not depend on some cute gui/tool that you didn't write yourself..

Before you read on and get frustrated, and rage quit. If you are trying to create a bootable card, this is not the poorly written tutorial for you. Sadly this method can't generate bootable images (I know I cried myself to sleep over this feature fail myself the first time..) But for creating regular media images this method works just fine. ( hint your missing the bootloader padawan. )

The way you create a bootable image is a bit esoteric manually and would only confuse the potato's amongst us reading the tutorial who just want a regular card image.

First create the image file using dd, I decided to go for a 4 gig card, that is big enough not to worry about having to use multiple images to store asses and binary files but its also not too big (but in fairness if you wanted to target a 64gig + sd card you just have to bite the bullet and use exFAT.) A lot of this is going to depend on your target. You need to go check the technical documentation on what it can and can't handle, what file system it is expecting, what the maximum card size it can take is. Had I gone for 1gb card image then FAT16 would have made more sense. I guess 4gig is just on that threshold where FAT32 makes sense.

Still you might have a target with older firmware for the sd/micro-sd reader so I will include the options for different sizes. It's just a matter of changing the value used in the dd command but if you are as much as a potato as I was your need some guidance/hand holding. Plus dd is not the sort of command you want to just play around with :lol: (its not jokingly called 'Disk Destroyer' for nothing) In addition for very old device targets you might need to use FAT16.. (I don't know you might be targeting some old school hand held thing..

Yea you can have some pretty large FAT32 cards but past a certain point performance starts to suffer and you really should just go for exFAT (assuming your target can support that).

Going bellow 1 gig switch to FAT16..

Remember exFAT is going to need a slightly different command syntax (don't worry I'll add that as an example just in-case you are reading this from 10 years in the future with a 10tb sd card image..)

You might be really pushing the edge case of life and need to use FAT12 (welcome to 1977) Ok I won't judge you...

32gb card

Code: Select all

dd if=/dev/zero bs=1M count=32768 of=mysd32gb.raw
16gb card

Code: Select all

dd if=/dev/zero bs=1M count=16384 of=mysd16gb.raw
8gb card

Code: Select all

dd if=/dev/zero bs=1M count=8192 of=mysd8gb.raw
4gb card

Code: Select all

dd if=/dev/zero bs=1M count=4096 of=mysd4gb.raw
2gb card

Code: Select all

dd if=/dev/zero bs=1M count=2048 of=mysd2gb.raw
1gb card

Code: Select all

dd if=/dev/zero bs=1M count=1024 of=mysd1gb.raw
512mb card

Code: Select all

dd if=/dev/zero bs=1M count=512 of=mysd512mb.raw
256mb card

Code: Select all

dd if=/dev/zero bs=1M count=256 of=mysd256mb.raw
128mb card

Code: Select all

dd if=/dev/zero bs=1M count=128 of=mysd128mb.raw
64mb card

Code: Select all

dd if=/dev/zero bs=1M count=64 of=mysd64mb.raw
32mb card

Code: Select all

dd if=/dev/zero bs=1M count=32 of=mysd32mb.raw
16mb card

Code: Select all

dd if=/dev/zero bs=1M count=16 of=mysd16mb.raw
(I remember my first sd card for my camera was a 64 meg.. (*wipes tear away..)

Ok now you have a raw file, congratulations - you did it and your system is not borked. (well were assume things went ok because your able to read this..) If not, well you have brought shame to your ancestors - go sit in the corner as your system is restored and try again later. All jokes aside. We can't just run off mounting our new card image, because its not formatted yet. Hold ya horses... to format the card image do the following.

get on your big boy pants - were going in as root. If you don't have root access beg the person that does to complete the following steps...

Instead of mysd.raw use whatever name you used to create the card image.. if you are using a different file format (FAT12, FAT16, exFAT or the various other formats... if you are using them your know what they are..) use that instead of FAT32 obviously. But I am going to assume a simple potato like myself is going to stick to something middle of the road size wise ( >2gb <64gb ) and so FAT32 is going to be what ya need to succeed.

For FAT32 cards

Code: Select all

su 

mkfs.fat -F 32 mysd.raw

exit
For FAT16 cards

Code: Select all

su 

mkfs.fat -F 16 mysd.raw

exit
For FAT12 cards

Code: Select all

su 

mkfs.fat -F 12 mysd.raw

exit
For the big boys...

exFat cards

Code: Select all

su

mkfs.exfat -F mysd.raw

exit
Ok cool the last part is perhaps the most obscure - because of some platform changes that happened back in 2012 to arch. A lot of the guides and tutorials that you will find on the interwebs for Linux will fail you hard in this next step.. most distros have the removable media live in a directory /media/ at the top of the file system.
In arch this is no longer the case fear not for I have shed the tears of frustration and rage so that you don't have too.. It's actually close by.

enter the following.. continue to wear your big boy pants in root. Like before if you don't have root access - beg the person that does to help you with the following step.

1 create a directory called sdcard in your media directory.. this is located in /run/media/<name>/ at the top of your file system. It doesn't have to be called sdcard but as I am the one writing this I got to make some choices right?

obviously when you see <name> look at what your actual account name is on the path.. don't know how to do that.. cut yourself just a little.. not too deep. the pain is the best way to learn. :lol: ok joke don't actually do that...

Code: Select all

pwd
look at the output, drink it all in. ok assuming you are in /run/media/<name>/ you should see something similar but your own systems account. use this instead of <name>... you get it?

next the finale! We mount the newly formatted card.

Code: Select all

su 

mount -o defaults,umask=000 /home/<name>/<folder>/<file>.raw  /run/media/<name>/sdcard/

exit
Ok like before <name> is your login, <folder>is whatever you called the folder you have the card image stored at on your system. <file> is the card image file name. you get it?

Assuming it all went ok.. savour the win, you now have the card mounted and ready for use. When you are done for the day, you can just unmount the image.

Code: Select all

unmount /run/media/<name>/sdcard
Remember to back up your image for safekeeping. at the start of your next session just go through the mount step and you are ready to rock out with your card out :lol:

Having gone through this manually the next logical step is to create your own script to handle the process or if you are of the FORTH persuasion - a set of words to create a tool that will handle the process. (Come on you knew that was coming..) Because I don't know about you but I don't trust myself messing with dd manually at 3am in the morning..

Once we have the script set up or alternatively a shiny new set of FORTH words we are all set to create card images of any size and format we want till our hard drive space runs out.

One thing I should add is that there are some really obscure settings you can use when formatting the image - its best to check the documentation but if your platform is mentioned then use that switch.

Anyway we now have a reliable way to generate images for use in development projects. Someone wants to see what your up to you just upload the image (assuming its a reasonable size / depending on connection speed and storage space that is going vary from person to person but don't be that guy that uploads a 4gb image with only 200mb of data on it.. ) to the net or burn the image onto a real media for them and they can walk away. No annoying searching for files or wondering if paths will work. This saves so much time.

The use case is your friend walks in asks to take your project home to work on, you ask if you can email him the files he then complains about how long that will take, can't you make it easy? you then ask him for his sd card/usb stick. You then promise not to look at his porn stash as you copy your development card image to the drive/card and he walks away happy yet oddly ashamed. And you now spend the next week poking fun at his choice of fetish subtly in front of unsuspecting friends and family. :lol:
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Well project time today was spent backing up my hard drive (boring but if I don't do it the laptop will explode and take all my data with it.) While this was happening got to do somthing I was meaning to finish for ages - setting up atari800 and getting the roms and carts all ready. Why? as far as 80s development machines go its not a bad choice, you could have a 6mb hard disk, ram expansions and lots of software. Lots of fig forth got written on the 400 and 800. My plan is test the high level forth stuff using the atari then when its ready run the definitions on the spectrum.

As it stands with the spectrum, developing natively is a bit of a pita. I have to dick about with tiny memories using the stock machines and if you load forth it leaves you with only 18k to play with. vs 1000k...

I thought about using the pentagon but that has its own issues, but to be fair a very cool machine.

So now I have a fig forth that is fast has a huge memory, this makes working through the old forth journals/periodicals so much easier to follow as there is no need to port the code to the new standard it will work right out of the box.

Probably don't need 1024k but nobody said no to bigger right lol?
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 46, 319 days left!

Got wine displaying at a proper dpi for fonts! :lol: no more trying to strain my eyes to make out the menus.
So that is good.

Project time was spent marvelling at the Corvus disk setup. :lol: It has to be the single best hardware you could get for the Atari. For a developer with the equivalent of 5k usd (in today's money) burning a hole in his pocket this 6mb drive is the business. The wait time to load from the hard disk is comparable to a modern machine.

The widget used the two joystick ports of the atari to get a parallel data bus, (thus the speed).

Internally the drive is split into a bunch of floppy disk sized partitions. But because this is a hard disk, and its always spinning. access times are fast. You just copy across the applications you would usually load via floppy disk and assuming there was no annoying copy protection you couldn't remove. The applications load at a fraction of their normal load times.

No more going for a coffee while the project files got backed up :lol:

I spent the day playing with ValForth - an already fast forth for the Atari, lol now its just nuts. :lol: I thought the openmsx was impressive when you pimped out the emulated systems but its got nothing on this.

Watching Amoeba debug at a speed like it was a threaded application is something else. :shock:

This has a cascading effect as it now means all the time you previously would have waited for disk access, swapping out floppy disks, waited for copies of files that is now gone...

To put it into perspective, I didn't get load times for applications like that till I had windows XP and a bunch of ram.

MSX is now in position 2# for nicest 8 bit dev machine I have ever seen. :lol: (I know what your asking... #3 BBC Micro with the Z80 coprocessor, hard disk, and econet)
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Update:

Got the program launcher working nicely with wine applications, this also has a side-effect that I can now use zxpaintbrush properly :lol:

The atari emulator also runs under wine so that now works with the program launcher one key press and I can launch the 6502 development tools, all running natively on the atari 800 and ready to run.

To get my files out of the atr disks, I have a utility that can extract the files, and pop them back once I have edited them on the pc. This means all of the productivity software and tools for the atari I can now mess with and export simply.

what this lets me do is share assets like the graphics, and listings across platforms simply. I can take my asm files that SevenuP creates and use them in the atari 6502 development box. But if you were really going to be a purist there are a number of pixel editors for the atari. But its easier just to use the same tool for everything I think.

This also means that all my fig forth stuff I can write using the atari then anything decent I can just curl out a floppy disk image then have the utility diddle the files to PC ready to do whatever.

This would also enable me to use the code editor to write assembly for the specy, write to the disk then have the utility diddle the files, ready for the pc to then assemble in pasmo. I do this because I can get better reliability with the atari editor, its faster than sublime text editor and its easier to use. :lol:

I'll add some screen shots later (for those playing along at home.) It just blows my mind that something that was written at the dawn of the 80s still owns an editor that is supposed to be the panacea of dev tools. :lol:

Ok here are the screen shots.

Atari intended this only to be a macro assembler to improve the speed of basic programs. The theory was that users would create subroutines they would call from Atari basic. But due to the fact Atari subcontracted this project out to a pretty kick ass development house they totally over delivered and created a brutally effective application that was used for full blown development of assembly projects. :lol: once the copy protection from the disk had been removed of course...

Image

Image

This was the in house debugger for Atari, it was only recently re-discovered but it has everything you could want. The nice thing is amoeba is tiny, fast and has lots of features. You pair it up with the macro assembler and that is a killer combo.

Image

The third tool Atari Program Editor - This is highly customizable code editor. As you can see I have it set up to have a kind of pigs intestines pink when ASM files are being edited. But you can use whatever colour you like. Its a nice way to differentiate between source files. I really like this feature. Its very fast as you would expect and easy to use. Just like a modern editor. But this one loads in less than a second. And has no slow down, and never crashes. Unlike Sublime editor lol. :lol:

Once I have it completely set up, will have z80 extensions show up as orange, the forth extensions will show up as green and basic as black.

Image

Image

Corvus tools +dos, once you get the hang of the commands its pretty straight forward, the menu is all based from one letter key presses. Its very fast also. This is what really makes the thing shine is you can have floppy applications on the Corvus drive running with almost no delay because the write / read times are so fast.

Image

Image
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 47, 318 days left!

Today was mostly a rest day - good to take a break now and again and re-charge the batteries. That said I still ended up messing around with the Corvus atari box :lol: Trying to figure out the extent of Amoeba's patch capability. But to be honest I was such a potato it was a good way to really learn how to use a debugger :lol: to let you in on a secret I haven't been using one for the spectrum. :lol:

Once I figured out what the thing did, and what I could do I face palmed as many of the errors I had with crapchess could have been traced using zeus (lets not go crazy, fuse's debugger needs a lot of love for it to have similar functionality.). So in a roundabout way I made some progress with crapchess in that I am now comfortable using the debugger features so that should catch a lot of the stupid errors I was making each build.

On the plus side the documentation for the Atari is really solid. You seem to have had more of a market for professional books. So everything is there to create a really slick program it just takes some effort.

But with the added advantage that you have lots of support processors/hardware in a way its like a 6502 MSX. A lot of the headaches you get with the spectrum are taken away and you can be very lazy in programming for the Atari.

I had a look at the 6502 mnemonics and they are not all that bad, the Lance L books are essentially the same across processor families just a straight port. So having read through the z80 book his 6502 book is pretty easy to work through. Though dry, the guy goes through everything and gives you a bunch of subroutines that are functionally equivalent across both processor families.

This is what would need to be done for crapchess, have each of the subroutines implemented in both the z80 and the 6502 - where things start to branch even further is when you need I/O. but that is really the only difference + the memory map for the target.

What I am thinking is have the different targets have there own library. That way I can just compile the version I need to test.

In the case of the 6502 the process its-self is different but its not a crippled cpu like say trying to get the z80 code to port to something like a 4004. I think a 6502 port could be done. Just the question is do you want to make a good port or not to the targets within the family.

For instance, I could have the code mostly use the 6502, and have the bare minimum of I/O code. This would require only some changes to the memory addresses used and stuff like figuring out where screen ram lives, the keyboard buffer. That's it. For a lazy port that is totally viable solution but the game would not take advantage of the target systems support chips. and Would probably be slower than it could have and definitely a lot less flashy. (Looking at you ZX spectrum ports on MSX) lol...

The problem with the MSX is - while its got extremely good system design, and its well documented that documentation is for the most part in Japanese. But in fairness there is a lot of good websites and documents to help its not the same as what you find with the Atari.

I think a middle ground can be taken, for logically designed systems with well documented systems its a lot easier to write the libraries and do the port. Because this is ultimately my hobby, its not like I am getting paid to do this so I will just target the systems I find interesting. I can always do more as the mood takes me.

The Atari 800 is well documented, feature rich and has a lot of tools (cough cough the corvus systems). I will do some tests and see if its as straight forward as the books make out to get the atari to bend to my will. :lol:

Anyway enough wibble, time for some action. :lol:

p.s

I did look at the Beeb, and even (spits) the C64 but it came down to two things.

1. the corvus development system is all kinds of awesome.
2. in the case of the Beeb - a lot of the websites are gone. Stairway to hell is for all intents a pay to play site now (you can pay for other peoples material) and all of the previously free stuff is taken off line. So I was less keen doing a beeb version.. In the case of the C64. Well - Something just made my skin crawl. :lol: Plus while having a larger software base its documentation is not quite at the same level. Plus I don't get the system design. The Atari is pretty logical. Same as MSX.

C64 seems like a bunch of compromises/hacks. In that its a lot closer to the spectrum. So I think it would be harder to make a good port to the C64. That said I will keep an open mind, never say never and all that...

Image

More of the Amobea debugger in action :lol: I think it says a lot about how easy to use a program is if a potato like me can pick it up.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Heres the Trace in action...

Image
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 48, 317 days left!

Today was cool, for the first time I wrote a sizeable program in assembly and it worked as I had planned, plus there were no errors. :lol: Well compared to where I started this is good progress.

So yea looking at a lot of the wonderful demo's on the spectrum got me thinking, I wanted to see what I could do with just a screen and some udgs.

Reading about token systems for displaying data got me thinking. Wouldn't it be great to have a program that did something with counting in another number base. Now there are many for hex and binary. That is a path well travelled. I thought why not base 20?

I can't have been the only one who wanted to learn how to count like a Mayan?

:lol:

So this also in a round about way links into the conversation about background tile techniques before. The UDGs are the most basic elements to construct a user interface. It makes sense to really nail this before going onto doing different sized tiles on the screen. Sure it looks crap - but that is because of my lack of pixel love for the UDGs - given enough time they could be made to look a whole lot better.

Image
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 49, 316 days left!

Spent today realising the implications of thinking of the permanent colour values passed to various rom functions as a matrix of continuous values. This makes selecting background and foreground colours pretty straight forward and could easily be implemented in a function. This is something to work on for later. Other than that - created a list of the 16 'bad' colour values that will result in both ink and paper having the same value.

All pretty simple stuff, but still its the little things that get you.

Second part of this was figuring out the most efficient way to preserve my registers when calling subroutines. I am thinking of just a set of register pair pushes to the stack then pop them after. At first I was concerned about the time spent pushing and popping each subroutine call but from a sanity stand point it makes much more sense just to do this each and every time and just eat the performance cost. The amount of hours I have wasted tracing bugs and implementing hacks to get round the register values being trashed after a subroutine call are embarrassingly large. There came a moment where it dawned on me that fixing the trashed registers was causing just as many problems as it was fixing, took a lot of my time and was unpredictable compared to just pushing and poppin' the stack.

Still I think its best to come to these revelations by your own pain and suffering otherwise it really does not sink in why you need to do something. :lol:

Aside from that my project time was taken up accepting that markdown was not going to be good enough to do what I wanted with documenting the project as a final product. The major sticking point is that there is no way to create multi column displays. Other than that it was ok. But I recalled that LaTeX was not all that bad. I found some good guides and sure enough you can create some quite nice presentations, documentation documents with not much change from the markdown. This made me happy. Y'all will get to see the fruits of this shortly. I figure its easier to read if I organize all my wibble into a logical flow relating to the various programs, techniques, topics.

Like for example, I wanted to find the code I used to block copy a screen to the display memory space I had to search through 17 pages of project talk :lol: I got irritated and I am the one that wrote it so I can only lament at what others must be going through. :lol:

Today was good as I now have a clear idea what to do to get all of the previous programs you have seen in this thread finished and working properly. Crap chess/Noughts and Crosses and the Mayan counter. The plan is to use a standard set of subroutines across all programs to cover stuff like I/O, maths, and graphics. That way it will cut the time needed to fix each program. Sure there is some unique portions of each program that need to be written to make them work properly and make sure that all my register values are preserved but its not such a big job as one might think. Plus when I have finished I have a reliable set of tools to use in the next project.

It's true what is said as soon as you are close to finishing something you will want to re-write it. :lol: But this iterative development stuff is ok it needed to happen as I was so embarrassed by what I had written before I had to do something to fix it. I figure a couple of more cycles like this should result in a tight set of subroutines.

The biggest change you will see compared to before is colours, lots more colours. The attribute clashes are going to be over as I am now at a place where I can start to use NIRVANA+ to handle the graphics. I did sevenFFF tutorial and it totally ruined me :o :shock: seeing what could be done on the crippled machine that is the spectrum left me with a feeling like 'I have to use this, there is no going back.' Haha I don't know about you but once you see it its hard to go back..

It might not look like it but I learned a lot from when I started this, reading through the thread awared me to that :roll: (well there is only one positive direction to go from 0)... So much time wasted on blind alleys and not following simple advice/concepts. But then what do you expect from a potato.

Here is to finishing the damn thing. its almost day 50 for f*^& sake and still no working program. :evil: Why do this log, well I think its a good way to make myself accountable and stick to my goal. Don't get me wrong I enjoy the process of creating stuff for the spectrum and its a lot of fun finding out about its quirks and 'features'. But were it not for this long thread keeps me honest. I tend to get distracted with many projects. And in fairness the spectrum is a pita to program for compared to Atari. (But not C64 it turned out.) At a stage now where I can implement my subroutine library for multiple targets. this completes one of the stated aims of the project to get it working on multiple systems.

It was perhaps the most ambitious part of the whole enterprise but then I am reminded of this
A man's worth is no greater than his ambitions. -- Marcus Aurelius
and
The great proof of madness is the disproportion of one's designs to one's means. -- Napoleon Bonaparte
:lol:

So here is to a working resolution to the project, with 3 working programs each working from a common library of subroutines. Each using the Nirvana engine. Each with the ability to be easily ported to different systems. Each fully documented, properly tested. And finally and most importantly finished.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 50, 315 days left!

I am now an enemy of Greenpeace. Lol I have in my grubby hands a hard copy of the Interface I rom, the spectrum 48k rom and the atari OS rom II b. :lol:

It is so much easier to figure out what's happening when its on paper and not scrolling around on a screen.

The 'easy' printing setup took 15 steps to manually install cups, the drivers, configure cups and set up a print buffer. Yup its one thing arch is its user friendly. :lol: Anyway got the documents printed that's all that counts.

I think once I understand the rom & the interface I rom that will give me a big advantage in deciding what to use and what to implement myself. Plus being able to see exactly how they set things up and try and figure out why is a exercise in itself. I enjoy that kind of puzzle. Trying to figure out a equivalent in the atari os is going to be the secondary task.

The big win there is even the bog standard source code listing was almost 100% commented to the line level. It is a lot easier to figure out what's going on. Once you get over the mnemonic variance - its so well written even a potato like me can appreciate the skill that went into that.

Next on the list is organizing all of my previous source code, log book comments into a more logical and searchable way. catalog all of the subroutines used. any bugs that need to be fixed on a todo list and the outstanding subroutines to be written. Once that is done then I have a clear idea of what needs to be created from scratch. Will then go back - refactor the earlier work to make it slight less potato then tackle the unfinished parts. This I think will take about a week. (not the rom study lol the re factoring of my own code...)

while I was waiting for Bono to zipline in and try and double tap me for abusing the planet I had a look through at my work and its further along than I remembered in most cases. Things are not looking quite so bad. For the spectrum versions the end is in sight for CrapChess, and for the mayan counter. Bizarrely noughts and crosses is going to need some major love as I seem to have written it in a frenzy period where things were just slung at a wall and I saw what stuck. :lol:

Tex typesetting is a pita but it looks very nice. All the pain will be worth it once I get it finished. The packages you can use with tex are like crack you just want to use more and more of them. When I saw how with a bit of pain I could create a microdrive byte map diagram I was hooked.

I was planning on going straight on to doing some more tools/games after I finish the ones I got on my plate currently but I think my time would be much better spent taking some time out once crap chess and the other two are done and going through the roms and really getting 'gud' I can bore you all with my T state analysis of the various subroutines and variants. :lol: you thought it was dry now you have not seen anything yet.

But not to fear, it will look pretty and be a whole lot easier to read.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

I been such a potato - the answer was right in front of my face the whole time.

Forth can directly manipulate memory, in a ridiculously easy way. therefore a cross compiler is just a matter of

1. writing the byte code to a area of memory, advancing some sort of pointer address and looping till you are done creating the binary blob.

2. When the blob is created in memory - write the blob to a device (tape/disk/paper tape whatever) then take it to the target machine and load the blob into memory and run.

For something like the Z80 your talking 252 words. Probably to make it a nice 256 you would just have the unused words be nop.

So a Vocabulary of 252 words, the core forth vocabulary + a sprinkling of initialization and load save routines (talking a handful of words) that wouldn't be such a crazy idea.

A byte code poke is nothing, its like at most a line in forth. even for the most complicated of oppcodes.

of-course the program I envisaged wouldn't be good at making decisions on things like labels and the like so the design of the code would involve a bit more hand holding than usual but for the moment it at least answers a question that was plaguing my potato brain. :lol:

But when you climb the mountain you only realise there is just another peak in the distance. a 2 pass cross assembler is a much more complicated beast. My 'skills' would have to be on another level to write something like that. but one day.. haha.

Telling you a cross compiler in forth or action! would be the business.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Update:

Well I am writing this using the Lynx browser. Why you might ask? well thanks to a broken system update my arch install can no longer run programs with GNOME dependencies lol.. Untill it gets fixed im stuck using terminal software and non-gnome stuff. This makes things a bit more of a challange to use. But I figure the mesa drivers are going to get a bug fix in the next few days and things will be back to normal (this is what happened last time in November lol..) Hopefully this will post correctly. I can tell you its a bit weird using text brower to use the net - it feels like I am back in the BBS days lol. Still your be glad to know the forum works OK. Despite all these problems the pdf viewer works and vlc so I can in a round about way still watch youtube lol I just how to use youtube-dl first. Bizarely one of the few apps not to be affected was Wine. So I can still do all my dev stuff just not with sublime text. If I could get used to the interface Lynx is really very fast... Progress on the project is going pretty good in a bizare way this is actually going to accelerate the development as I don't have any distractions not even pictures anymore haha. I might be a bit slow to respond to personal messages because of the way the interface works here.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 51, 314 days left!

Luckily the Mesa drivers got an update after I wrote the update post, it's still not perfect and it looks like programs with Gnome dependency's are still borked but at least chromium is working.

As a precaution I re-installed all the packages hoping that the new build would help matters, it didn't but it was worth a shot. On the plus side I got a lot of reading done in the downtime.

Getting better at tex beamer so expect some nice presentations :lol: I think that is a much better way to communicate what I have been doing in a more understandable way. I can then go through each part and show what the program does in a much simpler and logical way. It's also easier to take in in bytesized chunks rather than reading this dribble.

The other side effect to doing things this way is I can explain what I am doing often a lot more concisely with math notation. I think it will help others review what I am doing as its easier to spot my mistakes that way.

Other news: Found the source code for the corvus drive. Now have the manuals I need for the Atari. I wish there was a similar book for the spectrum to the 'Atari Technical Notes' :lol: They wrote a book that you could give someone, along with the hardware guide and a 6502 assembly book (probably zaks or Lance L's) and said 'go away - learn this and give us a game.)

Obscure subroutine corner: While reading a random paper about Danish folktales. They had studied 30k of folk tails and defined what was far-away/outside vs inside, the most likely location to find treasure, witches, robbers and monsters. So With these boundaries (no tale mentions anyplace further than 250km from the story teller and no closer than 10km) Why does this matter - well you can use this data to generate lore for your adventure game.

Each location is linked to others in the world. there is some way to measure distance from A-B. Therefore to generate lore for each point of your world. You just use a map on the location where a location is selected that is |10km -> 250km|. This could be further simplified if you defined the area as first a area of 8 subsets. then finally looking at the selected set to find a point to use for the quest.

That way every time you went to a different location, your random quests would occur in the 'right' places you would expect to conform to a myth structure. (no evil monster right in the village - it lair would always be miles away in a non-populated area.) converse, cunning women & witches would always be close to population areas or inside (as these were the 'inside' threat).

Robbers and bandits are in the sweet spot between population centers and the 'far outside' Because they needed to be within a realistic distance to the population center for re-supply and also to prey upon the people. But they couldn't be inside the population center because of the fear of discovery. They were 'Out' laws for a reason... (well technically, an outlaw was legally no longer a person with rights, once declared an outlaw your status in society was lower than a farm animal. You could be killed on sight by a citizen with no penalty. (But I digress)
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 52, 313 days left!

Finished writing the script to generate the noughts and crosses boards in latex. :lol:

Also done reading the libraries concerning chess and latex. So now can actually write up the source code properly and explain what I am doing in a non potato way.

Third have the bytefield library up and running so now with a bit of tweaking I can show a pretty sweet memory map & of course bit/byte diagram of structures.

BNF notation is also done, that is not really going to feature so much with the current projects but its more something for later with the Forth stuff. That really helps clarify what is happening with the language.

the assembly language code is shown using python pigments (well under the hood).

Other stuff, decided to use the memoir package as that seems to be more all in one solution. Its a compromise but I didn't want to have to learn 5 different 'best' libraries I would prefer something that was just 'very good'

There were a bunch of graphics libraries I looked at but all were lacking, and eventually I bit the bullet and I knew myself I wouldn't be happy unless I had full control and a strong library. So I went with the mamoth Tikz. It's fully featured you can pretty much achieve any graphics effect you want with this. But the documentation takes ages to read. That said its pretty easy to use. The noughts and crosses board is a good example. I could have done the chess illustrations in it but I wanted the extra features that chessboard & xkicks give you.

Found me some really cheesy creative commons graphic art - for my money there is not enough technical books now that have the same type of inexplicable cover art as back in the 80s.

Any thoughts on number of columns? I have been flipping between two column and single column with a big margin to put notes/illustrations.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 53, 312 days left!

Almost done typesetting my project notes! next will be going through and cutting out all the repetition and non-essential wibble. So I think i am going to loose about 50% of what was wrote. :lol:

Not going to lie, LaTeX is a nasty language, I would say its as frustrating as perl to use. :lol:
The one consolation is that once I have the damn template done, I won't have to touch it again.

Besides the typesetting was not a lot of time for other stuff. That said got a basic memory map done for the spectrum 48k stock. Next is going to be mapping the rom routines in a visual way.

For the morbid curious, bytefield is the package you need to do this in LaTeX. :lol:

WIth all that said, it makes nice diagrams, there is even a flowchart package that can be tricked into doing d-diagrams with some coaxing.

While organizing my notes I came to realize that my projects so far have all been positional games. That at least explains my itch to do battleships :lol:
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 54, 311 days left!

Refactoring Crap Chess. Thanks for all of the advice and hints/help you guys have given me.

Lol I got to see the really early screenshots from crapchess. :lol:

The end is in sight now ... finally. :lol: That said I kinda moved the goalposts a number of times with this project.

The thing that has surprised me the most is how little specific code you really need to make a game. Once you have the general routines done its really just the graphics and some engine rules.

Expect noughts and crosses/mayan counter to be done pretty fast. Once Crap Chess is out the way I can just update the routines and badabing badaboom.

Other developments,

Found a really interesting article in ZX computing about using the microdrive for random file access read/writes by abusing the table/buffer. This guy was doing it from basic to avoid '7 second read/writes' so I think doing it with assembly will make it even faster.

His technique is sound but its a fragile method. You really need to have a good idea of the microdrive's current file structure and what read/writes need to be done to what sectors.

Figured I would start trawling for new/novel techniques by going through the archive.org magazines. Started with zx computing as that seemed to be the most neck beard of the z80 magazines.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Update:

While not directly related to the project, the GAP programming language is very useful to anyone wanting to do maths with a computer. How it can be applied to the project - my looking for cyclical sequences can easily be handled by this program. It can generate thousands of sequences that will be extremely useful to creating music on the spectrum.

I really should have looked for this before, but I am a potato. Pretty much everything I was interested in using has already been created and is ready to use. I just have to hit a button and I get the data I want now. :lol:

This also is going to have a fairly large impact of what I can feasibly do - its greatly expanded the set of tools available. I now no longer need to implement half a dozen different algorithms to get the data I want. Its all done already. It completely changes the focus of what I am doing. I don't need to worry about implementation details. Very nice.

Even a potato can do a lot with such a system. :lol:
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 55, 310 days left!

Today project time was spent refactoring crap chess. (sound familiar.) :lol: One sentence covers a lot of work. So.. time to elaborate...

This might not be the most straight forward way of refactoring/defining the problem but I figured why not.

I got to thinking why not define a program as a Set, and all of the parts of the program as cosets of the Program set. Then work my way down from there mapping the features of the subsets.

This turned out to be a very nice way of defining the program. By counting the subsets that had the same name (Like for example GAME INPUT, MENU INPUT, SCREEN A,...) I could figure out just by a simple count what subroutines would need to be focused on, optimized the most and what I could just leave till much later.

One thing that was obvious was the amount of data crap chess needs, and that its a big issue even doing it this way. Game data is one of the major components.

That said the microdrive essentially solves this problem. With the hacks that were revealed by the ZX computing article I am now confident this can be resolved.

I decided to switch the assembler I was using also. hate to be lazy but zeus being able to handle the keyboard input & masks is fantastic. That removes a major headache. Not using the full blown Zeus ide as it looks pretty horrific under wine, just the assembler.

Feature bloat - I figured what is a chess game without a computer player... :lol:
Don't worry I am not alone I found of all things an Atari book that went through the design of a chess program.. in basic. But still it got my mind working on how to do this in assembly on the speccy. The computer will be a crippled opponent (because I don't want the person to have to wait 20 mins between moves.) but that is the price you pay - you can get a window-kicker opponent with acceptable load times or an okish opponent with a fair amount of lag.

Nirvana graphics - what I did was keep my animated loading screen, but the menu is nirvana, and also the main program. While its not exactly going to set the world on fire it does make designing tiles for chess a whole lot easier. I wish I had known how to use Nirvana from the jumpstart. :lol:

What happened was I was about done doing the write up, and I looked at what was there and thought to myself 'I can't put this out, its not a real game yet.'

I'd much rather do something right than cheese it.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Here are some screen shots for the visually starved.

These are the initial tests for the Atari port.. (Done during my laptop having that disaster mesa update where I could only use wine :lol: )

Internal clocks are nice, Atari Basic has some unusual design choices. Lol I can see why most people went for the Microsoft cartridge.


Image

Image

One really cool feature is the ability to have a cassette tape have one chanel set as an audio stream and the other as a data stream. What this lets you do is have audio from the tape play along with the program. You can do really cool things like show images and data on the screen as you have a narrator talk in the background. I wish there was a way to do this with the spectrum.

What this lets me do is add a nice feature to the Atari port. The chess tutor can have someone talking you through the moves/problems on the screen. If the player picks the wrong move then you can tell them they are a dummy / explain the proper move.

That was just my back of the napkin idea but there are many other applications. Atari used this feature to do the 'invitation to programming' course. But this technique was used by 3rd party developers to create extensive course ware. (but in this case they had a custom encoder that took until 2015 to be cracked :lol: )
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 56, 309 days left!

Search depth, and 8 bit limitations.

When evaluating moves in chess you come across an intresting problem. if we try and just evaluate every possible move you get an situation of eponentially increaseing choices in the search tree. This is fine for say a 64 bit multi processor machine.. (to a point) but on the 8 bit machines with much more limited processor power its a real problem.

Lets just throw a number out there. say to evaluate a position it takes 0.1 seconds.

We evaluate 10 moves at level 1, this takes 1 second.
level two we have 100 moves to evaluate that is going to be 10 seconds..
level three we have 1000 moves to eval.. 100 seconds (still ok..)
level four we hit the wall with 10,000 moves to evaluate giving us a whopping 16 mins and 40 seconds..

The problem is even if we go to level four its still not really enough just to brute force a positional evaluation of the board space. A good human player is going to be able to plan four moves ahead and so might have set up a trap for the computer. What we need is the ability to plan the moves perhaps 20 moves ahead.. to be sure that the human player could not possibly have planned so far in the future.

This is a real issue because say we just take the fact that the machine will sit there for 16 mins evaluating one move, we go to level 5 and it gets much worse.

Level five we have to evaluate 100,000 possible moves or 2 hours 46 mins to evaluate a board position.

But hey its research right? I bet someone would let it run for 2 hours + on one move... correspondents chess style.

Level 6 gives us 1 million moves to evaluate .. that now brings us to over 27 hours to evaluate a move. Still ok for postal chess.

Level 7 gives us 10 million moves to evaluate 11 days I think the patients of even a postal chess player is going to be strained at this point.

Plus we have to consider even if you are dropping the non-interesting branches of your search tree you are going to get into serious problems way before this point with the 8 bit systems.

Anyway.. just to push home the point that a pure positional evaluation is not enough for 8 bit. Probably the best bet is going to keep our 3 levels of positional evaluation but add on a bunch of rules to help focus the search tree. And also spot obvious gotcha's. One idea I have been thinking of is this.

Write the move evaluate to focus on control of the center squares (what a human would be doing anyway). Have a table of most probable moves the player will make D4|E4... and have a book of lines ready to play. There are play styles for black that can really annoy a white player by shutting down opportunities early in the game. If the human player lets crap chess do it, it will follow such a plan. Thereby overcoming computational limitations by just playing a very solid defensive/smothering opening against white.

A good player will still crush crap chess at this point. But we force a draw with the majority of potato players.

One of the big challenges is stopping crap chess being so reliant on a material count. Good players know that typically a computer player is going to be greedy to the point of loosing a game (by giving up position for points). By having it follow book openings somewhat mitigates this till the middle game/end game. But its still not a complete solution.

There is another way though, its very cheesy but crap chess through the interface I could 'phone a friend' and offload the evaluation. :lol: I think this is cheating though. You could just hook it up to stockfish and badabing badaboom it would crush the player every single time. :lol: would be a funny joke to play on your friends when they are around. Especially the chess nerds "can you beat a spectrum chess game?" Then watch them get wiped.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Update:

The Atari book while being a bit of a flawed diamond in terms of usefulness (its actually a well written book, just by a guy without much depth of programming know how..). What I respect about the guy was he held his hands up and said flat out he was not an expert but pointed the reader in the direction where to go to get better info. (SARGON listings). For me that is one of the more classy moves I have seen in a period microcomputer book.

While the book itself is not state of the art, its a nice practical introduction, you then take that and apply it to the more slick (well for 1979-85') techniques. There are a ton of academic books on computer chess from this period. Reading how SARGON/SARGON II/SARGON III was developed is great. I recommend this to anyone contemplating developing a 8-bit computer chess.

There are some excellent articles in BYTE on computer chess written by the programmers behind SARGON. What is nice is it was written in z80 assembler. But Sargon got ported to many different targets.

What I like about the Sargon system was they were never satisfied and really pushed the envelope of what was possible. Not just a 'grinder' there are a bunch of really interesting techniques being used to get the most out of the 8-bit machines.

The plan is to get a computer player with an ELO of around 1600. (Around SARGON II rating) That would be quite something on the spectrum. To put that into perspective that is your average club player. With the microdrive you can have quite an extensive opening and endgame book to cut down on the amount of calculations the engine has to make. The limiting factor as I said before is the time the engine takes to evaluate the moves.

Here is the listing for SARGON (the first one.) I think you can see why I got excited - points to note its designed to work with CP/M but that is no big deal. The big advantage is this is z80 baby.. It's the logic that is the most important things. Everything else is pretty straight forward to get working on the humble speccy.

To play along at home follow the link as there is to much to post here..

If you are anything like me, your first instinct was to save then print the listing.

http://www.andreadrian.de/schach/sargon.asm

This answers so many implementation questions I had. Ok its not SARGON II/III but this is way better a spot than I was 24 hours ago.

Being able to see how someone else did it is a great help.

Also well worth a look is ...

Alan Kotok's thesis http://www.kotok.org/AK-Thesis-1962.pdf
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Shout out to Marek Strejczek & the Technical University of Łódź,..

http://www.top-5000.nl/ps/SomeAspectsOf ... amming.pdf

This is a great overview - while the project was done in Borland C++ much of the research and theory is very useful.

So you get the Byte magazines, and the links above I think you are at pretty much the same stage with regards to research documents. Now comes the fun part. The analysis and then the coding. Much of the heavy lifting has been done already thanks to SARGON but I think that some improvements can be made to the Opening book and the end game analysis part.

The only thing I couldn't find a copy of annoyingly was the book written by the Spracklen's. Sargon, a computer chess program - This is deeply annoying as archive.org has a copy but its part of that book loan thing. So essentially unavailable :evil:

Still have the source code, the articles. So I think its going to be ok. My thinking being that they would have put the meat and potato portion of the book into the articles.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 57, 308 days left!

Today's project time was spent reviewing all of the books/articles regarding creating a chess engine for a 8-bit computer.

To give some insight into what is happening though. (for the morbid curious)..

I have been agonizing over the choice of board representation, really we have two basic choices when you write an engine. Piece centric vs Square centric. Crapchess has been a square centric design but this really limits what you can do when it comes time to write the analysis functions later.

If you have the chance most advice seems to be to go for a Piece centric bitboard design.

I will make the finally decision probably in the next day or so after I have slept on it. But unless something radical happens I am fairly positive I will go with a bitboard method.

After that is the next coding challenge - that is getting crapchess to have a set of the complete rules of chess that needs to have no errors. If I screw this part up the whole program is borked and it would require a complete rewrite. It also requires a decision to have been made about internal board representation. (how you explain the rules is in terms of the internal representation, so its different for square centric programs vs piece centric programs.)

The GUI for crapchess is already done (luckily). It's just a matter of plugging the engine in.

I was reading a port report on SARGON from a guy who had converted the z80 to 8080 code. This took him 6 months working every night. The scale of these engines is really quite something. It easily dwarfs every other part of the program in terms of complexity.

I am convinced you can get a semi-decent game of chess from a spectrum. These fellows were getting competent results from z80s on other platforms, stuff that beat engines running on mainframes. So there is no excuse.

But I will say this, I am fine with the engine being crap if it looks like I won't be able to complete the project. Just getting crap chess playing the game is ok. I can always come back to it and do an update once I get better.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 58, 309 days left!

I slept on it and I am going bitboard :lol: it makes it a bit more complex to implement a piece centric board representation for crap chess but the gains in doing so can't be ignored. And for the z80 you need every advantage you can get as we can't just build a grinder type engine. (the humble z80 is just too slow.. yes even an z80e..)

Todays development time will be spent creating a bitboard for crapchess.

Additionally, further reference works are needed for review. I have an idea how to offset the move evaluation but I need to check first against the theory books if I got it straight or not then search to see if anyone has (hopefully) implemented it.

The plan is to focus on a handful of openings, like I said before strong openings that smother the opponent and give the greatest chance for a draw. After that its just a matter of building a table of moves. This is one of the simple parts of the program to understand. The decision comes do you want a very wide but shallow opening book or somthing with a lot of depth? The issue with a shallow opening book is obvious. We have lots of memory being used for a bunch of moves we will never use.

You could overwrite the opening book after the game has moved past the initial n moves, but then that requires you reload the game every time. (but its a legit strategy..).

The second problem faced with a shallow opening book is that is not really how a human player plays chess. Usually a good player has a few openings that he/she will use based on a few key variables in the opening phase of the game. I want crapchess to behave more like this so I would prefer it had a fairly comprehensive understand of a handful of openings than a whole bunch that might never get chosen.

The nice thing about the smothering style openings is they generally give the player a very solid base for the middle game, mitigate risk of opponent gaining too much influence in the center squares and offset as much risk as possible. This hopefully leaves the computer in a good position to perform board evaluations without the help of the book.

The trick is to know what squares to watch (Hint.. its the center squares, and the positions of both its own and opponent men.)

There is a lot of other stuff you need to build into the engine to make it even competent. Like as a human player you know pawn structure is important. But I think it does not become clear just how important pawn structure is in evaluating moves until you do this. This is actually non-trivial problem trying to get the engine to understand pawn structure and how to identify good/bad layouts. There are lots of simple methods to do this but they all have one thing in common they either take up a large amount of processor time or memory.

What is needed is a way to simplify the representation of a good pawn structure... hmmm. ah well somthing to think about.

I remember from chess magazines sometimes people sent in board diagrams with the scored moves for each type of chess man for every legal move on the board. I think this might help with the chess engine it would cost a little memory but having a lookup table like this would be very usefull.

5 x 64 = 320 bytes.

per side you say... but hmmm. you could just flip the table and you have what you need.

If you are evaluating opponents moves you just negate the value in the table.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Update:

So it turns out there are a number of implementation decisions you have to make from the jump start regarding how you actually set up the bittable. It is important decision because it impacts the whole program.

That said, just picking the bittable gives you payoff when building your opening book/evaluation portion of the program. This is because we can use a powerful yet efficient technique Hash tables. This enables the program to switch between lines in the opening to adapt to the players moves without needing to move out of book opening phase. This is good because its much faster, and more reliable.

There is a more subtle reason to want to do this. With the 8-bit machine we want it as much as possible to stay within a book phase and try and get the maximum advantage. It is actually the most dangerous point for the opponent because when its in book its got the advantage of all these pre-evaluated/tested lines that are known to be the 'best' answer to the opponent. What you do is offset the evaluation to chess history/or a powerful engine that is writing the opening book for the 8-bit machine to use.

It becomes then a question - how much is really the 8-bit machine? When you use the opening book.. This question is one of the controversy with computer chess when the engines have to play without access to an opening book. It can be said its the best way to test the engines against each other but what if you designed the engine to work with the opening book from the ground up? Typically you would not want to build an engine that worked purely off evaluation. That is not an efficient use of the machine. Especially in 8-bit.

If you are looking for information how I wrote the bit board, lol stay tuned for my funky pdf.

It is not as straightforward as you might think :lol:
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: Crap 0.1 first assembly project

Post by Nomad »

Day 59, 308 days left!

Nearly day 60 and I think I have pinned down the specification for the Crap Chess engine.

Needs to have at least a 1600 with the end goal being 1736+ ELO.*

Sargon II by 1980 was at this level and had been kicking ass and taking names for a number of years, it was a z80 based chess programming running on a stock microcomputer. Therefore it proves you can get a high level of play from a z80 microcomputer. As the Spectrum is a z80 based machine. There is no reason why you can't do this on the spectrum.

* This would make it better than 99% of all chess players and better than 85% of all tournament players.

While I am not a husband/wife highly educated set of maths boffins. I do have something they didn't have 38 years of research that went after into the algorithms that are used in computer chess. :lol:

There was evidently something of a crash research project to get a chess computer to a stage where it could beat a grand master. I had no idea the amount of active research there was on this subject during the 80s. Fascinating. Of course what can be applied and what is appropriate to a z80 based computer is another thing. :lol: There are many intresting vector baised solutions that would work just great on somthing like a Cray. Not so much on a Spectrum.

But that is where doing the research survey pays off. For those reading this who are in the dark. Its simple. You take a book describing the subject you are interested in. Look for the bibliography/citations. Now take that list to google scholar or whatever database you use to look for papers. Get all the papers listed. You now have a stack of papers to read on computer chess. This is the start of the survey. Go through each paper and like a magpie look for stuff you want. :lol: The interesting stuff you mention in your survey paper. Why write the survey paper? Because you are going to forget what you read. This is your shortcut to reading the stack of papers later. All of the interesting stuff is going to be in your survey. You get the technical infos from the actual papers/reports when you are coding the engine. But often times you just need an idea or gloss on what to do.
Post Reply