Tursi
-
Content Count
7,205 -
Joined
-
Last visited
-
Days Won
8
Posts posted by Tursi
-
-
Thanks for that. I still wish I could get a dsk image made out of it. I wish I knew how. Having it on a cart would be very nice too. I'll have to see about that. I notice that there's two different versions in the folder. What is the difference between the two?
You would need to relocate the program to run from RAM instead of ROM. It's not a trivial exercise to make it run from disk.
There's only one version of the game - what you see there is a convention in TI ROM emulation - the C file is the first 8k bank, the D file is the second 8k bank. Both are needed to run the game.
MESS finally introduced a format that brings all the separate files together, but I haven't implemented it in Classic99 yet so haven't been using it.
-
It's still cartridge binary ROMs, so you'll only be able to play on Emulator or with a bank switching cart like the 64k carts Jon Guidry makes.
I overwrote some of the text on the first title page to store the second joystick code, and it may also interfere with some of the menu select (but I don't know that that worked 100% anyway). At any rate, the files are named so that you can load them into Classic99 with the Cartridge->User option. They should work burned to EPROM too on a bank switching cart.
-
2
-
-
Actually, CALL COINC seems to go and hit the VDP again.. I thought you'd said the CALL PEEK was faster. Ah well.. will benchmark it another time.
I got inspired and stayed up far too late doing a quickie. I consider this more of a warm up, it's the first XB program I've written in years, but I don't know that I'll get to anything else for the contest.
Trapped in a blue world, surrounded by zombies, with only your innate laser powers to survive!They want to eat your brains, so stay one step ahead of them!
Use the joystick to move. You will automatically fire in the direction you are moving.
The zombies are coming up everywhere, and moving in towards you. They're slow, but deadly,
and only a head-shot will take them out. Some of these guys are JUST floating heads, take
those out too!
Don't worry about a headless body - eventually it will disintegrate. It's harmless!
You score one point for every step you take and survive. You get two points every time a
zombie spawns, so keep blasting!
Watch out for the electrified barriers - if you touch one, that's instant death!
ZomBXB (Zom-B-X-B
) is a simple little shooter, loosely inspired by Robotron and that zombie farmer concept in the other thread. Originally I coded it for two joysticks, but that was way too easy since it can't speed up enough to overwhelm you, so it always fires in the direction you are moving. Might be a couple of little bugs still, but I've played it a fair bit tonight. 
30 lines of code, 3 lines of data.. though there's lots of room left technically, quite a few lines could still be packed. Still.. even though it's a bit easy, hopefully there's a little fun to be had.
On the technical side - I really cheat with the laser. Even though I'm using sprites for the players and zombies, the zombie heads are background characters. So I just draw and erase the lasers... zombies quit moving if they lose their heads, and eventually their body is recycled. That helps keep the framerate up (and explains the odd scoring - by giving you points when a zombie spawns, you are still encouraged to shoot them, without having to check every position erased.)
If they get too close to you, you can't shoot them, you have to back off. This is because you move before you shoot, but I left it that way to ensure there is a bit of a challenge - if they get close you need to make sure you still have an escape route!
Unzip the files, and drop in the Classic99 DSK1 folder. It's intended to run at normal speed, but it will run okay in CPU OverDrive (though be a bit harder
). -
Unhuman, I have them-- I'll have to locate them... Probably by tonight-- unless Marc Hull would be so kind.....
Bob Carmany just posted them on the no drama TI site so that is where I got them. Here they are hopefully...
... there seem to be some errors in that list, or at least poor choice of terminology (for instance, you can't CALL LOAD the sprite coincidence register to any value, it's read-only and the RAM location is just a mirror you can CALL PEEK). I can't sit and try them all, but if you find some that you want to use that don't work, don't be too shocked. Feel free to ask if there's another way for specific ones that don't work.
-
Was covered here: http://www.atariage.com/forums/topic/135727-ti-994a-robotron-2084/
I hacked it for two joysticks, I never mentioned that here, I guess. My hack isn't online anymore (I thought someone else was going to host it, hehe), but I can post it again I guess if anyone cares.
-
So the answer is no, it didn't happen. Neither did the other deal, which wasn't 3D0Kid though you're already trying to put words in my mouth. It's business, and that's how it goes. Oval, you're welcome to invest.
Primeform is looking to buy one. Don't go derailing his request with a bunch of bickering.
-
The Zombie Farmville title screen is awesome. I immediately wanted it!
You guys seem to be taking it in a different direction than I had in mind, though, so I'll watch to see what develops.
-
I didn't realize the Classic99 filesystem bug was still hitting people, can we please advise people to harrass me for a fix rather than advising them to go back to older versions?
The bug I suspect in the music routines won't require you to rewrite your music - that won't change. I suspect we aren't reserving VDP RAM properly. I don't know XB well and I just looked around for likely vectors. We'll need to ask the experts how to set aside some VDP RAM that XB won't touch from a running program.
-
The new torrent, with just MP3 versions in it, is at http://tursilion.com/tor/AtariLynxMP3.torrent
I can't edit the old post, but I've removed the old torrent seed.
-
I've been converting them to MP3 but it does take time because of the number of files. I can send them to Tursi once I'm done if anyone wants them as MP3.
That would be nice
I didn't think anyone would care. Trek, don't worry about it, I can batch convert to MP3.
Give me a few days, will post again when I get it done.
-
Sorry for the delay on this - I have the files up on bittorrent now, should make for easier distribution, and so long as a few people keep seeding, faster too.
You can grab the torrent from http://tursilion.com/tor/Atari_Lynx_Rips.torrent
I've left the files in the OGG format I received them in - most modern players can handle ogg, and it would take a fair bit of time to convert them.
Let me know if the torrent works for anyone, I don't set them up too often.
-
That's a neat idea. I haven't played with COM for about 8 years, setting it up really did kind of suck.
I wonder if things like messaging, named pipes, something like that might not be a better interface. Sure, it's not object oriented, but... (well, actually, that's all of it.) Also, the Bug99 interface is nearly done (Thierry and I hashed out some of the problems with the first release, I just need to finish implementing and testing the new one and let him know it's good to go).
-
1
-
-
Only 10 people have reported getting theirs so far. And no Youtube videos yet.
-
Oi.. what's with these crappy free download sites? I'll seed a torrent if the tunes are that popular (of course, I need to get a copy too... whoever has them PM me and I can set up an FTP folder to start with
). -
Probably both answers are correct. Some modern devices deinterlace the video by merging both frames onscreen, that would prevent the glasses from working. Not just LCDs, but projectors and other displays, too. Even though the original signal was generally not generated as interlaced, it's treated as such by modern hardware.
The light gun problem is caused by the lack of a scan beam to detect (except for the NES, where it is probably caused by the same deinterlacing issue).
-
You could in theory. All you need is to get enough code running to read the cartridge header and start the code. The problem is getting that code going without the GPL hook needs something either in a custom GROM (which we don't have yet) or something that hijacks the powerup vector. Not sure if you can do that through the cart port, it's missing a few important pins.
But if you had a game genie like device with a GROM or GROM simulator in it that did that much, it would work fine. Likewise, if you can run your own assembly code (like, say you have Editor/Assembler installed in the console), you just need a couple lines of assembly to launch the cart. There's no lockout except that it doesn't offer the ROM-based carts in the startup menu.
The reason you don't see many workarounds is that it's not actually a big problem. The v2.2 consoles are actually relatively rare compared to the v1.x consoles. I guess there's not enough demand to bump up their prices but I don't know of anyone who's actually stuck, and if you were, someone would probably ship you a free console for the asking to get you unstuck.
-
You can tell by looking at the side port actually. Mainbyte has a nice page with the differences and photos: http://www.mainbyte.com/ti99/computers/ti99qi.html
-
The ROMs are soldered.. and it's the GROMs that have the difference, meaning you can't even burn your own replacements. The main 'lock out' is that they no longer scan the ROM cartridge memory for a header.
I'm not aware of any changes that should prevent the side cars from working, especially since the 1981 motherboards are (as far as I have seen) all the same... the updated motherboard came with the updated ROMs.
That said, if you were somehow stuck with a 2.2 motherboard as your only machine and didn't want to replace it with a cheap console off EBay, there are numerous ways around it... a RAMdisk with the boot menu can launch them, for instance.
It is a small problem since most of the new carts are currently ROM-based. I had intended to program an Atmel as a GROM replacement to see what performance was like. Will get to that soon-ish.
-
I had trouble pasting the code, oddly, but it looks really great! A suggestion - moving multiple sprites can cause you to have cumulative positioning errors. To reduce that, my suggestion would be that whenever he stops, just manually correct the position of one of the sprites relative to the other.
-
Definitely curious what people think of the game too... if anyone gets theirs soon please post pics!
-
We had a long debate about this on the TI list not long ago, which led to me finally putting a 3.5" drive on mine.
I saved the notes here: http://harmlesslion.com/text/ti_35_inch_floppy.txt
But it's short, so to copy the article:
Using a 3.5" Floppy Drive on the TI-99/4A-----------------------------------------
Contributions by Marc Hull, Jon Vogel, and Tony Knerr.
1) Use a straight cable - no twists.
2) Change the drive select line ON THE CABLE in the appropriate place.
Pin 10 is DSK1, pin 12 is DSK2, and pin 14 is DSK3. The appropriate lead
goes to pin 12 on the floppy drive. With no changes, a standard 3.5"
drive will be DSK2.
3) Mix and match whatever you want, if you've got mixed 5.25's and 3.5's,
remove the termination packs from the 5.25's.
4) The HFDC doesn't like too much termination, other cards simply don't care.
5) Use only double density 3.5" disks unless you've got a Geneve and
are using high density. Taping over the hole on high density disks is
NOT RELIABLE, period.
6) Don't use a HD diskette on non-Geneve-HD systems - doing so can confuse
the controller. If you have an HD drive, you might want to disable the HD
sensor so that it never sees the hole. Doing so and using HD floppies
anyway is taking reliability into your own hands (see #5).
Using a HD drive on the TI Controller with HD disks /really/ confuses the machine... it's goes beyond simply not working to seriously misbehaving. I "converted" my HD 3.5" drive by using a bit of solder to permanently disable the HD hole sensor.
-
But yes, rush6432 had a problem getting his Skunk to work with a BJL ROM in his Jag. Tursi would have to let us know if that would still be an issue. Not an issue for [email protected] since he doesn't have one. But rush6432 had the BJL ROM in a socket so he just switched out the BJL boot ROM chip for an original Atari boot rom and then his Skunk worked.Nobody has ever contacted me about the Skunkboard not working in a BJL modded Jaguar. I use the BJL ROM in conjunction with my Skunkboard all the time to use its exception handler.
It does not work with the Stubulator ROM. But that's the only replacement ROM issue I'm aware of. If you guys know of others, wouldn't hurt to fill me in so I can fix it or at least document it, rather than spreading stories.
-
Sometimes, as always, your skill with the pixel art, especially with hiding the color limitations, blows me away.
-
You could probably start a separate page for homebrews in wikipedia and you'd be okay.Metafox (not sure if they're on this board?) did this a few years ago for the Dreamcast scene, covering all the companies and releases GOAT had approved and sold. They set up as a separate project Wiki, were reviewed, then approved for inclusion into Wikipedia. About a year later, all the entries were marked "not notable" and deleted.
I see there's still a list of independently released games: http://en.wikipedia.org/wiki/List_of_commercially_released_independently_developed_Dreamcast_games
All three bleemcast! releases are still active, as are DUX, Last Hope, Rush Rush Rally Racing and Wind and Water (though except for Bleemcast, all these entries postdate the purge I mentioned.) All the GOAT releases - Cool Herders, Feet of Fury, Inhabitants and Maquipai, as well as DreamParaPara from Teamcast, are listed but their entries were deleted.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Short and Sweet (SSGC) contest
in TI-99/4A Development
Posted
Ugh.. sorry guys, a last minute bug I noticed and fixed, and at 3am it looks like I didn't test it. You can replace line 570 with this:
Or grab the corrected version (tested this time!)
ZombXB.zip
Yes, this week has heard this request a lot in email, too.
Working on the new release when I'm not doing work or 30 liners. 
It was something I thought I saw during some other work. But I assume you are saying you missed a COINC... doesn't that confirm it? You shouldn't lose a coinc if it was reading the scratchpad RAM location, it would stay the same till the next read. Remember that the console interrupt ALSO reads and clears that register to update the scratchpad. So if XB hits the video chip directly, then maybe you CAN miss a COINC, either through racing yourself or racing the console interrupt.
I tried setting some breakpoints in XB with a tight CALL COINC loop, but I can't prove it that way. May look in more depth later.