Gip-Gip Posted May 16, 2017 Share Posted May 16, 2017 (edited) I'm taking a break from VePseu development, and I would like to make an OS named wem/yt (loW rEsource Memory/sYstem inTerface) for the TI I have lying around. The reason being so I can use the computer for something AND learn enough to port it to more systems, say an Intel. The idea is pretty simple in my opinion you have a memory manager which is powered by barebones I/O (keyboard and display) you can save, load, and execute blocks of memory it would implement voluntary multitasking (have programs jump back to a certain point once they're done) Implement a portable compile-when-ready executable format for non-critical executables drivers like disk or tape would be built-in, and would be run as essentially high-priority executables. The OS obviously isn't made for performance, rather to allow the lowest usable level of the system. I see use in programming and debugging, along with basic file editing tasks (I also plan to make an Arduino interface, but that's for later). Here's the thing Looking at the list of programming languages isn't very promising, as C (the best language for the job) lacks documentation (C99) or won't compile properly (GCC). I'll learn new languages if I have to, but I don't want to (learning a language and building an OS at the same time sounds like hell to me). If anyone has any suggestion I would greatly appreciate it Now that I have the manual for C99 I'll be using that Edited May 30, 2017 by Gip-Gip Quote Link to comment Share on other sites More sharing options...
Sinphaltimus Posted May 16, 2017 Share Posted May 16, 2017 I can't really help you except that I find it interesting you posted this. Recently a very similar thread popped up here. http://atariage.com/forums/topic/264863-ti-cartridge-based-operating-system-potential-discussion/?do=findComment&comment=3759414 1 Quote Link to comment Share on other sites More sharing options...
Sinphaltimus Posted May 17, 2017 Share Posted May 17, 2017 (edited) In the other thread you asked for compiler documentation. AFAIK, this is the largest repository I have access to for everything TI related. I bet your docs are here someplace. I couldn't find them below but possibly in another folder off the root.ftp://ftp.whtech.com/programming/c99/ Edited May 17, 2017 by Sinphaltimus Quote Link to comment Share on other sites More sharing options...
+chue Posted May 17, 2017 Share Posted May 17, 2017 (edited) What problems did you have with GCC? As for possible tools/ languages/ docs, take a look at the first post in the development resources thread here: http://atariage.com/forums/topic/153704-ti-994a-development-resources/?p=1881598 Edited May 17, 2017 by chue 1 Quote Link to comment Share on other sites More sharing options...
Gip-Gip Posted May 17, 2017 Author Share Posted May 17, 2017 What problems did you have with GCC? Errors while building GCC. Might be because I'm on an oldish mac, but I've personally never been able to build GCC, even when I follow the directions Quote Link to comment Share on other sites More sharing options...
Gip-Gip Posted May 17, 2017 Author Share Posted May 17, 2017 In the other thread you asked for compiler documentation. AFAIK, this is the largest repository I have access to for everything TI related. I bet your docs are here someplace. I couldn't find them below but possibly in another folder off the root. ftp://ftp.whtech.com/programming/c99/ Found it! ftp://ftp.whtech.com/programming/c99/C99REL4/c99%20v4%20for%20994a%20manual.pdf I'll also attach the manual to this post incase the site goes down (I don't necessarily trust the FTP server) c99 v4 for 994a manual.pdf 1 Quote Link to comment Share on other sites More sharing options...
Lord Vorkosigan Posted May 17, 2017 Share Posted May 17, 2017 Hi, There's also the Fuzix project which can be interesting as starting point: http://atariage.com/forums/topic/264588-fuzix-unix-on-ti99/ 1 Quote Link to comment Share on other sites More sharing options...
Gip-Gip Posted May 18, 2017 Author Share Posted May 18, 2017 Currently I'm getting the dev environment set up, I'll release a version of the OS by at most sunday Quote Link to comment Share on other sites More sharing options...
Asmusr Posted May 18, 2017 Share Posted May 18, 2017 Are you planning that your memory manager should support paged memory like SAMS? Quote Link to comment Share on other sites More sharing options...
Gip-Gip Posted May 18, 2017 Author Share Posted May 18, 2017 Are you planning that your memory manager should support paged memory like SAMS? Paged memory would greatly improve the ability of the TI, so I'll find a way(not just yet, however) Quote Link to comment Share on other sites More sharing options...
+TheBF Posted May 19, 2017 Share Posted May 19, 2017 It's a daring project. You might want to consider having programs for your O/S run as byte code rather than machine code, with the ability to call machine code when needed. Byte code systems can save a lot of space fro your programs if you build an efficient virtual machine. GPL is an example, although not one I would recommend. No sense constraining yourself to 256 bytes of RAM. Basically you build a virtual machine that is core of everything and it just interprets program bytes very fast. Your virtual machine can be register based or stack based or 2 stack based like GPL, but generally is made to be simpler than the underlying machine. Any language for your O/S then just has to create byte code. P-code systems work this way, but the TI-99 version that interpreted P-code bytes with GPL byte code was a bad decision. 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted May 19, 2017 Share Posted May 19, 2017 (edited) It's a daring project. You might want to consider having programs for your O/S run as byte code rather than machine code, with the ability to call machine code when needed. Byte code systems can save a lot of space fro your programs if you build an efficient virtual machine. GPL is an example, although not one I would recommend. No sense constraining yourself to 256 bytes of RAM. Basically you build a virtual machine that is core of everything and it just interprets program bytes very fast. Your virtual machine can be register based or stack based or 2 stack based like GPL, but generally is made to be simpler than the underlying machine. Any language for your O/S then just has to create byte code. P-code systems work this way, but the TI-99 version that interpreted P-code bytes with GPL byte code was a bad decision. True the GROM and VDP chip delays are horrid for running programs. Nothing worse then a built in HARDWARE DELAY for running Programs in any language. Edited May 19, 2017 by RXB Quote Link to comment Share on other sites More sharing options...
Gip-Gip Posted May 19, 2017 Author Share Posted May 19, 2017 It's a daring project. It isn't as big of a mess as the Intel machines, at least You might want to consider having programs for your O/S run as byte code rather than machine code, with the ability to call machine code when needed. That was sorta my original idea but the speed would be really bad (imagine running your daily programs in Valgrind 24/7). Granted, I wouldn't have to do some voodoo magic with the memory manager to make 32kb (or even worse, the stock 256) work with an OS, just include some large RAM chips on the cart. I needed to come up with an instruction set for the compile-when-ready idea, so I'll get that done and tell everyone about it Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted May 19, 2017 Share Posted May 19, 2017 GPL is an example, although not one I would recommend. No sense constraining yourself to 256 bytes of RAM. How is GPL constrained to 256 bytes of RAM? ...lee Quote Link to comment Share on other sites More sharing options...
+chue Posted May 19, 2017 Share Posted May 19, 2017 (edited) Basically you build a virtual machine that is core of everything and it just interprets program bytes very fast. Your virtual machine can be register based or stack based or 2 stack based like GPL, but generally is made to be simpler than the underlying machine. The Forth guys on this thread are too modest! Correct me if I'm wrong but Forth: - is a stack based VM - interprets byte code fast - is memory efficient - supports the TI hardware well I've read that someone has multi-tasking working: http://atariage.com/forums/topic/265697-tms9900-is-the-coolest-cpu-for-multi-tasking/?p=3763980 I've been thinking about a TIOS from a C point of view and it appears daunting. I'm not a Forth guy, but it "feels" right here. So what am I missing? Edited May 19, 2017 by chue Quote Link to comment Share on other sites More sharing options...
Willsy Posted May 19, 2017 Share Posted May 19, 2017 TurboForth had been my TI OS since 2007. I have block 1 configured to leaf the extensions that I need/need use (just like autoexec on DOS systems). I can read files, print files, catalog disks and load #3 programs without leaving Forth. Forth is a small OS with the added benefit of having a programming language and scripting language built in. All in 16K. Quote Link to comment Share on other sites More sharing options...
ti99iuc Posted May 19, 2017 Share Posted May 19, 2017 (edited) I Remember sometimes99er started a Windows Demo similar to Amiga Workbench I know it could be impossibe to have as OS but it was a funny dream. Edited May 19, 2017 by ti99iuc 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted May 19, 2017 Share Posted May 19, 2017 For you Amiga fans out there (yes, I had one, too (is that a confession?)). The attached pictures show the "Guru meditation" that I implemented on the Geneve. You can see on the first picture that the program is loaded; then I load the word 0000 to address A000, then I poke the A000 address into the interrupt hook so that this location is executed on the next interrupt. This is my original text that - if I remember correctly - was published in one issue of Micropendium. The GURU MEDITATION Author: Michael Zapf Suppose you want to write some machine language programs. Normally, it takes several passes until the program finally assembles - after having found the last syntax error. After the first "0000 ERRORS" you load and run it with great expectations ... and nothing happens, at least not what you wanted the program to do. Now, if you are lucky, you can press QUIT (or CTRL-ALT-DEL) for a "warm" boot, and maybe the program is still standing in the RAM so that you can PEEK it via TI BASIC. Otherwise you have to turn your computer off and back on, losing your program in memory. If you are using a Geneve, there is another threat not experienced by the standard TI user: System kernel RAM locations can be affected so that you cannot reset your computer any more, let alone debug your program. The reason for this is that the program counter is loaded with an unexpected address, and the execution is transferred to a part of memory which probably does not contain executable code. This happens when - subprograms are not terminated correctly (RTWP instead of RT or vice versa) subprograms are not called correctly (BLWP instead of BL or v.v.) array bounds are exceeded (especially with a list of addresses) return adresses are lost or incorrect (forgotten DATA after BL) and many more. One of the TMS9995 processor's most powerful features is the MID flag which is not used, however, by the operating system. Whenever the processor encounters a word that is to be executed but does not represent a valid command, it generates an interrupt of level 2 which is not maskable by LIMI. The interrupt service routine can check the CRU flag 1FDA: It is set when an illegal command has been encountered. The abbrevation MID means "macro instruction detect" which reveals another usage for this feature. Currently, the MID flag is simply cleared by the interrupt service routine. The following program is intended for the Geneve in GPL mode with standard Editor/Assembler and standard GPL interpreter. Newer versions may require changing of the absolute addresses in GROM or RAM. Assemble this program and load it via LOAD AND RUN once; it remains installed until you clear the memory completely or reload the GPL interpreter. Now take the source code of one of your programs and put a DATA >0000 right into the program text. If you run this bugged program the execution will halt right at this position and the computer will inform you that an error has occured, giving you the values of the WP, PC and ST registers. Press the left mouse button to return to the master title screen; your program remains unchanged. This early execution break can prevent your computer from totally disturbing the memory, but there is surely no guaranty that the computer will not hang. This program was inspired by the "Guru meditation" message of the Commodore Amiga which is more detailed, however. *** GURU MEDITATION *** * on Geneve 9640 in GPL Mode * Version 1.1 * March 14, 1991 * Michael Zapf * Put this utility in an unused RAM space AORG >8100 TEXT1 TEXT 'Software failure. Press' TEXT ' left mouse button to continue.' TEXT2 TEXT 'Guru meditation #' HEXD TEXT '0123456789ABCDEF' POINT TEXT '..' * VDP register settings VDPREG DATA >8004,>8170,>8203,>8347 DATA >8401,>8506,>8600,>8761 DATA >8888,>8900,>8A00,>8B00 DATA >8C06,>8D66,>8E00,>8F00 * Check MID flag. If not active, return. START LI R12,>1FDA TB 0 JEQ START1 B @>035E START1 SBZ 0 * Clear flag LWPI >8300 * Set VDP registers to defined values LI R1,VDPREG LOOP1 MOV *R1+,R0 BL @SETADR CI R1,START JL LOOP1 * Clear the screen LI R5,>8C00 LI R0,>4000 BL @SETADR LI R2,1920 LI R1,>2000 LOOP MOVB R1,*R5 DEC R2 JNE LOOP * Load upper and lower case character set * from GROM to VDP (R5 is VDPWD) * (to repair probably destroyed character definitions) * Note: The characters are stored by seven bytes in GROM * so that a 00 must be inserted before each definition. LI R0,>06B4 * GROM position MOVB R0,@>9C02 SWPB R0 MOVB R0,@>9C02 LI R0,>4900 * VDP position BL @SETADR LI R3,96 * No. of characters CLR R1 JL MOVB R1,*R5 * Insert 00 LI R2,7 IL MOVB @>9800,*R5 * Copy seven bytes DEC R2 JNE IL DEC R3 JNE JL * Write texts on screen BL @WRITE DATA >40AC,TEXT1,56 BL @WRITE DATA >4158,TEXT2,18 * Write values of R13,R14,R15 on screen. * R3 will be used as a pointer to the RAM location * of these registers (starting at >83DA). * R5 is still >8C00 (VDPWD). * Use the character list HEXD to transfer the nybbles * (half bytes) to the corresponding ascii char. DECT @>83DC LI R3,>83DA LI R6,3 DISP MOV *R3+,R4 LI R2,4 * four nybbles per word LD SRC R4,12 * shift to rightmost nybble MOV R4,R1 ANDI R1,>000F * mask it MOVB @HEXD(R1),*R5 * Write char to VDP DEC R2 JNE LD DEC R6 * next register JEQ FRAME MOVB @POINT,*R5 * Print a "." JMP DISP FRAME BL @CLRBLK * Clear blink attributes LI R2,6 * Six rows LI R0,>5009 * Step forward to columns 72+ * Set blink attribute of columns 0 and 79 * of six consecutive rows LI R1,>0180 F1 BL @SETADR MOVB R1,*R5 * column 79 SWPB R1 MOVB R1,*R5 * column 0 SWPB R1 AI R0,10 * next row DEC R2 JNE F1 * Set blink attribute of every column in the first row LI R2,10 LI R0,>5000 SETO R1 BL @SETADR F2 MOVB R1,*R5 DEC R2 JNE F2 * Set blink attribute of every column in row 6 LI R2,10 LI R0,>503C BL @SETADR F3 MOVB R1,*R5 DEC R2 JNE F3 * Check the left mouse button. If depressed, stop blinking * and return to the master title screen. MLOOP LI R12,>0038 TB 0 JEQ MLOOP BL @CLRBLK LI R0,>8D0F BL @SETADR BLWP @>0000 * Standard routine to set a VDP address. * Note: Add >4000 for writing to the address SETADR SWPB R0 MOVB R0,@>8C02 SWPB R0 MOVB R0,@>8C02 RT * Write the text on screen defined by the following three words: * DATA screen pos, RAM pos, length WRITE MOV *R11+,R0 MOV *R11+,R1 MOV *R11+,R2 MOV R11,R10 BL @SETADR WL MOVB *R1+,*R5 DEC R2 JNE WL B *R10 * Initialize the blink attribute table (VDP >1000) * by writing 00 in all positions CLRBLK MOV R11,R10 LI R0,>5000 BL @SETADR LI R2,270 CLR R1 MOVB R1,*R5 DEC R2 JNE $-4 B *R10 * Paste the B @START into the interrupt routine * of the console ROM (which is RAM on the Geneve) * replacing the clearing of the MID flag. * Normal execution will resume at >035E (see above). AORG >035A B @START END 1 Quote Link to comment Share on other sites More sharing options...
Gip-Gip Posted May 20, 2017 Author Share Posted May 20, 2017 (edited) Started on the opcode list over at GitHub. I'm doing a 6502-inspired instruction set, tell me what you think Edited May 20, 2017 by Gip-Gip Quote Link to comment Share on other sites More sharing options...
+TheBF Posted May 22, 2017 Share Posted May 22, 2017 How is GPL constrained to 256 bytes of RAM? ...lee I was thinking about the bare console, and how they engineers had to shoe-horn the language to use the PAD memory. Quote Link to comment Share on other sites More sharing options...
+TheBF Posted May 22, 2017 Share Posted May 22, 2017 (edited) The Forth guys on this thread are too modest! Correct me if I'm wrong but Forth: - is a stack based VM - interprets byte code fast - is memory efficient - supports the TI hardware well I've read that someone has multi-tasking working: http://atariage.com/forums/topic/265697-tms9900-is-the-coolest-cpu-for-multi-tasking/?p=3763980 I've been thinking about a TIOS from a C point of view and it appears daunting. I'm not a Forth guy, but it "feels" right here. So what am I missing? - is a stack based VM - 2 stack VM but who's counting - interprets byte code fast - The implementations you see here are running "address" lists rather than byte codes and some Assembler at the lowest level. There are byte-code Forths. Open-firmware which boots Sun machines is one such system. - is memory efficient - Evidence points to smaller final program sizes yes. Some of that can be to small routines, easily re-used and re-combined to make higher level functions. rather than the system itself. But that is disputed sometimes. - supports the TI hardware well - Sure. You write assembler code to get the real work done and the point to them on demand. Edited May 22, 2017 by TheBF 1 Quote Link to comment Share on other sites More sharing options...
Gip-Gip Posted May 22, 2017 Author Share Posted May 22, 2017 - is a stack based VM - 2 stack VM but who's counting - interprets byte code fast - The implementations you see here are running "address" lists rather than byte codes and some Assembler at the lowest level. There are byte-code Forths. Open-firmware which boots Sun machines is one such system. - is memory efficient - Evidence points to smaller final program sizes yes. Some of that can be to small routines, easily re-used and re-combined to make higher level functions. rather than the system itself. But that is disputed sometimes. - supports the TI hardware well - Sure. You write assembler code to get the real work done and the point to them on demand. I'm still working on the compiler situation, so I haven't implemented anything yet. I may ask, when I do implement the VM should it be stack based or register based? I'm already working on a register based system, just wanted to know if there are any advantages before I finalize it Quote Link to comment Share on other sites More sharing options...
+TheBF Posted May 22, 2017 Share Posted May 22, 2017 I'm already working on a register based system, just wanted to know if there are any advantages before I finalize it Excellent question! There are divergent opinions on the matter. The rumors say a stack based VM can created smaller code. The Java VM is one of the best modern ones. Once you add all the classes and methods the code is probably not any smaller when you write in Java, but you should be able to do any language on top of JVM. The Parrot VM which is used by a bunch of languages now is a register VM and I have read it outperforms stack VMs for speed. https://en.wikipedia.org/wiki/Parrot_virtual_machine You should probably get familiar with a all three. Byte code Forth VM, JVM and Parrot VM and then make a decision. :-) B 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted May 23, 2017 Share Posted May 23, 2017 As I think about it a little bit more, a register based VM could take direct advantage of the 9900's memory to memory architecture. Your byte codes can add,subtract, mpy etc directly to memory and use hardware registers only when needed. Just a thought And taking a page from Parrot... create some Virtual registers in memory myregs BSS 32*2 * now you have 32 16 bit registers. myfloats BSS 8* 8 * and 8 floating point registers ... how many more and what kind would you like? :-) Quote Link to comment Share on other sites More sharing options...
Gip-Gip Posted May 23, 2017 Author Share Posted May 23, 2017 As I think about it a little bit more, a register based VM could take direct advantage of the 9900's memory to memory architecture. Your byte codes can add,subtract, mpy etc directly to memory and use hardware registers only when needed. Just a thought And taking a page from Parrot... create some Virtual registers in memory myregs BSS 32*2 * now you have 32 16 bit registers. myfloats BSS 8* 8 * and 8 floating point registers ... how many more and what kind would you like? :-) I was thinking the advantage to a register-based VM would be I wouldn't have to deal with the lack of a built-in stack, and I could use the workspace to my advantage (change it for each task). I'll look at all of them tomorrow; I have plenty of time to kill now exams are over. I'm considering only programming a few core utilities like the memory mapper/task manager in ASM or C, while doing the rest in the VM's language (with calls to native code when needed). This would be slow, but it would also negate the need for a separate native-code multitasker (not like the TI's gonna be much faster anyways) Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.