libc library for GCC

[insomnia]

This is a libc implementation which is mostly compliant with the c89 standard. I've been working on this for a while as part of a disk-based OS for the TI, but this can still be used as an independent library.

 

I chose this standard since more recent ones mainly add support for wide characters, complex floating-point data types and other stuff which is probably not useful for a TI99/4a system.

 

All of the functions commonly used in stdio.h have been implemented, but there are two unresolved symbols: console_write and console_read. These are intended to provide text-based screen output and keyboard input respectively. In my OS project, these are provided by device drivers, but Tursi's libti99 would be better for anyone intending to use the stdio functions.

 

Hopefully this library is useful for someone. Feel free to do whatever you want with this.

libc99.tar.gz

[TheMole]

This is cool. Do I understand correctly that I "just" have to provide my own console_write and console_read implementations as per these function prototypes in order to use this?

size_t console_write(struct FILE_t *f, const unsigned char *buf, size_t size);
size_t console_read(struct FILE_t *f, unsigned char *buf, size_t size);

Also: super interested in learning more about the OS you're working on, would love to read more about that!

[insomnia]

Yup, that's pretty much it. However, those functions are only needed if you want to use the functions in stdio.I would recommend string-oriented functions like sprintf and sscanf instead, That way you could decouple file IO, screen manipulation and keyboard handling from text operations.

 

The OS I'm working on is intended to be written from scratch, support multitasking, be Posix-compliant, and not use anything from the existing TI console. It should run on unmodified hardware, and only need a cart for the core OS and an expansion box for the disk drives and 32K expansion memory.

 

Right now, I've got about 40% of the code written. A lot of the core functionality is done, but I got stuck on writing the floppy driver and finalizing a disk format. I want to be able to supports directories, links, and long filenames. Unfortunately, it's easy to get stuck in a cycle of feature-creep and early optimization.

 

After hitting that roadblock, I started working on a decompiler. That takes a binary image as input and outputs high-level pseudocode. That's pretty far along too, but still needs a lot of work.

 

I haven't kept my blog up to date since my time to work on TI stuff has been limited lately. I should probably pick that back up and do more documentation for the stuff I've written so far.

[TheMole]

Yup, that's pretty much it. However, those functions are only needed if you want to use the functions in stdio.I would recommend string-oriented functions like sprintf and sscanf instead, That way you could decouple file IO, screen manipulation and keyboard handling from text operations.

 

Makes sense, although I was mostly thinking about how this could be helpful in the process of porting existing applications.

[TheMole]

The OS I'm working on is intended to be written from scratch, support multitasking, be Posix-compliant, and not use anything from the existing TI console. It should run on unmodified hardware, and only need a cart for the core OS and an expansion box for the disk drives and 32K expansion memory.

 

Right now, I've got about 40% of the code written. A lot of the core functionality is done, but I got stuck on writing the floppy driver and finalizing a disk format. I want to be able to supports directories, links, and long filenames. Unfortunately, it's easy to get stuck in a cycle of feature-creep and early optimization.

 

After hitting that roadblock, I started working on a decompiler. That takes a binary image as input and outputs high-level pseudocode. That's pretty far along too, but still needs a lot of work.

 

I haven't kept my blog up to date since my time to work on TI stuff has been limited lately. I should probably pick that back up and do more documentation for the stuff I've written so far.

 

Yes... yes you should pick that back up, for sure

Edited November 15, 2017 by TheMole

[RickyDean]

Yup, that's pretty much it. However, those functions are only needed if you want to use the functions in stdio.I would recommend string-oriented functions like sprintf and sscanf instead, That way you could decouple file IO, screen manipulation and keyboard handling from text operations.

 

The OS I'm working on is intended to be written from scratch, support multitasking, be Posix-compliant, and not use anything from the existing TI console. It should run on unmodified hardware, and only need a cart for the core OS and an expansion box for the disk drives and 32K expansion memory.

 

Right now, I've got about 40% of the code written. A lot of the core functionality is done, but I got stuck on writing the floppy driver and finalizing a disk format. I want to be able to supports directories, links, and long filenames. Unfortunately, it's easy to get stuck in a cycle of feature-creep and early optimization.

 

After hitting that roadblock, I started working on a decompiler. That takes a binary image as input and outputs high-level pseudocode. That's pretty far along too, but still needs a lot of work.

 

I haven't kept my blog up to date since my time to work on TI stuff has been limited lately. I should probably pick that back up and do more documentation for the stuff I've written so far.

I would like to suggest the route of going the Petit fat way:

http://elm-chan.org/fsw/ff/00index_p.html

 

I was thinking of pursuing a like venture, down the road

[+TheBF]

Yup, that's pretty much it. However, those functions are only needed if you want to use the functions in stdio.I would recommend string-oriented functions like sprintf and sscanf instead, That way you could decouple file IO, screen manipulation and keyboard handling from text operations.

 

The OS I'm working on is intended to be written from scratch, support multitasking, be Posix-compliant, and not use anything from the existing TI console. It should run on unmodified hardware, and only need a cart for the core OS and an expansion box for the disk drives and 32K expansion memory.

 

Right now, I've got about 40% of the code written. A lot of the core functionality is done, but I got stuck on writing the floppy driver and finalizing a disk format. I want to be able to supports directories, links, and long filenames. Unfortunately, it's easy to get stuck in a cycle of feature-creep and early optimization.

 

After hitting that roadblock, I started working on a decompiler. That takes a binary image as input and outputs high-level pseudocode. That's pretty far along too, but still needs a lot of work.

 

I haven't kept my blog up to date since my time to work on TI stuff has been limited lately. I should probably pick that back up and do more documentation for the stuff I've written so far.

 

 

This sounds like something that would be useful for this:

 

http://atariage.com/forums/topic/270993-tms-9901-to-ide-interface/

[insomnia]

 

Makes sense, although I was mostly thinking about how this could be helpful in the process of porting existing applications.

Accidentally hit submit, actual content here in a bit...

Edited November 18, 2017 by insomnia

[insomnia]

OK, actual content time.

 

I was originally going to make this long-winded explanation about how console_read and console_write should be implemented, but thought a bit and decided to just implement demonstration code andbe done with it.

 

So I've attached a demo that shows a working example with printf and getchar. The user code is pretty simple and the back end screen and keyboard code is relatively quick. This should be a decent base for something more interesting, or a port of a text-mode program.

 

The only thing I failed to mention is that file IO is not working yet. That's where I got stuck. Again, Tursi's libti99 would be a great starting point. I shoould probably look into that.

 

Anyway, let me know if there are any problems or missing features,

 

BTW, the blog has been reactivated and I'll make sure it gets updated.

libc_demo.tar.gz