Crap 0.1 first assembly project

[Nomad]

Yea I flip the image in fuse but when I cat it the disk read 0 sector 0 data its like its complaining there are mo sectors. When I try and format it flipped it errors I notice for some reason I have single sided 40 sector drive selected for A so I think that is the problem. I will have a play.

So the stock amstrad disk drive on the +3 was 80 sectors DD?

[Nomad]

Lol now I remember why I wanted a beeb

I can't figure it out, I flipped the disks, changed the drives back and forth from 40 to 80 single and double and still nothing. Its still the tiny drive I remember

[Nomad]

Day 60, 307 days left!

Today's updates, not so much got done today as was busy. But one fun thing..

Here is the creator of Sargon, Sargon II, and Sargon III on Computer Chronicles.

[youtube]https://youtu.be/CnHiSeE-yBY?t=4m10s[/youtube]

You can see that even by 1985 things had dramatically moved on since the end of the 1970s with computer chess. Already you have good computer players and fully featured programs. Now how many people back in blighty had the money for a multi thousand pound machine in the early 80s well that is a small market. (for the Apple II) But its still pretty cool.

In project news.. Slowly comming round to the idea of doing this on the plus 3. Having the memory disk, and being able to swap data easly in and out from the physiical floppy disks is quite somthing. Plus more ram is always good. Only issue is +3 was not so popular and so the amount of information on the platform is a lot less than say 48k.

Anyway assuming I can convince fuse to allow me to use both sides of the disk image It would seem a lot more straight forward to use the disks than the microdrives. This is a little annoying as I spent a significant amount of time figuring out how to talk to the microdrive in assembly but there is no reason I can't do both I suppose. Its never wasted finding out about this stuff I think.

+3 ram use is a little bit esoteric with is many pages

Funny as there was a new series on youtube that poped up that deals with +3 and assembly. So that was well timed.

Thanks to peter's heads up about the Spanish +3 manual. I now can check the diagrams and tables. here is hoping google translate is going to be ok. I think comparing this to the text from the typed in English manual should be enough to check there are no errors.

[Nomad]

Thanks to the kind intervention of others I now have a scan of the +3 manual.



Lol now if only I could figure out how to use the other side of my disk in fuse.

[Nomad]

Day 61, 306 days left!

Major news in the world of crapchess. Ok your all sitting down...

Crap chess is going +3.. Yea I got the disk problem sorted out with a combination of lots of assistance from non-potato's (Thanks Peter and Bob for the assist).

I must have taken a rather large hit to the head before thinking the microdrive would have been a better solution. I can store tones of data on each disk this way with the +3 disks. Plus I get the memory disk into the bargain.. When you look at things like that its an obvious choice.

But for every gain, wadaya loose? Well besides market share (and that is the major issue with going to a +3 system from a historical point of view I just cut a huge chunk of the potential user base.)

There are also other concerns about errors on the +3 board and sound. Assuming the board never got fixed its going to sound more distorted than your stock 128k. But then this is not a demo scene performance - its crapchess. Sounds were never going to be a big part of this. So I can live with the loss.

Ok in light of this change - going to have to do some re-packaging when we use pasmo or zeus as so far as I know there is no way to generate a disk image. So its a case of generating a tap and then copying the memory to disk. That is ok. It's the same/very similar syntax to how you do it with microdrive.

So what did I do after I got the first disk set working - you better believe I backed that bad boy up I think the suffering/negativity/rage that went into the creation of that humble disk image Anyway - now that is safely backed up its time to get busy with the next stage of the project.

Now all of the examples I have for z80 chess engines use CP/M. It would be a lot easier to talk to the grey beards if I were to use the same OS... But I don't have to.. hmmm... This is the next choice.. CP/M gives me some advantages as there is a TON of information on it, lots of people have used it, tutorials, books, magazine articles abound. Most of the source code is going to use CP/M..

Lets just say there are some very compelling reasons to use CP/M in the project.

But going back to the original project brief - I get the feeling that expecting our already dwindling market demographic - someone who now owns a +3 and has CP/M.. who wants to play chess... You begin to see the problem.

That said with the disks, now you can create a very very nice chess tutor, and the opening book for crap chess is really only limited by the patients of the person operating the computer to swap disks. Given that assuming the person is a non-potato and has an organized index of disks.. There is no real difference between a system with 5 disks and 50 or 500... (well besides physical space)

I could have every opening in my chess encyclopedia including the variant lines contained on 200 disks... Just for example.

People were paying big money for a good chess computer/engine in the early 1980s at the high end your talking 1000-2000 dollars/pounds (there seems to have been the same transatlantic markup even then..)

Still the disks on this kind of system would have been a killer assuming we live in a fantasy world where I could have sourced 200 Maxwell CF2 disks for this it would have cost me 800 GBP for the disks alone. But as I remember these disks were always out of stock. But anyway lets assume you could acctually get hold of the kind of inventory you would need.

My guess is a system like this you would have had a demo system... then gone out and bought more disks when you made a sale. Lets face it a 200 disk system is not going to have many sales...

So lets be generous and assume we could get a bulk discount for 200 pieces from maxwell. (Even back in the day probably for bulk orders it would have been a much better deal). So lets say instead of 4 pounds we get a sweet deal of 3.25 per disk. The crap chess opening library would cost 650 GBP at cost... probably the same again for the game database (but you would have a very nice library. My guess is someone would buy that.. have you seen the money chess people spend on books?) Nobody is selling something like that for nothing... It needs a good margin. So call it a round grand for the opening library.

Fine so we established its kinda possible to make a boutique software solution on the +3, and that there is a strong likelihood to appeal to a handful of wealthy chess nerds who probably would have bought the +3 just to use the system if it was good enough...

We have gone a long way from the 5 pounds in the small adds of a spectrum magazine...

[Nomad]

Sources for crap chess.

So I figured the best idea with setting up the strategic rules for crapchess to follow was to use a method that is now called hypermodern system. Its nice because the book that I used as the basis for formulating the rules is extremely easy to read - its widely acknowledged as one of the best chess books ever written. True chess nerds will already know what book I selected but for everyone else..

My System - Nimzowitsch.

The daddy of the hypermodern style. It's hard to overstate the impact that his book had on chess.

Anyway that is getting off topic. What is important is he lays out a system to the whole game explaining each step in detail. Outlining what analytical steps needed to take place. This is fantastic for creating a set of rules for crap chess.

• The center

• Play on the open files

• Play on the seventh and eighth ranks

• The passed pawns

• The pin

• Discovered checks

• Exchanging

• The pawn-chain

The basics gives solid advice, if the program just managed to follow these rules effectively then it would win against most opponents. Against a strong club player there will be problems. But even then you already have beat 99% of the people that will play the engine. getting that last 1% is the really tough part.

[Nomad]

Day 62, 305 days left!

Received dogma and bitboards..

So it struck me today that perhaps; just for a moment. That the received wisdom of using multiple tables of bitboards to represent the board encoding might result in overly complex and expensive evaluation stages to the chess engine.

Especially for 8 bit.

There said it, lol. Seems to me that creating all of these tailor made, situation specific rules might result in just a huge mess of branching if else statements (well from a logic point of view)

Does not not make more seance to go for something that is more simple in the way it represents the board space? Sure you loose in that you can't use quick shorthand for various piece positions you need to pick them out of a board representation of other pieces. However.. everything is working from that same byte table..

Plus with the bit boards eventually you are going to have to merge the information to get a weighting for the board space as a whole anyway...

Smoke and Mirrors - a.k.a using a hashing function to direct a search.

Another thing that occurred to me was if processing power is at a premium (with the 8 bit machines) It makes seance to offset as much of the evaluation to external process as possible. Getting a robust and extensive opening book massively pays off. We can encode the most likely moves that an opponent will play and what we should do to avoid expensive evaluation periods.

All pretty humdrum stuff. I figure use a hash of the board to look up a baked evaluation. As its a table indexed by the hash that returns a move its pretty efficient.

This also helps with the problem of analysis paralysis that these engines seem to suffer from. If the decision weighting is not handled correctly you can end up with a situation where the engine does not know what to do with enough certainty to act. This is a bad spot to be in - but its better to pick a random answer from your set of candidates than waste hours looking at deeper levels of simulation.

My thinking is I would rather have an engine that was fast, that I could improve the weighting of its evaluation function through repetition than letting an inferior version of the engine spend hours evaluating a move.

This then brings us to our final 'revalation'

It probably makes more seance to build the evaluation data using a different machine, then just use the results on the z80. Why because nobody wants to be doing ill iterative learning on a z80 in 2018 . In a matter of days I can do what the humble z80 would have taken decades to perform.

So the plan is come up with a weighted table of values for various chessmen, based on a database of 16 million games. Once the data is compiled - it is the basis of what we use in the evaluation function for crap chess on the z80. But its all done on a modern PC initially.

[Nomad]

Day 63, 304 days left!

Media update:

I woke up to find a disk image that was a true copy of a Maxwell CF2 disk. Thank you Guesser.

This makes things way way simpler in creating the crap chess disk set. No longer looking at 400 files - it has cut the number of images in half. And as a bonus this is how they would have existed were they a true CF2 disk.

Excellent!

Project update:

I have been researching how to create a chess engine in hardware and I found out an interesting secret (well secret to me - the advertising behind these widgets tented to obscure the fact). The vast majority of chess computers you could buy commercially were really microcomputers just packaged with specialized interfaces (usually 6502 but sometimes z80s were used) They might have had tiny memories but the chip was stock and the ROM would have just been a regular program that used a limited ram stack.

Very few had anything like custom chips to do stuff like move generation, evaluation in hardware. It was essentially a software deal.

If you wanted a true hardware implementation of a chess engine, it would have been blisteringly fast when compaired to the microcomputer - but at a much greater cost.

However there were a few examples created usually by research groups and big corporations. You already know one (Deep Blue). Belle is another.

So to get back to the point, a lot of the research that went into these devices that eventually got talked about/published is applicable. As they are really using stock chips to work the magic. The chances of research in computer chess during this period being for non-standard chip architectures are very small. This is great as the depth of research is really something.

All of it is applicable to 8-bit.

Research win!

Ok you remember me talking about how it made much more sence to develop the opening book/rules/play style on a modern system and bake the results then import to the z80 target. This is much closer than before.

There are two systems I am testing - both are written in C. (Well they could have been done in x86 assembly but I don't have time). The neural network is a simple test, it takes four arrays of input and you teach it to regonise the contents of the arrays. It then goes into a loop where it 'learns' to regonise the input and builds a weighted evaluation.

This is only working for 16 data points at the moment, eventually it needs to do 128 but I am very encouraged by the performance. it works to a very fine margin of error (there is always a error in evaluation) but even on a potato system like mine its finishes its training in a flash.

This seems a great way to develop the evaluation weightings that you need. But this is a huge rabbit hole so I side step this part for now. And focus on a more well troden/conventional route.

The plan is to build a program that can generate the data I need for crap chess. This is pretty straight forward. I just feed it the first million games, it will sit and evaluate each ply and generate statistics that are used by the engine on if a move was good or bad, how it affected the game.

What you do is try and predict the outcome using this training data. you see how close the program was in making its guess. if its better than the last time you ran the program. you update the new weightings. if its producing about the same. you don't change anything. if its worse, you don't change anything. You keep repeating until you get a good weighting set.

Now you are confident your engine has a good set of values to evaluate moves, you can now test it against the rest of your data set and see how it does.

Hopefully its good, this data is then what you use in the evaluation function and move generation subroutines for crapchess.

z80 progress:

Found a great little encoder/decoder from the CPC wiki. (thanks SevenFFF). Somehow I missed it the first time. It works in real time and from what I can tell is really nice at encoding sparse data tables. Not sure where this will fit in but if your data is sparse it can save a ton of space. (assume you have a 32 x 24 table, you can encode 6-7 data points, think of it like a star map) Now to do that normally would take 768 bytes. with this encoder you can get it down to a ~32 byte string. very nice.

[Nomad]

Book recommendation:

Well if you are interested in computer chess. Otherwise its going to be dry.

Behind Deep Blue: Building the Computer that Defeated the World Chess Champion - Feng-Hsiung Hsu.

The head of hardware design for Deep Blue's account (mainly of the chip design) that went into Deep blue.

I think one of the weaknesses of this otherwise excellent book is he tends to skip over the software side of deep blue and focus on the nitty gritty of how he designed the chips. I guess its understandable as he was the hardware guy but it would have been a much more well rounded and useful book.

With all that said, its still a great read. I found it to be full of interesting details about the history and more importantly the background to why the guy thought the way he did about design choices. A lot of these type of historical retrospects are dry and boring but this is one of the rare books that finds a way to make a subject you would think was totally boring interesting and fun to read. I read this in one sitting,

If you read the book, he throws various bones explaining at a high/mid level how he built deep blue. You can then consult the literature and read up on the techniques/design philosophy.

I never realized just how much work was down to Hsu. Quite surprising as the guy didn't have a strong chess background. The speed that he was able to design the chips is really something. I had to laugh when the guy called himself lazy, yet managed to design, test and fabricate a entire chip in 6 months on a shoe string budget.

To sum up its a good book, easy read and lots of intresting ideas.

[Nomad]

Day 64, 303 days left!

Found a good utility for the +3 that will help a lot editing the disk. DICE, I knew it would be good when I saw it and read the features but it was only when I read the manual it dawned on me quite how nice this was. You can edit all aspects of the disk, even the files. So you can do stuff like design custom disk loaders, set down to the bit level how you want the disk to be.

Very nice.

Besides that, spent the project time tracking down more papers and information on 80s and 90s chess engines. Chessbase especially thank to the recommendations I got from the forum.

Got a lot further figuring out what to do with the game disks thanks to people here also. Everything is progressing nicely.

And with a compact printing routine that got shared a few days ago here makes it possible to make a tutorial look decent next to a chess board on the screen.

[Nomad]

Day 67, 300 days left!

What have I been up to? Re-learning grafx2. Why? Because I am a potato and its much easier for me to use something that is the spiritual successor to deluxe paint than try and get my head round these other pixel editors. I just always found it much easier to use.

Besides that - been in a fruitless search for a flexable source editor i can use on the actual +3 (or emulator), paired with a assembler so I could develop my technical demos without having to stop using the emulator. Kind of the same thing that I do with the Atari. (Everything is contained, I use MEDIT for writing the source and AMAC to assemble the source listing, i then debug it all with AMOEBA. All this runs on the Atari 800 so I can write, assemble and test & debug without leaving the emulator.)

I wanted this for the spectrum but I have been hitting a dead end with crappy applications. I get the feeling most of the serious development must have been done on other microcomputers or PCs. Nobody would have seriously used these assemblers.. But it was worth a shot I figure. Ya never know till you try.

Devpac - sucks. Compaired to the professional Atari assemblers.

Still - I have one other avenue to explore...

Pentagon baby! If there was going to be a powerful development program that would be designed from the jumpstart to be run on the actual system it was going to target. Would logically be this. Plus because a lot of the software would have be refined in the early 90s you should have the more modern application design ideas present.

Well I got Prometheus 128 to have a look at, will play with that and see whats up. Hopefully its easier to use than devpac was.

Found a new disk magazine on spectrum computing thread that was very interesting. This was pretty much last nights project time. Aside from that I have been playing around with my double sided Maxwell disk

This is just a random thing - but my memory is not the best and trying to remember the spectrum keyboard template is a pain in the butt. It makes using the emulators so much more difficult. Why can't you just type using the pc keyboard?

I read the +3 manual again. That and the little tutorials retro coder put on youtube are nice.

Plan for today's project time is stringing together a template for a self loading +3 disk. With a loading screen, menu and a game screen.

[RMartins]

When I started developing SteelBall, I started using Zeus, and I can assure you that it has a very nice workflow.
You edit some assembler, then assemble it, and execute it.

Just be sure that you know what you are doing, since a BAD error, might destroy/corrupt your source code that is also in memory.
You can always exit out of Zeus, and SAVE as usual in BASIC.

I stopped using it, when I reached the limit of memory, where I had about 20K assembly source code,plus the assembled output, plus the Zeus app running.
It would be possible to continue working using Zeus, like in the old days, but I would have to split the code base in chunks so that it would be possible to compile in blocks, so that everything would fit in memory at compile time. This approach would also require concatenating the result blocks into a single file for loading.
Time constraints prevented me to continue like that, so I switched to using Pasmo on a PC, and cross compiles for ZX.

Resuming, it surely is possible to build stuff with the tools from that time.

[Nomad]

The thing that frustrates me the most about the spectrum emulators is the token keyboard layout. This makes sense when you can actually see the tokens. Not so much on a PC keyboard. But then that is another inexplicable choice for most emulators.

I looked at Zeus but it uses line numbers, plus there is the memory restriction as you say..

Will just stick with PC zeus/pasmo till someone figures out how to design a spectrum emulator interface that relates to the PC keyboard layout.

Were i enamored with the use of arcane/obscure keybindings I would just use emacs

That is one of the infuriating things about fuse is it forces you to remember key combinations, then when you try and look up the keyboard help its the size of a postage stamp on the screen. It's like the program is trolling you. First it forces you to use a keyboard layout for a keyboard you don't have - then when you go to look up the tokens its impossible to check.

[RMartins]

The thing that frustrates me the most about the spectrum emulators is the token keyboard layout. This makes sense when you can actually see the tokens. Not so much on a PC keyboard. But then that is another inexplicable choice for most emulators.
...

That is not a problem of the emulators, since they are actually emulating the behaviour of the machine.

If that is a problem, which I understand it is when programming, then the best solution, is to use a different ZX ROM, that provides that feature, like a 128K ROM or for 48K you can use The Gosh Wonderfull ROM

[Nomad]

I tried the Gosh Wonderful rom, ok It took out the tokenizer but you still have the problem that the " $#@ type characters are still in the wrong place.

But granted its 1/2 the problem fixed.

RMartins, thanks for all of the info - I didn't know about this useful rom until now. Appreciate the assist.

[RMartins]

...
RMartins, thanks for all of the info - I didn't know about this useful rom until now. Appreciate the assist.

You are welcome

You can also program on the real machine, using a DivMMC or similar, to help out on the LOAD/SAVE part of things
I did that for a few days

Or eventually use a Spectrum Next (board), if you have one.

[Nomad]

Yea that would be really neat

I doubt much is going to get done project wise today as I discovered schism tracker last night.

Ever since milkytracker decided it didn't want to work on my computer anymore I been at a loose end for a modern tracker for a few months now. I tested a few but none were very easy for me to work with. This one was pretty intuitive.

[Nomad]

My entry to the April 23 comp..

I decided to do a utility program that would give various calculations that are useful in simulation.

Here we can see one of the programs - it calculates the equivalent megatonnage of a weapon system on a soft target.

The calculation is simple

EMT = N * Y^2/3

where EMT = equivalent megatonnage of a weapon system on a soft target
N = Number of re-entry vehicles or bombs carried.
Y = Yield of each bomb or re-entry vehicle in megatons.







You can see there is a little bit of work to be done with the interface . I was kind of torn on doing it in assembly language.. I figured get it working in basic then think about if its worth it in assembly...

You get some weird rounding errors if you try and input a megatonne value that is too high. (for example a tsar bomba type ( 1 bomb, 50.00) ).. Stick to kiloton yields / low megatonne (so 0.01 - 5.0 seems to work ok).

Try the SS-18 Satan Mod 2 stats..

8 re-entry vehicles
0.5 megatonne yield.

[Nomad]

For a little fun I was playing around with 1 liners (well almost one liner.. its really 3.)









When I saw the listing in 'spectrum programmer' I knew it could be a one liner I couldn't help myself.

I figure there is a way to make all three screens into 1 line but that is beyond a simple potato such as myself.

[Nomad]

Update:

Eyes are square after reading so many damn papers on wargaming and reviewing the following flawed classic.

I figured for the upcomming compition I would see if I could put my new 'skilz' to work in doing a sam becket 'putting right what once went wrong'.

To explain - when I was young for one birthday my parents had bought Battle of Britain' my young self loved the tension of being RAF commander defending the homeland from a sometimes insumentable foe. (you had a variable number of luffwaffe - going from even balance to 5 x your resources). You could define the fail state (how many bombers got to complete their mission 0-100.

I remember this game being awesome, its one of the reasons I got into wargaming later. But I thought to myself 'I wonder if I could make it run better?' I remember the game was slow.

Then I recalled that the magazines had panned this title. I loaded it up and sure enough its got some issues with input (its pretty non-responsive & slow).

But when I looked at the code a number of things became obvious.

1. This was a combination of machine code + basic. Not as claimed in the magazine reviews as 'just a program written in BASIC'. Had they looked at the source they would have seen that on the first few lines you have a machine code portion (to load the map.)

Code: Select all

40 LOAD "MAP" SCREEN$
50 LET A=58580
60 POKE 23658,0
70 LET A=A+1
75 IF A<58603 THEN GO TO 60
80 DATA 33,0,64,17,238,228,1,0,27,237,176,201,33,238,228,17,0,64,1,0,27,237,176,201
90 RANDOMIZE USR 58580

Just a BASIC game eh... facepalm...

2. The speed and control issues, its because there are huge test conditions all in basic and these stack. This all is happening in the input /core game loop. Thus the speed issue and probably the response problem...

The screen update is slow because its calculating all of the elements in basic.

All of these things can be given a whole lot of love by doing them in Assembly.

The nice thing is the guy that coded this tried to make it in a modular way. There is extensive use of go sub structures. I get the feeling this was on the verge of being converted to a full assembly project.

Anyway - its a interesting game and got some nostalgia for me. I was surprised how 'simple' the game is when you break it down. The desire to get this running as the creator obviously wished it to became overwhelming.

I am not planning any crazy graphics, I just want to prove to myself that this game could remove all of the issues that got it panned in review.













Here is the start of the code, figured nobody wants to see 40 screens of basic You can see what I am talking about in the way the code is set up, and the room there is for improvement for conversion.



Here is the graphics - basic and its probably what caused the majority of the poor reviews but it does the job...





The nostalgia feels when I saw this were epic.





I knew after this I could do it. It's essentially a input evaluation problem that hamstrings this more than anything. If I were to just get this in assembly it would 'fix' the issues that most of the reviews had.

[Ast A. Moore]

This was a combination of machine code + basic. Not as claimed in the magazine reviews as 'just a program written in BASIC'. Had they looked at the source they would have seen that on the first few lines you have a machine code portion (to load the map.)

Code: Select all

60 POKE 23658,0
70 LET A=A+1
75 IF A<58603 THEN GO TO 60
80 DATA 33,0,64,17,238,228,1,0,27,237,176,201,33,238,228,17,0,64,1,0,27,237,176,201
90 RANDOMIZE USR 58580

Just a BASIC game eh... facepalm...

To be fair, these are just two harmless snippets of machine code. One copies the screen to another memory location, the other copies it from that location back.

[Nomad]

True but it shows that the program was not just written in basic. Ok I am being pedantic but still.

It clocks in at 401 lines of basic, with a sprinkling of machine code and pokes.

It's begging for a make over. But then that kind of makes sense it was a very early program judging by the style. Having reviewed the code. I wonder why the author didn't do the input routine & screen update in machine code. It would have made a huge difference... Hmmm... mysterious.

[Seven.FFF]

I bet he got those screen copy routines from somebody else, and used them without knowing assembly.

[Ast A. Moore]

I bet he got those screen copy routines from somebody else, and used them without knowing assembly.

Heh. Possibly. Then again, those are just LDIRs, preceded by setting up the HL, DE, and BC register pairs. It’s also possible he set out to write the whole thing in BASIC, realized some aspects were painfully slow, and sped them up with morsels of machine code.

[Nomad]

I get the feeling if he knew machine code he would have done all the INK, PAPER, BORDER stuff with pokes, even if it was a BASIC program.

But if he was getting help you would have thought they would have done the input routine - but I can kind of see why they didn't if they were pushed for time and especially if it was not the author who was doing the assembly.

There again, this was 1982 so.. hmmm.