Jump to content

Photo

Linux-like OS for the TI


44 replies to this topic

#26 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,946 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

  • 181 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  

--- Ω ---

    Sunbaenim

  • 13,207 posts

Posted Wed Sep 5, 2018 8:35 AM

 

Conspicuously missing features:

 

  Some kind of catchy name

 

 

LinTI?



#29 TheMole OFFLINE  

TheMole

    Dragonstomper

  • 807 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

  • 734 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,421 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

  • 734 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

  • 734 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  

--- Ω ---

    Sunbaenim

  • 13,207 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

  • 232 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.



#38 willbilly OFFLINE  

willbilly

    Space Invader

  • 32 posts

Posted Wed Nov 21, 2018 2:10 PM

 

LinTI?

 

Minix Lint?



#39 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 835 posts
  • Location:The Great White North

Posted Thu Nov 22, 2018 8:19 AM

 

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, Thu Nov 22, 2018 8:19 AM.


#40 AMenard OFFLINE  

AMenard

    Dragonstomper

  • 760 posts
  • Location:Beauharnois, Qc, Canada

Posted Thu Nov 22, 2018 12:57 PM

 

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:



#41 FarmerPotato OFFLINE  

FarmerPotato

    Chopper Commander

  • 181 posts
  • Location:Austin, TX

Posted Thu Nov 22, 2018 1:14 PM

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)


#42 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 835 posts
  • Location:The Great White North

Posted Sat Nov 24, 2018 9:51 AM

 

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?



#43 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,424 posts
  • Location:Germany

Posted Sat Nov 24, 2018 10:37 AM

 

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.


  • RXB likes this

#44 FarmerPotato OFFLINE  

FarmerPotato

    Chopper Commander

  • 181 posts
  • Location:Austin, TX

Posted Sat Nov 24, 2018 1:31 PM

 

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, Sat Nov 24, 2018 3:09 PM.


#45 HOME AUTOMATION OFFLINE  

HOME AUTOMATION

    Chopper Commander

  • 192 posts

Posted Sat Nov 24, 2018 2:58 PM

 

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. ;-)






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users