Asmusr

I would like to add some sound effects to my game that are a little more interesting than the usual square wave crash and chime examples from the A/E manual. Do you have any suggestions for tricks or techniques to use to produce other effects or wave forms? I have read about the sample trick used by the Sound FX program, but I have no room for samples, so it has to be programmed and relatively short, but it doesn't have to be limited to a 60 FPS data feed. One idea I have is to rapidly changing the frequency on two generators slightly out of sync to obtain an illusion of phase shifting. I have no idea if that's possible or what that would sound like. Before I start experimenting, are there any limitations to the sound emulation in Classic99 and MESS that I should be aware of?

Yes, please. I don't remember having seen this.

Is there any need to debounce the keyboard in a game where you just want the keyboard to work as an alternative to the joystick? Reading the keyboard (or anything else involving CRU) is still a mystery to me. I have found the following code on Thierry Nouspikel's site <http://nouspikel.gro...99/keyboard.htm>. I would appreciate if someone would write a few words about how it works and how to change it to read other keys, e.g. S,D,E,X. Thanks. [Edit] Never mind, I found a really good tutorial here <http://nouspikel.group.shef.ac.uk/ti99/tutor1.htm#CRU>. *-------------------------------------------- * Routine to detect a key combination (in this case Fctn-=), * returns with Eq bit set if this is the case. * This routine alters R12 and R1 *-------------------------------------------- ISQUIT CLR R1 Test column 0 LI R12,>0024 Address for column selection LDCR R1,3 Select column LI R12,>0006 Address to read rows STCR R1,8 ANDI R1,>1100 Mask all irrelevant bits B *R11 Else return *-------------------------------------------- * Routine to detect a specific key (in this case <enter>), * it returns with Eq bit set if <enter> was NOT pressed. * Alters R12 only *-------------------------------------------- ISENTR CLR R1 Test column 0 LI R12,>0024 Address for column selection LDCR R12,3 Select column TB -13 Test R12-address >000A, i.e <enter> B *R11 <enter> was not pressed: return

This should demonstrate the problem. You can turn the blanking on/off in lines 63/64 but the sprite is always there. Thanks for looking into this. Sprtest.zip

Thanks for you help. I love Classic99 and I use it every day, so I'm bound to run into some problems, but I seem to fall into every trap when it comes to the difference between emulation and hardware! Did you see my reply in the 'Classic99 Updates' thread about the sprites being visible when the screen is blanked? If you still can't reproduce it I will write some test code.

Well that's what I did, I polled the status register with regular intervals and only saved the collision flag when the interrupt flag was set. It worked perfectly on Classic99. Could it have something to do with how long the screen redraw takes on the two emulators? I mean, if it only takes 1 ms on Classic99 and I only poll the status register every 4 ms my code would very likely work, whereas if the redraw took the full 16-17 ms my code would miss many of the collision flags. Anyway, my code works now so there's no need to start a lengthy debate, I just thought it was odd.

My code to disable the screen looks like this: LI R0,>0182 * Reg 1: 16K, display off, no interrupt, BL @VWTR * graphics 2, size = 1, mag = 0. Could it have something to do with the else statement in this part of your code? Looks like you're only checking for text mode and not for blank. if (redraw_needed) { ... } else { // we have to redraw the sprites even if the screen didn't change, so that collisions are updated // as the CPU may have cleared the collision bit // as long as mode bit 2 is not set, sprites are okay if ((VDPREG[1] & 0x10) == 0) { DrawSprites(); } }

I don't have any good test code to show you without sending you my entire project. But I found that code that worked perfectly on Classic99 hardly detected any collisions on MESS. This was because I only saved the collision flag when the interrupt flag was also set. After changing the code always to save the collision flag, it works on both emulators. My guess, and I might completely wrong, is that it's not about clearing the flag, which Classic99 indeed does. But since Classic99 is drawing the screen all at once there is no way you can read the collision flag half way down the screen. The flag will always represent the collisions of a full screen. If MESS is drawing the screen one scan line at a time you can happen to read the flag half way down the screen and thereby reset it. If you then read the flag again at VSYNC you will only get the collisions for the bottom half of the screen (unless you saved it the first time, which I didn't). Does that sound plausible?

Waiting for VSYNC without reading the status is only possible using the interrupt, right?

I found there's a significant different between how the collision flag works on Classic99 and MESS. When you poll the status register on Classic99 you don't have to save the collision flag unless the interrupt flag is also set. On MESS you must save the flag or you will fail to detect most collisions. Looks like Classic99 is caching the flag for the following vsync period and MESS doesn't. I guess MESS works more like the real hardware?

I noticed that Classic99 displays sprites even though the display is turned off in VDP reg 1. Is that a bug?

I do have a >D0 at the end of my SAT, but I use a y value of >C0 to place sprites temporarily outside the visible screen. Will coincidence be detected between these sprites?

It looks like I was fooled by this bug and the coincidence flag is working after all. My code was polling the status too infrequently, while on the F18A the flag was on most of the time (because of off-screen sprites, I guess). However, based on the tests of my current project, it seems that the reliability of this flag depends heavily on the environment: Classic99, MESS, F18A, TMS9929A. In Classic99 the coincidence always works while on my EU console it hardly ever works. MESS/F18A are in between. It has probably something to do with my code, but there's still a huge difference to explain. If if don't rely on the flag, my collision detection works perfectly, but it takes valuable clock cycles to execute for every frame, and it seems a shame not to use this hardware provided feature. Are there any tricks to reliably reading the coincidence flag, except of course to read it after every vsync? Should you, for instance, sample the flag over longer periods?

Thanks. It's working now. I had to save to contents of the >8370 pointer and restore it again when it's needed instead of just setting it to >37D7.

Well, my code now works on Classic99 and MESS but not on my console with a nanoPEB. All I'm trying to do is to read a 4k file as 32 records of 128 bytes from DSK1. I tried with two different DSRLNK routines that both work on the emulators. Any suggestions for what I might be missing? What should the >8370 pointer be set to for the nanoPEB?

What I found was that the same code that worked fine on a console with the F18A did not detect any sprite collisions on my other unmodified EU console. I have interrupts turned off. If you say it doesn't make sense I will try again.

Thanks again Willsy, I finally got it to work. It turns out the problem wasn't the DSRLNK routines (both of them work) but the pointer in >8370 to the "Highest available address of VDP RAM". I have been using the scratch pad at my leisure without any concern about what the OS is expecting. After setting the pointer back to >37D7 it began to work. I also switch from >8300 to a workspace in upper memory and save the contents of scratch pad in a buffer before calling DSRLNK, and restore it afterwards as you suggested.

Thanks a lot, I will try your routine.

Sorry to go slightly off topic. I found an 'all purpose' DSRLNK implementation here: http://atariage.com/forums/topic/163692-ea-file-access/#entry2071618 Anyone knows what 'all purpose' means in this context? I'm a bit worried by the comment: SINCE WE KNOW WERE USING "DSKn." I would like to use something like this because I want the entire area from >2000 to >3FFF for my own stuff, so I don't want to load any of the standard utilities. It works well in Classic99 but not in MESS. Is the real floppy DSR using other memory in the >2000 area or what could be the problem?

I guess you also need a cart with the E/A loader build in, or is that included on the 4A DOS disk? Does 4A DOS have to run from RAM (and not ROM)? Thanks, I thought about that. Even got as far as writing a shopping list for the components <http://atariage.com/forums/topic/213140-building-your-own-carts/#entry2769175> but then I heard about the new 512K cart project and thought I would rather wait and see how that went. I'm also worried about destroying my only E/A cart. To return to my original question, I tried with Warzone2 as an example of an E/A 5 application. I inserted the disk in DSK1 in Classic 99, placed a breakpoint at >A000 and ran DSK1.WZ2 from E/A option 5. When it reaches the breakpoint the pointers at >8356 and >831C are still there (pointing to >100E and >1000) but there's no trace of the PAB in VDP RAM. Am I breaking the program too late (I noticed that the screen has turned green) or what is going on?

Sounds very interesting. Only problem is to find a Super Cart. I don't suppose it will run from a Mini Memory?

Is there a standard way of knowing which disk drive or device the current running program was loaded from? E.g. if someone runs my E/A program from DSK2 I want to make sure that data files are loaded from DSK2 and not from DSK1. I noticed that E/A is using a PAB at VDP RAM >1000. Does that mean you can always read the device at >100A for any program that you run from E/A? Thanks.

A minor release, mostly to support my own projects about smooth scrolling. The new features include: Current foreground and background colors are now also marked with F and B in standard color mode In standard color mode empty characters are no longer shown with a question mark when a background color other than transparent is selected Clone tool is more responsive Somewhat clearer indication of foreground and background pixels in bitmap color mode The tool for analyzing character transitions (for use with smooth scrolling) has been expanded with support for checking that color transitions are OK for scrolling Export option for Binary Map (Current). Produces a simple binary file of the current map Export option for 'Assembler Character Transition Data' for use with smooth scrolling. Read more about the format in 'release changes.txt' (included in zip file) I don't want to hold on to my changes to the code for too long in case some of you want to make you own changes, which is why I release this now. It would be great to place this code under version control in GitHub or similar, but I don't think it would be appropriate without the consent of the original author Howard Kistler/Codex. If you're reading this, please let me know if you think it would be OK to turn the code into an open source project managed by the TI community. If you have suggestions for new features, please let me know. I enjoy working on this project when I have time, and programming in Java is so easy compared to TMS9900 assembler. magellan-1.7.5.zip

Aaarrghh! I've discovered that the sprite collision flag is not working at all in half-bitmap mode (with 1 color table and 1 or 3 pattern tables). At least not on my European console. Can anyone confirm this? I begin to understand why so few games are using this mode, attractive as it seems on first glance...

Thank you for all the positive feedback. I see lots of potential for using this technique for games (platform, driving, pinball to name a few ideas), and I hope that some of you will be inspired to make your own projects so we can share ideas and techniques. For now I'm focused on the vertically scrolling, half-bitmap project, which is beginning to look like a game, but I'm still not 100% sure what the objectives of the game are...