41 replies to this topic

[EmOneGarand]

e5frog, on Fri Aug 10, 2007 3:31 PM, said:

To set the boundaries you can add a check here:

.moveShipLeft:
	lisl	3
	ds	S
	br	.moveShipEnd
	
.moveShipRight:
	lisl	3
	lr	A, S
	inc
	lr	S, A
	br	.moveShipEnd
.moveShipEnd:

Like this:

.moveShipLeft:
	lisl	3
	li	5		; load A with 5 (minimum x-coordinate)
	xs	S		; exclusive or with scratchpad -> returns zero if equal 
	bz	.moveShipEnd
	ds	S
	br	.moveShipEnd
	
.moveShipRight:
	lisl	3
	lr	A, S
	inc
	lr	S, A
	br	.moveShipEnd
.moveShipEnd:

Same procedure with the moveShipRight.

Hmm.. the left boundry code worked, I tried the same with the right though I thought an inc would be used but it just makes the game lock up and try to boot the built in program.. hmm..

[e5frog]

EmOneGarand, on Mon Aug 13, 2007 3:32 AM, said:

Hmm.. the left boundry code worked, I tried the same with the right though I thought an inc would be used but it just makes the game lock up and try to boot the built in program.. hmm..

Try this then:

.moveShipLeft:
	lisl	3
	li	5	; load A with 5 (minimum x-coordinate)
	xs	S	; exclusive or with scratchpad -> returns zero if equal 
	bz	.moveShipEnd
	ds	S
	br	.moveShipEnd
	
.moveShipRight:
	lisl	3	; sets ISAR to the x-coordinate register
	
	li	50	; load Ackumulator register with decimal 50 (I'm just guessing the right boundry)
	xs	S	; exclusive or with register that is adressed by ISAR - which is the x-coordinate register
			; if they are the same, result will be zero and the zero flag is set

	bz	.moveShipEnd; if they were equal (result zero, skip increasing the x-coordinate)
			; and jump past that to the end of the .moveShip-code

	lr	A, S	; load A with contents of register adressed by ISAR (now set to the x-coordinare register)
	inc		; add 1 to A (A=A+1)
	lr	S, A	; store the increased x-coordinate back into the x-coordinate register

	br	.moveShipEnd		  ; jump to end of the .moveShip-code - which is not needed, since we're already at the end
			; the branch-jump will be exactly 0
			; You can remove that line if you don't want to keep it for "symmetry-reasons"

.moveShipEnd:

I hope this is clearer, should work fine but you probably need to increse the right boundry to something more than 50.

Good luck!

[EmOneGarand]

e5frog, on Mon Aug 13, 2007 1:25 AM, said:

EmOneGarand, on Mon Aug 13, 2007 3:32 AM, said:

Hmm.. the left boundry code worked, I tried the same with the right though I thought an inc would be used but it just makes the game lock up and try to boot the built in program.. hmm..

Try this then:

.moveShipLeft:
	lisl	3
	li	5; load A with 5 (minimum x-coordinate)
	xs	S; exclusive or with scratchpad -> returns zero if equal 
	bz	.moveShipEnd
	ds	S
	br	.moveShipEnd
	
.moveShipRight:
	lisl	3; sets ISAR to the x-coordinate register
	
	li	50; load Ackumulator register with decimal 50 (I'm just guessing the right boundry)
	xs	S; exclusive or with register that is adressed by ISAR - which is the x-coordinate register
		; if they are the same, result will be zero and the zero flag is set

	bz	.moveShipEnd; if they were equal (result zero, skip increasing the x-coordinate)
		; and jump past that to the end of the .moveShip-code

	lr	A, S; load A with contents of register adressed by ISAR (now set to the x-coordinare register)
	inc	; add 1 to A (A=A+1)
	lr	S, A; store the increased x-coordinate back into the x-coordinate register

	br	.moveShipEnd		 ; jump to end of the .moveShip-code - which is not needed, since we're already at the end
		; the branch-jump will be exactly 0
		; You can remove that line if you don't want to keep it for "symmetry-reasons"

.moveShipEnd:

I hope this is clearer, should work fine but you probably need to increse the right boundry to something more than 50.

Good luck!

Solved the problem nicely thanks

[EmOneGarand]

sorry if I'm not quite getting this hah hah.. but you mention that the registers are in octals, thats a step up from hex right? So I have 3 aliens I want to designate, the table says that reg0 -reg31 are general purpose so are these what I have at my disposal for everything else? the problem I have is how do I designate the x & y position values to a register for each alien (like how you guys assigned a bunch of them for the ghosts) Not quite sure how it works.. particularly how Octal 43 = Reg35

[e5frog]

EmOneGarand, on Mon Aug 13, 2007 9:22 AM, said:

sorry if I'm not quite getting this hah hah.. but you mention that the registers are in octals, thats a step up from hex right? So I have 3 aliens I want to designate, the table says that reg0 -reg31 are general purpose so are these what I have at my disposal for everything else? the problem I have is how do I designate the x & y position values to a register for each alien (like how you guys assigned a bunch of them for the ghosts) Not quite sure how it works.. particularly how Octal 43 = Reg35

Octal is a number system that has eight values only: 0-7, decimal has 10: 0-9 and hexadecimal has 16: 0-F.

You have registers 0 - 63 to play with, the lower registers can be addressed and played with without the need to go via the ISAR. These lower registers are usually used in different routines, as they can be used quicker (not having to deal with ISAR). Examples are the plot, blit, delay etc. etc.

Here's the table we use in Pac-man to permanently store information about the ghosts,
octal numbers written with three digits (all start with 0) and the decimal equivalence after #:

GHOST_0_X_REG = 040 ; #32
GHOST_0_Y_REG = 041 ; #33
GHOST_0_DIR_REG = 042 ; #34
GHOST_0_ANIM_REG = 043 ; #35
GHOST_1_X_REG = 044 ; #36
GHOST_1_Y_REG = 045 ; #37
GHOST_1_DIR_REG = 046 ; #38
GHOST_1_ANIM_REG = 047 ; #39
GHOST_2_X_REG = 050 ; #40
GHOST_2_Y_REG = 051 ; #41
GHOST_2_DIR_REG = 052 ; #42
GHOST_2_ANIM_REG = 053 ; #43
GHOST_3_X_REG = 054 ; #44
GHOST_3_Y_REG = 055 ; #45
GHOST_3_DIR_REG = 056 ; #46
GHOST_3_ANIM_REG = 057 ; #47

There's also a temporary register to hold the values of the current ghost being manipulated:

GHOST_TMP_X_REG = 034; #28
GHOST_TMP_Y_REG = 035; #29
GHOST_TMP_DIR_REG = 036; #30
GHOST_TMP_ANIM_REG = 037; #31


Then we have a cycle that copies ghost 0 information to the temporary registers, change that accordingly, copies it back, copies next ghost, change, copies back etc...
That way we can use the same routine for all the ghosts, I don't know if this is the best way, but that's how Blackbird solved it - if looking for speed it's probably better to have one routine for each ghost, not copying back and forth between a temporary register.


You should really take a look at these pdf:s if you haven't already, I uploaded all of them into my personal webspace except for the circuit schematics of the Fairchild unit:
Best one:
http://w5.nuinternet.com/s660100106/files/...Programming.pdf

Others:
http://w5.nuinternet...nnelf/f3850.pdf
http://w5.nuinternet.com/s660100106/files/...lf/f3851_56.pdf
http://w5.nuinternet.com/s660100106/files/...lf/f3852_53.pdf
http://w5.nuinternet.com/s660100106/files/...eneral_info.pdf
http://w5.nuinternet.com/s660100106/files/...hoff_(1979).pdf

I recommend printing the F8_Guide_to_Programming.pdf and definately the instruction-table from f8_info_'16_bit_%B5P_architecture',_Terry_Polhoff_(1979).pdf to more easily see what commands are available, what they do and how slow they are. As you can see in that table a PI takes 6.5 cycles to complete, so if you're using a routine a lot you'll save time if you are able to reach it without using a subroutine call.

Happy programming!

Edited by e5frog, Mon Aug 13, 2007 6:50 AM.

[e5frog]

the table says that reg0 -reg31 are general purpose so are these what I have at my disposal for everything else

That's only the table used in that version of Pac-man, these aren't used to store information during the gameplay, but rather as temporary registers for storing temporary data.

The 16 registers 0- 15 can be used directly, r9 - r15 also have alternate names ( J, HU, HL, KU, KL, QU and QL). H, K and Q can be used as 16 bit registers when handling addresses and such, H is made up of HU and HL and the other two uses the same principle.

So, instead of doing this:

	 lisu	 0
	 lisl	 7
	 lr	 A, S

You can transfer contents of register 7 directly

	 lr	 A, 7

Which saves both code and processing time.

So instead of doing a lot of work on the registers, changing ISAR and so on, you can transfer what you need to work with to these lower 15 registers. Like the plot routine, you transfer the correct values into the lower registers and then it goes to work.

Then you can also save time by using consecutive registers, doing that you only need to set a start register in ISAR and then increase or decrease it at the same time as you "Load Register" .

Copy register 'o'20-22 to registers 2-4:

	 lisu	 2	; load upper value of ISAR 'o'2
	 lisl	 0	; load lower value of ISAR 'o'0
	 lr	 A, I	; copy register 'o'20 into A and increase ISAR (now 'o'21)
	 lr	 2, A   ; copy A into register 2
	 lr	 A, I   ; copy register 'o'21 into A and increase ISAR (now set to 'o'22)
	 lr	 3, A	; copy A into r3
	 lr	 A, D	; copy register 'o'22 into A and decrease ISAR (now set to 'o'21)
	 lr	 A, D	; same again, just to set ISAR back to 20 - as we started with.

You'll figure it out if you check the pdf:s.

[e5frog]

I made a copy of the Instruction set table of the "Polhoff"-book

Attached here as a Word-document:
 F8_instruction_set_table.doc   132.5K   71 downloads

[e5frog]

VESwiki is now UP!

http://www.bingbangboom.us/productions/ves...title=Main_Page

[Tom]

Out of curiosity, what are you guys using to write Channel F software now? dasm with F8 support or f8tool or what?

[e5frog]

Tom, on Tue Aug 14, 2007 11:00 AM, said:

Out of curiosity, what are you guys using to write Channel F software now? dasm with F8 support or f8tool or what?

I usually write in wordpad, and compile with dasm.

Testing in MESS with debugger, I've left the link to a Channel F improved version (external palette-file, System 2 sound).

There is a very good Development package at the


Direct-link: http://www.bingbangboom.us/productions/ves.../3/3a/Devel.zip

[EmOneGarand]

Tom, on Tue Aug 14, 2007 5:00 AM, said:

Out of curiosity, what are you guys using to write Channel F software now? dasm with F8 support or f8tool or what?

I use Programmers Notepad 2 and DASM

[EmOneGarand]

e5frog, on Mon Aug 13, 2007 1:57 PM, said:

I made a copy of the Instruction set table of the "Polhoff"-book

Attached here as a Word-document:
F8_instr...et_table.doc

I'll have to take a look when I can get back on the net with my regular computer. My wireless extender died Linksys stuff seems to be crap these days..

[e5frog]

VESwiki has reappeared at a new address:

http://veswiki.com

[EmOneGarand]

e5frog, on Sun Nov 18, 2007 10:16 AM, said:

VESwiki has reappeared at a new address:

http://veswiki.com

thanks for the update! If I ever get the time to work on my program I'll be sure to take a look

[e5frog]

Just wanted to let everybody know that I've made a converter program that converts 1-bit color bitmap files to a blitGraphic object.

Simply drag and drop your bmp-file on the exe-icon or run from command prompt. If run from command prompt there's a switch called -i that can be used after the filename (which then has to be specified) which inverts the output in case original picture had the colors swapped.

If no filename is supplied it will try and read the file bitmap.bmp, output file is always called blitgraphic.data.txt.

Maximum size is 128 x 64 (same size as VRAM of the VES).


Any questions, do ask, feedback is most welcome.

Can be found in the http://veswiki.com here: http://veswiki.com/Homebrew:BMP2Blit

It makes graphics real easy!

All you need to do after copy and paste it into your code is to dci blitgraphic.bmp.parameters and then call blitGraphic with pi blitGraphic which you of course also have copied as a subroutine into your code.


Just go ahead and do some animation, with small enough graphics there's a lot of room!

[e5frog]

I've completed a MultiBlitGraphic converter as well and joined the two programs into one converter.

It takes a 1 bit color (2 colors) or 4 bit color (16 colors) .bmp and converts a two-color bitmap to blitGraphic-data and 16 color bitmap to MultiBlitGraphic-data as described on veswiki.com. Maximum size is still 128x64, note however that a blit- or MultiBlitGraphic object of that size will write in the background color encoding columns at column 125 and 126... Maximum visible size in MESS is 102x58 which is usually a little more than on a real system and TV.

An example picture is included to show which palette the 16 color bitmap is supposed to have to make your MultiBlitGraphic object look the same on the Channel F as on your bitmap picture.

I'll upload it to veswiki.com very soon...

Edited by e5frog, Tue Jul 15, 2008 9:02 AM.

[e5frog]

What has happened with EmOneGarand's game? Any updates?