Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Asmusr

Members
 View Profile  See their activity

  • Content Count

    4,000

  • Joined

  • Last visited

  • Days Won

    13

Posts posted by Asmusr

  1. Posted

    I'd like to see your test for this one - that's not how the code works.

    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?

  2. Posted

    If you wait for VSYNC to read the status, then the collision flag will represent any collision of any two sprites during that frame.

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

  3. Posted

    There's no reason for emulators to find the collision flag any harder just because of the operating system behind it... that would imply some sort of real time restriction that doesn't happen inside an emulator - it draws the pixel when it draws the pixel, and no other operations have happened in the meantime, even in Classic99 where the timing is detached. ;)

     

    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?

  6. Posted

    Note1: The F18A has a sprite collision bug in the 1.3V of the firmware. It will detect collisions of off-screen sprites when it should not. The proper functionality is that only sprites with pixels (of any color, including transparent) that would appear on the screen will cause the collision flag to be set. The bug is corrected in the V1.4 which you may have depending on when you purchased your F18A, or if you have a JTAG cable and did an update. I'm (slowly) working on the software-only update.

     

    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?

  8. Posted

    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.

     

    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?

  9. Posted

    Hmm, that does not make sense. The sprite collision is detected in the output pixel mux, and only sprites being disabled due to the mode should prevent the flag from being set. If you can see the sprites, the collision bit should be set accordingly. Unless the masking bits that come in to play with the half-bitmap mode somehow interfere with the setting of the collision flip-flop. Text mode inhibits sprites, but it is unclear at what "level". We know the reading of sprite data does not happen, but I wonder if the sprite shift registers are still active?

     

    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.

  10. Posted

    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.

  12. Posted

    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?

  13. Posted

    Mini-Memory only has 4K of the >6000 - >7FFF space available for programs.

    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)?

     

    This site makes it so simple, "Even a Caveman can turn an E/A into an SC"!

    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?

  15. Posted

    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.

  16. Posted

    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

    • Like 1

  17. Posted

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

  18. Posted

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

  19. Posted

    In this demo project I wanted to try out two new things on the same kind of space graphics I use in the half-bitmap mode project (which, BTW, is still going strong):

    • Horizontal scrolling
    • Scrolling in normal graphics mode 1

    http://www.youtube.com/watch?v=Js4hhBIdJlc

     

    The attractive thing about using mode 1 for scrolling is that it's possible to use pattern table switching, which is not possible in bitmap mode. This demo uses four pattern table buffers, each divided into a low character set (0-127) and a high character set (128-255). This allows you to pre-load up to 128 patterns in 8 scroll positions/frames into VDP RAM. The demo also utilizes two name/screen table buffers - one for the low character set and one for the high character set. The scheme for switching buffers goes like this:

    • Frame 0: Pattern table 0, Name table 0 - low
    • Frame 1: Pattern table 1, Name table 0 - low
    • Frame 2: Pattern table 2, Name table 0 - low
    • Frame 3: Pattern table 3, Name table 0 - low
    • Frame 4: Pattern table 0, Name table 1 - high
    • Frame 5: Pattern table 1, Name table 1 - high
    • Frame 6: Pattern table 2, Name table 1 - high
    • Frame 7: Pattern table 3, Name table 1 - high

    In terms of performance only the preparation of the name tables matters. Since we have 4 frames to prepare a table of 768 bytes we need to send only 192 bytes to the VDP RAM per frame. This leaves plenty of CPU cycles for sprites and other stuff - even at 60 FPS. The demo shows different speeds from 15 FPS to 60 FPS at 1 pixel/frame, and the top speed is 60 FPS at 2 pixels/frame. When moving 2 pixels you only have 2 frames to prepare a name table, i.e. 348 bytes per frame.

     

    Another good thing about mode 1 compared to half bitmap mode is that all 32 sprites can be used without running into the 'duplication bug'.

     

    The downside of using mode 1 is the limited colors, of course. Two adjacent tiles in the direction of scrolling must either use the same foreground color or the pattern for one of them must not contain any foreground color pixels (i.e. a 'space'). The same rule applies to the background colors. (Actually, horizontal scrolling in bitmap mode is subject to the same color limitations but applied to each individual scan line.)

     

    I'm going to post an update to the Magellan thread that provides better tools for designing mode 1 scrolling graphics plus an export function for generating the transition map, which I used for this project.

     

    This attachment contains a dsk file with the demo (looks much better in Classic99 and even better on hardware than on the video).

    hscroll.zip

    The source code is also included. Note that the code is overly complicated because of the scrolling at different speeds and because of the wrap around of the map. If these features were not required it could be done much simpler.

    • Like 4

  22. Posted

    If you associate *.DSK files with TI99Dir, then you can use Disk->DSK1->Open DSK1 in the Classic99 menu to automatically open the current disk image.

     

    Great, thank you. It was the quotes. I had to edit a registry entry under HKEY_CLASSES_ROOT\dsk_auto_file\shell\open\command to make it work.

  24. Posted

    -fix screen redraw on debug activities to VDP

    -fix debug character display in bitmap mode

     

    Thank you Tursi, this is great. Now I can see how the scrolling in Parsec was done, for instance, and I can use it for debugging my own code.

     

    I also have a wish for Classic99: an easy way to catalog a disk from windows, like in Win994a.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...