You haven't loaded an image into the memory. Which is comparable to starting your computer with no harddrive. It doesn't know what to do.

Type "make memory", and it will assemble the sources in the "ram/" subdirectory.

From there, you can run "bin/tunguska memory.image", and it will load the freshly created memory.image into the memory, and it will provide at least some interaction.

--

Also, don't grow too fond of the assembler. I'm working on rewriting it pretty much from scratch, having the excellent GNU tools bison and flex do the parsing (it will mean a slight change in syntax as well). In the end, this will make the assembler much more powerful and flexible than it currently is.

It really was never intended to do half the stuff I've convinced it to do, so this rewrite really is for the best.

Also, the "RTI without BRK" message basically means it's run into an instruction telling it to return from an interrupt, without actually being in an interrupt. A symptom of the program counter somehow ending up outside of an area of memory with code, and into where-ever an interrupt handler has been installed. Or, in this case, with nothing in the memory, the memory automatically in it's vanilla state has an interrupt handler that just consists of an RTI instruction at the very end of memory.

So, whenever the machine has executed every single instruction of memory (and wraps around from 444:444 to DDD:DDD) it spits out a "RTI without BRK" warning (that actually serves a decent benchmark, if you clock the time between messages, you can pretty straightforwardly work out how many operations per seconds it's doing).

That was probably confusing to anyone that doesn't know the machine inside and out like me.

It would be great to have some kind of OS here to load "applications" that will call some API (like read character from keyboard, print character to display, compare strings etc.) by specified addresses, defined as constants in some INC-files

I found this project on FreshMeat: http://freshmeat.net/projects/tunguska/Does author have ideas to put it on SourceForge and use CVS? I personally can help with something useful for this project Some features that are interesting for me:
1) ability to load additional binary to address 000 (using functional key for example);
2) command RUN that will call subprogram from address 000;
3) ability to save memory image to file (using functional key for example);
4) all standard functions should be called by predefined and never changed addresses;
5) loading and saving files from programs;
6) support for color raster graphics (at least 16 colors by pixel);
7) mouse support.

It would be great to have some kind of OS here to load "applications" that will call some API (like read character from keyboard, print character to display, compare strings etc.) by specified addresses, defined as constants in some INC-files

That's sort of what I'm working towards, a standard set of includes that does the stuff you describe, where you simply include them in the assembly process (similar to how you include headers in C) to use them for your program.

Shaos wrote:

I have just checked Tunguska instruction set and I can't find operation "inversion". Should I use A(+)444 instead?

That would work. I personally prefer to use exclusive or with %111. Ternary exclusive or of two trytes A = <A1,A2,A3>; and B = <B1,B2,B3> is defined as <-A1*B1, -A2*B2, -A3*B3>, so exclusive or between A and <1,1,1> is <-A1, -A2, -A3>.

Shaos wrote:

Also I didn't understand sentence about PHA/PSH and PLA/PLL - should it be replaced in opcodes table?

That seems to be an error in the specifications, the table should read PSH and PLL; not PHA and PLA. I'll fix it with the next release.

Shaos wrote:

I found this project on FreshMeat: http://freshmeat.net/projects/tunguska/Does author have ideas to put it on SourceForge and use CVS? I personally can help with something useful for this project Some features that are interesting for me:1) ability to load additional binary to address 000 (using functional key for example);2) command RUN that will call subprogram from address 000;3) ability to save memory image to file (using functional key for example);4) all standard functions should be called by predefined and never changed addresses;5) loading and saving files from programs;6) support for color raster graphics (at least 16 colors by pixel);7) mouse support.

Sourceforge: I've considered it, but not gotten around to investigating it.

1,2,3,5: I've been planning to include some sort of permanent storage, sort of like what a diskette station would be to a regular computer. It would be possible to change the "diskette" on the fly. Once that's done, it should be possible to achieve the rest of what you describe with assembly code.
4: I've thought about that. I don't quite want to make them that static, but something like a standard "OS" with standard functionality is something I'm planning.
6: Maybe. If it is actually possible to do. Speed is a big issue with this. The latest version is a lot faster with redrawing since graphics has been migrated to a separate thread, but it's still sort of iffy whether this will be possible. Another big issue is size. Even an extremely low resolution, like 320x240 would eat more than 14% of the memory.
7: Planned. Maybe not in the next version, but shouldn't be that far off.

P.S. I've just built tunguska-alpha-1 for Windows using CygWin if somebody needs it:
http://nedopc.org/ternary/tunguska/tung ... -1-win.zip (955K)
SDL.dll and cygwin1.dll are included.
Also I created couple BAT-files to build new memory.image (prebuilt version is already there) and to launch "tunguska" with current memory.image

P.P.S. It's even working in WINE

P.P.P.S. I built it for MacOS X 10.4 (PowerPC) also, but with some small tricks:
1) machine::brk() should be public
2) strndup should be defined in assembler.cc
3) main() should have return 0 at the end (assembler.cc)

That's actually pretty smart. But there's an even better way, using indirect addressing.

Simply define functions as you would, and then add memory pointers like this

@feedscreen DW @_feedscreen
@puts DW @_puts
@clear DW @_clear
And, then when you want to run a function, you simply call for an example JSR (@puts)
--

However, you should hold off with any major assembly projects until the next release, since it comes with an overhaul of the assembly syntax. It is possible to convert existing assembly code by hand, but it's very tedious (I should know, I spent an hour doing it to the existing ram image.)

I'm glad that it's portable to windows and macos.

--

As for raster graphics you mentioned earlier. I experimented with it and it actually seems to be working fairly well. It may actually be added in the future.

That's actually pretty smart. But there's an even better way, using indirect addressing.

Simply define functions as you would, and then add memory pointers like this

@feedscreen DW @_feedscreen@puts DW @_puts@clear DW @_clearAnd, then when you want to run a function, you simply call for an example JSR (@puts)

Yes, you are right! I forgot about this feature

eudoxie wrote:

However, you should hold off with any major assembly projects until the next release, since it comes with an overhaul of the assembly syntax. It is possible to convert existing assembly code by hand, but it's very tedious (I should know, I spent an hour doing it to the existing ram image.)

I'm glad that it's portable to windows and macos.

--

As for raster graphics you mentioned earlier. I experimented with it and it actually seems to be working fairly well. It may actually be added in the future.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum