FarmerPotato

Heh heh. I have been playing Chisholm Trail off and on each day! I have not got more than 3 "days" and a high score of about 10000 . Not my month to be a contender!

As the owner of that TI-99/4 monitor and the 99/4 console used in the magazine, I swear that Retro Gamer photoshopped that together. Radically. The table was white and there was stuff in the background. It's possible that the 99/4 monitor screen image did not photo well, so they just photoshopped a Parsec image onto it. As Marty stated here, conditions were far from ideal. I was setting up exhibits when the request came in: Retro Gamer wanted a 99/4A photo shoot. And Marty had 1 week to write up an article. I had a work deadline right after the show, so I pointed him at Orphan Chronicles and Bill Gaskill's TImeline. I was not shown any of the article in progress. Oh well.

I think it is a simple buffer overrun. One edit buffer for the current room holds 3 objects, but when you leave the room, it goes into storage for the room. There's not room for the 3 objects in the storage, but it still says there are 3, so when you come back it copies some memory from past the end of storage. My game AdventureQuest (unreleased) had a save file with sectors of 192 bytes of 6-bit tiles (arranged in 16x16) + a monster and item storage in the remaining 64 bytes. When the sector is in use, the 64 byte object list is unpacked into working memory. When the sector goes out of use, the list gets re-packed. I spent a lot of time ensuring that it would always retain its integrity when copied back to that 64 byte buffer. Because I didn't want the bug that TOD had. (it was actually a nested list.. each object in it was "Duck Typed" by a list of key-value pairs, and value could itself be a list.) This was built to allow for more weird corner cases than I could think of! If this structure had been damaged it would have been interesting.)

At least one bug where you get a glitched item was described in 99'er or Micropendium. I read about it and used it in 1985. I think it goes, when you find a scroll or more items in a room, refuse them, then drop your armor or weapon there. Leave and re-enter. I seem to recall any 3 items left in a room produce a glitched item. A glitched item will have a name of "0" and an attack parameter of 32. You can drop a sling into this bubbling cauldron and get back a ranged weapon titled 0(32). The 0(32) persists in saved games. The name 0(32) was an in-joke among my friends. It sounded like escalating from plain old Sword, +1, directly to M-1 tank or an F-18 fighter. Bonus points to the person who looks at the GPL and explains the bug!

in a TI sound list, termination is indicated by a 0 duration, but looping is indicated by a 0 length byte, followed by 2 bytes of address. Parsec sound list sample: SNDVDP EQU >3800 START ADDRESS OF VDP SOUND LIST LOOPHB EQU >38 SOUND LOOP HIGH BYTE ADDRESS LOOPLB EQU >00 SOUND LOOP LOW BYTE ADDRESS ******************************************** * SOUND LISTS - PARSEC * ******************************************** SHPSND BYTE 4,>DF,>FF,>93,>B3,1 FREQ TRICK SOUND BYTE 4,>80,>3F,>AE,>3E,60 BYTE 0,LOOPHB,LOOPLB OFFSND BYTE 4,>9F,>BF,>DF,>FF,0 ALL GENERATORS OFF SLWSND BYTE 5,>9F,>BF,>DF,>FC,>E7,1 SLOW SHIP FIRE BYTE 2,>C2,>05,30 BYTE 0,LOOPHB,LOOPLB FSTSND BYTE 5,>9F,>BF,>DF,>F6,>E7,1 FAST SHIP FIRE BYTE 2,>C2,>05,30 BYTE 0,LOOPHB,LOOPLB EXPSND BYTE 7,>9F,>BF,>DF,>E7,>F0,>C0,>07,5 EXPLOSION BYTE 1,>F1,6 BYTE 1,>F2,7 BYTE 1,>F3,8 BYTE 1,>F4,9 BYTE 1,>F5,10 BYTE 1,>F6,11 BYTE 1,>F7,12 BYTE 1,>F8,13 BYTE 1,>F9,14 BYTE 1,>FA,15 BYTE 1,>FB,16 BYTE 1,>FC,17 BYTE 1,>FD,18 BYTE 1,>FE,30 BYTE 1,>FF,0 FIRSND BYTE 4,>9A,>BF,>DF,>FF,1 LASER SHOT BYTE 3,>80,>0A,>98,1 BYTE 3,>80,>0C,>96,1 BYTE 3,>80,>10,>94,1 BYTE 3,>80,>14,>92,1 BYTE 3,>80,>18,>90,1 BYTE 3,>80,>1C,>92,1 HB20 EQU $+2 BYTE 3,>80,>20,>94,1 BYTE 3,>80,>28,>96,1 BYTE 3,>80,>30,>98,1 BYTE 3,>80,>38,>9A,1 BYTE 3,>80,>3E,>9C,1 BYTE 1,>9F,0

Yup. I checked the latest version, same behavior. I need to message Fred.

I second your prize motion! Yeah it's pretty far from a dusty cattle drive through Texas to the railhead at Abilene, Kansas. The converging cattle drive routes were called the Chisholm Trail. The way I see it, you camp each night with your 16 cows in a perfectly square herd. Square cows. They wander off one at a time when you're not standing guard on the herd. You have to track them down and lasso them with bullets. Their actual fate would be a bullet in the head at the slaughterhouse in Chicago, but the game gets it done early. Meanwhile, mutant rattlesnakes with lasers of vengeance approximate the risk of stepping on a rattlesnake in the brush. Each day, a new cowboy joins you to replace the attrition. At the title screen of the game, the blinking dot of attention-grabbing represents TI CEO J. Fred Bucy, who wants TI to invest lots of money in Lubbock, Texas. Lubbock was not on the Chisholm Trail. This is the rare appearance in a TI game of an actual employee. After he was forced out in 1985, J. Fred Bucy no doubt continued to haunt the wide hallways of TI as a bouncing 8-bit circle going "Weep, weep", that is when he was not busy sailing his yacht in the Gulf of Mexico. Shift 8-3-8 on the title screen represents the ability that all Chisholm Trail cowboys had to utilize an underground warp network to bypass the boring parts of the cattle drive. Chisholm Trail.. what a weird and semi-lovable game on our platform.

Because that takes hardware (probably an FPGA), not just more software in a DSR. It's not a bad idea (software compatibility!) it just takes resources to emulate the RS232 interface which is a bunch of CRU bit setting and reading. Or some extra cables to go from your real RS232 card around to the USB port.. hmm... If I were designing a little sidecar thingy, I, too, would want to be able to talk to it using Telco, or a trivial FORTH program for terminal I/O. But it takes resources...

I would get REVIEW MODULE LIBRARY sometimes when yanking out a cartridge. To me it was part of the mystery and wonder of exploring what was in there... having seen a GRAM device running Parsec at a TI employee bowling league night. All I could do with what I had was to yank out cartridges while they were running to see what would happen. One lucky occurrence was when Car Wars, interrupted, dropped into the 99/4 BASIC interpreter with all the car crash sprites still moving on screen. To this day I am still afraid of the number 32767, since it usually heralded memory corruption and imminent bad behavior. Except after a RESEQUENCE, which normally does that with unknown line numbers. Still freaked me out. I still don't do anything with GROM other than transferring the character set from GROM to VDP.

I'm using cfhdxs1 to avoid moving my CF card back and forth, so I needed a v9t9 file. So, I will go directly to v9t9 file with your example, xdm99.py -T program.img --ti-name -9 Here's what I hit on that worked, it's more steps: ../xdt99/xdm99.py work.dsk --initialize 720 -n G2 ../xdt99/xdm99.py work.dsk -a g2.obj -f DF80 hdxcfs can't send a whole dsk, so I extract the file in v9t9 format again: ../xdt99/xdm99.py work.dsk -9 -e G2 -o ../mount/G2 HFE/Gotek is in my near future.

Hi Ralph, I've been using xdt99 a lot recently. Thanks for making this great set of tools. Could you perhaps give some background on how you move DF80 object files to real iron? TI99Dir expects DOS files including DF80 to have line breaks. Tursi made them work in Classic99 for EA. It took me a while to figure out how to transfer xas99 object files to real iron. Thread here: http://atariage.com/forums/topic/288360-how-to-move-disfix-80-through-hdx-as-files/

Alright, sorting out my own problem. xas99 produces one very long line of 80 character records. I only thought it had line breaks because "more" shows it properly on my 80 column window. g2.obj So ti99dir is confused by this. I think it reads up to 256 bytes with no newline, then breaks that into 4 DF80 records, then reads another 256 bytes, makes 4 records... Classic99 guesses the file format in TIAD mode when providing it to EA3 Load and Run, so I never noticed an issue there. However, from BASIC, Classic99 behaves badly, resulting in this undefined error: So I use xdm99: ../xdt99/xdm99.py work.dsk --initialize 720 -n G2 ../xdt99/xdm99.py work.dsk -a g2.obj -f DF80 hdxcfs can't send a whole dsk, so I extract the file in v9t9 format again: ../xdt99/xdm99.py work.dsk -9 -e G2 -o ../mount/G2 where 'mount' is the Ti99HDX files directory. After this, I am able to transfer the file with CFHDXS1 and run it! Hooray!

Wow, there were some really harsh comments in this thread from three years ago. As Marty pointed out, 3 years ago, all of the hardware was mine, and other conditions of production were not ideal. I guess I have to ask myself, is my hardware in that bad of shape? I'm sitting here working on the beige console that was there. It has an F18A in it, which travels with me, a bare-board FlashRom, and was running Mario Bros the night the photos were taken, just maybe not at that moment.

When TI99Dir (v6.3a 20171101) converts the file it has these bytes for a header: (little endian) >0000 3247 2020 2020 2020 2020 0000 0300 1a00 'G2 ' 5050 004c 0000 ... Not TIFILES.. I guess it's V9t9? TI99Dir identifies it as v9. DIS/FIX 80 >0080 (sector 1) 80 bytes of tagged object code ending in '0001' 80 bytes of tagged object code ending in '0002' 80 bytes of tagged object code ending in '0003' 16 bytes of 0 so far so good. The last 4 characters of each record should be a consecutive line number. >180 (sector 2) 'A003EB06A0C0010' nul nul nul ... offset 80 (decimal. Start of where 2nd record would be.) 64 bytes 'B04C0B0201BD000B ...' line ending in ' 000' Considering what I read from TI BASIC, every 4th line is mangled with just 16 bytes of data, followed by an unnaturally short 64 character line.

Coincidentally, I've recall driving through there (Waterloo, IA is what his eBay address says) going from Council Bluffs IA to the SPAM museum in Austin, MN. It's close to Des Moines, I-35, I-80, and I-90 which makes some sense as a distribution center. That area is chock full of Roadside America. The SPAM museum is really worth a stop, totally fun. Disclaimer: I also found the Great Twine Ball of Minnesota highly amusing, and seen the albino squirrels. Weird Al soundtrack all the way. Your mileage may vary.

I'm stuck. I just got HDX working for the first time. Yeah coming out of the stone age. Using some seriously amazing software from Fred Kaal. I'm trying to move a DIS/FIX 80 file. On my PC it is written by xdt99 (oh yeah, the modern world is amazing) The PC has a text file with CRLF line endings. I converted it with TI99Dir to TIFILES format. I tell it it is a DIS/FIX 80 file. I told it to remove CRLF at the same time. TI99Dir produces this format: 128 bytes of TIFILES header 256 bytes organized as: 80 bytes, space filled, 3 times. 16 bytes of zeros. repeat I drop the file in the HDX files directory and transfer it to the 4A using CFHDXS1 (nanoPeb version). E/A3 says "Illegal Tag". When I look at the file it has a 4th line between every 3. 10 OPEN #1:"DSK1.G2",INPUT,DISPLAY,FIXED 80 20 INPUT #1:A$ 30 PRINT A$ 40 GOTO 20 Every 4th line looks like an object record truncated to 16 bytes. Something similarly bad happens when I transfer my EA5 version. However, I was able to transfer 'CANFIELD' from the 4k game contest alright and run it. I'm just stuck at this point. Probably try the same dumb things over and over looking for options I missed, while surrounded by screaming kids. Can anyone help me with the HDX part of my problem?

I haven't touched it since 1987. I just found my disk though. It has some 8-bit samples I downloaded from CompuServe and converted to 4 bit without knowing that I should use a logarithmic scale. "My god its full of stars" and a TOS phaser sound. Barry Boone came up with the same technique, and published it, so I moved on. I also had a program that would draw '*' when the cassette input was 1, and I experimented with filling the screen over and over just to see what patterns it might make. Totally ignorant about what to do next. The real value to me? I spent a summer reading the E/A manual and asking myself 'what can I do with this info?' on every page. The world is so much more complicated today. I don't want to get distracted by sound just when I've spent two weeks doing bitmap graphics routines.. I have a 24 bit I2S DAC hooked up to my 4A that I have to get back to... so many projects...

Thanks for correcting me on that. I think I heard the Perfect Push sample on a disk with BUSHCNN and others for sound chip playback, so I thought it was done that way in the game.

Perfect Push utilized the sound chip output. It's possible to set the sound chip to the highest frequency and change the amplitude. There are 16 possible amplitude levels, and you can process an 8-bit sample to a best fit, and play it back. It's not a tremendous fit, but it was pretty exciting to break through that limitation in 1986. with the sound chip, you can do better by mixing 3 channels of that trick. There is another trick I found on the Intellivision forum that rapidly changes the square wave frequency. They have decomposed the sample onto square wave basis functions, and select the 3 highest coefficients per playback sample period. Here is that thread: http://atariage.com/forums/topic/260647-sound-synthesis-with-square-waves/page-2?hl=fm%20synth Sky Jaguar Speech 2 plays samples in game on 3 square waves. PSG is the AY-8910 chip. This one I think requires an expansion hardware to add 5 SCC sine waves?

Computer game AI is one area I never had a clue about. I've spent a day thinking about it and actually dreamed I was playing Stratego (and losing). Thanks for posting this info.

I have got the fast rectangle fill working. It's kind of spaghetti at this point and I am inspired to do a rewrite from the beginning. g2 is the test driver and filare.a99 is the routine and subroutines. I did not test all the corner cases yet. If the rewrite doesn't pan out I'll call this version 1 and get it under a C interface. EDIT 2/19/2019: files replaced, with corner case bugs fixed. There are some logic errors where the right edge is +1 pixel, but no crashes. No color. Still needs a rewrite. This is still just a first draft. g2.a99 filare.a99 g2.obj

I bought the Wico joysticks from him, at the same time that arcadeshopper ran out of them. Same price. I'm pleased with that.

Price for the original working Speak and Spell with round buttons has been around $70 for decades. There is a demand for it among circuit benders. The Austin synth shop "Switched On" had a circuit-bent Speak and Spell on sale, last time I was in there. I am always buying TI learning toys, but I am going to buy more now in case demand goes up. I remember the last batch of Compact Speak and Spell going for $5 at Odd Lots in 1994, but I already had a few so I passed them up.

no It's definitely CALL SAY 100 CALL SAY("") this gets the problem out in the open. I tried to make it run under Extended Basic with the following changes: (all with Classic99) 210 FOR J=96 TO 136 STEP 8 27130 IF K<144 THEN CALL CHAR(K,W$) 32140 IF K<15 THEN CALL COLOR(K,L,M) This prevents the BAD VALUE due to the chars 144-159 not available in XB, at the cost of missing graphics. However, I still get BAD VALUE IN 14210 14210 CALL SAY("", W$) W$ is the following chars of LPC data: FOR I=1 TO LEN(W$) :: PRINT ASC(SEG$(W$,I,1); :: NEXT I 96 0 81 162 164 165 74 36 44 233 210 150 182 244 69 137 121 170 87 144 196 45 18 251 203 132 213 158 200 134 31 85 207 114 163 147 218 121 110 158 141 78 109 111 90 68 69 25 181 189 145 81 99 123 212 110 89 69 175 99 4 216 214 138 128 224 199 1 20 48 114 183 2 230 188 177 128 6 28 208 230 181 5 30 160 At this point I give up. I'm not aware of a reason why the XB interface with raw speech input to CALL SAY is different than Speech Editor? I would try it on real hardware. Are there cartridges besides Speech Editor that provide CALL SAY to TI BASIC?