Tunguska the ternary emulator

[eudoxie]

Good to see it still ports with the new bison and flex dependencies...

[Shaos]

Good to see it still ports with the new bison and flex dependencies...

CYGWIN does everything (plus good SDL port for it)

[Shaos]

P.S. Right now I'm working on "alternative" Tunguska assembler with "alternative" syntax, based on my RoboAssembler (RASM)
Next step - to make my C-like programming language to be able to cross-compile programs for Tunguska...

RASM v2.4 released!!!

http://sourceforge.net/project/showfile ... _id=181535

RoboAssembler (universal assembler with external opcode tables) released as GPL source code and binaries for DOS (16-bit and 32-bit EXE), Windows, Linux-x86, Linux-PPC and MacOSX-PPC. It supports "alternative" assembly languages for Intel 8080/8085, Intel 8086/8088 (this one is not fully supported, but it's enough to do something useful) and (since v2.4) Tunguska the ternary emulator (see project "tunguska"). Limitation of Tunguska programs - address range from 0 to 32K only.

[eudoxie]

That's cool.

I finished adding mouse support for tunguska today, as well as added a small (and buggy) demo of raster graphics.

[Shaos]

That's cool.

I finished adding mouse support for tunguska today, as well as added a small (and buggy) demo of raster graphics.

We noticed that

When do you plan to release alpha 2?

Actually I need something simple to launch my programs on Tunguska:
1) vector of system calls in known place (to call it from separate subprogram);
2) free space from %000000 to %100000 (in address %000000 you can have JMP inloop for first run to jump to main program somewhere above %100000);
3) ability to load file to that free space (for example using key F8 and simple file dialog);
4) ability to run subprogram from %000000 (for example using command SUB).

I did some of that changes in my copy of sources - just for testing, but if you will do this functionality in official version it would be great!

[eudoxie]

Alpha 2 will be along when I get some of these bugs worked out. Also, I need to make some documentation. It's looking reasonably stable now, but I still don't feel it's quite ready.

I've been planning to add something like that. Maybe not exactly the way you describe it, but similar. But probably not for this release, maybe alpha 3.

[Shaos]

Alpha 2 will be along when I get some of these bugs worked out. Also, I need to make some documentation. It's looking reasonably stable now, but I still don't feel it's quite ready.

I've been planning to add something like that. Maybe not exactly the way you describe it, but similar. But probably not for this release, maybe alpha 3.

Ok, here is a "patch" for Tunguska sources from 22-Feb-2008 (I name it "alpha 1.1") that gives us ability to launch subprograms compiled for Tunguska by RASM v2.4

http://nedopc.org/ternary/tunguska/tung ... tch.tar.gz (14K)

To get correct Tunguska sources you need to run script "download_tg080222" that will download sources from the past using CVS repository on SourceForge. Then simple "make" will do compilation including patching by 4 diff files and one additional assembler file stdtab.asm:

Code: Select all

@ORG 		%1DA000
v_feedscreen:	@DW	feedscreen
v_putchar:	@DW	putchar
v_putnon:	@DW	putnon
v_puts:		@DW	puts
v_strcmp:	@DW	strcmp
v_strlen:	@DW	strlen
v_index:	@DW	index
v_strspn:	@DW	strspn
v_strcspn:	@DW	strcspn
v_memset6:	@DW	memset6

Simple example TG_TEST.A is included to archive (use TG_TEST_MK to compile it by RASM):

Code: Select all

    ORG 0

+TUNGUSKA
+TERNARY

    LAD STR
    JSR_IN @PUTS
    
    RST

STR DW @TG_TT,@TG_EE,@TG_RR,@TG_NN,@TG_AA,@TG_RR,@TG_YY,@TG_DOT,@TG_II,@TG_NN,@TG_FF,@TG_OO,@TG_NLINE,0

To run it use "launch" to launch Tunguska, then F3 to load sub.tg0, then "SUB" to call address %000000 where we already have loaded subprogram...

P.S. Don't forget to download and build RASM v2.4 from here http://sourceforge.net/project/showfile ... _id=181535

[Shaos]

README from tunguska-alpha-1_1-patch.tar.gz:

Code: Select all

To build patched version of Tunguska-2008-02-22 (alpha 1.1) 
do this (intenet connection is required for download!):

 ./download_tg080222
 make

It should create tunguska and tg_assembler binaries and memory.ternobj

To launch Tunguska use "launch"

To build "sub.tg0" from TG_TEST.A use TG_TEST_MK (need RASM v2.4)
http://sourceforge.net/project/showfiles.php?group_id=181535

F3 - loading of "sub.tg0" subprogram
SUB - launch loaded subprogram in Tunguska

* Description of changes in ram.asm:

1. After label "null:" put these 2 lines

    JMP inloop
    @ORG %100000

2. In "commands:" add new command:

    @DW sub_txt,null

3. Before label "help:" put name of new command:

sub_txt: @DT 'SUB',0

4. Add description of new command to ".message":

    @DT '  SUB (call loaded subprogram)', 2

* Description of changes in machine.h:

1. Add new protected method:

    int load(int address, const char* filename);
    
* Description of changes in machine.cc:

1. Add new method body:    

 int machine::load(int address, const char* filename)
 {
 	FILE* f = fopen(filename, "rb");
 	if(!f) { perror("fopen"); return 0; }
 	fseek(f,0,SEEK_END);
 	unsigned int sz = ftell(f);
 	fseek(f,0,SEEK_SET);
 	short data;
 	int end = address+(MEMSIZ>>1)+(sz>>1);
 	for(int t = address+(MEMSIZ>>1); t < end; t++) {
 		fread(&data, 1, sizeof(short), f);
 		memory[t] = data;
 	}
 	fclose(f);
 	return (int)(sz>>1);
 }

* Description of changes in keyboard.cc:

1. Add new cases in switch(e->key.keysym.sym) in method kboard::got_key:

 	case SDLK_F2: m->save("saved.ternobj"); return;
 	case SDLK_F3: m->load(0,"sub.tg0"); return;
		
	
Alexander Shabarshin <shaos@mail.ru>
http://ternary.info

[eudoxie]

Interesting. But I'm not sure I like how it injects data directly into the memory, it feels like cheating somehow. It would be much more elegant to have a virtual "floppy disk", where you can load and save stuff from/to the memory by writing assembly functions for it.

But that's quite a lot of work to get done, so it might be better to use your code in the meanwhile. I'll tinker with it later tonight.

[Shaos]

Interesting. But I'm not sure I like how it injects data directly into the memory, it feels like cheating somehow. It would be much more elegant to have a virtual "floppy disk", where you can load and save stuff from/to the memory by writing assembly functions for it.

Anyway you will load it to memory - directly or indirectly

But that's quite a lot of work to get done, so it might be better to use your code in the meanwhile. I'll tinker with it later tonight.

If you will do something similar in your official code then my personal request is to keep vector of system functions in 0...32K address range (it can be even immediately after ORG 0; JMP inloop) - it will be much easier to implement first version of my cross-compiler for Tunguska because it will have the same limitation as intermediate RASM level...

[eudoxie]

Yeah, something like that should be doable.

[Shaos]

Yeah, something like that should be doable.

Thanks!

[eudoxie]

I've added basic disk support now. It isn't very tested, but it seems to work fine. I also added a loadsub-function like you described. It only loads one page, but it should be possible to -in that page- write a basic disk driver that loads more code into different memory areas.

I'm working on a jumpvector like you described now.


--edit-- The jumpvector is in. To call a specific function, just do something like
JSR (jumpvector.getstring)

--edit2-- I've added gzip compression of the memory image format (this applies to the virtual disk as well). This will reduce the .ternobj-file size from 1.1 mb to a few kb. And from what I understand form gzip's documentation (and a test confirms this), loading non-compressed formats will not be a problem. Gzip will automatically identify them as uncompressed, and just pass them on as they are.

[Shaos]

I've added basic disk support now. It isn't very tested, but it seems to work fine. I also added a loadsub-function like you described. It only loads one page, but it should be possible to -in that page- write a basic disk driver that loads more code into different memory areas.

I'm working on a jumpvector like you described now.

--edit-- The jumpvector is in. To call a specific function, just do something like
JSR (jumpvector.getstring)

--edit2-- I've added gzip compression of the memory image format (this applies to the virtual disk as well). This will reduce the .ternobj-file size from 1.1 mb to a few kb. And from what I understand form gzip's documentation (and a test confirms this), loading non-compressed formats will not be a problem. Gzip will automatically identify them as uncompressed, and just pass them on as they are.

Great work! Loading of first "floppy" sector to %000xxx and vector of system calls at %001000 look fine, but command processor (inloop) is now located at %002000 and it still occupies memory that can be used by loaded programs (for example created by RASM or RW1P2 cross-compiler). Is it possible to move "inloop" to %100000 at least?

[eudoxie]

Done.