Tursi

Another fantastic looking entry, and the collision detect is nice!

You underestimate me again, Batman! Classic99 has supported sprite flicker since 22 Jun 2009. The method used to calculate it is hacky, but the results are 100% correct.

Beautiful presentation, that's flipping impressive!

Sprite rotation is pretty easy, like Sometimes suggested, layout your sprite table in CPU memory, and do your updates there. The simplest routine is just a little function that runs on the user interrupt and copies the sprite table to VDP. For my Coleco work, I just rotate the start point of the copy by four sprites each frame.. that way the worst case is one in 8 frames (which doesn't look that good on its own.. if you can use fewer sprites it's better. 16 sprites gives a worst case of 1 in 4, which isn't bad). To do an offset copy like that, you just set the VDP address, copy from the start point to the end of the table, then copy from the beginning back to your start point. So, in the first frame: -Set VDP address -Copy sprite entries 0-31 -Nothing left to copy -add 4 sprites (16 bytes) to start point Second frame: -Set VDP address -Copy sprite entries 4-31 -Copy sprite entries 0-3 -add 4 sprites (16 bytes) to start point Third frame: -Set VDP address -Copy sprite entries 8-31 -Copy sprite entries 0-7 -add 4 sprites (16 bytes) to start point ... etc.. looping when you hit the end of the table. It's a simple and effect rotation. If you have multicolor sprite characters, and space them out nicely, you can have some part of them visible most of the time even in the worst case.

You guys are totally putting me to shame with your entries! I guess I will go back and spruce up ZomBXB a little with the time remaining so I stay in the running! hehe

That's actually what I had in mind when I saw the TI Farm thread, hehe... a strategy game combined with arcade-action fighting off the zombies. So I did my half of it for this. TI Farm is pretty impressive, nice work!

TI Farmer looks pretty darn sweet! Hehe.. nice work No live score in ZomBXB because print is slow.. I wanted to keep the framerate up, and you get more points every frame. Also, I didn't want people to complain that they shot a zombie and didn't get any points for it, hehe. This way I can hide the screwy scoring system

You're looking for the CF Adapter from Jagware. Skunkboard is a dev tool and doesn't need mass storage.

I loved my SegaCD, too, I got one new after watching the promos for SolFeace (the animation in the attract mode was pretty impressive for the time!) I never regretted it. True that there was a lot of FMV crap, but I actually liked Sewer Shark, and of course it made for a decent Dragon's Lair. I kept my original discs for Batman Returns, Silpheed, both Ecco titles, and (though not such a great game) Brutal Paws of Fury, just because I liked them that much, even though I sold the machine itself. (I finally have everything again ). I don't see Batman Returns mentioned much, but the driving game in that was really well put together and always impressed people when I showed it to them. I never played the platformer side of it at all, honestly (you could turn it off in the options menu).

No worries, Oval, thanks for the clarification. Just to be clear.. if we're talking about someone financing a run of Skunkboards, this isn't really me making an offer to the community. The offer would come solely from the person with the money, to essentially hire me to get the run put together. That's more or less what it boils down to. So if people seriously step forward with an offer, then withdraw the offer, I don't have a problem with that, because it's not really me being kind and generous to the community, it's a business investment. I provide the background info, they run the numbers, and either pull the plug or go ahead. The downside is that the information from the last run is less and less relevant to a new run, meaning that a serious investor would have to do some additional work to get modern cost figures.

Thanks, Marc. VERY interesting on the turning off of sprite motion... this kind of suggests to me that the interrupt routine itself might be running long (ie: by the time we cache the value, the VDP is into the next frame? Still a theory with holes though.) At this point, though... I don't really have the cycles to dig deeper, I'm just relieved to see I'm not crazy. Let's just leave it as a known for now and scratch our heads about it later. Oh no.. it doesn't wait for the end of the frame. It just reads a cached memory address. But that address is updated at the end of the frame. CALL COINC itself shouldn't add any delay to the program, that much we did settle.

That's my problem, that doesn't explain it. That theory has potential for your case, but makes no sense in mine. Look at the example program that I'm working with, not your example. My sprites are not moving. They are always touching. So the COINC should never return 'no coincidence'. But it does, and so does the CALL PEEK. If the ISR is the only thing writing that memory location, as my debugger tests suggest, then yes, the ISR /is/ missing coincidences. This is observation and not supposition. Let's start with the simpler of the two cases.

Yes, actually, for a single-bank game, anyway. I don't know for sure but I believe the various bank switched Supercarts used a different scheme for switching.

Primeform: While I strongly disagree with Oval's posts implying that he's privvy to more information than he has, he is correct that two people thus far have not followed through. Therefore, as far as financing another Skunkboard run might go, serious inquiries only, and serious inquiries don't start with a public forum post asking me to do the legwork.

I did a little research here on the COINC issue. My CALL COINC app on the real machine -- frequent coincidence misses, as expected. Using CALL PEEK to the scratchpad -- reports 156 and 188. That's 9C and BC. 9C sets interrupt (expected), and 5th sprite number 28 (but 5th sprite flag not set). That's a bug I can fix in Classic99 Anyway.. BC simply adds the coincidence flag. So that means that just peeking the scratchpad copy is ALSO not reliable, which I find interesting! With the real behaviour confirmed, back into the debugger. First, see who reads from the VDP status register. In debugging with the COINC version of the program running, it's always the console interrupt that reads it, coming from the GPL interpreter. This seems to discount my theory that XB reads it directly (you win!) So why does the interrupt routine miss collisions, when it should be reading at the end of the frame? I likewise checked, and nothing else writes to >837B. So that's good, we have likely got an accurate copy of the VDP status. I checked who READS that value, too, and it's a GPL memory access from XB GROM - likely the COINC. Confirmed this by removing the COINC - no more breakpoint. So far confirmed: -Yes, CALL COINC reads scratchpad -Yes, nothing except the console interrupt reads the VDP status byte. -Coincidences in a tight loop are still missed! Outpacing the vertical blank shouldn't matter... you can read a RAM location as many times as you want and the value won't change. So I don't fully understand why it's getting no collisions on some frames, since that's coming from the video chip by all appearances. So a bit baffling, but good to be aware of anyway, and you found a workaround.. Thanks for putting up with it! Thanks everyone for the ZomBXB comments, too. It occurred to me that I'm not trying to save memory, I should have used magnify 3 sprites instead. But that's okay, it works fine.

You also need a flipflop on the board to do the switch. Jon Guidry offered up a whole bunch of new cart kits for just that, I think there's still time to get in on that buy. http://www.atariage.com/forums/topic/155089-ti-994a-64k-cart-board-2nd-run/

I see you have a utility that converts programs to ROMs. Why is it harder to do it the other way around? You're making a bad assumption about what my program does. It takes a program that normally loads from disk to RAM, and copies the files into a ROM file. It then prepends a tiny little program that copies to RAM. So the program was written to run from RAM, and still does. These cartridges are written to run from ROM. It's a different memory space than RAM -- if you copy them to RAM, they will attempt to jump back into ROM, but the program won't be there, and they will crash. You basically need to go through and change all the address references for both data and code to point to locations in RAM instead of in ROM, then it will work. I've done such a tweak once but it's not a simple task.

You won't believe this... but you have a space in the word CALL in line 260. For some reason, that is causing the prescanner to report an out of memory error. Oh, too late. I think you should have left it. It's a non-intuitive error that may help others

You're assuming only one possible scenario, but I can give you the same "false" positive with the direct access mechanism: The problem space is: a. CALL COINC - detects the collision b. Your code responds by moving one of the sprites c. CALL COINC - reads the VDP again, still sees a collision Your assumption is based on this process occurring: 1. VDP interrupt occurs, console copies status register to scratchpad (Clears VDP status) 2. CALL COINC reads from scratch pad, detects collision 3. Your code responds by moving one of the sprites 4. CALL COINC reads from scratch pad again, STILL detects collision 5. VDP Interrupt occurs, console copies status register to scratchpad (Clears VDP status) ... and your goal with the delay fix was to move step 4 to after step 5. This is what I think happened: 1. CALL COINC reads from VDP, detects collision (clears VDP status) 2. Your code detects the collision... 3. VDP draws the screen again, sees collision, sets status again 4. ...your code moves one of the sprites - status bit stays set until it's read! 5. CALL COINC reads from VDP, detects collision again 6. VDP interrupt occurs, console copies status register to scratchpad (clears VDP status if it's still set) And your fix, adding a delay, simply moves step 5 after step 6, similar to the other scenario. Remember that unlike in today's emulators, the VDP sets the status register the instant it detects a collision, not at the bottom of the frame (which is when Win994A and MESS set it), and Classic99's setting of that bit is completely detached from real time right now, even though it can do it separate from the frame. So if it was in emulation you saw it, I wouldn't count it. Also remember that Extended BASIC can keep interrupts disabled for longer than 1/60th of a second -- if interrupts don't run, then the interrupt routine can't clear the VDP status bit. (Of course, this same argument /also/ works for your theory, too, since it shows why XB can appear to outrun the console interrupt. It's not that XB is that fast, it's that it blocks it.) Finally, the collision bit remains set until it's read, no matter how many times the screen has been drawn and regardless as to whether the sprites are still colliding. I thought Ben had previously mentioned that he'd had CALL COINC miss obvious collisions, and that I'd reproduced that. That supports the theory of it racing with the console interrupt routine. I tried this short piece of test code just now: 10 CALL CHAR(42,RPT$("F",16)) 20 CALL SPRITE(#1,42,2,100,100) 30 CALL SPRITE(#2,42,4,104,104) 40 CALL COINC(ALL,C) 50 PRINT C 60 GOTO 40 The sprites are /always/ touching so C should always return a collision, but in fact it frequently returns no collision. If you change it to a CALL PEEK() of the location that the register is copied to: CALL PEEK(-31877,C) -- this alternates between 160 and 128. 128 is the interrupt bit, and we would expect it to always be set (and it is). The other bit is value 32, which is the sprite collision bit. Bizarrely, it's not always set either in Classic99, meaning we're either racing the chip again (but we are in vblank when it is copied, so we shouldn't be), or something else is ALSO reading the register. I'm inclined to be suspicious of those results, though, and will try them on the real machine (unless someone beats me to it.) I'll work out the right answer when I get some time at home, but it's not so cut and dried.. you can have those symptoms either way. I think we should find out.

Names. C'mon. How can you say it was a false positive? Did you move the sprites after the first one to guarantee none were touching?

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.

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. RoboTr2J.zip

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. 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 ). ZombXB.zip

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.