Jump to content

ZeroByte

Members
  • Posts

    564
  • Joined

  • Last visited

  • Days Won

    39

ZeroByte last won the day on December 4 2021

ZeroByte had the most liked content!

1 Follower

Recent Profile Visitors

786 profile views

ZeroByte's Achievements

  1. Someone needs to support that device in MAME and make more hats for other chips like OPM, OPN, etc. That'd be awesome.
  2. Why not just put an openssh daemon in front of a TTY and lie to WWIV and tell it it's a serial connection? Make all the init strings blanks. I think the only thing that might need to be messed with is the whole "ring/answer" thing that the software would expect to have to do... It would save all that extra code hacking on the comm side of things. All that would remain would be either a mod or middleware to make it think the forums' DB are its own DB.
  3. More or less true for me, with the one exception being that I'd like the ability to send messages to the mouse so that Intellimouse mode support is possible, even if not via the Kernal.
  4. And if your BBS interface works like WWIV, I'd be like
  5. You'd want to make a big flashing red disclaimer that people's forum password should be one they have not used anywhere else if they plan on accessing an unencrypted interface.
  6. Most classic games seem to do this kind of enemy as tiles in the BG layer. That would certainly cut down the CPU time required to keep track of them and move them along with the scroll....
  7. From the looks of your rasterbar at the sides of the screen, you're doing fairly well CPU-wise except for a few frames where it takes the whole screen's worth of raster time... is that an artifact of the GIF creation, or is it really hitting some super-expensive snag every once in a while? Also - is this done in C or ASM? Given the thread topic, I'm guessing ASM...
  8. BBS over SSH. Don't forget to have a Tradewars door game on it.
  9. Sites like this offer features and functionality that just aren't possible / reasonable on sites like Facebook. Social media is all in the here and now. Sites like this have more permanence. If someone announces a game on the FB group, for instance, it will get focus for a little while and then fade into the past, whereas a thread about it is much more searchable and focused. To me, the number 1 feature is the software area. Once a project is uploaded there, it remains visible and accessible where on FB it would quickly fade into the past as new posts push it out of view. I totally get why Dave et al would consider it an extra workload to have yet another inbox to check, and why they may not be interested in participating directly, but the site is very important to me and many others. Having team members who run the community is just as important as team members who crunch kernal code or test HW designs. In fact, this is the one job that will continue to exist once the HW and Kernal are finally done and "in production."
  10. Number of sprites definitely puts load on the program even when the video card can easily accomplish it. Consider that the sprites' X/Y/"frame" information is 5 bytes. For 128 sprites, this alone is 2 1/2 pages of memory that you need to update into VRAM on every frame (potentially) - If you only update the ones with changes, that reduces the amount of data to be moved, yes, but it increases the complexity of the algorithm, which now needs to evaluate data on each pass to determine which registers need to be updated and which don't - this is usually more expensive than just blitting the sprite register updates into the registers whether they've changed or not.
  11. Thanks to everyone for picking up the ball on this one. This site is a fantastic resource.
  12. A lot of the older arcade games used dedicated circuits to produce a particular sound effect. I think Donkey Kong used that kind of tech as well. Nice project there, man!
  13. It's probably better to eschew the "instructions" count, given that the underlying reality is clock cycles and not instructions. Using Tom's numbers, you come up with ~254 clocks per scanline. I try to avoid using (ZP),Y addressing where feasible, and where not, I also tend to use page-aligned pointers in ZP because of the page-boundary-crossing penalty / slower check for non-zero Y exit value. I don't have all of the clock cycle counts memorized for the various instructions - I just bear in mind what the CPU does and that helps remember: implied-mode instructions like inx, rol, sei, etc.... those are all 2 clocks. Essentially one clock to read the instruction, and one clock to do it. 1-byte operand instructions tend to be 3 clock minimum. 2 clocks to read the instruction and operand, and one to do it. 2-byte operand instructions are essentially take 4 clocks: 3 to read the opcode + 2-byte instruction, and 1 to do it. So then the (ZP),Y mode makes sense why it's 5 or 6 clocks to execute: It has to read 2 bytes to get the instruction, then it has to read 2 bytes to get the address it needs to read from, and if ZP+Y causes an overflow, it takes an extra clock to inc the page portion of the target address. Then it takes 1 clock to actually get the byte from memory into the accumulator. Hence 5 or 6 clocks to execute.
  14. If you're dealing in PCM, you're probably going to need to make that part of the code using assembly. I recently implemented a non-mixing PCM streaming routine in my zsound library (that I'm planning to share soon with the community). Just a single stream that does nothing but write into the FIFO takes quite a bit of CPU if you're not careful. For instance, my initial implementation took over 40k clock cycles (about 33% CPU) just to move the data into the FIFO for a 22K/16bit/stereo sound. After a few re-works, I got it shaved down to ~16k CPU cycles for the same stream, but this used several tricks like self modifying code and loop unrolling. If you're mixing 2 streams in C, that could be taking up most of your CPU. Another unfortunate truth right now is that the current Keyboard polling routine in R38 / R39 is VERY slow (due to the nature of PS/2) - just pressing a couple of keys causes the VSYNC IRQ handler to run well into the visible frame ~20% or more of the way)
  15. The YM2151 is at a different base address in R39 as well. It moved from 9F80 to 9F40
×
×
  • Create New...

Important Information

Please review our Terms of Use