Reviving the Vera project!

[Timendus]

Dear friends, community members and other nerds,


Summary: I need some experienced people from the scene to help me work on an alternative OS for the calc in C. If you're in any way interested, please read on and drop me a line at mail@timendus.com

Edit: Could someone link the UTI forums to this topic please? Vera originated there, but I can't seem to remember my password on their forum...


I'm somewhat seriously considering reviving the Vera project as a personal toy, because I'll be working on an adaptation of the Linux kernel in a somewhat professional capacity in the coming several months, and writing my own lightweight kernel could be a nice alternative to working the monolithic giant with millions of LOC that is the Linux kernel. Also, it could be a nice experiment in setting up an open source project.

For those of you who don't know what the Vera project is (or better put - was): Vera is the name of an attempt at an open source community effort for writing an alternative operating system for Ti-83+ and family calculators. Unfortunately, the project attracted many very interested, but very inexperienced enthousiasts who basically just wanted to bring TI Basic 2.0 to life. Also, people started talking about all kinds of things like "plugins", "extensions", "programs", "files" et cetera without actually defining what these things meant. It lacked any kind of leadership to stear away from these problems and focus on what needed to be done, because nobody could really afford to put any time in it.


What's going to be different this time?
- It'll be my project; anyone can submit code, changes, bugfixes, patches and the likes, but I'll decide what gets in and what doesn't (although I'll probably appoint one or two others to help me make such decisions, and I'll probably welcome any attempt at writing code with great relief and joy )
- The required entry skill level should be slightly lower, because I'll be aiming primarily at an easy to use development environment before I move on to the actual OS, I'll try to keep the code clearly structured and commented, and most of the OS should be written in C (what'ya saying? C? Yup, more about that later)
- No open forum, not even forum-based releases untill there's actually something working to release, no wiki, no publicity, big words and getting people's hopes up, but just a mailinglist and probably a CVS or FTP server. Anyone can apply to get on the mailinglist, but it'll require some useful skill known to the rest of the mailinglist (which currently means: me) to get accepted (knowledge of hardware internals, experienced ASM programmers, good C programmers, people with experience on the Linux kernel, people with good ideas, et cetera. In other words: knowing Basic isn't going to be enough)

What gives me the right to claim control over this project?
Nothing does. But it's been abandoned for months, even the website and wiki are dead nowadays. And I came up with the name

What's been done yet?
Hardly anything I've split the original source made by Jim e (or to be more precise: my adaptation with "console" of it) into a few different files and directories, only to conclude that I didn't want it that way and that I wanted to do this in C. I've written a makefile to compile the source using Brass and run it using PTI through my PTI frontend, and did the same with a batch file named "make" for Windows users (though that remains untested). I've started a readme on how to compile and run the thing. I've searched for, and found, a C compiler that compiles and optimizes for Zilog z80 processors and read up on how to write libraries for it (to control the LCD, the keyboard, et cetera; this is going to be a significant part of writing the OS). In other words: I'm trying to set up a good programming environment. No real work on the OS has been done yet, though I've got a few ideas forming in my head.

What goals do you have in mind for Vera?
At kernel level:
- To provide a robust platform that's fun to play with for developers and a good learning experience for everyone involved
- Investigating the possible use of C in z80 calc programming
- Support multitasking (I know it can be done, so who knows, with the right tools )
At application level:
- Provide the possibility to do some calculations with it, since it's still a calculator
- "Compatibility" with Ti-OS in the sense that it should be able to communicate with normal calcs through the link port and transfer files
- Provide a platform on which programming language other than Basic could be developed (on-board C compiler, interpreters, ...?) which brings us back to the first item in this list


So, if you're interested in keeping informed about this project, if you support the cause, if you're interested in learning about (and helping to develop) programming for the calc in C or in a fun little open source experiment, drop me a line at mail@timendus.com with your TI scene nickname and your reasons for wanting to join in (if any ). Contributing code or active participation in discussions is certainly not necessary; I also need testers with know-how, more eyes for spotting bugs and just occasionally the experience of the community, really. And I will not have all that much time to spend on this project either


Oh, a final word on programming in C for the calculator. I know a lot of people are against this bacause it produces bloated code, I know a lot of people have wanted to do it but failed to find a proper compiler. I think I have found a good compiler and a good reason to do it. An OS is just too big a project to work on with only an assembler, assembly is just too chaotic to write an OS in as it misses any form of abstraction, template programming, doesn't have the least bit of memory management, et cetera...

And I think that the main reason why people think compiling C to assembler produces bloated code is that it tends to include it's own libraries with displaying routines and whatnot, where you'd normally rely on the Ti-OS routines. But in this case, we will not be able to rely on the OS, as we'll be building the OS, and write those routines ourselves. So there'll be plenty of work for the true assembler freak; we'll need to use a lot of inline assembler code to get our calcs to communicate with the LCD, the keypad, the interrupts, the link port...

[Jim e]

If I remember correctly the death of vera was the FONT.

You're still aiming to high. Kernel should only provide a layer of abstraction between the hardware and the software. Hell it shouldn't even have a graphical user interface since that would change radically down the line.

If you're really serious you should figure out a good model for everything that is an absolute must in for the kernel. Then move on to the OS from there.

[Timendus]

If I remember correctly the death of vera was the FONT.

The font was just one of the many aspects of people not looking past the GUI/CLI. But let's not get back to discussing what went wrong, let's look ahead. And I want you in

You're still aiming to high. Kernel should only provide a layer of abstraction between the hardware and the software. Hell it shouldn't even have a graphical user interface since that would change radically down the line.

Don't worry, it won't. It'll be hardware abstraction (including some abstract concept of file, probably) and - if we can pull it off - some form of multithreading with timeslotting. On top of that comes some kind of shell which will certainly not be a first priority, and perhaps a few daemons that are even less of a priority. Things will be modular, things will be "simple".

[Demon]

Maybe Vera and this project...

http://www.ticalc.org/archives/files/fi ... 39863.html

...should combine forces.

[tr1p1ea]

Revive? More like 'start' .

Im with Jim e on this one also, you dont need bells and whistles, you need a base. Critical routines for working with hardware and managing memory (which will also need to be planned out).

[CoBB]

I envy you for all that free time. Food for thought: Contiki is finally being ported to a Z80-based platform (using sdcc) by a guy called Takahide Matsutsuka. This OS offers nice things like multitasking (cooperative though), TCP/IP support and even an on-board ELF loader if you want, which allows hot-pluggable processes written in C. You should definitely check out the source.

[Timendus]

Maybe Vera and this project should combine forces.

Nope, he's already done all the fun stuff, and in assembly

Revive? More like 'start'

Revive the project, start the development...

Im with Jim e on this one also, you dont need bells and whistles, you need a base. Critical routines for working with hardware and managing memory (which will also need to be planned out).

Correct. I believe that's pretty much what I've been saying..?

I envy you for all that free time.

I have none, that's what makes me productive

Food for thought: Contiki is finally being ported to a Z80-based platform (using sdcc)

That's looking pretty advanced, apart from the ASCII effects. TCP/IP support isn't very likely to work for the calculators, considering the limited number of lines we can spare (really just the two from the link port), but an ELF loader... damn

Anyway, sdcc is also the compiler I had in mind. I seems quite capable of producing proper assembly, it just needs libraries and a way to convert the output to a ROM image, which is something that's being worked on according to the website you mention. Nice

[Jim e]

I think multitasking is a whistle.

Honestly I would really like a c compiler for some things, I just hate doing math in z80. It's the worst the existence of mankind. I just don't know any that are set up to well for practical coding.

[CoBB]

I have none, that's what makes me productive

I'm not feeling that effect unfortunately... I'd gladly take part in this, but the most I can contribute is some verbal input, so take me in as you see fit.

That's looking pretty advanced, apart from the ASCII effects.

That's not part of the core, of course. As far as I understand there's a ridiculously cross-platform GUI (?) library included that you wouldn't need anyway. But you should definitely read up on protothreads, which were invented for Contiki.

TCP/IP support isn't very likely to work for the calculators, considering the limited number of lines we can spare (really just the two from the link port), but an ELF loader... damn

I had the pleasure to use this feature on Tmote Sky sensors (MSP430 clocked at 8 MHz), and it worked pretty well. I mean, it wasn't even too slow.

Anyway, sdcc is also the compiler I had in mind. I seems quite capable of producing proper assembly, it just needs libraries and a way to convert the output to a ROM image, which is something that's being worked on according to the website you mention. Nice

I don't know, I did some experiments with it, but the assembly output never seemed too promising. Probably the IAR compiler is the best you could possibly get your hands on, but it's a commercial product.

[Timendus]

Hmm, I can't seem to get sdcc to output in a proper format. Manually transforming the ihx file into a .83p gives me all wrong adresses, resulting in very ugly jumps into Ti-OS space... I should give the ihx to rom thingy a try.

Protothreads look like fun, but I'd rather have proper multithreading, combined with threads being able to hand the processor back in. That would allow for daemon like threads that monitor something "in the background", taking up only 1% of the CPU time, without the "foreground" process having to know about it. Protothreads only run as long as you keep calling them in your main loop.

Being able to use uIP would open up a LOT of doors, but I think it'd be overkill. We can't plug the calculator into an ethernet connection or a WiFi stick anyway, so in communicating with other calculators and a PC some serial protocol will probably do just fine.

Anyway, I will not have much spare time over the weekend, so I'll start adding people to the mailinglist next week. I hope to keep it relatively small for now. CoBB and Jim; I'll be needing your e-mail adresses Ben, if you're reading this, I'm adding you too

[King Harold]

I don't know about this sdcc, it made some very odd code when I tried it
Excessive use of index registers and SP..
Is that because of the libs?

Idea: make the thread checker/switcher callable (then threads can call it and thus pausing because an other thread would be called - well unless it's the only thread)
On second thought, that sounds too simple to work (if it did you'd already have thought of it)

[Timendus]

You're right about the index registers and the stack pointer... I don't really like that either. But I'd guess it enables local variables on the stack, and allows the routine to dump all those variables by replacing the stack pointer when it returns. Nothing wrong with that, except when you don't use any local variables in a given function... And there must be a better way than by using ix... But then again it's an open source project, so maybe we could help them improve on a few small things like this while we're at it.

And what I wanted to do with the multitasking was something pretty much like what Ben made a few months ago. An interrupt routine timeslotting X different threads by making a context switch, so they have to share the CPU. But I'd like to add a sleep function, so processes that don't need as much CPU time (because they're waiting on something that hasn't happened yet) can tell the system to make the context switch earlier. That way several small threads could easily keep track of things like silent transfers, special key combinations and stuff, without taking 1/Xth of the available CPU time. And we'd also need a function to tell the interrupt to back off for a while, for processes that are either time critical or too heavy on the CPU.

Code: Select all

while(1) {
    if ( linkport_anyLineLow() ) {
        // Start taking up your 1/Xth of the CPU time,
        // maybe even stop the multitasking interrupt
        linkport_acceptTransfer();
    } else {
        // Nothing this time, let the next thread have it
        sleep();
    }
}

Also, keeping a kernel thread running in the background could be useful for killing threads that have crashed, restarting your shell when it quits unexpectedly, ... You can't do this with protothreads, and still run totally thread-unaware programs (maybe even ordinary assembly games from ticalc.org).

[driesguldolf]

I just found this topic, has any progress been made? Because I really want to be in and I have alot spare of time...

Btw, how does one make an OS? I mean in terms of compiler/linker?

Oh yeah, 'bout that multitasking thing, maybe you could utilise the fact that there are 2 ram pages in a ti83plus. This would allow easy multitasking AND there's no mess with absolute addresses.

[benryves]

Btw, how does one make an OS? I mean in terms of compiler/linker?

Any Z80 assembler will do. For testing purposes you can just dump out a raw binary and use it as a ROM dump.

[Timendus]

Hey Ben, good to ehm... "see" you again How are things going?

I just found this topic, has any progress been made? Because I really want to be in and I have alot spare of time...

If you look at the date of the first post you'll see that this thread has only existed for three days, so take it easy, cowboy You can join in, requiring that you have some useful skill or knowledge to add. And there hasn't been any "progress" in the usual meaning of the word, just some conceptual talk and convincing people I don't envision a bloated Basic 2.0 capable beast.

Could someone please point me to some kind of reference that would explain (or make it obvious) to me what all the different .org's and port read/writes in the (let's call it) "boot sector" are good for? I know it doesn't have anything to do with the calculator, it's z80 specific, but what does it do, and why?

Oh yeah, 'bout that multitasking thing, maybe you could utilise the fact that there are 2 ram pages in a ti83plus. This would allow easy multitasking AND there's no mess with absolute addresses.

That reminds me of a problem my ideas don't yet address; absolute jumps in a relative context... I would prefer to execute programs directly from flash ("the file system") to keep the RAM as empty as possible, let them allocate some memory through the kernel, and only have to swap the stack and the registers on a context switch. But that would require us to convince sdcc to keep from using call and jp, or somehow magically work around it...
Anyway, your idea is good, except that it doesn't really comply with my idea of keeping the RAM purely for memory allocation (runtime memory), but there's a bit of a problem with it if you'd want more than two threads