WIP: Reversi

[MADrigal]

> Regarding the way to start a game, what you don't know is
> that the routine checks BOTH fire buttons.

whops, got the point!

> One of them will make you do the first move (always as black,
> unfortunately - I'll see if I can change that) and the other one
> will make the computer do the first move. Thus it will look
> like 4-1 instead of 2-2.

why not changing it a bit? left button = player uses white, right button = player uses black. you can do that by "swapping" the colour definition for the dots operated by player and cpu.

in such case, i'd always let the player move first.

or, if you want to make the game like the commercial creativision games:
- boot -> game in demo mode (to design at will... might even be an empty playfield with blinking dots randomly, or the "purple dots" making the external frame change colour or shape)
- press RESET -> game into "SELECT MODE". when in select mode, by pressing the left/right buttons, you select which mode, example:
1=P1 white, P1 starts
2=P1 white, CPU starts
3=P1 black, P1 starts
4=P1 black, CPU starts

> I can increase the joystick delay so it doesn't move so fast.



> Also the flashing cursor is subject to alteration, although I
> kind of like the idea that it looks like a marker. What I can
> do is to add code to have the cursor skip already placed
> markers, but it means more complexity.

hm... i dont like the idea of skipping the placed dots. a "target" marker-shaped sprite is the best choice in my opinion.

> Of course the CPU can be delayed a bit or add some sound.
> For more complex games, the CPU gets a little bit slower
> after a while.

so are you planning to add hard/easy modes? wow! this means that you really *must* add the "select" mode

> As for graphics, the dots in my version of FunnyMu are purple, not cyan.

sorry i meant purple but i wrote cyan!

> The border can absolutely be prettified, and use at least up to
> 8 different characters in its tileset. I just wanted something that
> is easy to draw to start with. When it comes to the board, it is
> supposed to be dark green with medium green squares inside each
> position.

i'll try to design some graphics and will show you my idea. maybe you'll like it

> As you mention black squares and cyan dots, it sounds like your
> installed emulator is broken or misconfigured?

no it's just my minde which is misconfigured

the "black squares" I meant the black lines that stay between green squares

> I used the official VDP colour numbers all the way and get expected colours
> on my installed version of FunnyMu.

I suggest you to use also CvEmu2, because there's also the EXTERNAL BORDER (the area outside the 256x192 pixels display) emulation, which FunnyMu hasn't. If you decide to leave the black background, you should also make sure that the external border matches the same colour.
Or if you decide to change the background color (I would personally do so, and make the game a little bit more colourful) that's an absolute must-do.

> I have studied a half dozen different implentations on other VDP-based
> machines. Some of them have a checkered board (e.g. Daniel Bienvenue's
> Reversi for Colecovision) but I'm not so sure that is a proper look.
> There is another type of layout with black lines completely separating each
> square, but it makes the markers 8x8 pixels instead of 16x16 and I think
> that looks too tiny. See my RetroChallenge blog for more pictures.

will do

> Your last suggestion to make the dots 3D, I don't know how that would be
> doable. Surely one could put some kind of fine checkered shadow below,
> but it would just look ugly. As for a truely isometric view, I think colour
> limitations would require a major rethink to make it work. Not this
> time...

ok i wasn't capable of explaining my idea at all. at this point i really need to design you a gif/bmp of what i have in my mind.

i'm at work now, will do this in the afternoon

thanks for taking the time to read and reply my suggestions

[carlsson]

I'll look into select mode, and perhaps a way to read the keyboard too. I understand several zeropage bytes are used to decode the whole controllers, so somewhere the other keys are kept too. Currently the CPU only has one difficulty level, but I mean that the more markers placed on the board, the more options the computer has to evaluate, in particular if there are no border or corner squares to get.

I'll look forward to some ideas from you. I know there should be a border around the screen, which is default set to black in the VDP setup. As you see from the other VDP implementations on my page, almost all of them have a black background. The one that stands out is the Memotech MTX version which looks a bit more C64 like in its colour scheme. Of course one doesn't have to follow convention, e.g. my original VIC-20 version has light blue background and darker blue border.

First of all, I must locate the bug(s) and fix those, before adding more options but it'll come. If you are up for some artwork, we could later on dream up a Creativision-like box for a Reversi game. Actually I'm planning to develop about three small games that hopefully will fit all inside one 8K cartridge. In that case, it becomes obligatory to have some SELECT GAME mechanism, whether it should be done with a keypress or an onscreen menu. I don't know how much the manufacturing costs for the cartridge boards are, and of course the shells were hard to obtain but it'd be nice if CreatiVemu by 2014 (yes, I'm not rushing things) finally had a brand new homebrew for sale in limited quantity. For testing issues, I'm planning to use my Diagnosticart with removable EPROM which is one of the reasons why I once asked to receive it in that configuration instead of soldered so the case could be closed.

[MADrigal]

> Currently the CPU only has one difficulty level, but I mean that the more
> markers placed on the board, the more options the computer has to evaluate,
> in particular if there are no border or corner squares to get.

aha i understand!

> I'll look forward to some ideas from you. I know there should be a border around
> the screen, which is default set to black in the VDP setup. As you see from the
> other VDP implementations on my page, almost all of them have a black background.

ok

> The one that stands out is the Memotech MTX version which looks a bit more C64
> like in its colour scheme. Of course one doesn't have to follow convention, e.g.
> my original VIC-20 version has light blue background and darker blue border.

i just had the time to look at your blog, and i like the colecovision version very much. well they're all very nice, but my favourite is probably the memotech layout (i mean the colour scheme and coloured squares, white lines, etc).

> First of all, I must locate the bug(s) and fix those, before adding more options but
> it'll come. If you are up for some artwork, we could later on dream up a Creativision-like
> box for a Reversi game.

why not?

a creativision-like box would be great. i have all the knowledge to make a perfect creativision-like box, even with internal cartridge holder

and i still own the metal mould to build new plastic cases, identical to the ones of multicart/diagnosticart

> Actually I'm planning to develop about three small games that hopefully will fit all inside one
> 8K cartridge.

hm... 8k is probably not enough, at least if you want to add some nice graphics and sounds in it.

for example, look at the crazy chicky and air-sea attack games. the actual playfield is small, and there's panels on the right side, making the game look better. maybe you can add a similar layout to your Reversi game, instead of letting the right side "naked". i'm here in case you need help.

> In that case, it becomes obligatory to have some SELECT GAME mechanism, whether it should be done
> with a keypress or an onscreen menu.

i agree.

> I don't know how much the manufacturing costs for the cartridge boards are, and of course the shells
> were hard to obtain

we still have around 100 pcb's here. but they're made to work with 28-pin dip package EPROM, while the standard 8K eprom is 24-dip.

i suggest you use 32k EPROMs, which is still very cheap if compared to 8K EPROMs, but will let you save money because we would give you the needed PCB's for, or eventually we can give you the "project" file and you can print them wherever you want.

> but it'd be nice if CreatiVemu by 2014 (yes, I'm not rushing things) finally had a brand new homebrew
> for sale in limited quantity.

that would be great

> For testing issues, I'm planning to use my Diagnosticart with removable EPROM which is one of the
> reasons why I once asked to receive it in that configuration instead of soldered so the case could be closed.

oh that's a great idea.

in such case, you'll need a 32k EPROM

here's a quick preview of what I'm thinking for the game graphics. hope you like it.

ps. just noticed that your current version has green squares with small square inside, whops, when i wrote my previous messages, i had memory they were BLACK lines!

[carlsson]

Yup, those graphics could work. As you know, the colour combinations are defined in sets of 8 characters. With alternating background colours we need four different sets of which only 50% will be used: white on dark green, white on medium green, black on dark green, black on medium green. How do you like the idea to define additional markers that are upright, in the middle of a flip? I believe the routine that flips the logic board could e.g. set the high bit on each memory position to indicate this one has been flipped, then redraw the board in middle action, clear all high bits and redraw the board again after some delay.

Of course a 32K EPROM is much better, giving about 8K per game if divided evenly. The original VIC-20 release using ROM graphics and virtually no sound fit within 1K, but this one will be a little more mature.. hm, for a lack of better word. I don't mean we're looking for Strip Reversi although I'm pretty sure a such game has been implemented elsewhere.

[MADrigal]

> As you know, the colour combinations are defined in sets of 8 characters.

yep, i had to respect the vdp limitation when coding the basic programs you can find on the creativemu downloads page.

> With alternating background colours we need four different sets of which
> only 50% will be used: white on dark green, white on medium green, black
> on dark green, black on medium green.

...plus the ones for texts and the "reversi" logo

> How do you like the idea to define additional markers that are upright, in
> the middle of a flip?

uuuh? sorry I don't understand!

you mean adding a a few frames to animate the "markers" (what I call "dots") when they change colour (flip) ?

> I believe the routine that flips the logic board could e.g. set the high bit on
> each memory position to indicate this one has been flipped, then redraw the
> board in middle action, clear all high bits and redraw the board again after
> some delay.

hm.... something nice would be like this:
- add the "flag" to the markers that are to soon to flip
- cycle from position row 1 to row 8 (or from column A to B) and make markers flip row by row, or column by column, in 8 separate VDP frames.

i mean: why making all markers flip together, while it would be a great effect to make them flip in rows or columns? if you flip them in columns, the marker would flip in "vertical" position. or, if you prefer making them flip horizontally, the animation frame would display a horizontal marker.

it would be great if you could add 2-3 frames to the flipping animation, this means that you'll need an additional array to store the coordinates of the "markers-to-flip". Add integer numbers to that array (3 to 0, for example) and then display the marker as "frame 3, frame 2, frame 1" and then the "normal" marker (0).

i can do the graphics if you want. sorry i cant help you with asm.

> Of course a 32K EPROM is much better, giving about 8K per game if divided evenly.

8k is a nice amount of RAM space to fit a nice game in it, with music and graphics. most CV games use 8K RAM space.

> The original VIC-20 release using ROM graphics and virtually no sound fit within 1K,

wow very tiny!

> but this one will be a little more mature.. hm, for a lack of better word. I don't mean
> we're looking for Strip Reversi although I'm pretty sure a such game has been implemented elsewhere.

hm.... might be a good idea

[carlsson]

Ok, some small progress tonight:

* Blink delay and move delay made compile-time configurable, move delay increased (slower movement)
* First player always is white, meaning human gets white or black depending on which fire button is pushed
* Blinking sprite is disabled when computer makes its move and on setup (no more blink after reset)

Computer routine still is buggy. Sometimes it hangs in an infinite loop, sometimes it goes outside the board. I'll keep debugging in the weekend.
No graphic updates yet, also no real reason to post a new binary.

Update: I took another look at the code and wrote down which subroutines are used both by the human player and the computer, as well as those only used by the computer. Then I had a closer look at those only used by the computer and found that it runs two loops outside of board dimensions, which seems why the bugs appear. After adjusting those loops, the game suddenly seems to run as intended! Thus I'll post an intermediate binary for some additional play testing before I get on with the visuals.

reversi-0.2.zip

[MADrigal]

What a nice wake-up surprise! ^_^

Just tested the game and it works great. The only remarkable "bug" is the place where the "game over" text appears. I suppose the best place would be under the "you" and "cpu" texts

What will happen after game is over? A jingle will be played? A text will be displayed, reading "and the winner is... player/1up/you/cpu/creativision - press button to start again" or similar ???

[carlsson]

The end of game action is yet to be determined. I have some ideas to implement a soft text scroller, but perhaps that would be out of style.

Unfortunately I didn't get as much development done today as I had hoped for, but at least I plugged in the Creativision start screen. It was very easy, just change a pointer and add a return address to start of the actual game.

[MADrigal]

Well this is good news. I was pretty sure it was just a matter of a couple of jumps

Something to care about: when pressing RESET, the logo must not be displayed again. There's probably some byte to set in the RAM, that excludes the full restart of the program.

[carlsson]

Based on the FunnyMu behavior, this is already taken care of. Apparently something is initiated so the boot screen doesn't show again.

0,0,7,31,63,127,127,127
0,0,224,248,252,254,254,254
63,95,103,56,31,7,0,0
252,250,230,28,248,224,0,0