Search the Community

I found this unusual paper: COMPUTER SYSTEM CROSS-FERTILIZATION: MAKING YOUR TI 980 PLAY YOUR TMS 9900 by John D. Meng Presented at TI-MIX Atlanta 1979 It describes creating a cross-assembler for the new TMS9900 chip, within the assembler on the laboratory's TI 980A minicomputer. The TI 980 had a different instruction set than its successor, (you guessed it) the TI 990 minicomputer. However, the 980 assembler had two directives for defining new instructions! OPD (operation define) and FRM (Format a new instruction) The syntax looks scary--but they grew to love it. For example, the arithmetic format I instructions are defined with a FRM. There are constant values for the mnemonics and addressing modes. ARI FRM 4,2,4,2,4 BIT FIELDS FOR 9900 FORMAT I D EQU 0 I EQU 1 A EQU >A MOV EQU >C To assemble a MOV instruction, ARI MOV,I,0,D,2 MOV R2,*R0 which packs the 16 bits of a word, according to the FRM above: 1100 (four bits, opcode) 01 (two bits, register indirect, dest addressing mode) 0000 (four bits, dest register 0) 00 (two bits, register direct , src addressing mode) 0010 (four bits, src register 2) Note that the format here is opcode, destination, source... backwards... (a matter of debate) Another example, EXT FRM 6,4,2,4 MPY EQU >E EXT MPY,D,1,D,0 produces MPY R0,R1 In other cases, the format of a 9900 instruction fit neatly into the pattern of a completely unrelated 980 instruction, so they took advantage of that with the OPD directive. Format 8 of 9900 instructions, such as AI (add immediate), happen to fit into the TI 980 Format 7. This declares a mnemonic with Format 7: AI OPD >220,7 Then, how to debug the code? This scheme was exactly what TI's AMPL microprocessor laboratory would later provide, of course with the cost of a new TI 990 bundled in. But programming and debugging in assembly was no joyride. Therefore they invented a little language. Reminiscent of the Forth inner loop, the interpreter follows a list, calling BLWP on each address. Translated back into TI syntax for y'all, the inner loop was: START LI R0,PROGM POINTER TO FIRST STEP (PSEUDO PC) RUN MOV *R0,R2 OPCODE IS PARAMETER POINTER JEQ START ZERO OP CODE MEANS RESTART INCT R0 STEP PSEUDO PC BLWP *R2 EXECUTE THE PSEUDO-INSTRUCTION JMP RUN LOOP The sample program is: PROGM @SCAL RESET @TIMR RESET @TIMR START @ADC ON FIN END. RESTART. which is, in 9900 syntax, PROGM DATA SCAL,RESET DATA TIMR,RESET DATA TIMR,START DATA ADC,ON DATA 0 FIN inside the SCAL routine, the parameter RESET is picked up via something like: MOV *R13,R0 MOV *R0,R0 INCT *R13 In the Epilog, the author makes me feel sad that this effort was superseded. What we have described is not a tutorial on what to do. Nearly everything we have done has been superceded in economic and efficient fashion by material now available from Texas Instruments. We still use our cross assembler simply because we have it and we are very familiar with it. However, TIBUG achieves much of what we were attempting with our cross-connection between the 980 and a 9900 chip, and the recent introduction of POWER BASIC supercedes our own pseudo-language develop­ments. What we have described is,first of all, history. It is a story of challenges successfully met when a new and apparently useful device appeared without much manufacturer support. It is also a story of how to learn in great depth about a new device. Finally it is a story about the immeasurable value of ingenuity in the face of crucial challenges coupled with a perennial budget crunch. ------------ Some cute instruction mnemonics of the 980 are SNO (Skip on Not all Ones) and SOO (Skip On all Ones). All the conditional branches are called Skip and they only jump over the next instruction! You might follow a Skip with a BRU, branch unconditional, for the opposite case. I would like to have its directive BRR (Base Register Reset.) I imagine this as a valid 980 program: BRR ADD SNO BRU IDL Here is a gentle introduction to 980 assembly, prepared for the TI-MIX group (much more under bitsavers TI-980) I chuckled at this sequence, since CR refers to both Card Reader and Carriage Return. Hit it. Notice that our beloved name CS1 was used by the operating system to refer to the cassette tape unit. If you don't have enough grey hair: the Card Reader/Punch* was a frightful I/O device where a stack of paper cards held your data, punched out with little holes across 12 columns. For example, the numbers 0 through 9 were single punches of the columns 0 through 9... letter A would be 0 plus a hole in the "X" column, and so on. The 990 reference card still featured a table of punch codes, listing the 64 characters of IBM ECBDIC, followed by a helpful ASCII conversion table (also 64 codes...) Dave Pitts mentions a card reader for the 990. From the style of these two documents, it's for sure that 980 users had a sense of humor. 980s in working order were still put to use at TI, in the late 70s, alongside 990s. (see the speech lab manual that I uploaded.) *In the most antiquated lab course I had in college (6811 embedded lab), we had a network of computer terminals (MTS) connected to the IBM mainframe with all its disk storage and programs. Yet its 6811 assembler still referred to your input source file as "SCARDS" and output file as "SPUNCH". I forget what the next step was called--you referred to that assembler output as SCARDS again, and sent it out your terminal's second serial port (STYPE?), assuming the 6811 board was hooked up there and ready to receive it. Typically I avoided writing code on the lab terminal. Instead I logged into MTS and uploaded files from my Geneve 9640. Fast-Term (hmm) mapped the extended keys on the Geneve keyboard to MTS escape codes. Reference Meng, John D. (1979). COMPUTER SYSTEM CROSS-FERTILIZATION: MAKING YOUR TI 98C PLAY YOUR TMS 9900. February 1979. Lawrence Berkeley Laboratory, University of California at Berkeley. To be presented at 8th annual TI-MIX, Atlanta GA, 3/27/1979. Downloaded on 1/27/2023 from https://escholarship.org/content/qt1vz517x5/qt1vz517x5_noSplash_0a4bcf88c0d7a86260d9787b1bc5fc73.pdf?t=li5ywu TI-980 playing the TMS9900.pdf

Here's a thing I've been playing with, and thought about putting it in a separate thread. With the help of @Asmusr I tweaked the f18a emulation in my local clone of js99er, so that it can now run in 60 rows, 80 columns mode. The idea was to see how I need to setup VDP memory to get stevie running in 60 rows, 80 columns mode and do refactoring for the different video modes (24x80, 30x80, 60x80, ...) This is still a work-in-progress and will never be officially released, but it does prove that it's doable. As a starting point I took the stevie build I made for classic99 where I use a character cursor instead of a sprite cursor. (Sprite cursor is possible, but will only get halfway the screen, due to 1-byte for Y in the sprite attribute table, so of no real use here) Anyway, the build for classic99 was also a hack, because I refresh the frame buffer each time the cursor blinks. That clearly shows here, because I'm dumping quite a bit of data to the VDP and it gets a bit slow. So, next thing to do for me is to get that cursor routine a bit smarter. You never know, maybe the f18a mk2 will support a 60x80 mode. I'm still wondering if it'd be doable on the f18a mk1 with a firmware update, but I think Matthew said it won't work because of VHDL already being chuck-full. 16K of VDP memory is enough though, as my demo shows. Enjoy the demo (VDP corruption at the end when turning on the ruler., but that's part of the fun. I still need to fix some things in stevie). js99er-20230123204409.webm

I like to do my programming, these days, for my TI99 using a PC. First off I can use the wonderful Notepad++ for editing and test the software in the equally wonderful MAME and secondly I don't wear out my 40+ old TI99/4a. And to increase the already massive wonderfulness I have added language support for the TI99 to the already extensive list of programming languages built into Notepad++. I added TMS9900 and TI99 XB support to Notepad++ with the two .XML files attached in the .ZIP below. To add language support for TMS9900 & TI88 XB to Notepad++ use | Language>User Defined Language>Define Your Language. on the 'Define...' page click the Import button and add one .XML file at a time. Shutdown Notepad++ then restart and TMS9900 & TI XB will now be a choice in the Language list. Note: the TI XB works well with AdvBASIC of the Geneve too. I then use Classic99 and paste straight in XB or for Geneve ABASIC I use TIImageTool to import the file into a .dsk or .hd by | Edit>'Import from Text Editor' then paste>save the file. For TMS9900 a cross compiler would work nicely as well as the other two previous methods. that's it. Enjoy. notepad++-xml-lang-files.zip

** This question is about the crunch buffer in TI Basic, not the crunch buffer in Extended Basic ** ok, so I have been doing some experiments with TI Basic lately. For one of the tests I'm doing I am using the F18a with 30 rows mode. What I would like to do is add some information on the rows 25-30. The thing is that the VDP memory for that area is "blocked" by the TI Basic crunch buffer that starts at VDP >320 So here are my questions: Is it possible to move the TI Basic crunch buffer to another location in VDP memory? I presume it's hardcoded in the TI Basic interpreter in GPL. Was thinking about using a ISR routine in assembly routine that "kicks-in" and changes addresses (GPL registers, addresses) in a transparent way. Considering that TI Basic is so slow I might actually get away with it Any ideas on this one? Is the TI Basic disassembly available somewhere? I'm aware of TI XB disassembly, but not TI Basic itself. Actually I start liking TI Basic much. Yes it's slow, but I'd like to learn a lot more about its internals before addressing TI Extended Basic.

I'd like to jump into the TI Basic interpreter coming from an assembly language program running from cartridge space. It's not that I want to run a specific call or so, just start the TI Basic interpreter like selecting option 1 "TI Basic" on the selection screen. Is there any sample code to show how that works? Guess that I basically need to get the GPL interpreter running TI Basic at >216F (?) Was hoping for a vector address in the console ROM that triggers the TI Basic interpreter, but couldn't find it.

Is there a standard in the level-2 IO calls for setting path and directory handling? If yes, where can I find description/details on PAB & subprograms. What I'm after is a way to change into a new directory and also to create a new directory, rename a directory and delete a directory. Target is the TIPI and the IDE card. These are the sole PEB cards that I'm aware of that support this. Any other PEB cards are unobtainable I'd say (SNUG, HDFC, ...) Thanks.

So I have a few lines of code I want to optimize for speed. Have some ideas what I can do, but I'm also very interested seeing what the community comes up with... The code is used for reorganizing my TiVi editor index when I delete a line in the editor. Note that when I reorganize the index, I make sure that the index pages form a continuous memory region, so I don't have to worry about mapping pages or anything. That's already been taken care of. The index can grow up to 5 SAMS pages mapped to (>b000 to >ffff) for 10240 lines of text. ok, Here's what I would do: Copy code to scratchpad and work from there for reducing wait states Reduce loop counter overhead by putting multiple mov instructions in a single loop, say 8 Look at the fastest mov instructions (only use registers?) What else could be done for faster access? Note that in the code fragment tmp0=R4, tmp1=R5, tmp2=R6 and so on. *************************************************************** * _idx.entry.delete.reorg * Reorganize index slot entries *************************************************************** * bl @_idx.entry.delete.reorg *-------------------------------------------------------------- * Remarks * Private, only to be called from idx_entry_delete *-------------------------------------------------------------- _idx.entry.delete.reorg: ;------------------------------------------------------ ; Reorganize index entries ;------------------------------------------------------ ! mov @idx.top+2(tmp0),@idx.top+0(tmp0) inct tmp0 ; Next index entry dec tmp2 ; tmp2-- jne -! ; Loop unless completed b *r11 ; Return to caller *////////////////////////////////////////////////////////////// * TiVi Editor - Index Management *////////////////////////////////////////////////////////////// *************************************************************** * Size of index page is 4K and allows indexing of 2048 lines * per page. * * Each index slot (word) has the format: * +-----+-----+ * | MSB | LSB | * +-----|-----+ LSB = Pointer offset 00-ff. * * MSB = SAMS Page 00-ff * Allows addressing of up to 256 4K SAMS pages (1024 KB) * * LSB = Pointer offset in range 00-ff * * To calculate pointer to line in Editor buffer: * Pointer address = edb.top + (LSB * 16) * * Note that the editor buffer itself resides in own 4K memory range * starting at edb.top * * All support routines must assure that length-prefixed string in * Editor buffer always start on a 16 byte boundary for being * accessible via index. ***************************************************************

In the 4K Basic Support Module thread, @Schmitzi found three disk images with Disassemblers on them. As I pointed out in this post, the second disk contains an XB LOAD program that can load a GPL Assembler or a GPL Disassembler. Those two programs appear to be written in TMS9900 Assembly Language Code (ALC) rather than Forth, as was hoped. What interested me, and the topic of this thread, were disks one and three. They happen to be two different versions of René Leblanc’s Universal Disassembler, which he wrote in TI Forth. As near as I can tell, Universal Disassembler is for ALC rather than GPL. The first disk is v1.2 on a 90 KiB disk and the third is v2.3 on a 360 KiB disk. Unfortunately, neither of these disks work. As I discussed in the above-referenced thread and will repeat here, it appears that these disks were prepared from the originals by copying the three files, FORTHSAVE, SYS-SCRNS, UNIVERSAL (aka FORTH) (in that order), from the system disks with no further processing, which is verboten for TI Forth system disks because the system screens (blocks) will never be copied properly. They will all be there, just not in their proper places and almost certainly misregistered, i.e., each block’s line 0 will not start on a 4-sector boundary. The only way to properly duplicate a TI Forth system disk is to copy the disk, sector by sector. Creating a larger system disk is more complicated, but doable. I have every reason to believe I can restore these two disks to working order, unless there is more than misregistration wrong with them. My intention is to produce 90 KiB (SSSD), 360 KiB (DSDD) and 400 KiB (CF7+/nanoPEB) versions of each disk. Right now, I need to mow a lawn—TTFN! ...lee

I'm currently implementing file access in my TiVi editor. The editor is designed to run in 80 columns mode. My question is what text file formats should be supported? I mean DIS/VAR 80 for sure. But are there editors out there that support other file formats as well. Does it make sense to implement scrolling in the editor so that I can let say open a file with 255 record length and show it on a single line with scrolling? Any opinions on that?

Has anybody documented the undefined behavior of the TMS9900 data and address buses when no memory cycle is happening? I noticed this today while debugging a hardware glitch (unsuccessful so far): During the Add instruction, the databus repeats the two operand values. I don't see this behavior documented in the TMS9900 manual. It seems like a nice feature to have. I guess it's the ALU "leaking" its values onto the data bus. What does an Add instruction do? The sequence of operations is roughly: instruction fetch instruction decode fetch source operand fetch destination operand internal ALU cycle (in this case, ADD) store destination operand Here is an observed sample case where the cpu adds 0010 + dec8 = ded8: My registers: WP 83E0 PC 7d32 (whole program from 7d00 to 7d80) R0 0010 R5 A000 Bus observations (each row is at least 1 clock cycle): ADDR DATA Signals Action 7d32 a540 MEMEN DBIN IAQ read instruction: A R0,*R5 ???? xx40 decode ???? xx10 decode 83e0 xx10 MEMEN DBIN fetch R0 from 83e0 a000 dec8 MEMEN DBIN fetch dec8 from a000 ???? xxc8 internal ???? xx10 internal a000 ded8 MEMEM WE store result to a000 xx are the high byte I can't see (I'm reading the side port. I only see one half of an internal 16 bit bus read.) ?? are addresses I missed cuz I only grab the address when MEMEN is asserted. The internal cycle values xxc8 and xx10 match the destination and source values. I'll be taking more notes on other instructions.

I will be using this thread to document the development of a new programmer editor for the TI-99/4a called "Stevie". Download the cartridge image in the official release thread. As you might expect from its name, the editor is somewhat inspired by the unix editor "vi" and will also take elements of "tmux". So what do I have in mind: Designed from the ground up for 80 columns mode, specifically using the F18A but 9938 will be supported as well. Designed from the ground up for using SAMS card. Programming language of choice is TMS9900 assembly language The editor itself will run from cartridge space (multi-bank cartridge). Uses my spectra2 library as foundation (been doing major changes in the last couple of months, not related to games) Will have some "API" so that I can integrate with external programs and go back and forth between programs. Would like to add some kind of mouse support. This will not be a GUI in the traditional sense. If you used tmux with a mouse before you know what I mean. Possibility to have multiple editor panes open at once. Should handle files with up to 65536 lines Undo functionality, well up to a certain extent that is. Language awareness, e.g. behave differently based upon language (e.g. assembly, C, Basic, ...) Internal text representation will be decoupled from what actually will be rendered on screen. Should make the editor more responsive when dealing with large files, allow split panes, etc. Reconfigurable keymaps, possibility to swap between keymap with single key combination. Not everyone is into VI This is the start of a large project and I don't expect to have a truely useful version anytime soon. I expect this project to take multiple years, but you gotta start somewhere. Now I've taken my mouth full, I will use this thread to keep myself motivated ? There aren't too many resources out there discussing the architecture of a text editor, so cross-linking here: Dr. Dobb's Journal 1993 - Text Editors: Algorithms and Architecture Gap Buffers: a data structure for editable text Rope (data structure) - Wikipedia Vi Editor: Why Programmers Think This Old Editor is Still Awesome Threads on Atariage discussing topics -somewhat- related to Stevie: F18a F18a 30 rows 80 columns mode F18A high-resolution timer How to lock the F18a and halt the F18a CPU File handling CRU scan sample code, my implementation of a CRC-16 Cyclic Reducancy Check DSRLINK Code Tutorial File operations in assembly language E/A file access Opinions on TI-99/4a text file formats TI Basic integration Jump to TI Basic from assembly language Detect if TI Basic is running a program TI Basic move crunch buffer in assembly TI Basic session manager Others: Favourite text (programmers) editor on the TI-99/4a Better keyboard scanning? tmux for developers github: Stevie source code Issue tracker

Do we have sample code showing how to do a device CRU scan. What I would like to accomplish is scan and identify peripheral expansion cards like HRD3000, RS232, SAMS, ... Basically something like we have in the CFG834 configuration program.

Hi everyone. I've enhanced my pretty6502 formatter to allow for TMS9900 assembler source code plus xas99 directives/syntax. It works very well with my games Astro Cube and Borzork. Of course it could need more testing Enjoy it! https://github.com/nanochess/pretty6502/releases/tag/0.5

Hi everybody, I'm looking for some good working examples of doing disk file I/O operations in assembly language. Already looked at section 3 DSR (Device Service Routine) / Disk & File Management in the development resources thread. Lots of good stuff there, but seeing some working code definitely would help. What I want to accomplish is to create, read, update text files and load binary files. Basically I'd like to write a small programmer's editor for running on the TI-99/4a. For keeping things simple and compatible with as many disk devices as possible I would only focus on level 3 I/O calls. Now here's where things get tricky. I want to use my spectra2 library for most of the stuff. I learned that scratchpad memory and VDP memory must be setup in a certain way for DSR calls to work successfully. Currently I'm exclusively using scratchpad memory for all my stuff, so will have to reallocate that to somewhere else. That should be possible easily enough. Now here are my questions: 1. Does a scratchpad memory map exist, with the minimal requirements for calling DSR routines ? 2. How do I need to setup VDP memory so that file I/O is possible. I understand that a PAB must always reside in VDP memory. But the disk controller DSR also uses VDP memory for work buffers during file I/O. Does the disk controller DSR always loads files from disk to VDP or is it possible to directly load to RAM ? 3. Is it possible to do file I/O calls in pure assembly language or do I have to involve GPL in some way? The documentation being focussed on Monitor, Basic, etc. seems to imply that GPL is always involved. Is that a necessity? 4. What is the easiest way to "interface" with DSR memory setup. I mean would have to switch between my "application workspace" outside of scratch-pad memory, into the "DSR workspace" in scratch-pad memory and return safely. 5. Any good examples out there? On a sidenote, I remember a discussion with InsaneMultitasker many moons ago where it was mentioned that a file operations document was in the works. My memory is a bit blurry on that, can't recall if this was finished or not. Cheers Filip

To share more on the progress, this is the current output of the tool I am working on: http://www.ti99.eu/wp-content/uploads/TIcode99/ROM-4A_A.html http://www.ti99.eu/wp-content/uploads/TIcode99/ROM-4A_B.html http://www.ti99.eu/wp-content/uploads/TIcode99/ROM-4A_C.html The content in these files is the original commented source code for TI-99/4A System Rom, created by the TI developers. Basically an assembler source code file is read in by TIcode99 and parsed to generate a new assembler source code file. These html files are something I wanted to do for a long time already, they include rich syntax highlighting, which is only possible because the tool actually understands and categorizes the content in the code. The tooltips (hover with the mouse on certain elements) show you detailed information about the opcode, about the symbols and their resolving, the operand type,... The symbols can be clicked on to jump to the location where they are defined. However with the enhanced tooltips you hardly need to jump for and back just to read the definition of the symbol. All this is done automatically and can be done for any Tms9900 source code file. When I change the render options to always render numbers in hexadecimal format, it generates these instead: http://www.ti99.eu/wp-content/uploads/TIcode99/ROM-4A_A%20-%20Hexadecimal.html http://www.ti99.eu/wp-content/uploads/TIcode99/ROM-4A_B%20-%20Hexadecimal.html http://www.ti99.eu/wp-content/uploads/TIcode99/ROM-4A_C%20-%20Hexadecimal.html When I change the render options to always render numbers in decimal format, it generates these instead: http://www.ti99.eu/wp-content/uploads/TIcode99/ROM-4A_A%20-%20Decimal.html http://www.ti99.eu/wp-content/uploads/TIcode99/ROM-4A_B%20-%20Decimal.html http://www.ti99.eu/wp-content/uploads/TIcode99/ROM-4A_C%20-%20Decimal.html Here are the original source files for reference: http://www.ti99.eu/wp-content/uploads/TIcode99/ROM-4A_A.a99 http://www.ti99.eu/wp-content/uploads/TIcode99/ROM-4A_B.a99 http://www.ti99.eu/wp-content/uploads/TIcode99/ROM-4A_C.a99 See also the formerly used thread where people helped me get this far: http://atariage.com/forums/topic/274552-lots-of-assembler-questions/

I was looking over an old game in a hex editor recently, and I noticed something interesting with the text data embedded in the program. All of the strings seemed fine until the end character, which was a byte value of 128 or greater. I realized what the program was doing was using the top bit on ASCII characters to determine the string end. This lets you store strings at their exact size, rather than one byte more to store either a length byte or a null terminator byte. Very clever! So I thought, how to leverage this on the TI, where I've spent a considerable amount of effort building menus and interfaces that consumed a lot of memory because of having to store strings and their addresses and lengths? So I write a routine, VTEXT, and it's companion, VTEXTC. It's a subroutine that takes the address on screen into R0, and a pointer to the desired text in R1. No length needed! It writes to the screen until it encounters the eighth bit, and stops. VTEXTC is the same, except it doesn't alter the VDP address. This will allow you to write concurrent strings to the screen one after the other. Advantages are: - Your text strings take up exactly their length in space - Reduced operations for plotting text to screen Disadvantages are: - All static text in source files has to end with the top bit set, which can be aggravating to figure out the value of a given ASCII character - Slower than a straight VMBW due to the need for a COC and copy operation on every character - If you don't have the top bit set, it could overrun the screen buffer and the rest of VDP Future expansion may include the idea of "values". Using characters 0-31 can be used as an indicator to, for example, switch to a stored numeric value in text form, so you can introduce string formatting. "%0 takes %1 damage!" for example, so it knows to plug in the 0 and 1 pre-calculated values into the string as it's writing to the screen. TOPBIT DATA >8000 * Top bit word VDPWA EQU >8C02 * VDP Write address port VDPRD EQU >8800 * VDP Read address port VDPWD EQU >8C00 * VDP access port (input/output) SCRADR EQU >0000 * Screen address TXTLN1 TEXT 'This is sample tex' BYTE 244 TEXT 'More sample tex' BYTE 244 TEXT 'Sample Tex' BYTE 244 TEXT '-Sample Tex' BYTE 244 * Video Text writer, CPU to VDP * Uses only R0 and R1 for location, length is determined by the top bit * Sends R1 value back to calling rouine for continuous stream of text * VTEXTC does not update position in VDP, so you can write multiple strings concurrently VTEXT ORI R0,>4000 * Set address for VDP write SWPB R0 * Swap to low byte MOVB R0,@VDPWA * Move to VDP address SWPB R0 * Swap MOVB R0,@VDPWA * Move to VDP address ANDI R0,>3FFF * remove extra bit so address is preserved for subsequent calls VTEXTC MOVB *R1+,R2 * Copy character to R2 COC @TOPBIT,R2 * Check if top bit is set (end of line indicator) JEQ VTEXT1 * If so, skip to end MOVB R2,@VDPWD * Write character to screen JMP VTEXTC * Loop VTEXT1 ANDI R2,>7F00 * Reset top bit on character MOVB R2,@VDPWD * Write to screen RT * return to calling program * Example LI R0,SCRADR+128 * Set R0 to SCRADR+128 LI R1,TXTLN1 * Set R1 to start of text BL @VTEXT * Write string to screen AI R0,32 * Add 32 to screen position BL @VTEXT * Write a second line of the text LI R0,SCRADR+256 * Change R0 to a different position BL @VTEXT * Write next line to screen BL @VTEXTC * Write the next text segment immediately after the prior * Program continues...

Hi, can the experienced programmers confirm if the following statements are true and I understood the topics correct? The background is that I am working on a tool TIcode99 and would like to get it reading in 99xx(x) source code files correct. Special operand types [CruBit <cnt>, Xop <xop>, ShiftCount <scnt>] - If an opcode requires a numeric input for an operand, the sourcecode can define the number as decimal or hexadecimal. - If an opcode requires a numeric input for an operand, the sourcecode can always define a symbol (EQU opcode) and refer the symbol name instead of a direct numeric input - If an opcode requires a numeric input for an operand, the sourcecode can refer a Workspace Register instead (like 'SLA R5,R0'). However not the value of the Workspace Register is used but the number of the Workspace Register - for these operand types I can not use '1+2' as operand. Immediate operand type <iop> - If I define a Symbol, I can refer the symbol as immediate operand. Here I can also use a symbol reference like below to define an immediate operand. -SYMB1 SYMB1+2 SYMB1*256 SYMB1+SYMB2 All of these examples don't work for the operand types CruBit <cnt>, Xop <xop>, ShiftCount <scnt>. - Below instruction is not supported on the TI-99 Editor Assembler, but probably on the TI-990 Assembler (SDSMAC). LI R1,MF1+(>F*4) I assume it can be translated to? LI R1,MF1+>FFFF Questions about the Immediate Operand type: 1. What does this instruction mean? CI R0,@ENDDAT ... ENDDAT EQU $ It fails for me in the EA, never the less the 99/8 source code uses such code in DEBUGG. Other example: PAR02 CI R8,@INTEG$*256 ... INTEG$ EQU >AE 2. How can a String be useful as immediate Value? 'E' 'I'-'0' -'0' '--' '-'*256 I don't understand the usecase when to use a String like shown as Immediate operand. How are these "translated" into a numeric value? Symbol operand type <symbol> This operand type is a bit unclear to me. Afaik this i used by opcodes DEF, REF, SREF, LOAD, DXOP, END and DFOP. Should this solely allow the definition/reference of a symbol? Or should I be able to use something like "SYMB1+2" or other 'expressions'? Workspace operand type <wa> XPTL EQU 6 SRL XPTL,8 Since this works, it seems I can use a Symbol instead of a direct reference of one of the Workspace Register. Is it translated to Shift R6 by 8 to the right? However I can not use "XPTL+2" for that operand. Expression operand type <exp> It is quite clear that wherever the syntax definitions says here should be an <exp> as operand type it allows an expression to be used. However it seems that the Immediate operand type <iop> and the General Address operand types <gas>,<gad> are heavily using expressions as well. Is the assumption correct, that every expression has to result in some number (address) during assembling time? General operand type <gas>, <gad> I see sometimes an operand looking like indexed memory addressing, however the @ sign is not there. WRTADD EQU >402 ... MOVB R4,WRTADD(R9) Any explanations on why this is missing the @ sign? Many thanks for your help in advance.

I completed the replacement of the crystal in this TI99/4A so the color stability should last years and years. I also re-did the thermal paste on the two IC chips. Cleaned every part. Sadly the machine was missing one of its metal case covers. So I asked a professional auto body painter to give it a new metal look. The paint looks great and won't rub off like spray paint cans. I added the BASIC manual, AC adapter and home made composite video cable. This is a machine that will work and work for many years at that. http://r.ebay.com/CIIJg9 Thanks for looking!

Hi there! I try to find an overview and comparison of all mnemonics of all CPU TI made. I'm looking for a comparative table with all mnemonics for each processor with its addressing modes an opcodes, perhaps with additional descriptions like affecting status bits etc. Does anybody know of such a list? I'll be thankful for any tips.

ok, so I'm working on a cross-compiler for my own little high-level language called b99. The language is kinda similar to Pascal or ADA. The target is to create software in b99, compile and then assemble the TMS9900 assembly source code. It uses my spectra2 library as its runtime. So the program will run on a bare console, no 32K memory expansion required. It's still very early work (started in january), so I'm not releasing the compiler yet. The compiler itself is written in perl (using Parse::RecDescent as parsing module) Language constructs are subject to change as I'm playing around and doing funky stuff sndtest.b99 : Here's a little b99 music demo. Tunes converted by @OLD CS1 Here I am using multiple cartridge menu entries, some labels and the play sound command. Note that I make use of resources (e.g. binary files that are automatically dumped to byte statements). The idle command is used for passing control to the runtime library kernel. This is what starts the tune. sndtest.a99 : The resulting assembly source code ... and this is the cartridge binary you can run in classic99 or on the real deal: CART.bin

So it has been a few years since I've done TMS9900 assembly language programming. Here's a recycled demo where I've now attached a speech sample. Tried it with classic99. Anyone willing to try if this also works on the real deal? It's an 8K image, scratchpad memory only. You'll need a supercart and a speech synthesizer to run this. CART.bin

Probably lots of people had this idea already, and I've been reading about TMS9900 assembly only sporadically. Let CALLEE be the address of a subroutine like this: CALLEE (instruction) (instruction) (instruction) ... RTWP And my idea for a "reentrant call": STWP R8 S 36,R8 MOV R8, @32(R8) MOV CALLEE, @34(R8) BLWP @32(R8) Could be turned into a macro, and the trashed register cound be any one that doesn't have a special use (R12-R15). I did this on paper only, so it may have a few holes. Also, this is NOT for hardware interrupts! And, of course, for machines with a respectable amount of RAM -- definitely not a base 99/4A! So, makes sense? Is it horribly slow and wasteful and a much better method exists? EDIT: No, wait, wait. I don't need that additional space for the transfer vector. It can be located in the middle of the new workspace. STWP R8 S 32,R8 MOV R8, @8(R8) MOV CALLEE, @10(R8) BLWP @8(R8) EDIT II, THE SEQUEL: And if I didn't mind trashing the first few registers of my current WP I could even make them overlap! What do you think?

Had to say this; just installed the F18a and WOW. it was so easy to install and the picture is great! The only hard part is cutting the hole for the plug. The only program I, so far, have problems with is 'The missing link'. keep getting, 'out of memory' and Stack memory goes to 0. Since I don't use it much, don't care. on the other hand It might be my imagination but the graphics seem faster. can't wait to delve into some of the extended features.

Are there any good 9900 disassemblers out there for the TI-99/4A (or for running on the PC) ? I'm particularly looking to disassemble some ROMS. Thx retro