Hello,

First off, I will admit that I don't really post here often. I lurk a few times a week but have never really interact. I am more of a vintage computer guy.

Over the last 6 months I have been designing an operating system for 8 and 16 bit systems. While I have been designing it with the TI-84 in mind, it can be ported and will run on just about anything with at least 16kb of memory and some sort of timed interrupt. It is nowhere near complete, but over the last few weeks it has progressed to the point where I can demonstrate portions of the system.

While targeted at the TI-8x line of calculators, I am currently developing it on a custom Z80 system emulator I whipped up in Java. I did this so it is easier to interact with the system. I am also not a TI-84 expert, so this is easier to develop for.

What Is It?

System/I MICRON is a fully preemptive multitasking operating system. It is not another TIOS shell, but an entirely new operating system. Inspired by the likes of UNIX, OS/9, RT-11, and CP/M, it provides a powerful environment for designing, compiling, and running programs while using minimal resources. The finished operating system will include:

- Full preemptive multitasking.
- Ability to run comfortably in ~16kb.
- Process forking and piping.
- Drivers can be loaded/unloaded from memory on the fly.
- Batch files can be executed
- Hardware can be interfaced using device drivers.
- All user space programs can be compiled using the MICRON-Basic language, providing fully portability between architectures.
- Compiler, text editor, and command line standard on all systems.
- And much more

Why Is It Useful?

It isn't really, to be honest. It is more of an interesting programming project for me. Maybe once I finish up writing the core operating system, I can start writing network drivers or something.

What is Inside?

I tried to make MICRON as portable has humanly possible. No MMU or complicated interrupt hardware is required. The only things that are needed is a single timed interrupt to signal a context switch.

The system is divided up into two basic parts. The Kernel and the User Space. The Kernal allows user programs to be interfaced to the system. For my specific test-bed the Kernel is written in Z80 assembly. The Kernel is fairly small, as it only handles context switching, pipe management, and memory allocation. It takes up about 2kb of memory in total. All other programs are running in the user area. User area programs are all written in MICRON-Basic, which is a simple, basic-like compiled language that I wrote for MICRON. While it is fairly limited, it is better than assembly and allows for fully portability. This should make porting the system extremely easy, as the only things that need to be modified are the Kernel, compiler, and device drivers.

Here is a simple diagram of the MICRON system running the program TY.PRG



All user space programs interact with the Kernel in some way or another. In addition, The CONSOLE program acts as the hub between different programs. FSD's (File System Drivers) are attached to the console, and programs communicate with it through the console instead of communicating directly.

As mentioned before, all user space programs are written in MICRON Basic for comparability sake. While it isn't the most powerful language by my own admission, it is still easier than assembly. The compiler is also super small, so it should be able to fit onto an actual system with 16kb of memory.

Here is an example of the classic "Hello World" program, like I said, it ain't pretty.

Code:
BYTE A = 0
BYTE E = 0
STRING H[13] = "HELLO WORLD",10,0
@START
   ;WRITE TO SIO
   WRITE #SIO,H[A],E
   IF E > 0 GOTO ERROR
   INC A
   IF H[A] > 0 GOTO START

   ;KILLS PROCESS
   GETPID A
   LET #COM[1] = A
   LET #COM[0] = 255
HALT:
   GOTO HALT
ERROR:
   FORFIT
   GOTO START


Progress So Far

So far I am about 60% done with the system. The Kernel and MICRON Basic Cross Compiler are all completed. The CONSOLE program is almost completed, with all that is needed to be added is some internal process commands. The things that still need to be added are a text editor and a user space MICRON Basic compiler. It also still needs to be ported to the TI-8x calculators, but that shouldn't be too difficult.

I made a small video showcasing the progress I have in my emulator:

There is more information about this test is the youtube video description.

Questions

So, I know a little bit about the internals of the TI-84s, but I am not an expert. I am going to be porting the system over to a real calculator over the next couple of months so I have a few questions.

1. Can I dual boot TIOS and another operating system somehow? Is it possible to write a routine to load TIOS instead of a custom operating system. If not, is it possible to be able to boot some sort of fully-memory utility (bigger than 8kb) from inside of TIOS.

2. Do I get full access to memory when running an OS. Is there any restrictions of portions of memory I can actually execute.

3. Can I reserve actual space in the Flash memory so I can have a separate file system without clobbering the TIOS file system.

If anyone has any feedback or questions, I would be more than happy to hear them. This is my first large scale low level programming project, so this is kind of learning experience for me.

Thank you for reading.
Looking good! Is this just for z80 calcs, or will it work for the ez80 ones as well?
epsilon5 wrote:
Looking good! Is this just for z80 calcs, or will it work for the ez80 ones as well?


Since all user space programs are written in MICRON Basic, theoretically you can write a program once and have it run on z80, ez80, or even M68k calculators without modification. The only issue is that binary (.PRG) files are not compatible between different architectures, so they would need to be either cross-compiled or compiled on-calc.
tergav17 wrote:
1. Can I dual boot TIOS and another operating system somehow? Is it possible to write a routine to load TIOS instead of a custom operating system. If not, is it possible to be able to boot some sort of fully-memory utility (bigger than 8kb) from inside of TIOS.
You could maybe write a utility that swaps out the contents of page 0 (by hacking around Flash protection when switching from TI-OS) with your own stuff. But the short answer is no.
Quote:
2. Do I get full access to memory when running an OS. Is there any restrictions of portions of memory I can actually execute.
The hardware enforces some execution limits, but they can be changed if you're able to unlock Flash (as you can if you're an OS). See port 26h and related.

Quote:
3. Can I reserve actual space in the Flash memory so I can have a separate file system without clobbering the TIOS file system.
Closest you can get is probably claiming whole sectors and putting a header on them so they look like giant appvars or something (archived variables have a header that is nearly a copy of the VAT entry, so that's not hard). Not sure if you might be relocated during a garbage collection though.
Tari wrote:
tergav17 wrote:
1. Can I dual boot TIOS and another operating system somehow? Is it possible to write a routine to load TIOS instead of a custom operating system. If not, is it possible to be able to boot some sort of fully-memory utility (bigger than 8kb) from inside of TIOS.
You could maybe write a utility that swaps out the contents of page 0 (by hacking around Flash protection when switching from TI-OS) with your own stuff. But the short answer is no.
Quote:
2. Do I get full access to memory when running an OS. Is there any restrictions of portions of memory I can actually execute.
The hardware enforces some execution limits, but they can be changed if you're able to unlock Flash (as you can if you're an OS). See port 26h and related.

Is there any way to skirt around the ~8.8kb limit for TIOS binary programs, and disable the hardware execution limit? If possible, it would clobber most of the system memory, but would still leave archive memory intact so TIOS could be booted again on hard reset.
You could compile it as a 1-page app (16384 bytes, but ~130 is used for headers and whatnot). Alternatively, you could write a simple program that stitches together other programs and appvars, but you'd still need to modify the ports to disable the execution limits (however, those ports are locked unless you can unlock flash).
Xeda112358 wrote:
You could compile it as a 1-page app (16384 bytes, but ~130 is used for headers and whatnot). Alternatively, you could write a simple program that stitches together other programs and appvars, but you'd still need to modify the ports to disable the execution limits (however, those ports are locked unless you can unlock flash).

The issue I am running into is that if I am running this from TIOS, I don't need very much actual read-only executable memory. The Kernel+Booter only takes up around 2.5kb of memory. What I am looking for is a large portion of writable memory in which code can be executed from. I am not too concerned with clobbering TIOS memory, as TIOS can be rebooted by a hard restart.

I understand that this can be achieved by just making this an real TI-84 operating system, but I am trying to find a way to get the memory perks of a real operating system while at the same without having to remove TIOS from the calculator. Similar to how Linux was done on the TI-Nspire.
Oh, then create a small program that loads the actual programs into the 0x8000-0xFFFF region (RAM) and (again, the hard part) unlock flash in order to then disable RAM execution limits (allowing code to execute in the 0xC000-0xFFFF).
Xeda112358 wrote:
Oh, then create a small program that loads the actual programs into the 0x8000-0xFFFF region (RAM) and (again, the hard part) unlock flash in order to then disable RAM execution limits (allowing code to execute in the 0xC000-0xFFFF).

Alright, that would work perfectly. I have been doing some research and I can't seem to find methods of unlocking the archive that have been made in the last 10 years. For now, I can just use the 0x8000-0xBFFF, as the Kernel, Console, Drivers, and most user programs should fit in that space. Unlocking that portion of memory can be a project for a different time. If worse comes to worst I can modify the Kernel so it only allocated executable portions of memory in the lower 16kb.
tergav17 wrote:

Alright, that would work perfectly. I have been doing some research and I can't seem to find methods of unlocking the archive that have been made in the last 10 years.

the_mad_joob posted some routines here a couple of months ago and they last updated it a few weeks ago (they've been working on cleaning it up and documenting).

You'll want the flashunlock.z80 file in the flash.zip attachment Smile But please, test it in an emulator! Wouldn't want to brick a calc!
I have a small update:

Over the last week and a half I have been working on adding more internal commands in the CONSOLE. I am nearing the point were I am almost done, just a few more file IO and FSD management routines are needed (along with device drivers). I have posted a new build demonstration the shows file write operations, process forking, and piping.



Any feedback would be greatly appreciated
Well, it has been a while since I have made an update here, but I have made a large amount of progress on the CONSOLE portion of the OS. All of the actual file I/O commands are done, along with the ability to load additional file system drivers on the fly. I have a new demonstration showing this function in action by loading in the file system IO. It is little more than a boilerplate driver capable of creating valid responses to all CONSOLE commands, along with outputting premature directory entry when prompted. Nevertheless, it shows that all of the features do work.



Now that all of the core components are finished (besides the on-board compiler and text editor, projects for a different day), I will start porting all of my code to the TI-84+. Not much code will need to be changed, but I will need to write a custom driver for a file system that can co-exists with the existing TIOS file system.

I will also be putting all of my code onto GitHub sometime, but I need to clean up my code first. Nobody likes spaghetti code.

As always, feedback is greatly appreciated!
Wow very impressive, so much progress!
I have starting porting over to the TI-83+ and I have a few questions. First of all, what exactly is in Ram Page 0 (C000-FFFF)? Second, if I clobber some or all of this area of RAM, as well as preserving all of the RAM before 9D93, can I still do BCALLS as normal?

On a seperate note, all of the code is now on Github.
Well, it has been around 2 weeks, but progress is still being made.

First and foremost, the KERNEL has been successfully ported to the TI-83+. On all of the tests I ran, it seems to work fine.



On a separate note, I was a little confused at the rate of the interrupts. From all of the sources I have read, the timer interrupt should be running at ~160 hz. The issue is from the emulator, it seems to be running at somewhere around ~4khz. Is this just an emulator thing, or am I doing something wrong?
Are you specifically setting the timer frequency via port 4? And what emulator is this? It's possible the timer emulation is wonky, or your configuration is weird.
Tari wrote:
Are you specifically setting the timer frequency via port 4? And what emulator is this? It's possible the timer emulation is wonky, or your configuration is weird.


I was using WabbitEmu, but I think I figured out my issue in which I was not acknowledging the interrupt so it would trigger again instantly after I returned from my interrupt routine.
Well, it has been about a week, and I can say that the KERNEL is for the most part working. Context switching works, along with memory allocation, piping, and process management. In addition, I have been able to load small relocatable programs through the kernel by including them in the binary of the calculator executable itself.

The only thing that I have left now is to figure out how to do a few file-related operations. All of the information I have found online about the VAT and system calls related to it have be a little confusing, so I have a question

How does one take a binary file, and convert it into and appVar that can be transferred to a calculator. I understand how to create, write, and read appVars on the calcuator side of things, but I can't find any information that details how you create them on the compuer side of things. (if that is even possible).

Thank You
Well, it has been quite awhile since I have posted an update to this project. I am still working on it, but the FRC build season as kinda sucked up every second of free time I have had. Due to that, work has been very slow.

After completing a program which allows for userspace memory to be formatted and used as a "RAM drive", I learned a few things:

1. The SYSTEM/I CONSOLE is buggy, unoptimized, and unmaintainable. This was sort to be expected, as I didn't put much thought into the program structure as I created it. So in short, it will be need to be written up from scratch. This shouldn't be a problem, and will allow me to add new features and make the program more optimized.

2. MICRON BASIC, the compiled language of which the CONSOLE and all of the userspace utilities are written in, needs to be replaced with something else. I originally wrote it to be small, fast, and easy to port to different platforms (After all, my goal is it be able to run a full system that will be able to compile itself on a Z80 with less than 16kb of userspace). Unfortunately, after writing the RAM drive program, I have decided that it is simply to hard and bulky to write large programs. Stuff tends to get disorganized quickly.

Instead of adding features to make MICRON BASIC more usable, I have decided just to scrap in favor of something better. I am currently thinking of writing my own limited dialect of C (remember, 16kb of userspace so programs can be compiled on-calc). After doing some research, I think it can be done. It would also allow me to be able to steal code port other premade programs, so I don't have to write every program from scratch. If anyone has any other languages that they know of that can be made to easily generate 8-bit code, let me know.

As for the KERNEL, nothing really needs to be changed. I have already tested it on the TI-83P, and it works perfectly. It should also be able to handle the switch from MICRON BASIC to C pretty easily. I am thinking of implementing directories, but I fear it could make everything too bulky to fit on the calculator. So for now I am just going to keep the flat RT11-like file system.

Stay tuned!
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement