Jump to content

ZeroByte

Members
  • Posts

    564
  • Joined

  • Last visited

  • Days Won

    39

Everything posted by ZeroByte

  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
  16. The mouse in X16 is janky. It only returns screen X Y positions and buttons. (i.e. no dX dY options) and it coopts sprite 0 even if you don't want to have a pointer on the screen. You can specify a blank sprite as sprite0 as the graphic for the pointer, but sprite 0 will be positioned at the X,Y the Kernal wants it to be. Whenever I get zsound to the point where I push it out the door, I might get back on my widget library I was working on, where I planned to counter this by making the engine hide the kernal pointer and move it back to the middle of the screen on each frame so you won't ever run into the edge of the screen and not be able to continue moving the mouse in that direction.
  17. My sound library builds for both r38 and r39 and puts both builds into the .lib file, and projects that use it can define REV=38 or REV=39 to link the correct version. The way I did it is that I submitted a PR to SlithyMatt's x16.inc file (which I have grown accustomed to using in all of my projects now) that adds support for --asm-define REV=x where x can be 38 or 39. It defaults to 38 if you don't specify this. When you do this, it creates a define _X16_VERSION_ = 38 or 39. The symbols in x16.inc use this definition to selectively define the values for ROM_BANK, RAM_BANK, YM_reg, and YM_data to the appropriate values for the two revisions. My code also has conditional sections switching on _X16_VERSION_. I came up with a system of building all files as example.o38 and example.o39 which export their symbols with appended revision tags - helloworld: is exported as helloworld38 in example.o38 and as helloworld39: in example.o39. Then anything that imports should import whichever one is appropriate and alias it with the un-tagged symbol. ( helloworld := helloworld38 ) I made macros for this: (I switch on REV and not _X16_VERSION_ in the .inc file so it doesn't require x16.inc to be included in order to work properly)
  18. To me, the X16 is like a TG16 with better graphics and sound. I think of it like 4th gen / 16bit era. Sure, the CPU’s 8bit but so was the TG16….
  19. My first “console” was a Pong machine, and it was hooked up to a black&white TV that used vacuum tubes. If I recall correctly, the controllers were the type that had a stick (not a knob) and however far it was deflected up or down controlled the paddle position. It had 4 modes but I can’t remember all of them. Regular, doubles, squash, and I think hockey…
  20. I knew better than that - it's the .A value of LOAD, not SETLFS. Whoops. (fixed my post) Thanks for pointing it out.
  21. If no VSAVE then copy the screen tile map data from 00000 to 03FFF into main memory from 5000 Then do a normal call to save giving 5000 to 8FFF as the area to save. SAVE doesn’t work right for HiRAM yet (at least not in the Kernal) which is why I suggested Main memory.
  22. Does VSAVE exist? If so just do that and do VLOAD to put it on the screen. In assembly, VLOAD is: Usual call to SETNAM/ and usual call SETLFS with A=0, X = 8 and Y=0 Then call LOAD with A=2|3 and XY = VRAM address. (A = bank+2) (edited to fix erroneous info)
  23. Can you go into a little more detail about what it is I'm looking at? I'm interested in this library as dealing with HiRam is quite a PITA. What's the narrow band at the top? Low RAM? Is data being moved between Hi and Lo RAM?
  24. Sure it would. Yamaha's FM synths dominated the Japanese market, being prevalent in FM-Towns, Sharp 68000, PC-8xx / PC-9xx, MSX machines, etc. If they had included SID cores, I think the results would be very interesting. We'd have a situation where we'd have a lot more diversity in the SID chiptune field. When I think SID, I think "techno-style" as the peak awesome SID sound, as PSG (SID in particular) dominated the scene in Europe. If there were also a body of work in the "J-pop" line, it would be very interesting. So yeah, the SID-FM combo chips would definitely have a use in home computers. It's just a question of whether the western markets would have used them more than they used FM chips in our own timeline. Maybe we'd have better synth compositions from the west if the FM+SID combo had been a thing, because SID was definitely a popular synth for chip-savvy composers back in the day. If there were a "Super SID" that also had FM channels, I think it would've made a bigger splash than FM did over here. Imagine if the Rob Hubards of the world were incorporating FM tricks into their compositions...
×
×
  • Create New...

Important Information

Please review our Terms of Use