Jump to content
insomnia

Linux-like OS for the TI

Recommended Posts

99ix?

 

Or steal naming inspiration from a DIFFERENT child of Unix and call it Plan99. Perhaps a little misleading, but I'm sure people will figure it out.

 

I've got a Plan9/Inferno boxed copy and I admire the "everything is a socket" concept.

Share this post


Link to post
Share on other sites

TheMole, on 03 Sept 2018 - 3:22 PM, said:snapback.png

Especially the overlay programming technique is worth looking into.

 

Interesting, I had never seen that before. It's similar to how I do paging/bankswitching in my stuff with gcc, but instead of chaining the calls from page-to-page together like they're suggesting in that document, I have a single page always available that is used to facilitate calling from one back to another. The benefit of this is that you're not limited to a "call depth" of 24k and you don't need to keep track of a "call tree", every function can call every other function and you can page in the right page by leveraging the trampoline. The downside is that you lose a bit of RAM to the trampoline functions.

  • Like 3

Share this post


Link to post
Share on other sites

So I've mentioned on here a few times that I've been working on a new operating system for the TI. Development has gotten to the point where I think it's time to do some kind of announcement. Additionally, I've read the suggestion that something like Contiki should be ported one too many times. We can do better, folks.

 

 

 

Here's a current feature list:

Kernel runs from a cart image

Device driver API

Drivers for:

text screen

keyboard

floppy drive

/dev/null

/dev/zero

/dev/random

 

 

Just trying to understand things a bit here. Are your drivers for floppy drive access based upon the DSR code of the device, or have you created something new from scratch and are pretty much just using the ports on the devices?

 

Just curious is all.

 

Beery

  • Like 1

Share this post


Link to post
Share on other sites

Would probably be best to use Sector I/O access like Forth does.

After all Unix and Linux disk storage is way different then Windows or DOS or TI normal formats.

  • Like 1

Share this post


Link to post
Share on other sites

But does the driver create a link between the program and the DSR? Or does it interface directly with the hardware? If directly with the hardware, then you are talking about individual drivers for each TI, Myarc, or CorComp peripheral. That is all I was trying to understand in his original notes back in the first message.

 

Beery

  • Like 1

Share this post


Link to post
Share on other sites

 

Just trying to understand things a bit here. Are your drivers for floppy drive access based upon the DSR code of the device, or have you created something new from scratch and are pretty much just using the ports on the devices?

 

Just curious is all.

 

Beery

 

The floppy driver is written to directly access the FDC registers, specifically the TI FDC. As you suspected, this means a new driver will need to be written for each hardware variant (Myarc, Corcomp, etc.)

 

This may sound like an unnecessary hassle, but the driver is only 600 lines of well-commented code. About 100 of those lines are just symbol definitions. Additionally, it looks like most FDC and HDC manufacturers took inspiration from the TI FDC, so there are a lot similarities to exploit. Heck, there may even be common code that can be made device-independent.

 

The reason for ignoring the DSR was that it didn't provide the features I needed, was slow, and needlessly stepped on the scratchpad and VDP memory. Additionally, the DSR code only works with the TI disk format. I wanted to use a different filesystem that allowed for deep directory trees, support for zero-length files, and softlinks (not yet available, I'll come back to it though.). I also wanted a sector cache to speed up common operations.

 

The only way to do that would be to embed the CFS volume in the TI volume. The DSR would treat CFS as a big file, and then another layer would do the actual filesystem stuff. I didn't time it, but I suspect that to things this way would increase access time by about 200 to 300 percent. No thank you.

 

I'm using sector-by-sector access as that's how the hardware wants to operate. File operations ride on top of this and function in the normal Unix-y way. I'm not using inodes though. Standard Unix filesystems use a fixed number of inodes that subtract from storage space. Instead, I'm dynamically allocating file metadata records as needed to maximize space.

 

Sorry, I've gone off topic a bit. Let me try to reel it back.

 

Yes each piece of hardware will need it's own driver, but there is a lot of similarity between devices of the same type that can be exploited. Plus it's more fun this way.

 

Other topics:

 

I read the AMS overlay document, and that is an approach to paging I have not seen before. I'm not sure it's any better than what people have been using so far, but it's worth more time to think about it.

 

So far, I'm liking plan 99, and I think the parallels with plan 9 are a good thing.

 

I would report some progress here, but I got bit by what looks like a compiler bug in my bank-switch code, so I'm working to fix that first.

  • Like 1

Share this post


Link to post
Share on other sites

Probably it is not quite what you guys are looking for, but vintage Unix has already been ported to the 99xx CPU: a port is available for the mini Cortex.

Maybe Stuart still has a blank mini Cortex PCB available.

 

As overlays were mentioned in this thread: its C compiler supports semi-automatic overlays: what goes into which overlay is user defined, but all other work is done by the compiler and linker (like generating thunks, etc.). However, I have not ported the support routines for that to the mini Cortex (yet).

 

How vintage Unix did overlays is described here, in section 6.4 and 6.5 (warning: document is a 17M pdf download). In short, the program code is split in a base section and several overlays. The base section is always loaded. Every function call or return that potentially crosses an overlay boundary checks the current overlay number and if different to the desired one the runtime support routines swaps in the right one.

 

 

 

 

Share this post


Link to post
Share on other sites

 

The design philosophy I've been following is that while TI wrote a bunch of neat code for the time, modern developers should only be limited by the constraints of hardware, not software decisions of the past. So that means backwards-compatibility is out. Developing against raw hardware is in.

 

I'm assuming this as a base platform:

Console

1MB AMS card

Two 96KB floppy drives

RS232 card

 

I have a couple of questions concerning what I quoted above.

 

1) With support for two SSSD drives, will you also include support for all combinations up to and including DSDD 80 track, only limited

by the users actual hardware? Will this support cover formatting from withing the OS itself or simply reading the format the user has

opted to implement?

 

2) In including support for the legacy RS-232 port, were there any plans to include new drivers within the OS for modern printers?

 

3) Will this OS bypass other hardware implementations? Meaning, will TIPI extensions will still be accessible?

 

Sorry if my questions are so basic, I'm not a super programmer or hardware guru, merely a lowly but interested user.

Share this post


Link to post
Share on other sites

Would probably be best to use Sector I/O access like Forth does.

After all Unix and Linux disk storage is way different then Windows or DOS or TI normal formats.

 

Once "they" understand the TI architecture, they will come to this same conclusion, as I've already done it in X4th99, and I was in process of adapting my MML (paged memory libraries, TF core was done so no need for X4th99 paged core) to TurboForth when a medical condition brought that to a screeching halt. I never got back to it as development had proceeded too far, so I just went back to X4th99, and not believing another forth would do anything for the community, I saw a bigger need for an enhanced TI Basic for many newbies and even oldsters coming back to the TI-99/4A with old TI consoles, and not much else.

Share this post


Link to post
Share on other sites

 

Minix Lint?

 

There actually is a MINIX O/S in a text book by Tannebaum. It was used by Linus as the start of LINUX.

(He said if he had known about FreeBSD he would have never done all the work to create LINUX) :)

 

And LINT is a C utility to find source code errors. So these names are taken unfortunately.

 

 

Hmm....

 

LINUX+UNIX +TI becomes ...

 

LUNITIX

 

cuz you might need to be crazy to build a UNIX for TI-99. :D

 

(This is a joke. No offence intended)

Edited by TheBF
  • Like 2

Share this post


Link to post
Share on other sites

 

There actually is a MINIX O/S in a text book by Tannebaum. It was used by Linus as the start of LINUX.

(He said if he had known about FreeBSD he would have never done all the work to create LINUX) :)

 

And LINT is a C utility to find source code errors. So these names are taken unfortunately.

 

 

Hmm....

 

LINUX+UNIX +TI becomes ...

 

LUNITIX

 

cuz you might need to be crazy to build a UNIX for TI-99. :D

 

(This is a joke. No offence intended)

 

To keep with the spirit of GNU, you have to find a recusive name... :grin:

Share this post


Link to post
Share on other sites
I downloaded the Unix V6 port for the TI-990 from http://www.cozx.com/dpitts/ti990.html


I was interested in how the LMF "Load Map File" had been used in TI-990 O/S.


LMF allows you to partition the 64K address space into 3 regions. Each region has

a bias address register to where it maps into the 1MB extended address space. Each region has a

limit address; the third region can end earlier than the top of memory. Access above

the third region limit raises an error interrupt.




v6/mmu_990.s is the memory mapping routines.

It illustrates usages of the LMF, LDS, LDD instructions.


LDS alters the address of the next source address, by loading a bias register

to address the full 1MB. LDD alters the next destination address.


The memory map used by mmu_990.s looks like:


0000 - 0fff 4k of kernel, biased to somewhere

1000 - efff 56k of user space, biased to somewhere

f000 - f800 workspace and tiline peripherals (hard disk etc)
  • Like 1

Share this post


Link to post
Share on other sites

 

I downloaded the Unix V6 port for the TI-990 from http://www.cozx.com/dpitts/ti990.html
I was interested in how the LMF "Load Map File" had been used in TI-990 O/S.
LMF allows you to partition the 64K address space into 3 regions. Each region has
a bias address register to where it maps into the 1MB extended address space. Each region has a
limit address; the third region can end earlier than the top of memory. Access above
the third region limit raises an error interrupt.
v6/mmu_990.s is the memory mapping routines.
It illustrates usages of the LMF, LDS, LDD instructions.
LDS alters the address of the next source address, by loading a bias register
to address the full 1MB. LDD alters the next destination address.
The memory map used by mmu_990.s looks like:
0000 - 0fff 4k of kernel, biased to somewhere
1000 - efff 56k of user space, biased to somewhere
f000 - f800 workspace and tiline peripherals (hard disk etc)

 

 

Is it possible to emulate the 990 on TI-99 with a SAMS card to page equivalent memory spaces?

Share this post


Link to post
Share on other sites

 

Is it possible to emulate the 990 on TI-99 with a SAMS card to page equivalent memory spaces?

 

Including the additional opcodes? Not so likely. The TMS9900 is a stripped-down version of the original TI-990.

  • Like 1

Share this post


Link to post
Share on other sites

 

Is it possible to emulate the 990 on TI-99 with a SAMS card to page equivalent memory spaces?

 

No, the SAMS scheme is TI's LS612 memory mapper, which does a direct substitution. SAMS replaces the the top 4 address bits with a long address. So you can only map 4k chunks to SAMS addresses.

 

Also, TI put the memory-mapped peripherals and PAD at 8000-9FFF which breaks the flat memory model.

 

It is unlikely that external hardware on the 4A could implement LDS and LDD for external memory... more likely on the TMS9995. On the TMS9995, LMF, LDS and LDD, 0320, 0780 and 07C0 resp, are trapped by the MID interrupt (Macro instruction Detection) which goes BLWP @0008.

 

I find these 990 instructions fascinating in part because they were left in the port of the assembler for the 4A Editor/Assembler, I could see them in there back in the day with DISKO, but there was no documentation.

 

I don't know exactly what the TMS9900 does with illegal opcodes.

Edited by FarmerPotato
  • Like 2

Share this post


Link to post
Share on other sites

 

No, the SAMS scheme is TI's LS612 memory mapper, which does a direct substitution. SAMS replaces the the top 4 address bits with a long address. So you can only map 4k chunks to SAMS addresses.

 

Also, TI put the memory-mapped peripherals and PAD at 8000-9FFF which breaks the flat memory model.

 

It is unlikely that external hardware on the 4A could implement LDS and LDD for external memory... more likely on the TMS9995. On the TMS9995, LMF, LDS and LDD, 0320, 0780 and 07C0 resp, are trapped by the MID interrupt (Macro instruction Detection) which goes BLWP @0008.

 

I find these 990 instructions fascinating in part because they were left in the port of the assembler for the 4A Editor/Assembler, but with no documentation.

 

I don't know exactly what the TMS9900 does with illegal opcodes.

Next!(instruction)

 

I find it amazing just exactly how much you do know with regard to so many things "TI-99/4a"! Thanks for all the useful Tips thus far. ;-)

  • Like 3

Share this post


Link to post
Share on other sites
I'm using sector-by-sector access as that's how the hardware wants to operate. File operations ride on top of this and function in the normal Unix-y way. I'm not using inodes though. Standard Unix filesystems use a fixed number of inodes that subtract from storage space. Instead, I'm dynamically allocating file metadata records as needed to maximize space.

I use Linux almost exclusively. I consider it far superior to Microsoft's Windows. When I've gotten a few hardware issues solved I was thinking I would have to have something like Linux to manage it. I am still planning on that, and I was going to model it after the NitrOS9 operating system designed for the 6x09 microprocessor. It has some pitfalls that I hope to avoid such as their commitment to 256 byte sectors, which makes hard drive access a small problem. Here is a technical spec that describes how they do their drivers, file systems, etc

 

http://www.nitros9.org/NitrOS-9_Technical_Reference.pdf.

 

The RBF manager is the part that addresses the disk drive issues. There might be a few good ideas in there for you. I know I always liked it.

 

I know almost nothing about the way Unix/Linux file systems work. When I ask myself how they work the answer is usually, "They work good." They all seem to use inodes, though. Aren't inodes an integral part of how Unix/Linux implement hard links? Having two directory entries that point to the same inode, and thus the same file? Do you have a guide to how you're allocating the metadata?

 

 

I would report some progress here, but I got bit by what looks like a compiler bug in my bank-switch code, so I'm working to fix that first.

I've been popping into this thread to check for an update for several weeks now. I hope you aren't going to give up on this. I've got it set up to notify me via email now. I hope to see something more soon.

 

HH

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...