TheFairChild

I think I am missing the reference for "You lose Turkey", not sure what it means. Interested in some context 4-in-a-row should be easy. I thought about it, there is a lot of reuse that could be done between Reversi-F and a 4-in-a-row (changing the game layount/memory structure a bit, the "AI", the pieces movements, gameover detection... most of that is already in independant routines). I will try to give it a go, but no idea when, I've got some personal stuffs coming up till the end of the year, so I will have less time to play with my side projects. If someone wants to beat me to it, no worries

Yeah, if you know what you are doing, the computer is not that hard to beat That's on purpose. I tried with the computer skipping by itself, but it was feeling akward (as in, I was placing my green chip, and then it was directly my turn to play again). That way, the human player sees that the computer has to skip, and they have to press the button to "acknowledge" that the computer is skipping. Wahoo, that one was a tricky one, I spent the last hour finding what was causing it It was of course a register being overwritten by a subroutine call, but the tricky part was that it was dependent on the board state to produce this buggy behavior. No idea about that one, couldn't replicate it with a few games played, and looking at the code didn't bear much result yet. Not sure if it could have caused by the other bug (I don't see how, but not 100% sure).

Added some sound "effects" to Reversi-f, when moving around the board, placing/flipping chips... No music or stuff like that, I tried, but it really sounded awful 😛

I think you are referring to the "Financial Info" share permission. This is only the history of in-app purchases if I remember Android dev correctly, not your actual financial credentials. I can't download the app either in my country, so I can't test it, but if there is no in-app transactions, then this is just a useless permission that they could have forgotten to remove. On their website (channelf.com), they say "CHANNEL F is a trademark of Skalectrotechny, LLC.". Never heard of that Skalectrotechny company, and Google doesn't seem to know about it either.

Debounce is back on the master branch

That's awesome! The last version on github (and itch.io) has a number of fixes, and one main new feature: - the titlescreen and the sidebar extend a bit more to the bottom now, to try fixing the issue you had on a real TV - also changed the delay between plots from 4 to 6 (it was 6 on the veswiki, it was my fault for changing it to 4 like in Videocart 21; maybe that's what was causing the bad white line in the sidebar) - using the palette set with blit now, instead of the Bios clrscreen, as you suggested - changed the fonts and the text to make it bigger: as you said, no need to shrink it if it's not needed! - and finally, I spent a few hours the last week-end to add a computer opponent The version I did is basically using a scoring system (number of chips it can flip basically), along with positional weighting to determine the best move. When several moves of equal weight (or score) can be played, a random one is chosen (thanks for the LFSR implementation, pretty interesting!). It is not unbeatable, but can give some challenge if you don't pay attention. You can see the computer move the cursor when it knows what to play, this is silly, but this is actually a touch that I really like One way it could be made (a lot) better is by adding: - minimax: basically allowing the computer to look-ahead several moves. However, I am soon running short of registers (still not using the schach ram) - also add some alpha-beta pruning: basically pruning moves that we know have no future => this is an optimization of minimax - then there are some trickier things: special endgame strategies, some pattern recognition (especially along the borders of the board, there are some nice tricks to play) I didn't add it back yet, but shouldn't be too hard. I will give it a go tomorrow maybe. If you prefer, I can add you as collaborator on the repository (if you have a github account). Or you can fork it of course The game now sits at ~6kb. That's fat This is really interesting, because reorganizing the code the way I did, with maybe too much MACRO use, made the code easier to debug/features easier to add, but at the expense of the size. There were some clever tricks that I used in the first version (like reusing registers in a crazy way) that I couldn't do once I started using MACROs/routines. This really makes you realize how far we have come in terms of computer programming science / methods.

Wahoo, that's really cool to see it running "for real" ! Good to know, I will update that. When I read that, I finally understood what I read about the palette on the VESWiki! Thanks, that would indeed be much more efficient. Yes, it did, but I was using some debounce mechanism for that. I lost that when I started using the "Wait for release" trick. I may change back to debouncing, at least for moving on the board. No idea why the left controller doesn't work though. On MAME, do you know why controller is mapped to the arrow keys/Ctrl key? Is it the left or right one? About the line that is not fully plotted on the sidebar, maybe it has to do with the fact that I changed the delay in plot to "4" (instead of the original "6"). I will try to change it back for the next version. There are no sounds at the moment, you didn't miss them I read about the theory of playing sound on VESWiki, but didn't get around to try it yet. Maybe in the next few days. I also would like a "vs Computer" mode. There are a few ways that I can think of to make a simple AI to play against. Thanks so much for all your feedback.

True, that looks a lot better!

It says Bo1, Bo3, or Bo5 Maybe fonts 4x3 are a bit too small...

I also posted it on itch.io as @Mikebloke suggested, just for the posterity https://sonyc.itch.io/reversif

Thanks! I actually ended up replacing the debounce mechanism I had in place with your "check for release" idea (it works better for a board game, I think debouncing would be more useful in an arcade game where you want continuous input). I think I am done with this game for now. Added since last time: - I reorganized the code a lot (maybe too much, I guess that's me trying to apply modern software development methods to an old assembly language ;)) - the game now has 3 game modes: Quick Game (or Best of 1 basically), Bo3 and Bo5 - scores (both for the current game, and for the match in case of Bo3 or Bo5) are displayed in the sidebar - pretty simple to do once you understand BCD - chips flipping is slightly animated (nothing fancy, just a delay when flipping pieces to see what is being flipped) - at the end of a game, I made it so that you need to "pull up" the button to go to the next game (to avoid inadvertent presses). That's the Alt on Mame for those of us testing with emulators only The master branch on github is up to date. That was a nice trip down memory lane I must admit, last weeks were pretty fun digging around ChannelF history. Amazing community. If someone needs help or something, development related or not, and if I can help with my limited abilities, don't hesitate to ping me. Some screenshots:

Oops, my bad, I had a debug JMP in the master branch, that I was using to test draw/skip conditions (artificially making them necessary, so that I didn't have to play a whole game). I just pushed the master branch again without that JMP, so that it should be possible to play a real game now. Although it only supports player vs player for now, not player vs computer. The wip branch is just an attempt at re-organizing the code, I have a few ideas there but it ain't stable/compilable yet.

Just got a kinda working version of Reversi out: The code is available on github for anyone interested. It’s not the prettiest, but I’ve learned a lot along the way. There's definitely plenty of room for improvement (and I mean a lot). I will continue to update/clean when I have time, there are still things that really bother me there The 1970s and 1980s were definitely an exciting time to experience. The F8 Programming Guide is a nice documentation, but the amount of reverse-engineering available on the VES Wiki is truly amazing. Thanks for that.

I actually ended up writing some code to do exactly that => loop through the 255 values, and see what could be used. Turns out there are not only plain screen colors, but also some fun patterns (lines of different kinds)!

Amazing. I've been reading the bios annotations, and had a look at the videocart disassemblies. The most interesting was being able to look at the pacman source, after a few days, I think I kinda understand how it works I used a bit of everything to do a simple code, when I can draw a pixel, change its color (by cycling through green/red/blue/bkg), and move it around (and check that it doesn't go outside of bounds). ; ; Control a pixel, while being able to: ; - change its color ; - change its position ; - make it permanent ; Thanks to the trove of information available at https://channelf.se/veswiki ; for making it possible. processor f8 include "ves.h" ; Constants START_X = 51 START_Y = 29 COLOR_BACKGROUND = $c0 COLOR_GREEN = $00 COLOR_RED = $40 ; Registers used PIXEL_X = 30 PIXEL_Y = 31 PIXEL_COLOR = 32 org $0800 cartridge.start: CARTRIDGE_START cartridge.init: CARTRIDGE_INIT main: ; clear screen, colored background li $c0 ; $d6 gray - $c0 green - $21 b/w - $93 blue lr 3, A pi BIOS_CLEAR_SCREEN program.init: ; init pixel (x, y) to middle of the screen SETISAR PIXEL_X li START_X lr S, A SETISAR PIXEL_Y li START_Y lr S, A SETISAR PIXEL_COLOR li COLOR_BACKGROUND lr S, A program.loop: ; draw the pixel (make it blink) li COLOR_RED lr 1, A SETISAR PIXEL_X lr A, S lr 2, A SETISAR PIXEL_Y lr A, S lr 3, A pi plot li $12 lr 5, A pi BIOS_DELAY SETISAR PIXEL_COLOR lr A, S lr 1, A pi plot li $12 lr 5, A pi BIOS_DELAY program.loop.readController: clr outs 0 ; enable input from controllers (related to bit6 of port0?) outs 1 ; clear port1 (right controller ) ins 1 ; read right controller first (requires half the CPU cycles than reading left controller on port 4 com ; invert bits, so that 1 means button pressed ni %10001111 ; mask out twists and pullup bnz program.loop.readController.endRead ; if button pressed, no need to read other controller outs 4 ; clear port4 (left controller) ins 4 ; read left controller com ; invert bits, so that 1 means button pressed ni %10001111 ; mask out twists and pullup bz program.loop ; no input, continue loop program.loop.readController.endRead: ; button pressed ni %00001111 bz program.loop.handleInput.changeColor ; up direction ni %00000111 bz program.loop.handleInput.up ; down direction ni %00000011 bz program.loop.handleInput.down ; left direction ni %00000001 bz program.loop.handleInput.left ; right direction (only one left, and we know something was pressed) jmp program.loop.handleInput.right program.loop.handleInput.changeColor: SETISAR PIXEL_COLOR lr A, S ci COLOR_BACKGROUND ; color_background is 192, the other colors are 0, 64, 128; loop back to 0 if we are at 192 bz program.loop.handleInput.changeColor.reset ai 64 lr S, A jmp program.loop.handleInput.changeColor.end program.loop.handleInput.changeColor.reset: li 0 lr S, A jmp program.loop.handleInput.end program.loop.handleInput.changeColor.end: li $64 lr 5, A pi BIOS_DELAY jmp program.loop.handleInput.end program.loop.handleInput.up: SETISAR PIXEL_Y ds S jmp program.loop.handleInput.checkBounds program.loop.handleInput.down: SETISAR PIXEL_Y lr A, S inc lr S, A jmp program.loop.handleInput.checkBounds program.loop.handleInput.left: SETISAR PIXEL_X ds S jmp program.loop.handleInput.checkBounds program.loop.handleInput.right: SETISAR PIXEL_X lr A, S inc lr S, A jmp program.loop.handleInput.checkBounds program.loop.handleInput.checkBounds: SETISAR PIXEL_X lr A, S ci 255 bz program.loop.handleInput.checkBounds.xyMin ci 102 bz program.loop.handleInput.checkBounds.xMax SETISAR PIXEL_Y lr A, S ci 255 bz program.loop.handleInput.checkBounds.xyMin ci 58 bz program.loop.handleInput.checkBounds.yMax jmp program.loop.handleInput.checkBounds.end program.loop.handleInput.checkBounds.xyMin: li 0 lr S, A jmp program.loop.handleInput.checkBounds.end program.loop.handleInput.checkBounds.xMax: li 101 lr S, A jmp program.loop.handleInput.checkBounds.end program.loop.handleInput.checkBounds.yMax: li 57 lr S, A jmp program.loop.handleInput.checkBounds.end program.loop.handleInput.checkBounds.end program.loop.handleInput.end: jmp program.loop ; Includes include "drawing.inc" ; Padding org $fff .byte $ff I used the ves.h, and the my drawing.inc basically contains the plot function from veswiki. I am really curious about how it was back then: do you think the coders at the time had access to internal Channel F documentation? For instance, I understand that for us, we know that to clear the screen to a specific value, someone had to reverse engineer the values "$d6 gray - $c0 green - $21 b/w - $93 blue". But back then, how did they know that?