-
Content Count
3,419 -
Joined
-
Last visited
-
Days Won
3
Posts posted by jedimatt42
-
-
I grew up in the county outside Bremerton WA, USA, near the Puget Sound Naval Shipyard. In 1984, I was 11, and took to the computer like it was the essence of life. My father actually bought the TI to try and get my older brother interested, but that failed, largely because his friends had C64s and they couldn't share. I found one kid at school that had a TI, but when I wrote a game and tried to share it with him, he had no idea how to load a basic program from anything... So, to him it was a cartridge based video game console. I did luck into a neighbor that was interested in programming on the TI. It was one of my friends, older brother's... We wrote a Transformers ( the robot toys ) database. We'd go to the local stores with a notepad, write down all the statistics on the back of the retail packaging ( it had something like a baseball card of stats on it. ) And then go code them into this database, with a little graphics to indicate a thing or two. That was my first joint programming effort, until I ran into the same guy again actually in college.
My father was a smart guy though. We had all of these computer user groups in the Puget Sound area, there was a group for the commodore 8bits, the amigas, the atari 8bits, the atari st folks, the PCs, and the apple II users... So every month my father would drag me down to the Kitsap TI users group. When it started to fail, he took it over. I am the center of the universe, so I'm pretty sure he did all of that to make sure I had support.
My father and I each had our own TI setups. I'm pretty sure, in the end, we were our own user's group. Shortly after I moved out, he retired his Geneve setup.
I've gotta say "Thanks Dad!" Not that he'll ever read this. I should probably get off the computer and call him
I really enjoy hearing how Opry99er, and Buck are building a relationship that involves the TI, as well as Ksarul and his boys... That's pretty cool!
-
3
-
-
It is hinkey, but I've always had good success just taking the twisted PC cable, and untwisting, then squeezing it all back together with my hands... I'm all for the right tool for the right job though...
This search works well on amazon: 34 pin ribbon cable
lots of options that will work quite well.
-
Sweet! That ties the explanations about sprites and COINCALL back to reality for me.
Thanks again for the help... I was able to work around each of those issues, and get the first basic game I ever wrote, ported to fbForth. That was a great exercise for me. Now I can learn some tricks like multi-layered sprites, and many others, to make it into the game I want it to be. ( The American Grand Prix is tomorrow, hopefully that will be inspiring - if the rain stops )
I believe I saw automotion appear to mutate character definitions after switching to TEXT ( 40 column ) mode as well. I didn't think of this as a bug at the time, as it is so easy to do something like create a word say, 'DEVMODE' that stops motion and sets the text mode I want... And I couldn't particularly tell how much initialization the mode commands intend to be responsible for.
As for Ω's concern about an obsoleted printed manual, it would be great to get the added resident words in as an Addendum PDF. I like my reference material in physical form too, mostly so I can step away from the desk when I'm studying. https://goo.gl/photos/56AM8opJVGbGBbHX9 <-- There is a picture of my fbForth spiral bound book.
-
1
-
-
'Tis, indeed, the same buggy code, but in a different place.
To clarify, as I see the code, the sprite with the first motion vectors should move in the same direction as one set with252 255 0 MOTION
that is, it should move in a west-by-northwest direction (1 up for every 4 left). Is that the case?
...lee
Yep, that is the case. 1 up for every 4 left.
Does forth have a signed-int16 to signed-byte conversion word? It seems that you are trying to take care of that in words that expect signed bytes, but numbers on the stack are always treated as int16. The JOYST routine through me for a loop too... The output vectors are signed bytes ( -4 is represented as 252 ) so it quite naturally fed the inputs of the MOTION word, until I tried to multiply the value. You could probably teach us about some conversion words that would be handy in these situations.
-
While working on the above sprite explanations, I discovered a bug in the code for SPRPUT which is also used by SPRITE . The bug causes the x coordinate of a sprite to be decremented if the y coordinate input is 0! I will fix it in the imminent release of fbForth 2.0:3
...lee
Maybe this is related? When I use decimal negative number for x motion vector, the sprite moves up the screen.
-4 0 0 MOTION
where I only expect my sprite to move to the left? But the following moves to the left just fine.
252 0 0 MOTION
-
It is not horrible at all. I just wanted to point out the convenience of an existing word. TurboForth has a word similar to yours that you can easily use in fbForth. Its definition is
: THRU ( start-block end-block -- ) 1+ SWAP DO I LOAD LOOP ;
CLOAD (conditional load) is a good word to keep in mind. CLOAD allows you to avoid loading requested blocks or prerequisite blocks if they have already been loaded. Check the manual for more.
...lee
The next block word turns out to be very nice. With my LOADALL, or THRU, a typical code-test cycle would have me FORGET my first word in block 1, and then perform a 1 LOAD, which would call LOADALL. If I wanted to go faster, but was changing something on block 5, I'd FORGET the first word on that block, and then 5 LOAD 6 LOAD... But by using '-->' at the end of each block that continues on to the next, I can FORGET and then load the lowest block that was edited, and the rest follow. Very cool.
-
Sprite patterns should not have anything to do with collision unless they are associated with a sprite. The only reason I can contrive for the behavior you see is not using a lower-numbered sprite. Anytime you define a sprite in fbForth, all lower-numbered sprites are checked for whether they have been marked as undefined with their y coordinates set to >D0. If that is the case their y coordinates are set to >C0 (192). The effect of this immediately after invoking GRAPHICS and DELALL , is that all previously undefined sprites will be defined as though by
0 192 0 0 0 SPRITE
Their motion vectors will also each be 0. With the magnification factor set to 2, character patterns 0 3 are, indeed, associated with each of those previously undefined sprites. I checked the collision bit with overlapping, off-screen sprites and it was not set, contrary to the E/A Manual, so I am puzzled. It certainly could be a bug in fbForth. If we find any such bugs, they will not survive!

...lee
So could this have been caused by my starting with sprite number 1, instead of 0. ? I started this project by coding some XB, and then I'm porting that to practice forth. I'll run that experiment when I get home.
Your code has no doubt changed, so I won't get too much into it, yet. Just a couple of comments. The conventional way to show stack effects in Forth is to separate stack entries with spaces, which would change
: .AT ( X,Y -- ) SWAP 32 * + CURPOS ! ;
to
: .AT ( X Y -- ) SWAP 32 * + CURPOS ! ;
Also, with Y on the top of the stack (rightmost item), your code should be
: .AT ( X Y -- ) 32 * + CURPOS ! ;
But, there is already a resident word with a more generalized form of this definition. It is actually written in ALC; but, here is the equivalent high-level Forth:
: GOTOXY ( X Y -- ) SCRN_WIDTH @ * + SCRN_START @ + CURPOS ! ;
Of course, it could be that your stack effects are backwards, in which case
: .AT ( Y X -- ) SWAP 32 * + CURPOS ! ;
could be written
: .AT ( Y X -- ) SWAP GOTOXY ;
...lee
I love the feedback. Is it acceptable to follow a pattern of no stack effects if there should be none?
And thanks for the pointer to GOTOXY, my implementation of .AT was going to get me in trouble, and wasn't working right anyway

Perhaps you know this: You can load successive blocks with --> as the last word on each block except, of course, the final block. That way, the blocks can start anywhere without needing to redefine a word like LOADALL .
...lee
I did not know this. I was wondering how horrible it was for me to do what I was doing loading several blocks... What are some best practices in this area? Multiple block management seems like it will get complicated soon.
A note on joystick use
There is no need to worry about JMODE if you are not using JOYST for joystick action. It has no effect on normal keyboard use. It only affects which word, JKBD or JCRU , JOYST invokes when it is executed. The reason I set things up this way is to remain compatible with TI Forth while also allowing monitoring joystick action through the CRU if that was the programmer's desire. You are using JCRU directly, so setting JMODE is superfluous.
...lee
I like to initialize properly as much as I can, and intended to migrate to JOYST so keyboard support would be for free, but I started with JCRU cause I was being lazy first.
There are a couple of problems I see with game play. With the first crash, the game is over because the sprites are still overlapping when the game continues. All the lives are gone before the colliding cars are free of each other. Resetting the cars to initial positions after each crash would mitigate this. If you don't want to reset to the initial positions, you will need to add at least the length of a car to all the car positions because you don't really know which car hit you. Actually, you could figure it out by stopping motion after a crash, reading the position of each car with SPRGET or COINC , moving the colliding enemy car beyond you and only then restarting motion.
...lee
Gameplay is horrible
In the XB version I wrote in '84 after a crash, it just resets, and keeps looping... no scoring or anything game-ish. So I was trying to port that first, before making it better. Hopefully I'll make it a lot better. I have actually updated it to reset to initial positions, cause that is what my childhood version did 
All the help is massively appreciated, and I love the feedback. Thanks so much!
-
What kind of battery life do you get out of the CR2032 powering the SRAM on the HDX DSR board?
I know I've seen pictures of nicely placed switches to power off that SRAM when it gets corrupted. I've been experiencing that corruption preventing boot regularly, so I just pulled the battery, and just have to reload each session. I'm sure I'll tire of that and wire a good switch in copying Ω's disk drive drawer technique...
But in the meantime, what has your experience been with battery life?
-
That was it... DELALL sets all the sprites patterns to 0, but with my magnified sprites, some magic invisible sprites are tripping the COINCALL. So I defined character patterns 0 - 3, to all 0000s, and COINCALL behaved as I would expect.
I still feel like that means I'm not initializing the unused sprites correctly... Now I read a little further in the Lee Stewart book, and it suggests I should move the sprite pattern table so it doesn't overlap with the normal pattern table in Graphics mode... Would that have saved me this issue? or would I still have to have made sure that sprite pattern 0 - 3 is all zeros?
-
Ok, I've found that my sprite numbering is off... I've straightened that out... so now I have sprites 0 the driver, and 1 through 7 the cars. and I'm supposed to use 7 + 1 for the #MOTION... so that wasn't the problem...
It is the CONTROL word in block 5 that is confusing me. COINCALL is just returning -1 all the time, which as a flag is true.
Do I need to redefine characters 0 - 3 since I'm in '2 magnify' mode?
-
Ok, I am performing GRAPHICS, then DELALL, then creating a driver sprite, and 7 rival sprites.
This code currently, experiences coincidence immediately in the 'CONTROL' loop and terminates. But if I change block 5 word SHOWLIVES to end with "30 22 .at", then things loop around. I think I just spotted my error, block 4... Do loop end values are not inclusive, so I'm looping from 2 to 9 to create the enemie cars, which creates sprites 2 through 8. but then I set 9 in motion... which should probably be 8... ?
## BLOCK: 1 ( TITLE SCREEN ) : .AT ( X,Y -- ) SWAP 32 * + CURPOS ! ; : ALLCOLOR ( F,B -- ) DUP SCREEN 15 0 DO OVER OVER I COLOR LOOP DROP DROP ; : TITLE GRAPHICS 1 13 ALLCOLOR 5 7 .AT ." FORMULA-TI RACING" 9 8 .AT ." MATTHEW SPLETT" 10 11 .AT ." 1984,2015" 20 6 .AT ." PRESS FIRE TO BEGIN" ; : WAITFIRE BEGIN 1 JCRU 1 = UNTIL ; ( LOAD OTHER BLOCKS ) : LOADALL 7 2 DO I LOAD LOOP ; LOADALL ## BLOCK: 2 ( CAR PATTERNS) BASE->R HEX : RACECAR 03C7 CFFF CFCC 0B0B 68 SPCHAR 0B0B 0FCF CFFF C7C4 69 SPCHAR C0E3 F3FF F333 D0D0 6A SPCHAR D0D0 F0F3 F3FF E323 6B SPCHAR ; : CURBS FBF5 FBF5 FBF5 FBF5 6C CHAR DFAF DFAF DFAF DFAF 6D CHAR ; R->BASE ## BLOCK: 3 ( DRAW TRACK ) : DRAWTRACK CLS CURBS 1 15 ALLCOLOR 5 0 24 108 VCHAR 25 0 24 109 VCHAR ; ## BLOCK: 4 ( ADD SPRITES ) : SPRSETUP DELALL 2 MAGNIFY ; : DRIVER 121 160 13 104 1 SPRITE ; : RNDSPEED ( --n ) 10 RND 3 + ; : ENEMIES 9 2 DO 17 I 20 * + 9 I 3 + 104 I SPRITE 0 RNDSPEED I MOTION LOOP 9 #MOTION ; : GOCARS RANDOMIZE SPRSETUP RACECAR DRIVER ENEMIES ; ## BLOCK: 5 ( CONTROL LOOP ) 5 VARIABLE LIVES : SHOWLIVES 2 2 .AT LIVES @ . ; : CRASH -1 LIVES +! SHOWLIVES ; : CONTROL 0 JMODE ! 5 LIVES ! SHOWLIVES BEGIN COINCALL IF CRASH ENDIF LIVES @ 1 < UNTIL ; ## BLOCK: 6 ( LAUNCH GAME ) : DEVMODE 0 #MOTION TEXT ; : GAME TITLE WAITFIRE DRAWTRACK GOCARS CONTROL DEVMODE ; ." Enter GAME to begin."
( I wrote a little groovy/java code to create this block dump )
-
Also, COINCALL doesn't behave like I would expect. Is the cursor a sprite? do I need to disable it? I suspect this because I have repeating overlapping sprites with motion going on, and the collisions are almost never detected. But when I started printing out the flag from COINCALL, quite lazily with just a 'DUP .', then I started getting lots of collisions detected even through my intended sprites were not in collisions at the time.
If I move the cursor by doing something like 32 8 * 23 + CURPOS ! then that issue goes away, but doing that seems really fishy.
-
Are there already tools that list blocks in fbForth to DV80 files? I could probably do something with 'sed' on the ?windows? box hosting my hdx drive, but wondered if there was already something out there... I saw the thread on using Intellij for editing forth files, which would imply moving the code to and from pc text files...
I want to be able to commit any of my code to git in a reasonable manner, while actually using the TI for as much of the workflow as is reasonable.
-
http://www.copyright.gov/title17/
The software industry has been doing unnecessary things around copyright for so long, that despite what the law says, it is becoming necessary.
Regarding the Atariage bit... Does this website claim copyright over any works posted here?
-
This all caused me to buy a CC-40, just cause they are available. I actually brought one of those with me to school everyday my senior year in high school. It was my first mobile device..
Back then I taught it how to do all the hard work for my physics class. I didn't go to any dances
The fun part was it arrived, and I got to try and explain why I wanted it to my wife... -
1
-
-
Now you can breach the subject of internet security, identity theft, and privacy...
-
2
-
-
Did you stop by my Booth?
Greg
I looked for ya, but didn't spot you...maybe I left too early...
-
Oh, and I wouldn't recycle them just yet.
I was out at PRGE today, and something was very clear. Cartridges survive. Someday after the internet apocalypse, these systems that use solid state software, will still have software being traded.
I saw about 1 shoebox of Atari 8 bit cartridges, enough 2600 cartridges to drown in. And of course tons of various generations of nintendo and sega cartridge wars.
CD's were still being traded, although consumers were taking the precautions of checking for scratches.
But magnetic media didn't last.
Oh, I saw one 4A black and silver for sale, and one 4A beige for sale. Very little in the way of classic computing, even though those systems sank or swam by their game titles (that last part is just my uneducated opinion)
Anyway, it doesn't seem right to recycle our cartridge innards for scrap metal just yet.
I remember as a kid, I found a bare 2600 cartridge board in the street. It had been run over, and was muddy. I cleaned it up, and plugged it in, and was shocked then, that it worked. I don't think I ever knew what that game was called, as it didn't have a title screen.
-
1
-
-
That is crazy impressive recognition!
I thought those chips looked familiar myself. I've only only stolen shells from 2 carts, and didn't remember what they were. Plugged it in, and sure enough that was it.
Looking at grom only boards, TI impresses me. Those groms seemed like such a strange thing to do. But the proprietary chip simplifies the boards so much.
I have one other board bare... 4 groms: CD2020ANL, CD2021ANL, CD2022NL, CD2023NL, with rom CN19310N
Anyone recognize that?
-
Ok, nevermind about the 'redo' suggestion... The fire button works just fine there. I think you mentioned that somewhere already.
-
1
-
-
I got 1150 before dying on the bat.
TheMole, this is really great! Playing on my little TI. It makes me soo happy.
The the new .bin burnt nicely and works on my little old TI video chip.
For more than a decade, I've played around with retro emulation (as a user). I've been aware of Alex Kidd by name, but never gave it a go.
Now the TI can feel some of that platformer love.. The outlines on the main character and dangerous enemies look great. It makes them pop. I get a little sprite ghosting I think when I get to close to the first scorpion, and punch. But given the layered sprites, it doesn't create playability issues like say, burgertime... where invisible pickles kill you.
This is truly great!
1 thing would be cool ( if this isn't just cause I have my keyboard all 'in-progress' ) if you implemented REDO after the RIP screen
That would be useful.Having a platformy game like this on the TI... I never imagined... It makes me so happy to see on my real iron! My wife must think I'm crazy.
-
3
-
-
Confirmed, I have no F18A.
-
I burned the .bin, but get scrambled graphics similiar, but different to OLD CS1. So I verified that my chip and the bin inside the .rpk, and and the alexkidd8.bin are indeed all the same.
-
Nevermind, when I scrolled through the image with more care, I see the rom headers at 0x07E000... Thanks!

HDX time...
in TI-99/4A Computers
Posted
Is there any reason that the HDX DSR board can't just be a couple eproms? Does it use the RAM at runtime for buffers?