kl99

If it is not straight forward, I suggest a live video stream where the pros give ciro advices which steps to do and directly see how the system reaction. That would be one awesome historical stream. The Chicago TI User Group uses the free service ustream.tv for their broadcastings. Or we use skype - I think you can record the video with some addon there.

RXB, your work is appreciated a lot and acceptance and knowledge on RXB will rise a lot once this 512k GROM cartridge board gets finished. I promise to take a deeper look into your Software soon. And I am certain already, that GPL is something I want to make a deeper look. Big projects like Geneve 2 and stuff take time and time will tell if there will be a finished product in the end. We can really be lucky to have the F18A now buyable as finished product. The thing that is missing for programs to use F18A feature enhancements is emulator support. I see myself trying out stuff in Classic99 every day, be it when I am on my laptop or at home. It's just so more flexible than a real console as a development environment. I can debug easily. I have all the manuals as pdfs there, I have Ti99-Dir to view my program listing nicely.

So, this is the XB version of the demo that uses your assembler routines, right? Once this is compiled, it will even get faster... Will the new version be compatible with programs made for the XB-Compiler v2.1?

Maybe mizapf can help you instruct how to dump the system rom and the p-code rom to share both versions with the community. As far as I know the demand for this is still there. Btw - i found proof that there might have been more 99/8 produced than we thought. John Phillips (famous programmer) got serial #200 of the TI-99/8 prototypes - directly from Texas Instruments as a bonus for his work. i saw the scanned signed TI letter with this info on a Bill Gaskill Cd-rom.

Thanks to sometimes99er, RXB, Vorticon and Willsy for the tips on this complicated topic. I will answer to these in a dedicated game thread. @senior_falcon: I found two XB Compiler issues: 1. Extended Basic supports variable assignment like: 100 A,B=5 110 PRINT A;B The compiler keeps hanging on a line number that contains such a multiple variable assigment. I suggest either add this to the documentation or try to add multiple variable assignment. 2. DISPLAY AT - SIZE Parameter is not interpreted: Example: 100 CALL HCHAR(1,1,64,768) 110 DISPLAY AT(21,1)SIZE(:"12345678" 120 GOTO 120 In Extended Basic this program results in a screen filled with 760 "@" characters and 8 digits in row 21 from column 3 to 10. This program compiles fine in XB Compiler 2.1 but the result looks like if you have not set the SIZE parameter. So at least in this example the SIZE parameter is not interpreted and the whole row gets erased. This should not be taken as a critic but the possibility to further enhance the undoubtable usefulness of your Compiler. BTW: I will demonstrate the XB Compiler on the upcoming TI99 February Meeting in Vienna.

Thanks sometimes. It seems you took some deep thoughts into it and I appreciate it. I had my TI Basic version once as far as all the 4+ capsule check and erasing worked. The reshaping of remaining half-capsule was fine too. But when that part is finished all capsules should "fall down" whenever there is a hole below them. Under certain circumstances there can be a lot of pills to handle (and when those landed check again for 4+). I didn't get the falling algorithm to work, more precisely I didn't find an algorithm for that. Now with attempt #2 on programming this I know at least that I better check the whole screen for 4+ times of each pill color. My current proposal for this is using string function POS.

Hi! It's only partly related to the XB Compiler but with the Assembler Function VREAD I can read from VRAM a number of bytes. Since XB stores your string variables in VRAM as well, I wonder if it is a waste of memory if I store all my strings as a string variable. I can store/read a string into/from VRAM anyway. Or is it a performance question - is it faster to have dedicated string variables in the XB program already. I mostly need them in loops, so only one string at a time. I ask because I want to do some string functions on the dr. mario 16x8 game screen: check for 4 chars of the same type in a row, check for 4 chars of the same type in a column. It's like a full line in Tetris which gets erased and the rest of the chars "fall down" accordingly. If you don't know Dr. Mario, check out: Klaus

A guy from our austrian group has seen these video errors a few times (he fixes a lot of 8/16 bit systems), one of the 8 video memory chips could be faulty. Open it and try to see if one of the memory chips is really hot compared to the others, this one needs replacement then: http://www.8bit-home..._reparatur.html http://www.8bit-homecomputermuseum.at/repair/ti_994a_2/ti994a_2_reparatur.html Since the VDP is socketed you can further try removing the VDP chip and putting it back into the socket. Of course you could try a F18A in there which bypasses the 16K VDP Ram all together because it is using it's own 16K as VDP.

I recommend the TImeline from Bill Gaskill. It really gives you a indeep look into the history of the Texas Instruments Home Computer and its relations to its competitors. It's still being updated. The version I own is 115 pages. There was once a version with color pics which was around 200 pages. Since it's a copyright text I can't publish it here. The versions on the web are way outdated: http://99er.net/hist1.html http://99er.net/hist2.html http://99er.net/hist3.html http://99er.net/hist4.html or http://chung.yikes.com/~leonard/mirrors/ti99/timeline.html Then there is "The Orphan Chronicles" which is available for download here: http://pergrem.com/tibooks/ Furthermore you need to read Home Computer Wars.

Hi Michael! This is Klaus Lukaschek from Austria. Welcome on board RXB is here a lot actually, i have taken a first look in the RXB software and GPL this week, it looks like a nice cartridge! Klaus

True, it's a pity, but speaking about TI 99 world, a lot of this prototype (or finished) software has survived the home computer crash and seen the day of light by now. Thanks to hardware like the: http://hexbus.com/TI-99_4A_Home_Computer_Page/The_TI-99_4A_Home_Computer_Page.html#6 and there was another cartridge simulator box (GROM simulator?) used by TI marketing guys to promote the home computer. Those boxes featured most of the unreleased cartridges on disk. Other software that was planned for a cartridge release was later released on disk. We can be lucky that we have that

interesting that this guy owns 3 revisions of the game. at least one revision of superstorm got rom dumped.

How are you testing your compiler? Are the Extended Basic instructions tested individually by a human comparing the results on screen or have you achieved to create some kind of automated tests? Maybe we as the community can help you here in order you can concentrate on coding. I will have a talk with the tester in our team in my company. He creates Gherkins, Automated Tests, Manual Tests on a daily basis. Of course to create some kind of test framework for this compiler there is the need to know a lot about the compiler. Ideally we would write something like: I take instruction CALL CLEAR for a first example. After execution I expect the VDP memory from 0000-02FF to be filled with Char 30. The rest of the memory should be basically untouched and ideally be checked as well. Maybe an emulator is good for such a test framework, since it can save/compare all the memory from outside world easily? Another test example would be. I execute CALL SCREEN(17). I expect an error message with a specific exception - value out of range or something. And ideally simply ignore this Extended Basic Instruction. When I execute all the tests: the framework should give me information like TESTING CALL CLEAR: OK TESTING CALL SCREEN: OK ... Maybe it's overkill but this way we could be sure that such a compiler handles each instruction correct and does proper error handling. If someone finds one of the many hints in ti books or magazines where XB actually behaves strange or a bugs occur, we could easily add a test for this and see if the compiler recreates this "wrong" behavior.

thanks for all the replies, seems like I have still a lot of reading/learning to do Harry, do you have plans to extend your compiler somemore?

Sorry to hear that. The TI Joysticks give you the original feeling but they are horrible to play with. After 15 minutes your hand/fingers are hurting. The response of directions is bad as well. I always use the TI Joysticks only because I am a TI Geek.

going one step slower: back in the time you started the games usually via keyboard. TI Invaders: 1. hit any when color title screen shows up 2. hit "2" key on the keyboard to enter TI Invaders 3. hit the "1" or "2" key on the keyboard to begin the game. 4. now joystick input is read by the game Moon Patrol: 1. hit any when color title screen shows up 2. hit "2" key on the keyboard to enter Moon Patrol 3. hit the "Enter" key on the keyboard to begin the game. 4. after a short intro joystick input is read by the game The TI Joysticks look like this: http://www.ti99.eu/gallery/index.php/Hardware/Joysticks-and-Adapters/DSCF2082

Welcome to the TI-99 world! Although you have two TI Joysticks together at one port, each game usually wants either #1 or #2. So for a particual game only Joystick #1 works, while another wants you to use Joystick #2. Alpha Lock [it's a Key] releasement is important in order to use the "UP"-direction on the Joystick. This is the main bug of the console and can be fixed with a resistor installment on the mainboard/keyboard.

wow, great!

well, the reason I was told why the cyc and pc99 can't be decoupled, that a lot of software/books authors gave their permission to c.a.d.d. that it to be used with pc99 only. but i don't think they have to pay for every sold pc99 license a fee to texas instruments. if you ask me, the bundle restriction doesn't prohibit them to reduce the price of the emulator to 10$ or even give the emulator away for free since it's really made for a legacy OS, and just ask a fair fee for the big amount of work that goes into the cyc. we europeans could try to organize one big order for everyone interested, this way not everyone himself has to pay the bank fee. i think the bank fee is 15-30 euro. I am interested in a cyc update for me. so who else wants to order something from europe?

good to hear, mike wright (and his wife) are still active on cadd electronics. i want to update my cyc dvd as well soon have transfered all pdfs to my 7" nexus tablet last week currently I am concentrating on reading a lot about getting the most out of TI Basic / TI Extended Basic, with CALL PEEK and loading direct values to RAM via CALL LOADs. After 30 years this machine is still so cool!

since there is a C version of v9t9, could it be used to create an iOs App? As far as I know i-Phone/i-Pad Apps are based on objective C. did someone had success to run it the java-v9t9 version on an android system?

got an Atari game cartridge with that connector/Interface from Bernhard L on the last europe ti treffen.. Bernhard bought it on ebay but had no use for it.

Another feedback from my point: I have started to use this XB Compiler for my game development on the weekend and I am very impressed with the quick results. Now I need HUGE delays in XB to make the game not too fast to play! Crazy world! Will use Call Sound for those delays like suggested in the manual. The includable assembler routines "DISPY" and "VWRITE" are really useful! I use them to synchronisly relocate 2 sprites to the next char. Amazing! CALL LOCATE(#1,Y1,X1,#2,Y1,X1+1) was never satisfying sync at least in XB - non compiled. You can see a delay between the first Sprite relocation and the 2nd Sprite relocation. CALL LINK("VWRITE",768,CHR$(Y1)&CHR$(X1),772,CHR$(Y1)&CHR$(X1+1)) does the same but the relocation of both sprites is perfectly in sync, even in XB! It writes directly to the Sprite Description Table of the Video Ram. Call me back into programming With this Compiler XB Game Programming is fun again! The manual is good written, congrats on that! As a sidenote: for a non assembler person it will be heard to understand the usefulness of VWRITE/VREAD. I know it's out of scope to explain all possiblities with direct VRAM writing but maybe a link to a good document on whtech, that deals with that, could be added to the manual. If you wanna make arcade games in XB, go for this!!! A question: I haven't tried it yet, but it is said that multiple CALL SOUND statements will make the compiled code to be just playing the sound until the sound is finished. With this limitation, how do you suggest to get background music to a game that doesn't interfere with game play?

I made an unfinished TI Basic (no XB) version for the Basic On Cartridge Contest called Virus Fever. It always bothered that I didn't finish the game because I ran out of memory and failed at one big algorythm. Here is the former game thread: http://www.atariage.com/forums/topic/174172-virus-fever-bocc-thread/page__hl__+fever?do=findComment&comment=2180206 Now I am trying to recreate and finish the game in XB with 32KB. The new version is still a prototype, all you can do is move/spin the pill and pile them on top of each other

wow! impressive release! my congratulation to finish this. can we (as users) add meta data to the game entries and share these added data with others users?