Tunguska the ternary emulator

[Shaos]

Done.

Great!

[eudoxie]

I've also written a short documentation of the new assembler

http://nedopc.org/ternary/tunguska/assembler.html

And uploaded an updated version of the specifications

http://nedopc.org/ternary/tunguska/specsdraft-cvs.pdf

[eudoxie]

To test out the new floppy disk system, I put together a small pong clone using vector graphics and mouse steering.

It's nice because it illustrates pretty much every change from alpha-1 to soon-to-be-alpha-2. It's a bit sphagetti-code at the moment. It's also a nice indicator of how fast Tunguska really is. I had to put 8 calls to random (which effectively is a wait for next clock interrupt) just to get it slow enough to be playable. That's just south of 3000 idle instructions.

Code: Select all

;  Small (completely unbeatable) pong clone. It is not loaded as an operating
;  system, but rather through the LOADSUB function. 
;
;  Assemble into pong.ternobj
;  Run 'tunguska image.ternobj -F pong.ternobj'
;  Type 'LOADSUB'
;

@EQU	mouse.y		%444C12

@ORG	%DDD000
	; Bootstrap function
	;
	; Read page 2 from disk into page 2 in memory
	LDA	#2
	LDY	#2
	JSR	(jumpvector.fl_read_block)
        ; ... and page 3
	LDA	#3
	LDY	#3
	JSR	(jumpvector.fl_read_block)

	JMP	pongish

; These won't be copied. They are also present in the host at the same
; memory location. 

@ORG	%001000
jumpvector:
.getstring:	@DW	0
.feedscreen:	@DW	0
.putchar:	@DW	0
.putnon:	@DW	0
.puts:		@DW	0
.strcmp:	@DW	0
.strlen:	@DW	0
.index:		@DW	0
.strspn:	@DW	0
.strcspn:	@DW	0
.memset6:	@DW	0
.random:	@DW	0
.between:	@DW	0
.repaint:	@DW	0
.fl_read_block: @DW	0
.fl_write_block: @DW	0

@ORG	%002000
pongish:
		; Clear the screen
		LDX	#%DDB
		LDY	#%DDD
		LDA	#0
.clearloop:
		STA	X,Y
		INY
		JVC	.clearloop
	
		; Enable vector mode
		LDA	#%003
		STA	%DDDDDB
.loop:
		LDA	mouse.y

		LDX	#-121+paddle.height/2
		LDY	#121-paddle.height/2
		JSR	(jumpvector.between)
		STA	paddle.pos
		STA	mouse.y

		JSR	paddle.draw
		JSR	enemy.draw
		JSR	ball.draw
		JSR	ball.move
		JSR	enemy.move

		JMP	.loop


.txt:		@DT	'PONGISH', 0

paddle:		
.pos:		@DT	0
@EQU		.vectors	%DDBDDD		; Length 4*3
@EQU		.height		27
@EQU		.width		3

.draw:
		LDA	#%DDD

		STA 	.vectors
		LDA	#%444
		STA 	.vectors+3
		STA 	.vectors+6
		STA 	.vectors+9
		STA 	.vectors+12

		LDA	#121-.width
		STA	.vectors+1
		STA	.vectors+3+1
		STA	.vectors+12+1
		LDA	#121
		STA	.vectors+6+1
		STA	.vectors+9+1

		LDA	.pos
		CLC
		ADD	#0-.height/2
		STA	.vectors+2
		STA	.vectors+9+2
		STA	.vectors+12+2
		LDA	.pos
		CLC
		ADD	#.height/2
		STA	.vectors+3+2
		STA	.vectors+6+2

		RST

enemy:
.pos:		@DT	0
@EQU		.vectors	%DDBDDD+15	; Length 4*3
@EQU		.height		27
@EQU		.width		3

.draw:
		LDA	#%DDD

		STA 	.vectors
		LDA	#%444
		STA 	.vectors+3
		STA 	.vectors+6
		STA 	.vectors+9
		STA 	.vectors+12

		LDA	#-121+.width
		STA	.vectors+1
		STA	.vectors+3+1
		STA	.vectors+12+1
		LDA	#-121
		STA	.vectors+6+1
		STA	.vectors+9+1

		LDA	.pos
		CLC
		ADD	#0-.height/2
		STA	.vectors+2
		STA	.vectors+9+2
		STA	.vectors+12+2
		LDA	.pos
		CLC
		ADD	#.height/2
		STA	.vectors+3+2
		STA	.vectors+6+2

		RST
.move:
		LDA	.pos
		LDX	#-120+.height/2
		LDY	#120-.height/2
		JSR	(jumpvector.between)
		STA	.pos

		LDA	.pos
		CMP	ball.y
		JLT	.inc
		JGT	.dec
		RST
.inc:		
		INC	.pos
		RST
.dec:
		DEC	.pos
		RST
	
ball:
.x:		@DT	0
.y:		@DT	0
.vx:		@DT	2
.vy:		@DT	1
		@EQU	.width 4
		@EQU	.height 4
		@EQU	.vectors	%DDBDDD+30	; Length 4*3
.draw:
		LDA	#%DDD

		STA 	.vectors
		LDA	#%444
		STA 	.vectors+3
		STA 	.vectors+6
		STA 	.vectors+9
		STA 	.vectors+12

		LDA	.x
		CLC
		ADD	#0-.width/2
		STA	.vectors+1
		STA	.vectors+3+1
		STA	.vectors+12+1
		LDA	.x
		CLC
		ADD	#0+.width/2
		STA	.vectors+6+1
		STA	.vectors+9+1

		LDA	.y
		CLC
		ADD	#0-.height/2
		STA	.vectors+2
		STA	.vectors+9+2
		STA	.vectors+12+2

		LDA	.y
		CLC
		ADD	#.height/2
		STA	.vectors+3+2
		STA	.vectors+6+2

		RST
.move:
		LDA	.x
		ADD	.vx
		STA	.x

		LDA	.y
		ADD	.vy
		STA	.y

	
		; Flip y if floor/ceiling collision
		LDA	.y
		CMP	#121-.height/2
		JGT	.flipy
		CMP	#{.height/2 - 121}
		JLT	.flipy

		; Don't perform collision detection if not close to
		; user paddle, x-wise
		LDA	.x
		CMP	#121-paddle.width/2
		JLT	.enemytest

		; If paddle position - height/2 > y, reset
		LDA	paddle.pos
		ADD	#0-paddle.height/2
		CMP	.y
		JGT	.reset


		LDA	paddle.pos
		ADD	#paddle.height/2
		CMP	.y
		JLT	.reset

		JMP	.flipx

.enemytest:
		LDA	.x
		CMP	#-121+paddle.width/2
		JGT	.mdone

		; If paddle position - height/2 > y, reset
		LDA	enemy.pos
		ADD	#0-enemy.height/2
		CMP	.y
		JGT	.reset

		LDA	enemy.pos
		ADD	#enemy.height/2
		CMP	.y
		JLT	.reset

		JMP	.flipx

		LDA	.x
		CMP	#121-.width/2
		JGT	.flipx
		CMP	#-121 + .width/2
		JLT	.flipx

.mdone:
		JSR	(jumpvector.random)
		JSR	(jumpvector.random)
		JSR	(jumpvector.random)
		JSR	(jumpvector.random)
		JSR	(jumpvector.random)
		JSR	(jumpvector.random)
		JSR	(jumpvector.random)
		JSR	(jumpvector.random)
		RST
.reset:
		LDA	#0
		STA	.x
		STA	.y
		RST
.flipy:
		LDA	.vy
		EOR	#%444
		STA	.vy

		LDA	.y
		LDX	#-121+.height/2
		LDY	#121-.height/2
		JSR	(jumpvector.between)
		STA	.y
		RST
.flipx:
		LDA	.vx
		EOR	#%444
		STA	.vx

		LDA	.x
		LDX	#-121+.width/2
		LDY	#121-.width/2
		JSR	(jumpvector.between)
		STA	.x

		RST

[Shaos]

It's almost uncontrollable by mouse
Also it looks slow on my Linux...
P.S. After removing "random" calls it became much faster
but still impossible to control something by mouse...

[eudoxie]

Yeah, I know, the mouse has issues. I havn't been able to pinpoint exactly what's going wrong though.

As for the speed thing, I've got a dual-core computer, that probably has a huge speed effect (since it's dual threaded now adays).

--edit--

I tinkered with the mouse interrupts. They -may- be less buggy now. Not completely though.

[Shaos]

Yeah, I know, the mouse has issues. I havn't been able to pinpoint exactly what's going wrong though.

As for the speed thing, I've got a dual-core computer, that probably has a huge speed effect (since it's dual threaded now adays).

--edit--

I tinkered with the mouse interrupts. They -may- be less buggy now. Not completely though.

If you add API to read "real-time clock" with 1 ms precision from Tunguska programs then it will become possible to write "self adjustable" programs that will work similar on computers with different computational power.

[eudoxie]

Hm, something like that could be doable. Something like a call that simply takes the host RTC, and stores it in a register. It would only be good for differentials since it wraps around to %DDD after %444, but it could be very useful to gague stuff like "how much time does it take to do this", and then adapt the program accordingly.

I'll tinker with that later.


--edit--
I need an opinion on an idea I had: Implementing some trigonometric functions on machine level, primarily sine and cosine. It would calculate the product of sine or cosine of the accumulator with a memory address, and store it in accumulator.

And the angle argument would be in degrees (it's a hard urge to resist with 364 being so close to 360.)

It would be very useful to have fast sine and cosine functionality with vector graphics and whatnot.

[Mac Buster]

Is it possible to load raw binary data to memory of Tunguska without encoding to balanced ternary code ? I mean that after loading data should take as many trits as number of bits in original binary file. Binary 0s must be left as ternary 0s, and binary 1s should be left as ternary +1s (or it could be converted to ternary -1s).

[Shaos]

sin/cos may be implemented with values -364...+364 instead of -1.0...+1.0 and input may be degrees (0...360)

P.S. I tried to compile last version for Windows. First problem - using of option "-o" in tg_assembler does stack dump. Also "pong" is not working for some reason...

[eudoxie]

Is it possible to load raw binary data to memory of Tunguska without encoding to balanced ternary code ? I mean that after loading data should take as many trits as number of bits in original binary file. Binary 0s must be left as ternary 0s, and binary 1s should be left as ternary +1s (or it could be converted to ternary -1s).

Not by design, but there shouldn't be any problem writing a converter. The file format is just a gzipped series of signed shorts with values in the range [-364,364]. So, if you wanted to convert a "plain binary" file into a file that would effectively be loaded as you describe, you could write a function like this

Code: Select all

short bin2tern(unsigned char c) {
  return (c&1) + 3*(c&2) + 9*(c&4) + 27*(c&8) + 81*(c&16) + 243*(c&32);
}

and iterate through all the bytes in the file, and write the output of bin2tern as an array of unsigned short to a file.

sin/cos may be implemented with values -364...+364 instead of -1.0...+1.0 and input may be degrees (0...360)

Hm, that could work...

P.S. I tried to compile last version for Windows. First problem - using of option "-o" in tg_assembler does stack dump. Also "pong" is not working for some reason...

That's strange. I can't think of anything I have touched since the last version you ported. Maybe it's zlib-related somehow. (that's a dependency now)

Beyond that, I really can't help you. I haven't got any experience in cross-OS porting at all.

[Shaos]

P.S. I tried to compile last version for Windows. First problem - using of option "-o" in tg_assembler does stack dump. Also "pong" is not working for some reason...

That's strange. I can't think of anything I have touched since the last version you ported. Maybe it's zlib-related somehow. (that's a dependency now)

Beyond that, I really can't help you. I haven't got any experience in cross-OS porting at all.

Actually I tried to use options for a first time just in latest Windows version, so probably it was broken since first version...

[Shaos]

P.S. I tried to compile last version for Windows. First problem - using of option "-o" in tg_assembler does stack dump. Also "pong" is not working for some reason...

That's strange. I can't think of anything I have touched since the last version you ported. Maybe it's zlib-related somehow. (that's a dependency now)

Beyond that, I really can't help you. I haven't got any experience in cross-OS porting at all.

Actually I tried to use options for a first time just in latest Windows version, so probably it was broken since first version...

Ok, the next "unofficial" build of Tunguska for Windows:

http://nedopc.org/ternary/tunguska/tung ... _2-win.zip (1.1M)

P.S. Demo program pong.asm and pong.ternobj are included (with build_pong.bat and launch_pong.bat)

P.P.S. For CYGWIN version the order of arguments is important:
tg_assembler pong.asm -o pong.ternobj crashes, but
tg_assembler -o pong.ternobj pong.asm works and
tunguska out.ternobj -F pong.ternobj does nothing by LOADSUB, but
tunguska -F pong.ternobj out.ternobj runs the demo...

[eudoxie]

I think that's how it is supposed to behave in Linux as well, strictly speaking from how 'getopt' is specified. So the problem is that Linux libc does it's work better than it's supposed to.

--

I'm considering changing the default file extension away from .ternobj to something more manageable. I haven't made up my mind as to what to replace it with. I've got the following ideas:

.tto, as in ternary/tunguska object.
.tti, as in ternary/tunguska image.
.tmi as in ternary/tunguska memory image.
.tmo as in ternary/tunguska memory object.
.img as in image. Problem with this one is that the extension also is used for CD images and whatnot, and it could cause confusion as to what sort of file it is.

I'd also be glad to hear other suggestions.

--

I put up a test build of tunguska just now. If you can get it to build without any problems (it's using automake instead of that homemade makefile system I used with alpha-1), I'm going to release version 0.0.2 within a few days.

http://nedopc.org/ternary/tunguska/tung ... st.tar.bz2

[Shaos]

It's compiled successfully, but make install tried to install binaries to /usr/bin that is not good I think, because by default it should be /usr/local/bin, right?

P.S. What if extension will be simply .tg? tg_assembler will create tg-files

[eudoxie]

That's peculiar. Could you try compile some other automake-based package and see if it does the same? It attempts to install to /usr/local/bin on my system.

--edit--

I just released version 0.0.2.