majestyx

I downloaded this and played it in o2em since I don't have a real Odyssey (and have also been trying to get as many O2 & Videopac games to play in RetroPie) and think it's a pretty cute concept. Reminds me a bit of Atari Adventure with a bit of Smurf Rescue thrown in. I'm guessing there are only a few actual programmed screens since I kept going to the right for about 20 screens after encountering the large P and saw nothing new. Hope you eventually go back to this. Maybe you can come up with something like what David Crane did for Pitfall! with a polynomial counter so that you can get the machine to generate the screens instead of having to program each one. Anyway, thanks for all the cool Homebrews you've developed for this platform!

Kinda like a (bad) cure looking for a disease.

Go back to the previous page and see the discussion which starts here: http://atariage.com/forums/topic/240800-coolcv-emulator-for-mac-os-x-linux-windows-and-raspberry/page-19?do=findComment&comment=3906168 It's apparently due to the XBOX 360's d-pad being mapped as axes 4 & 5 which don't seem to be read within coolcv.

Based just on the condition of the box in that listing, it appears that the box at the very least had some major water damage. That being said, everything else looks pretty mint, including the manuals. Should you open up the computer itself, let us know how it looks on the inside.

I received an email from them (Atari) with a link to the IndieGoGo site which tells me exactly as much as I knew before about what it is they want me to fund... which is something that looks somewhat similar to a late 70's wood-grain home video game system with an Atari logo but without a cartridge slot, switches or joysticks. Is that 21 second youtube video supposed to be the clincher?

I posted this in the other RPi subject (PiPlay) here: http://atariage.com/forums/topic/271054-piplay-and-attracting-new-blood/ ...but figured it was worth posting here as well. ----- Before I try to get this running in RetroPie, I just have to ask - does this implementation support diskettes or is this meant just to play cartridges? I understand that TI-99/Sim run from a command line (i.e not launching through emulation station) can do this, but I'm not sure I see how you could play a game like Tunnels of Doom or Adventure without the diskette images that go along with them. Since there is no GUI, there appears to be no way of changing diskettes on the fly either such as in Classic99. I'm just debating whether it's worth the effort to run this through RetroPie if diskettes are not usable and instead just stick with my Windows based emulators.

So before I try to get this running in RetroPie, I just have to ask - does this implementation support diskettes or is this meant just to play cartridges? I understand that TI-99/Sim run from a command line (i.e not launching through emulation station) can do this, but I'm not sure I see how you could play a game like Tunnels of Doom or Adventure without the diskette images that go along with them. Since there is no GUI, there appears to be no way of changing diskettes on the fly either such as in Classic99. I'm just debating whether it's worth the effort to run this through RetroPie or just stick with my Windows based emulators.

Ah, thanks for that. F7 does indeed now work on the RPi, so thanks for the explanation on that. Unfortunately, coolcv_pi isn't reading the 4 & 5 axes. It reads all the buttons, the two analog sticks which are axes 0-3, but it reads nothing when pressing the d-pad. The program jstest does read them and shows them as I explained previously, which is the only reason I figured out what they were. Looks like I'll need to get a different controller. Thanks again for your help!

Thanks for the explanation. I attempted to use your suggested addition to the coolcv_mapping.txt file but this apparently wasn't yet implemented in 0.6.2 since those lines got deleted. So it looks like I'll need to wait until the RetroPie install gets updated. I have no idea who takes care of that and I'm not sure how to update the current installation. I tried simply copying the coolcv_pi file from the 0.6.6. zip file here at AA to the RetroPie directory where that file is located, but after I did that, the program would not launch at all, dumping me back to the ROM select screen in emulation station.

Okay, it appears the problem is that RetroPie isn't downloading the latest version. The version it grabs is v0.6.2. Maybe we're talking about two different things - a RPi running RetroPie (my setup) while others may be using it as a stand-alone program. I see in the what's new file for 0.6.2 it does state that the RPi version shows status messages (including the key codes shown by F7), but I see absolutely no status messages anywhere. The results I get with jstest are in my first post: http://atariage.com/forums/topic/240800-coolcv-emulator-for-mac-os-x-linux-windows-and-raspberry/page-19?do=findComment&comment=3906168 ...but maybe I didn't explain it clearly. So I'll try again. You mention something about a joystick axis above. Is there a way to choose the axis? Because the XBOX 360's d-pad is mapped to axis 4 (Hat0X) for left & right and axis 5 (Hat0Y) for up & down. The directions do not correspond to any KEYS but instead if, for example, UP is pressed on the d-pad, axis 5's value changes from 0 to -32767. If I press the d-pad to the right, axis 4's value changes from 0 to 32767. My guess is there isn't a way to choose this. If there isn't, then I understand that it's an issue with the controller and I wouldn't expect you to go out of your way to program specifically for the XBOX 360 controller. But what I'm not clear on is how the joystick is mapped to the ANALOG axis. The analog stick acts as the joystick, which is strange since the Coleco controller is digital (on/off as opposed to a value between -32767 and 32767). There are no options in the coolcv_mapping.txt that correspond to the analog stick (up, down, right, left are mapped to the keyboard arrow keys only in the mapping file) so I am guessing that is hard-coded into the emulator. If the analog stick worked better, I wouldn't be complaining, but just try to play Donkey Kong with it and see how far you get. And so that I don't sound like an ingrate, I'd like to thank you immensely for the time and effort you've put into this emulator. It's so cool to see the machine I loved as a teenager on my modern HD screen!

If it works, I'm not sure what you're doing that I'm not since it's not working for me. Pressing F7 does nothing. And I've already explained above that I've used jstest and reported what I'm getting in that post. How do I map those results?

Does F7 work on the RPi? I swear I had pressed it but nothing happened. I was expecting some sort of status message on the screen to display. Do I need to HOLD F7 while pressing a button or direction on the joypad? I'll try this when I get home later tonight.

Has anyone been able to figure out how to map an Xbox 360 d-pad to use as joystick 1 instead of the analog left stick (axis 0 and 1)? The d-pad in jstest displays the d-pad as axis 4 (left/right) and 5 (up/down) which correspond to Hat0X and Hat0Y. The values correspond to -32767, 0, 32767 (left & up, not pressed, right & down). Is this something that is hard-coded into CoolCV or can it be added to the coolcv_mapping.txt file? If so, what are the values that need to be entered? The analog stick is even worse than the original CV controller! Thanks to anyone who can help.

Yes indeed regarding the cassette port. When I was in 9th grade (1983), a buddy of mine made what you described for our TI-99/4As out of $5 in Radio Shack parts. We would use that to send each other programs over the phone... for no other reason than it was cool to do!

Sorry to interrupt all this tech talk, but I am really happy to see that some exciting developments are being made for this machine. I bought one awhile back and was a bit disappointed (although not surprised) to find that it really needs more accessories to have it be all that useful and fun. Can't wait until a multicart, RAM expansion cart and a true storage device are available for it. Thanks to all who are working on this project~!

Shout Factory recently added the early 80s show Starcade to their online streaming site. One of the prizes on many of the shows was a TI-99/4A Home Computer. They are still missing some episodes and they are not in true series order, but it is pretty cool to see this show in decent quality again.

Nice to see you here, Jim! I've drawn inspiration from your ports to the MC-10. I figure if you can do it on that little machine, there's not reason a lot of that stuff can't also work on the TI. Now it's just a matter of finding the time.

Great looking game! Very cool fonts and really nice graphics.

My job has been keeping me busy these past few weeks (I'm typing this at work... shhh! ). senior_falcon was kind enough to send me some replacement libraries for his compiler but I haven't yet had a chance to recompile and test the result. Once I do, I'll post an updated version which should eliminate that ACCEPT AT issue.

I'm not using VALIDATE but I am using SIZE(1). Here is what I am using for the newly added next level confirmation: 502 DISPLAY AT(19,1):"TAKE LADDER TO NEXT LEVEL? (Y/N)" 504 ACCEPT AT(20,17)SIZE(1):N$ 505 IF N$="Y" THEN 170 506 IF N$="N" THEN 509 508 GOTO 504 509 GOSUB 5030::GOTO 280 Is it possible there is a bug in the original TI programming of the ACCEPT command?

Thanks to the feedback I received, I've gone back and tried to play-balance the game by increasing the difficulty and hopefully making it tougher to get to the final (8th) map. The biggest step in implementing this was to give the weapons and armor differing amounts of boosting power based on their qualities. So now a rusty dagger gives the least boost while a magic claymore provides the highest. Armor was done similarly. A few other tweaks were made to get it to what I feel may be just right. I've also added a prompt to see if you truly want to go to the next map level when you get to that tile (the small H). There are still issues with the ACCEPT AT command which sometimes results in it not accepting your input regardless of what you type. All I can say about that for now is to just keep typing either Y or N and it will eventually register, then press enter. It doesn't do it every time (seems to be about every 4th or 5th time), so it may be a tough bug for Harry to pin down. I can always change it to a call key in a future version, but I really like the ACCEPT AT command so I'm not giving up hope on getting it working properly. I also fixed a few logical flaws that were in the first version of the game. I'm going to keep the first version available above, as it would be a fun version of the game for young kids of the early '80s or for someone just getting familiar with this style of game. I have again included in the zip file below the compiled version (GRAIL-C), the Extended BASIC source (GRAILEB), and my "working" text file which I use to do the actual programming and then copy & paste into Classic 99. GrailOfTheGods-TI-XB-v1.1.zip

Wow! I guess when you're used to programming it a certain way, you overlook the simple stuff. Thanks for pointing this out!

Not a problem! I just hope I've explained them clearly enough. If not, feel free to send me a PM. Your CALL SOUND suggestion to force a delay was just what I needed in order to cause a delay to the CALL KEY "press any key" sub-routine when messages would be displayed on the screen. Without that, messages would more often than not disappear due to the next key press being read.

Yeah, it's definitely a simple implementation and I realize that the difficulty isn't all that tough. I have lost, but more often than not, it was on the first level due to bad random numbers. It was a real chore just to get the player to move and update the screen, so for now, and with my skills still being nowhere near pro level, moving monsters are not in the cards. I could probably make them invisible until you bump into them (or make that an option), but that seems even less realistic than them simply standing around. Right now the trade-off is that once you start a battle it's a battle to the death... usually the monsters' deaths but hey, I wanted to prove something like this could be done on the TI. I do envision making the monsters have differing levels of difficulty, as well as differences in power for the weapons and armor you find and if space permits, maybe even a paper thin story a-la Tunnels of Doom. Ladders go down only and once you move over one, you are on the next level. I'd like to at least add an option to ask if you want to descend so you don't accidentally go to the next level if you didn't want or mean to. Also, I didn't want to spend a lot of time on something if people didn't like it. From the few who have commented, it appears those who have tried it like it. So thanks for the feedback to those who have left some!

Thanks! Yes, the .txt file is what I use to program and then paste into Classic 99. I also noticed I didn't need line 480 since it's taken care of in the ON GOTO in 500. I obviously fixed it in the final program but forgot to update it in the txt file. I'd have preferred a line-of-sight exposure, but with the way it's set now, I realized I could "tease" parts of the dungeon that aren't accessible but that you'd want to visit by finding the path to it. Level 6 in particular is like that.