Killer Snakes (Channel F)

[+atari2600land]

The timer now works. At first I wanted it to count from 99 to 0, but I couldn't do it, so instead, I had it count from 00 to 99. And that's what it will do. I had some troubles because the timer kept stopping at 80, but I finally got the timer and game to stop at 99.

[+atari2600land]

What do you think?

[+atari2600land]

The game now plays more like you'd expect a snake-eating-fruit game than ever. Please check the Kevin Vs. Tomatoes website download the game and give me feedback on it. My highest score is 18. What's yours?

[+atari2600land]

A short YouTube video of the game in action:

[+fdr4prez]

An interesting concept.

 

You must eat all the fruit! No waste

 

Is a two player game possible, where the player getting the entire fruit in a single bite, or the player getting the last bit of fruit gets the point?

 

Is a game like Intellivision's SNAFU possible?

[+atari2600land]

Is a two player game possible, where the player getting the entire fruit in a single bite, or the player getting the last bit of fruit gets the point?

 

Is a game like Intellivision's SNAFU possible?

It might be possible for a two-player game. I don't know how many sprites the Channel F can have on the screen at once, so I went this route.

 

Maybe, although I don't know how the collision detection would work on it.

[Kurt_Woloch]

OK, just to clear things up... actually I don't understand how you were even able to code this up without knowing much about the technical data of the Channel F.

Sprites??? Sadly, there are no "sprites" per se on the Channel F, only bitmap graphics. And the graphics memory is write-only, so you can't read it in order to determine if the snake has hit something. There's also no collision detection in hardware, which means the processor can't see what's actually in graphics memory at all, not even through small windows. As for colors, each scanline can have one of 4 possible 4-color (or 2-color) palletes, one of which is black and white and the other red/blue/green on grey, light blue or light green (if I remember right). Inside of that scanline, the dots can be freely set, that means you can have red, blue and green adjacent to each other.

[+atari2600land]

When I said "collision detection," I meant how I would code it. I know there's no such thing for collision detection. I didn't know about the sprite/bitmap graphic thing. I am having quite a problem subtracting 4-bit numbers, since there doesn't seem to be an opcode for it, only for addition. I can make the beginning timer be 99, but I can't figure out how to subtract 1 from it. I can add 1 to it, but just can't subtract 1.

[+atari2600land]

changes:

- timer now starts at 99 and moves down to 00.

- added sfx.

- eyes fixed so it's always a top view.

[+atari2600land]

Looks like Kevin Vs. Tomatoes will get a cartridge release. Stay tuned for more details.

[Kurt_Woloch]

I am having quite a problem subtracting 4-bit numbers, since there doesn't seem to be an opcode for it, only for addition. I can make the beginning timer be 99, but I can't figure out how to subtract 1 from it. I can add 1 to it, but just can't subtract 1.

 

In which form do you store the timer? This would determine exactly what to do.

It's true that there's no subtract command on the F8, but there are ways to get around this. In my code for the Video Brain which also has an F8 processor, I've coded it like that:

Let's say, we want to subtract the content of A from register 0 and store the result back into register 0. Since we can't subtract the number directly, we have to create a complement of it, add 1 to that and then add the result to register 0, which goes like follows:

 

COM ;complement A

INC ;increase A

AS 0 ;add R0 to A

LR 0, A ;write back the sum to R0

 

I hope this helps...

[+atari2600land]

I ended up doing something similar e5frog suggested and then adding some code that makes sure it displays 9 instead of F.

 

    LIS  1
    COM
    INC 
    AS S
    LR S, A

[Kurt_Woloch]

Did you really code it like that? Let's see what this actually does...

 

LIS 1 loads the accumulator with 1.

COM complements the 1 just loaded so it gets FE.

INC increments it so it gets FF.

AS S adds S to the accumulator and stores it there, so now the accumulator is S - 1.

LR S, A stores back the value so S has now decreased by 1, and the accumulator has the same decreased value.

 

However, if you're always subtracting 1 (and not more), you can use a decrement command instead, which is DS.

So you could write this shorter as:

DS S (decrements S)

LR A, S (you only need this if you also need the value to be in A afterwards)

Don't know what S refers to, though... do you write a definite register number instead of S, or is it another register I forgot?

[+atari2600land]

I used "LIS 6" to subtract it by 6 to make F a 9.

S is a sign flag according to the VES wiki.

[Kurt_Woloch]

Well, if you know the value beforehand, you can still write it shorter by loading the complemented value instead of loading 6 and then complementing it. So instead of

LIS 6 ;loads 6

COM ;complement it to $F9

INC ;adds 1 to make it $FA

 

you could write...

LI $FA ;load FA so 6 gets subtracted

 

This would be one byte and 2 lines shorter and probably faster to execute.

 

I'm still puzzled about that S though... according to the VES wiki S can't be used as an argument directly. It's only affected by certain operations. If the compiler accepts the S in this place, I wonder what it's compiled to.

[carlsson]

I'm a bit late with the feedback, and I fully understand that you can't read the screen on the Channel F which makes it extra difficult to tell which parts you have already moved on, but it would enhance the game greatly if you came up with an alternative way to determine if the snake ran into itself. I'm not sure how that would be done in this environment though. It strikes me that e.g. Tetris manages to detect full rows for both players which suggests either there is RAM somewhere you could use, or there is an alternative way to do it.

[+atari2600land]

Yeah, I know. That was something I would have liked as well, but I don't think there is a way I could do it. And if there is, I probably wouldn't understand any of it.

[carlsson]

The VES Wiki writes:

 

Schach RAM is a two-kilobyte block of extra RAM used in cartridge #20, Schach (Chess) for the Saba Videoplay. This consists of four 2114 chips (1K x 4 bits), and it starts at memory location $2800, and ends at $2FFF. This RAM is different than using the registers or VRAM, because it can be access directly in memory using the data counter.

 

Since most homebrew development carts are made from Schach cartridges, and MESS emulates it, modern homebrews can safely use it.

http://channelf.se/veswiki/index.php?title=Schach_RAM

 

It seems that Peter Trauner's Tetris game uses this area at $2800:

http://channelf.se/veswiki/index.php?title=Homebrew:Tetris

 

I suppose making physical cartridges would require those to have the same PCB as the Chess game, or newly made ones. Whether that is financially and practically meaningful is another matter, but adding 2K of all purpose RAM would let you do a lot more.

Edited February 7, 2018 by carlsson

[e5frog]

Hey there.

Adding 2k of RAM (like Pac-Man and the Multi-Cart has) would cost less than $5 more per cartridge than what was spent on the current Kevin vs Tomatoes. There's more information about the physical K. vs T. cart in the Multi-Cart thread.

[e5frog]

Well, if you know the value beforehand, you can still write it shorter by loading the complemented value instead of loading 6 and then complementing it. So instead of

LIS 6 ;loads 6

COM ;complement it to $F9

INC ;adds 1 to make it $FA

 

you could write...

LI $FA ;load FA so 6 gets subtracted

 

This would be one byte and 2 lines shorter and probably faster to execute.

 

I'm still puzzled about that S though... according to the VES wiki S can't be used as an argument directly. It's only affected by certain operations. If the compiler accepts the S in this place, I wonder what it's compiled to.

I was looking in the thread to see if there was any news about shipping the KvsT cartridges, I know it's a lot of work cleaning off labels on those carts - and get the free time from the family to do it.

Anyway, I read through the posts in the thread and thought the above was interesting.

 

"S" (when using DASM) means the register that the ISAR is set to, you can also use "I" to increase ISAR after the operation or "D" to decrease it afterwards - it doesn't carry the octal number so if you're at 7 for example octal register 27 and use an "I" it will change to 20 - which can be cleverly used sometimes.

 

In disassemblies you can see S be called (IS), D called (IS--) and I called (IS++)which makes a lot of sense but it's longer to type, I think DASM works with that as well.

There's a "LR IS, A" opcode as well that sets the ISAR directly, it takes 1 cycle to run - but you usually have to use an "LI 'value' " first that takes 2.5 cycles (or "LIS '4 bit value' " which uses 1 cycle) so the LISU/LISL combination for a total of two cycles is not beaten by any other method when just setting up the ISAR.

Remember though that you have registers 0-15 that can be used directly (of course also with ISAR).

 

S is also a symbol for Sign in the op-code table of veswiki.com but that isn't part of the mnemonics nor arguments.

 

When using subtraction in general the method is as described above:

LI 'value'

COM

INC

Then you have the initial value as an 8 bit signed negative number.

AS r

Would then add "r" (which is a directly usable register or one addressed with ISAR) to the negative number. You'll get "r - 'value' " in Accumulator.

If subtracting the same number every time it will be a lot quicker to use the precalculated negative value.

If we want to subtract 1 we can use "LI $FF" for 2.5 cycles or "CLR" followed by "COM" that will use 2 cycles.

In the same spirit we can use "LIS 5" then "COM" for 2 cycles - to get "$FA" which is negative 6...

 

The standard method will work fine, if it's a time critical part it can be worth to check other options as it takes as much as 4.5 cycles to use the basic way.

 

In this particular case there was some programming already done, to fix the problem and get the data as Binary Coded Decimal numbers (that was used in the number drawing routine - or if it was the other way around) it was patched for normal behaviour. If rewritten from start BCD could have been used - you only have instructions ASD and AMD to use.

http://channelf.se/veswiki/index.php?title=Binary_coded_decimal

Edited June 30, 2018 by e5frog

[+atari2600land]

I need to redesign the end cartridge label and then print them out and then I think I can send them once I get everyone's money.

-chris

[+stupus]

Awesome Chris!

Looking forward to it!

[+KylJoy]

I need to redesign the end cartridge label and then print them out and then I think I can send them once I get everyone's money.

-chris

 

Super awesome!

[Kurt_Woloch]

OK, I see... so S is the same thing as (IS). I thought it was referring to the status register. But no, that one is actually called W on the F8.

 

In my code I currently use the terms (IS), (IS)+ and (IS)-, which seem to work the same way as S, I and D, or as (IS), (IS++) and (IS--)... at least DASM understands them that way. That's the way the mnemonics have been written in the VIdeobrain disassemblies which I studied when I first tried to code for the F8 processor.

 

I'm usually careful with registers 0-15 since some of them have other nicknames and secondary functions... I'm generally only using registers 0 through 10 in a direct way since registers 11 through 15 have other functions as well... registers 10 and 11 together form register H, and registers 14 and 15 together form register Q, both of which can be used to manipulate memory pointers. And I do use Q in this way to access tables. Also, registers 12 and 13 form K which is used to store the return addresses of subroutine calls. This is probably overcautious, if not using H and K I could go up to R13.

 

As for the LI - COM - INC chain, it's not only about saving time, but also about saving code bytes since doing a LI with the final value only takes 2 bytes. Depending on what you try to do, I admit it may be hard to read though... I saw a video on Youtube that claims that code is actually written to be readable by humans and only happens to be executed. So actually code is often written so that it's readable if the optimum size or execution time isn't achieved this way (happens at work all the time as well).

 

"S" (when using DASM) means the register that the ISAR is set to, you can also use "I" to increase ISAR after the operation or "D" to decrease it afterwards - it doesn't carry the octal number so if you're at 7 for example octal register 27 and use an "I" it will change to 20 - which can be cleverly used sometimes.

In disassemblies you can see S be called (IS), D called (IS--) and I called (IS++)which makes a lot of sense but it's longer to type, I think DASM works with that as well.

There's a "LR IS, A" opcode as well that sets the ISAR directly, it takes 1 cycle to run - but you usually have to use an "LI 'value' " first that takes 2.5 cycles (or "LIS '4 bit value' " which uses 1 cycle) so the LISU/LISL combination for a total of two cycles is not beaten by any other method when just setting up the ISAR.
Remember though that you have registers 0-15 that can be used directly (of course also with ISAR).

S is also a symbol for Sign in the op-code table of veswiki.com but that isn't part of the mnemonics nor arguments.

When using subtraction in general the method is as described above:
LI 'value'
COM
INC
Then you have the initial value as an 8 bit signed negative number.
AS r
Would then add "r" (which is a directly usable register or one addressed with ISAR) to the negative number. You'll get "r - 'value' " in Accumulator.
If subtracting the same number every time it will be a lot quicker to use the precalculated negative value.
If we want to subtract 1 we can use "LI $FF" for 2.5 cycles or "CLR" followed by "COM" that will use 2 cycles.
In the same spirit we can use "LIS 5" then "COM" for 2 cycles - to get "$FA" which is negative 6...

The standard method will work fine, if it's a time critical part it can be worth to check other options as it takes as much as 4.5 cycles to use the basic way.

[e5frog]

@Chris: Hang in there, don't forget to enjoy the summer as well.
I once measure the edge label to 14.1mm in height, 101.2mm in width and the round area is part of a 44mm diameter circle - which should make perfect sense to an American (after some measurement translation in Google). But perhaps it's the motif that is changed?



@Kurt:
Yes, the old version of MESS with the old debugger (v 0.133 from 2009 for example) presents it the way I mentioned, I recall using (IS)+ etc some time in the beginning - whichever the compiler likes. I'm glad I can save up to four button presses using the macros S, D and I.

Register 9 is also called J... yup, you need to keep track of what registers are used, especially when calling routines in internal ROM (sometimes referred to as BIOS) or ones written by others, it doesn't get easier with HU (r10), HL (r11), KU (r12), KL (r13), QU (r14), QL (r15) - as well as the option to call them using ISAR-addressing... I like it when (sub)routines are marked with what registers they affect in the code.

The LIS x - COM will also use two bytes and is 0.5 cycle quicker - IMHO optimizations can be done if needed and one should keep to what makes sense, if using a method that's difficult to understand there's a bigger risk for errors. Myself as an example, I seem to be off by 1 a lot in every loop I write - either at the start or at the end.

That's true, we wouldn't have assembly language at all if the human readable thing wasn't an "issue", it would all be machine code.
Code that various AI outputs can be totally incomprehensible to a "normal" human - there's a lot that could be done if trying to go the most efficient route.
I try to use a lot of comments - to explain to myself what I did or what was the plan and to easier edit it if I need to revisit the code. Sometimes I have no clue how I had thought in some cases. I don't get to do a lot of programming, takes a while of undisturbed time for me to get into it and if disturbed it's like starting over - so coding at nights when the family is sleeping is the best time for me, which is of course not so good for other reasons...

Many thanks to you Kurt for the wonderful graphics converter: http://channelf.se/veswiki/index.php?title=For_full_screen
I made a simpler one for converting smaller objects from .bmp files: http://channelf.se/veswiki/index.php?title=Graphics_converter
(Indirectly telling Chris - and others that may visit in the future)

Edited July 1, 2018 by e5frog