Porting my SHOGUN game to the Videopac

[dr beep]

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.

[cjherr]

I would be interested.

[dr beep]

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)

[Rafael]

Great 

[dr beep]

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.

[dr beep]

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.

[dr beep]

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.

[dr beep]

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.

[dr beep]

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.

[dr beep]

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......

[TedFoolery]

Don't forget there's around 29 bytes of Internal Ram available too. I believe it's from 0x20h to 0x3ch.

[dr beep]

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.

[dr beep]

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!

[dr beep]

I have the boarddisplay now working.

The SHOGUN-stone is displayed inverted

[dr beep]

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.