Jump to content

adamantyr

+AtariAge Subscriber
  • Content Count

    1,852
  • Joined

  • Last visited

Posts posted by adamantyr


  1. Greg has already said he can't do this alone. And that's fair; moving into a new home takes ALL your energy and focus. I know that all too well!

     

    I'd help out if I could, but If I was the host/organizer, I would want to do it a lot closer to home. Which I'm sure would eliminate most of the attendees there down in Oregon who would be disinclined to drive up north.


  2. Star Trap by Databiotics was, in my opinion, pretty bad. It looked in promotion shots like a cool Star Wars arcade clone. In reality it's a static screen with only enemies moving and sound effects recycled from Parsec.

     

    On disk, I'd go with Doom of Mondular from Symbiotech. It sounded like an awesome CRPG based upon the entry in the Triton catalog, but it's a really crude Might and Magic clone (if that) which runs like total crap due to the horrific copy protection scheme that was used.

    • Like 2

  3.  

    After a bit of label renaming I managed to assemble a new version with the large monster list. I had to move some data around to make it fit into memory, but it's all there and a few hundred bytes left. I reintroduced the Villain monster because it's special for the town. I noticed there are two Gricks.

     

    What's missing, as you can see if you try to run the attached version, is that each monster should be mapped to its graphics via the pattern number. There are currently only 16 different patterns to choose from, as you can see from the attached screen shot, and the pattern number is the 0 based index into this list, .e.g the Villain is 12. If there is no longer a monster fitting each graphics, e.g. the mushroom, I think some of the old monsters should be reintroduced.

     

    Nice graphics! I'm doing bitmap mode 16x16 and 32x32 monsters myself. I have 8x8's for travel mode, but they don't have a unique one per monster, just a general "green lizard" that can be a dragon, a lizard, etc.

     

    Right now I got about 60% of my monster graphics done. I have 170 16x16 patterns and 24 32x32 patterns.


  4. When I was a kid, I used a regular desk for the TI. My dad actually built both me and my brother computer desks uniquely designed for our computer systems (TI-99/4a and the TRS-80 Color Computer) with spots for printers and whatnot. Right now theyr'e in storage at my parent's place, I am musing getting them at some point. (They have strict instructions NOT to junk them. They're large enough I would need a truck to haul them, and it's 200 miles away.) The problem is, I don't think they would work as well for me today, and the days of having a claustrophobic desk has passed.

     

    I was using a beautiful wood table for awhile for my TI set-up, but I had to stop because the weight of the machine and P.E. box started bowing the table in the middle. :/ It was never intended to be used as a desk anyway, it's not even a great table it seems.

     

    So I went to a local office supply place and found one of the raisable/lowerable desks, the kind software companies like Microsoft buy in bulk, and got one for $50. It has 1 1/4" thick surface and sturdy steel legs, so I know it can take the weight. So far it's working great!

    • Like 3

  5. Periodic noise doesn't have the right "sound texture". I think the NES APU and the 9919 are clocked the same internally, so I don't think that's an issue either. And there's no way to play PCM directly at 60Hz.

     

    Here is the original PCM sound: attachicon.gifOriginalDoorSound.wav

     

    and here is what I came up with using white noise: attachicon.gifTildaDoorSound.wav

     

    EDIT: Oh, if you're talking about bass notes, then yes, the periodic noise can be used to play at 1/15th of the frequency of GEN3 and it does have a more buzzy feel. I am doing that in the music, you can usually hear where it flips between using GEN3 directly and Periodic. Maybe it would be more consistent to use Periodic for the whole APU Triangle channel?

     

    Yeah, the TI one is fine, don't sweat it. :) It's the only one I heard that wasn't an errie perfect reproduction of the original!

     

    Do you have an idea yet of when the game will be complete? How far away is the finish line? Any major tasks left to do?

    • Like 1

  6.  

    Couldn't you use periodic noise controlled by tone generator 3?

     

    Periodic noise is just a buzz noise, more regular than a white noise. It doesn't actually go lower in tone.

     

    The TI sound chip is pretty good but it's hamstrung on base notes because of the 3mhz clock. Because the frequency divider is faster, it pushes the tones up to higher octaves. The same sound chip in a 1mhz architecture would be able to go about 2 octaves lower easily.

    • Like 1

  7. Stock, I'm not a hardware guy. I had my membrane keyboard replaced with a mechanical several years ago, but as was stated, those don't count. More of a repair than anything...

     

    I do have two modded P.E. Boxes with quiet fans though. :)

    • Like 2

  8.  

    The Oak Tree Restaurant is big enough, has plenty of electrical outlets and is close enough to multiple hotels for a "two day thing." It's only 30 minutes north of the Portland Airport for those coming in out of the area. Pushing the date back a month or so would probably work and give people more time to make plans and set up accommodations.

     

    I liked the Oak Tree! I even took my GF and her daughter there on our way back from Rose City Comic Con. And there are close by hotels that are inexpensive too.

     

    Adam

    • Like 2

  9. It's cool, that's a bunch of stuff going on you definitely should focus on. I'm sorry about your FIL, I hope he makes a full recovery!

     

    I'm cool with Vancouver again. I'm not that keen on Beaverton, but I could probably make that too.

     

    I'll also add that if we have to push Fest West back a month or two in order to accommodate I'm all right with that.

    • Like 3

  10. SAMS has no real "platform" on the TI, any application written for it has to roll their own loaders and manage paging itself.

     

    For example, my CRPG is a 144k program binary, 72K of which is program "modules" of 12K each. One module always resides in memory in the lower 24K block, the upper 24K is switched to whatever module is needed. The lower 8K block is used for data access and is switched frequently as needed.

     

    Loading all this required writing a custom loader which opens to the binary and reads it in 8K chunks which are then copied to the CPU RAM page needed. It takes about a minute or so to load the game from TIPI, faster in Classic99.

     

    Art Green's old AEMS assembler offered a linking loader design that could load object code into pages, but I'm not sure the design was ever fully worked out. Consider that if you wrote all your code into 4K module chunks loaded generically into a SAMS card (you don't have fixed pages for anything), that would mean maintaining a list somewhere of modules and their page assignments, which could get messy very quickly. Especially if one module is dependent upon another one being in memory at the time. I'd much rather write my games than focus on designing a framework to drive them on.

    • Like 2

  11. Okay so you ARE blasting bitmap then. :)

     

    What exactly are the name tables? There is the pattern table, the color table, the screen table, sprite pattern table and sprite attribute table.

     

    Regardless, the first thing I would do is make sure my screen table is right next to the pattern table at >1800. Then I would have a 2.75k buffer in CPU and make sure all my changes are there. I'd then use 16 bit registers in scratch pad and put the VDP ports IN registers for maximum speed and just write the 2.75k in one linear write.


  12.  

    I think I am seeing some tearing. And I am enjoying unrolling loops to just blast it all out!

     

     

    Hmm, I forgot that I could move the name table from >1800 to >3800 to do page flipping.

     

    But isn't there something with reading VDPSTA? I did something with the 9938 back in the day to synchronize page flipping (register write) with vertical retrace, because it was tearing even more obviously during a page flip.

     

    What exactly are you writing to VDP? Can you share some code?


  13.  

    What is the technique to synchronize screen updates with the vertical sync?
    To avoid tearing by trying to draw in between video frames.
    My game loop is like this:
    LOOP
    enable interrupts briefly
    write screen and sprites to VDP
    KSCAN
    update internals
    B @LOOP
    I'm not sure the VDP writes still take more than 1/60th of a second, but I'm working on that.
    3 address changes for 3 blocks of 128 consecutive bytes seems like it could fit into one refresh cycle.
    2 writes to Bitmap name table and another to sprite attribute table.

     

     

    I honestly wouldn't worry about vertical sync issues until you observe them. Until you're trying to blast bitmap graphics in real-time you don't really have an issue with this in assembly. (Coming from Basic and Extended BASIC it's easy to think "But sprites and graphics are SLOW!")

     

    Your best method of handling the VDP is to treat it like an output device, like a printer. Don't try and figure out WHAT you're writing in the midst of writing to VDP. Use buffers in CPU and pre-calculate so you can just blast it all out in one large block without stopping. You can also use a alternate screen in VDP and do swaps with a single VDP register change.


  14.  

    I think it is a simple buffer overrun. One edit buffer for the current room holds 3 objects, but when you leave the room, it goes into storage for the room. There's not room for the 3 objects in the storage, but it still says there are 3, so when you come back it copies some memory from past the end of storage.

     

    My game AdventureQuest (unreleased) had a save file with sectors of 192 bytes of 6-bit tiles (arranged in 16x16) + a monster and item storage in the remaining 64 bytes. When the sector is in use, the 64 byte object list is unpacked into working memory. When the sector goes out of use, the list gets re-packed. I spent a lot of time ensuring that it would always retain its integrity when copied back to that 64 byte buffer. Because I didn't want the bug that TOD had.

     

    (it was actually a nested list.. each object in it was "Duck Typed" by a list of key-value pairs, and value could itself be a list.)

    This was built to allow for more weird corner cases than I could think of!

    If this structure had been damaged it would have been interesting.)

     

    Yeah, items in ToD have their characteristics copied with them, so if it read past the buffer it's probably picking up a "32" consistently from a memory area beyond that.

     

    Come to think of it... ToD must be using VDP memory to store item and room data, it's the only place with enough RAM on a base console. Using Classic99's debugger you could probably find in memory where it's storing all of it and discern the data structure.

     

    In my own CRPG, I use two bytes for all items; a category and a # assignment. If the top bit of the # is set, it's an unknown item of it's type. All other data (damage, hit, protection, etc.) is stored in data tables that are referenced. This means you can't have honing stones or similar effects that change your item's abilities, as I'd have to store the entire structure for an item (16 bytes) everywhere.

    • Like 1
×
×
  • Create New...