Jump to content

adamantyr

+AtariAge Subscriber
  • Content Count

    1,639
  • Joined

  • Last visited

Community Reputation

1,134 Excellent

About adamantyr

  • Rank
    Stargunner
  • Birthday 07/16/1975

Profile Information

  • Gender
    Male

Recent Profile Visitors

30,865 profile views
  1. It's going pretty good! The main hurdle we have is anytime I make content changes (which are script-driven), the testers have to start over from scratch because their saved content no longer aligns. I need to spend a few hours myself just testing a lot of content and try and get it as clean as possible before the next major release. I had a release a bit ago where I also refactored the monsters general power levels when it became clear they were TOO strong in places. Trying to get pacing right is a challenge.
  2. Yeah, at some point I need to get the program onto disk images and test it out in MAME. On that note, MAME does run on Mac, right? I had one co-worker who was interested in trying the beta, but he's a Mac guy.
  3. It doesn't have save states, no. Just PM me an email contact address and your full name for the credits! Also, we use a Discord server, which you are free to join and chat with other testers, report issues in real time, etc. Or you can just stick with e-mailing reports, whichever works best.
  4. Actually I prefer emulation for beta testing. I've had guys step through the debugger for me when I wasn't able to repro the issue myself. Classic99 is also 99.99% solid in terms of replicating the original hardware. We even discovered a small bug in Classic99 with the key scan routine in the process of testing.
  5. Just a quick update... Beta testing is going well, we are up to build #13. IF you are interested in testing, please drop me a PM. Bear in mind testing means actually dealing with having to start the game over a lot, encountering bugs and trying to repro them, having some free time to devote to it, etc. I believe that I will be able to also offer the game as executable with a 180K drive system as well. It would be six disks, and you'd have to swap the load disk for a game disk right after the title screen. And I'd still strongly advise anyone to just get a TI-PI because it's WAY more convenient.
  6. Yes, currently in closed beta testing. Hopefully not for too long, my goal is a Christmas release.
  7. Yeah, that is definitely a rare find. I imagine the seller wants a chunk for it.
  8. Wow it had a manual? That looks sweet, honestly! Databiotics did nothing but simple cheap colored cardstock manuals.
  9. Well now my game requires a bit more than 256K... bummer.
  10. Hopefully not too far off... Under normal circumstances with another game, I would just release it and let feedback come in to fix bugs and stuff. But I feel like I need to have a higher quality here, since a CRPG takes a considerable amount of time to complete. I don't want six months from now someone saying "Oh BTW, you can't actually finish it because of this". I've played through the early content on my own a lot, but fresh eyes definitely helps as well to catch particulars I may have missed because I'm too close to things. Much like with Wizard's Doom, I'm going to probably end up tweaking monster statistics and general play difficulty a LOT. I want the game to be accessible but not too easy.
  11. I have sent out the announcement and links to the beta testing team!
  12. I use a Magnavox Professional RGB Monitor 80, model 8CM575. I have several back up monitors of this type now. I kind of like the old NTSC look, it does some nice things artistically to the pixels.
  13. Yes, I meant in the context of registers. Unlike the 8086 design where you can access the high or low byte of a register independently. Memory to memory everything is wide open. You can even cheat a bit and use the actual workspace pointer address to get to your register low-byte. If you are using >8300 for your workspace registers, then the low byte of R0 is >8301, for example. If you are in a context switch via BLWP, you can use @>0001(R13) to get to the low byte of the calling routine's R0. You get a LOT of bugs though coming up from the memory-to-byte considerations. For example: If you do a CLR op-code for example, it only works on whole words. But if you try and use an index value, indices are always in byte counts, so the first word is at index 0, second word at index 2, and so forth. So if you want to clear byte-only data, using CLR can over-write something you didn't intend to if you have an odd-number of bytes in an array. You're better served just using a MOVB @ZERO,*R1+ approach to ensure your data is cleared correctly.
  14. Hi and welcome! The TMS9900 architecture is substantially different, not just from the 6502 but from the 8086 as well. It has some strong advantages but disadvantages too. One thing to note is that there is no accumulator, you can do many operations on registers to registers, registers to memory, memory to registers, and even memory to memory! So doing a MOV @THIS,@THAT is totally fine, where both of those are just addresses in memory. The reason is that the registers themselves are just in memory, which allows you to switch quickly to different register sets. The advantage is flexibility, the disadvantage is a general latency overall as it takes extra clock cycles. There is a 256 byte RAM area in the base console (called the scratch pad) which is true 16-bit access memory, most of us use that space for registers as often as we can as it gains us some speed by cutting out a 4-cycle delay on every memory access. Some op-codes require registers as either the source or destination. All the immediate instructions (Add Immediate, Compare Immediate) only work with registers. This isn't a limit of the architecture so much as just a limit of opcode decoding. An important consideration though is that all the op-codes on the TI are 2 bytes. So the MOV operation I noted above is actually 6 bytes. While we can get more done in far less instructions than a 6502, they do consume more memory. On the other hand, we do have unsigned Multiply and Divide op-codes, which save a lot of memory to use. (Although you'll hear a lot of guys grumbling how divide takes too long.) Also, because of the way the address lines on the TI work, there are byte and word equivalent instructions for most everything (Compare verses Compare Byte, Add verses Add Byte, and so forth). The byte versions only work on the first/high byte, you have to use shifts or a swap byte opcode to access the other byte. I don't have immediate answers about your CRU questions, but I will point you to a grand resource: The TI-99/4a Tech Pages You'll find answers for a lot of the hardware and architecture design there.
  15. An audio upgrade, even a simple one, is a welcome addition to the TI. My own experiments with both sound and music have left me feeling like the sound chip in the TI is rather like the 2019 Seattle Seahawks defense... fair to mediocre. I wouldn't compare it to a SID, since that was made in a much later period, but even compared to other chips, the frequency range is not as wide. (The MSX machines had 12-bit frequencies verses 10-bit, for example.) Plus the architecture using the 3mhz clock as a divider causes it to push all the octaves up, pretty much making base sound impossible. So I'd be happy to acquire a SID-Master and see what can be done with it!
×
×
  • Create New...