Hello,
in stead off rewrting my emulator I will first make a port of my ZX Spectrum / ZX81 game SHOGUN boardgame to the Videopac to get reaquainted with the Videopac.
So I got myself a compiler (ASW) and a setup to compile my first .BIN
I will code it autostart (no SELECT GAME) since it will be the boardgame only.
I recently rewrote the entire game to make it run on a 1K ZX81. This reduced the use of RAM to a mere 128 bytes extra RAM and a stack of 72 bytes.
I am expecting the following problems when converting the game:
1) The game uses recursion for the best computermove and finding valid endfields. It stack parameters on the stack, I will need to "simulate"a stack for the paramaters.
2) The game uses selfmodifying code. This will need checks in RAM-memory
3) Speed: no idea how quick the AI wil be on the Videopac.
This is the old version on the ZX81
http://minigamecompo.weebly.com/2k-page.html
If you like I would keep up the progress in this topic.
I would be interested.
Got some compiling errors I couldn't understand, but isn't R0 and R1 only allowed to write to VDC?
In the end I got my board on display, next to add the stones.
But to do that I need to use the full set up of the board, how the board is stored in memory.
From the memory It must show the visible stones.
For stones I am thinking of characters 1,2,3 and 4 in 2 colours (player and computer).
The SHOGUN-stones will be defined by 4 sprites (2 for player with 1 and 2 with crown, 2 for computer in other colour)
Great 8)
I am reading about the amount of external memory.
I need 128 bytes for the board and a copy of it to allow moves on the board.
(technically could do with 64 but AI would get slower, never tested but could be too slow)
Besides these 128 bytes I also need a stack with 48 bytes which, as far as I find the info, is too much.
Am I right? If so I need to find another way to store the info.
Been thinking about a routine to reduce both stack and memoryuse.
I have an idea, but must test it in BASIC on a ZX Spectrum first before I can make it 4048-code. This would make a recursive routine iterative, thus saving a stack of max 48 bytes.
Yes,
iterative way is working. It still needed a few extra's but the stack is not needed anymore.
Now I can built the board and do player moves, after that computermoves will need some extra attention but must be possible.
My randomroutine is now working, also reading eram working.
Minor steps for you, but coding the 8048 is a whole new experience for me.
Found the debugger in O2EM to check stepwise if my routines work.
Now setting up the boarddata in eram with random pointers needed on the board.
Also the stack needed on the ZX81 and ZX Spectrum can be skipped with the iterative routine I worked out. Saving registers can be done by selecting other registerbank.
This must be enough for the AI.
I had trouble finding out how much ERAM I had.
It is 128 bytes, which I only need for the storage of the board and moves. Besides that I need a few bytes as variables too.
This means that my board will need a different storage than I had untill now. I can do it in 64 bytes with a trick.
Besides the RAM-problem I had a problem with the display of 16 stones on the board (possible with characters and sprites)
but I would also need a cursor to move over the board.
I will solve this by using a line of the background flashing as a cursor.
A lot of problems if you are used to code in RAM-only and the possibility of 32x24 characters on a screen.
I will get this game ported to the Videopac......
Don't forget there's around 29 bytes of Internal Ram available too. I believe it's from 0x20h to 0x3ch.
Quote from: TedFoolery on April 07, 2021, 03:29:33 PM
Don't forget there's around 29 bytes of Internal Ram available too. I believe it's from 0x20h to 0x3ch.
I know, but I have an idea where I can store all needed information in 96 bytes.
I already use a few bytes in iram to store information about my cursor.
Cursor is working, now checking if board setup is working, then next is some kind of characterdisplay of the full board.
After that it is just rewritting Z80 code into 8048; the AI.
All pointers to stones and data are set.
Now I need to code the most important routine: The display of the stones on the board.
When this routine is working the rest is nothing more than rewriting Z80-routines to 8048.
Nothing too hard too handle, but first this MAJOR step!
I have the boarddisplay now working.
The SHOGUN-stone is displayed inverted
All visual part is now working. Only visual part to add is the changing colour of the background to inidicate who has won.
Now I must code the recursive part from the original game into the iterative part I tried on the ZX Spectrum.
After that I can play the legal moves from the player.
I am still rewriting the most important routine (find enddestinations) into 8048 code.
The new routine has 5 loops, a pointer to RAM-data, X and Y pos and fieldposition.
A lot of registers and for the computermove I need to save them as well.
Tough job, but I will get it done.
Keep your great work!
2 bugs in the code solved... slowly getting further.
Yes, first test on a 1 step stone working. Next to test step 2,3 and 4.
This is the most important routine in the game, so when this is working only the AI of the computer is the next thing to solve.
I noticed a bug in the display of the board at the start of a game. This only happens once in a while and can be solved by restarting again.
Step 2, 3 and 4 still had a bug, but now all destinations are found.
Next step is to store the destinations in memory and use them for the final move of the player.
Sometimes a display error on the board appeared.
The problem had to be the use of RB0 while intrupts were still possible.
With a trick I managed to alter the stonevalueroutine without the use of an alternative registerbank.
Next to do: add move player.
Selecting an empty field or computer stone was detected, but the flashing background somehow got corrupted. Now repaired by always writing a repaired background.
Coding on the 4048 is new for me.
Errors with relative jumps outside a page I solved with filling empty bytes to fit a routine on the right page, but now I solve it with a JZ/JNZ on the same page to an address where I make the absolute JMP ROUTINE.
Quote from: dr beep on May 16, 2021, 01:51:22 PM
Coding on the 4048 is new for me.
Errors with relative jumps outside a page I solved with filling empty bytes to fit a routine on the right page, but now I solve it with a JZ/JNZ on the same page to an address where I make the absolute JMP ROUTINE.
Yes. These problems are really boring. Keep your good work and soon we´ll have this nice game ready
I have solved the move-bug that didn't show on the board.
Due to the movement I found a bug in the destination with step4 which I need to solve now.
All destinationfields now OK, but cursor disrupts characterdisplay. I need to find another place to store cursordata.
Some small bugs solved now as well.
Time to show the progress.
Next : AI from the computer.
https://www.youtube.com/watch?v=u4V_cyHadjQ
Thanks for the video, it's getting cool. 8)
Another step foreward.
The first step in computer ai, all possible positions reached by stones now in memory, next is a back up of that board to undo moves calculated by the computer ai.
backup of board and stones now added. First endfield of computermove reached.
Next to check what is on that endfield and calculate the score.
In the original game I used selfmodifying software to handle the AI from the computer.
Since the ROM can't be altered that same check is now done with a flag in RAM.
The first destination for a move is now reached. The evaluation of the move is the next to do. And then check it against best move.
Slowly getting the game ready.
Where I could code the entire game in 1K on a ZX81 it looks like I will need a bit more for the Videopac version. No problem since I have 2K ROM available without extra banks.
The AI of che computer plays all moves and then evaluates each move in a score. A higher score is a better move.
At this moment the best move before playing the actual move is found. This needed a different startscore on the Videopac than on the ZX81. Due to the 2-complement check I can't start with the value 0 as start since that will never give a carry when a chcek is done. The startvalue is set to 1.
I also passed over the 1K boundary and I still need to code extra checks, winner check and signaling an attack on the shogun.
So far it goes well, although coding 8048 is quite hard to do as a first game.
Arggghhhh,,,,
The compiler doesn't do a correct jump from 07FF to 0800. Must check it by hand.
Furthermore a bug in the computer AI. Somewhere a value is written to an address and I can see where.
No if the debugger could do a stop when writing to a certain address I could find the bug.
Now I am searching in the dark for several days already.
I hope you love to read the struggle I have coding my game.
For this game I needed a whole new routine to find endplaces and to handle the computer AI. It looked like the AI did not save 2 registers in the right way. I altered that and now I will slowly adapt the AI-routine in it again.
Of course, we love reading about game development. ;)
What Rafael say...
I can now show you the very first AI-move from the computer.
Thanks to the reply a few days ago I now have the display working and a small part of the AI.
For development the board is now not random so I can replay situations.
In this board I move my stone to a position where the best move would be to capture the stone
(which is just a small part of the AI) and the computer does that move.
https://www.mediafire.com/file/4azabzuw0l6wgsn/compai1.png/file
Although my AI is not complete yet I played a game against the computer where more AI was added. I still need extra checks, endgame testing, signalling attacked, but it is getting somewhere. Small bugs repaired which occured in AI, R0 was corrupted on return in checkloop so it is set again. For playerloop R0 stayed ok, so no repairsetting was coded.
The checkloop is used by both, but the ai uses the enddestinations where the player only gets a valid field check.
The next step in the AI is the info after a move.
The info is still correct which means the temporary move is not working as it should.
That is the next thing to check.
Bugs are often just typo's.
Like MOVX A,@R0 had to be MOV A,R0
Now I need to add another save of 2 positions as well.
Debugging goes slowly, but another bug solved
Now the check on all positions on the board is working as it should.
Now I must check again why certain moves are not found as best move.
Slowly (too slow in my opinion) the game becomes as it should be.
When the AI is working as it should then I must add end of game checks and SHOGUN ATTACKED signalling.
Sound effects for selecting a stone is nice to hear what you did.
Finally 2 extra AI options will be added but those are extra.
It will fit 2K easily, but I am not ready yet.
1199 bytes at this moment.
A bug in the AI solved which made me find another bug.
The board was not always resetted to the start of move.
After that the game became playable until an invalid move was done by the computer which lead to a crash of the game.
Now I need to find how this invalid move was selected. This part of the game is fully rewritten to make it fit for the Videopac
so I can check it with the original game.
I was able to make an invalid move by the player. This simplifies the search for the bug.
Bug found.... and another appeared..... and solved.
The game plays quite well although after many moves a display error appeared.
I think in a certain moment the VDC is written to and not ERAM.
Hope to find fixed steps to re0enact the error.
Yes.... Displaybug finally solved.
This might even be the cause of incidental crashes.... I hope it is.
if so I can work on the final steps of the game.
The display of the board remains an issue.
Although EXTRAM tells what to display, the final display is still not as it should.
I am working on it. The VDC of the Videopac is a real brainteaser for me.
ZX81 and ZX Spectrum are much easier to access.
Solved the displaybug that sometimes appeared after a computermove.
Now sometimes background goes off without taking graphicsoff
When back home tonight I will try to solve this by regularly calling graphon.
Hope this will do the trick.
Hopefully then the final displaybug is solved so I can add extended ai and
signals who won or under attack. and finally some soundeffects.
Yesterday morning I solved the characterdisplaybug. That same evening I solved the disappearing of the background.
To set the background back visible you can't just CALL GFXON, you also must have VDC access before calling it.
As said before: VDC is a brainteaser.
It looks like all bugs are solved. Now I can add end of game checks, signaling SHOGUN attack and then the game is functionally ready.
Due to the altered code on the Videopac then only the AI needs finetuning.
THE BASE VERSION OF THE GAME IS WORKING WITH ALL THE NECESSARY RULES.
Now I am working on extra things like sound, better AI, Easy and hardmode.
Work in progress video.
https://youtu.be/wOGkTOluVJg
Excellent :D 8)
The game is ready.
I added a second AI.
You can play an easy and a difficult game.
Now the game will be playtested by a member from this site.
Fun to follow your progress - will you get it released as a cartridge?
@minodk,
that is up to Rafael..... he is testing it right now.
He lost his first game and even I lost a few games already on the Videopac.
Shogun is a really fun game and I think Odyssey needs more games in this style. 8)
Not sure if you all know (I didn´t knew) , but it´s a 1976 boardgame:
https://boardgamegeek.com/boardgame/2043/shogun
On request I am adding a 2 player option, which is working right now.
Next to add is also the SHOGUN-attacked message when player 2 is attacked.
All extra's will make the game much better.
2 player option added, SHOGUN ATTACKED message on all players.
To do:
Winnertext, altered cursor, option to disable sound from cursor.
I added:
Highlighting of the selected stone.
Delay in the computermove so it shows which stone will be moved and then some time later the move is done.
Indicator who's turn in a 2 player game
It is now up to Rafael to playtest this version.
The game didn't run on the G7400, but now it does.
The game runs in 4K on the emulator but.....
on the real hardware the display is not as it should be.
Since I only have an emulator I can't fix this, nor do I know WHY the emulator response differently than the real hardware with my code.
So I hope SOMEONE HERE can solve this.
I can try to help, but I'd either need pics/description of what is wrong or the code.
Typically, emulators are more forgiving than real hardware.
See PM.
Johan kindly authorized the insertion of graphics plus in this excellent game, so here is the result.
Looks fantastic!
I was wondering what the text translated to. Google translate let me know the secret...
...it's just "SHOGUN".
Mistery Solved ;)