I'm trying to build the OS, but it seems that trunk/src/tools/ihx2rom.cpp is missing and it's causing the compilation to fail. Any ideas where I can get this?

I am due to look at committing again, however, I am a bit stuck... The OS has its launcher disabled and boots into a FORTH interpreter running in a test mode. I can try to get the toolchain change added to svn without breaking anything. Hopefully tonight if this hockey game doesn't go too late.

<edit>

Added revisions 86,87, and 88. You should be ok to build. I don't know if there any side effects from the missing forth code.

The rom compiles now, but I can't get glasslink to compile. it fails saying that the cmake variable "USB" was not defined while executing the task "gosusbcommd_"

You need to have libusb1 development packages installed. I lack any warnings there :/

Well I can't find the development package on my mac, so I tried building it on my fedora emulator after running `yum install libusb-devel`, but it still fails with the same error. Any ideas? Is that maybe the development package for libusb2.0?

libusb0.1 != libusb1

To grab it, use
Code:

I have been looking at the COMPILE word in FORTH that would take bytecode for FORTH words and compile them down to z80 op codes. Right now, the FORTH system has a main interpreter loop that will read a byte, parse it and either treat it as data, a branch, or a word call. This is a "safe" way as errors can be detected and reported back.

This isn't a good way to run programs quickly as each byte must be handled by the interpreter. Instead, a branch table will be added to allow redirecting words finishing execution, exception throwing, etc.. This will let me replace the bytecode with call/ret/ld/push/pop/jr/etc. removing unneeded code running.

I still have yet to code anything new for the OS, my focus is on other things right now :/

AHelper, did you base your forth implementation on any prior code? There's a full z80 implementation intended for CP/M in CamelForth, which also claims that it's suitable for conversion for usage on embedded systems.

GPLv3 license on it. Not sure if that's an issue for you.

http://www.camelforth.com/page.php?5

They claim 6KB of Program ROM and 640B of RAM for a standalone implementation, not counting programs you execute.

No, I wrote it from scratch mainly because I haven't made any z80 asm projects yet.

Thanks for the link, I will try to look and use parts of it when possible (I am also GPLv3, no issues).

What happened to GlassOS, you may ask?

Firstly, college. I am "busy"... I have been focusing my time on Redintegrate right now. However, that says nothing about the status of GlassOS.

Right now, I have glassFORTH on my plate. The OS is unstable to be put into subversion else my rom and 8xus will be made unusable. glassFORTH currently can run compiled programs using bytecode and mixed in z80 asm. It can't compile yet, I am writing the actual compiler in FORTH and hand-compiling that.

After that, I will need to make a optimizer that can look at the bytecode of FORTH programs and insert z80 asm into the program, optimizing register usage. Instead of having a bunch of stack manipulation ops run together in bytecode, I can take the asm version of them, allocate registers and output an optimized asm form. A bit more than a normal peep-hole optimizer.

I will probably look at working on this over break once my finals are done and I have fully enjoyed Doctor Who on Saturday.

Currently throwing out details on gFORTH, mainly because I will forget eventually:

gFORTH runs by interpreting bytecode, simple as that. Right now, that all works.

The bytecode has the following rules:
Code:

Since it just reads bytecode, it has no words in it and no code to run. So, I have to bootstrap it with built-in words. I have quite a few built-in core words that are written in asm, which are made into words. In order for gFORTH to do something when ran, I also need to get it to interpret input. This means I have to write the interpreter by hand. I now can compile the FORTH code into bytecode instead of hand-compiling, so that is a big plus. For example, here is the source for a basic interpreter and the C structure output from the compiler (PC):

Code:
Writing the compiler in C helped a LOT with taking care of jump offsets. Those were hell to do by hand.

I currently have some code for a compiler, I just need to look it over and compile/tweek it and see how it runs. I might want to change up how the compiling works in relation to the interpreter, such as having compiling just change the mode that the interpreter works rather than taking control from it (current code does that).

An interpreter is working!... again?

My old interpreter, shown above, needed some love, so I rewrote it with a compiling mode built in. The interpreter and compiler (compiler almost done) are sitting at about 330 bytes in bytecode. I still need to get aborting working as it... has no where to go yet.

Expect me to show off what is working on HCWP today.

So I decided to try compiling GlassOS, and I get two errors about float_long being redefined. This is strange, as the source has an #ifndef that should prevent this.

I went ahead and commented the "extra" float definitions out, only to have a linker warning for __sdcc_isdigit not existing, while being referenced by _atof. Whether that's a real issue or not, it is preventing the makefile from finishing. I find this strange, since from what I can tell _atof is a reference to SDCC's own library, and not your code at all.

Is the most recent build of GlassOS up online to download? I looked on its site and there's missing gifs of GlassOS on the Ti 84+ CSE?

If you want a recent version at all, you'll have to build it yourself. However, unless you also make and install some apps for it, you won't have much to do aside from a game or two.

There's an extremely outdated version up on the sourcefourge page, here.
http://sf.net/projects/glassos/files

I did get it to compile after installing the right version of sdcc. It's quite promising. Once the FORTH finishes I might actually be able to use it for something

You actually got GlassOS compiled? On Linux or Windows?

Linux, but I can send you the OS file if you want it. I wouldn't recommend using it on an actual calc yet, since it doesn't do much as of now.

Once gCAS and the FORTH interpreter are done it will be a different story. You'll have math and programming then, as well as linker software. From there you've got about as much as TI-OS provides.

Can you please send me the OS file?

Here's a link to a 7z of the entire build folder. The 8xu and the rom should both work fine in an emulator.

https://dl.dropboxusercontent.com/u/10071991/glassos%20april%202014%20build/bin/GlassOS%20April%202014%20Build.7z

AHelper said he wasn't releasing official builds recently because the OS isn't really that usable for anything practical yet. Keep that in mind.

I don't think I'm breaking any rules by doing this, but if ahelper tells me to take down the link I will.

I strongly recommend installing it onto your calculator until you've tried it out on an emulator first. Then you can know if it's good enough for your purposes or not.

I understand. Thankyou so much will!

I shall install the correct revision of SDCC (639, correct?) to compile this myself too!