Jump to content

Photo

Linux-like OS for the TI


36 replies to this topic

#26 Asmusr ONLINE  

Asmusr

    River Patroller

  • 2,908 posts
  • Location:Denmark

Posted Tue Sep 4, 2018 2:35 AM

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

I'm sure some stuff can be learned from those implementations

 
Especially the overlay programming technique is worth looking into.

Attached Files



#27 FarmerPotato OFFLINE  

FarmerPotato

    Chopper Commander

  • 136 posts
  • Location:Austin, TX

Posted Tue Sep 4, 2018 10:20 AM

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.



#28 --- Ω --- OFFLINE  

--- Ω ---

    HexaCoreRunner

  • 12,986 posts

Posted Wed Sep 5, 2018 8:35 AM

 

Conspicuously missing features:

 

  Some kind of catchy name

 

 

LinTI?



#29 TheMole ONLINE  

TheMole

    Dragonstomper

  • 806 posts
  • Location:Belgium

Posted Wed Sep 5, 2018 8:57 AM

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. 



#30 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • 680 posts
  • Location:Campbellsburg, KY

Posted Wed Sep 5, 2018 9:06 AM

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



#31 RXB OFFLINE  

RXB

    River Patroller

  • 3,349 posts
  • Location:Vancouver, Washington, USA

Posted Wed Sep 5, 2018 11:57 AM

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.



#32 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • 680 posts
  • Location:Campbellsburg, KY

Posted Wed Sep 5, 2018 12:20 PM

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


  • RXB likes this

#33 insomnia OFFLINE  

insomnia

    Star Raider

  • Topic Starter
  • 90 posts
  • Location:Pittsburgh, PA

Posted Wed Sep 5, 2018 2:52 PM

 

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.


  • RXB likes this

#34 BeeryMiller OFFLINE  

BeeryMiller

    Dragonstomper

  • 680 posts
  • Location:Campbellsburg, KY

Posted Wed Sep 5, 2018 7:22 PM

Thanks for the follow-up.  Good to know and understand what is involved.

 

Beery


  • RXB likes this

#35 pnr OFFLINE  

pnr

    Chopper Commander

  • 108 posts

Posted Thu Sep 6, 2018 3:26 AM

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.

 

 

 

 



#36 --- Ω --- OFFLINE  

--- Ω ---

    HexaCoreRunner

  • 12,986 posts

Posted Fri Oct 26, 2018 9:58 AM

 

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.  



#37 FDOS OFFLINE  

FDOS

    Chopper Commander

  • 225 posts

Posted Sat Oct 27, 2018 12:17 PM

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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users