Jump to content

ZeroByte

Members
  • Content Count

    100
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by ZeroByte

  1. Check out MatsukeN's channel on YouTube - he built MIDI cartridges to go into a real NES and one for the SNES. He and several others put on live performances playing the real tunes manually on MIDI keyboards. Their performance of Final Fantasy IV was pretty amazing - it sounded exactly like the original, but since it's being played by humans, there're micro-mistakes that you can hear it's really them playing it and not just faking while the system plays the music. Basically, there're 9 people in the SNES team - one player for each voice, and one person responsible for switching the patches on the various voices at the correct times. (each keyboard is monophonic, it would seem)
  2. Are you sure this would work on real HW? Whenever I run my Wolf3d audio demo using SD images, it takes orders of magnitude longer to load the one image into VRAM than it does when the emulator hyper-loads it (using the host FS). I'm sure the emulator is slower with SD cards than the real HW is going to be, but given that the emu is just teleporting the data into VRAM (essentially) and the real HW is still going to have to chew through it at several cycles per byte - I'm curious to see if it will be able to keep up.
  3. I've had this version of Flappy Bird done to this point for well over a year now. Due to life reasons, I had to drop out of the X16 scene for quite a while, but I've got the bug again, and decided to dust off this old code and finish this game for the X16. It was written for R31 so a _LOT_ changed since then, and it's been quite a headache refactoring all of the various bit shifts into the various VERA registers, but it's back to the point where it compiles and runs correctly, so I should be able to start making forward progress again, and if I stick to my guns and stick to writing sloppy non-project-worthy code, I should be able to have a playable version soon. However, if my TYPE-A self wins, I'm going to spend the next 2 weeks refactoring the code into modules and different C files, etc, and have lots of work done with no visible progress in the game. LOL. Anyway, I wanted to go ahead and put this back out into the community that I'm working on this, and I may even do a YT video going through the code, or at least a dev vlog or something.
  4. Well, the thing to remember is that there are things done in HW that help out a lot. Working in tiles is much faster than working in a bitmap (frame buffer) because you only have 40x30 / 80x60 memory addresses to update if you decide to make "all tiles use the same color palette" as a constraint. Scrolling is faster in VERA than on, say the C64 because while the C64 supports smooth scrolling, it can only smooth scroll up to 8px, so you have to cascade your entire screen's tilemap down each time you scroll 8px, but VERA can scroll up to 1024px w/o having to touch the tiles at all - so you only have to update one column of tiles at a time if you want to keep scrolling wider than 1024/tilesize. I'm doodling around to see if I can get a working version of Space Invaders using BASIC - leveraging this kind of "HW acceleration" So the X16 BASIC is faster because the CPU itself is faster, but the GFX and sound HW also help speed things up too. (FM music may be tricky to make good-sounding patches, but once set, you can play a sound with just two pokes, potentially) The X16 hits a nice sweet spot where it's definitely a lot more powerful than the classic 8-bit systems were, but it still imposes some serious limitations so it's not just like having infinite resources. For instance it can show 640x480 bitmaps, and it can display 8bit color, but an 8bit 640x480 bitmap is $4b000 bytes, but VERA only has $1fa00 bytes of VRAM, so you can either do 640x480 @ 2bpp color depth, and even then you're using $12c00 bytes of VRAM.
  5. I'd be happy if it just worked like DOS - dir, delete, rename, move, cd, etc... and execute a file by just typing its name. This should be able to replace the BASIC environment if you so chose - i.e. burn a ROM with this shell in one of the unused banks, and make it executable by a SYS call or something. You could pick and choose which Kernal calls to use to make your life easier in building the thing. Last, just build in the command to return to BASIC be 'basic' and then it just does RTS.
  6. And since OP wants FPS anyway, all he has to do is use the jiffies directly, since they inc++ once per frame anyway. starttime = RDTIM <render a few dozen frames (nFrames)> fps = RDTIM-starttime / nFrames I'd suggest 64 frames, so you can just do RDTIM-starttime >> 6 to compute FPS
  7. Okay - once this comes out, someone needs to make a demo doing the Death Star trench run briefing animation, and streaming the audio from disk to accompany the animation.
  8. My dream combo would be to have all of the PSG/FM/etc type of chips in one big bank to hook up to MAME and have it use the real HW for all non-digi-sample sounds. I imagine something like a giant stack of Arduino shields with one chip each, and the arduino itself providing the USB service to pipe the results back to the computer as if it were a USB microphone or something. I can't put my finger on it, but something about the sounds in the Capcom CPS1 games like Strider and Ghouls N' Ghosts have certain SFX that sound just plain /wrong/ to me - I've even found a video or two on YT where someone was comparing real HW Ghouls N' Ghosts to MAME - but unfortunately the stuff they featured didn't include the sound I wanted to hear on real HW.
  9. It’s a shame PS2 sends 11 bits because the VIA has built-in shift register functionality, but only 8 bits wide. The VIA could shift in the PS2 data automatically and the kernel could just read the latched value at leisure. But not only are there too many bits, there are also too many bytes... maybe VIA could pause the PS2 device between each byte but the problem remains that the parity and stop bits will push the 2 MSB of the keycode out of the latch. now, the joysticks don’t have this problem. THEY return 8 bits per latch (rather 16 but that’s just two runs of shifting in 8 bits) However, I bet the clock/latch pins of the controller ports aren’t connected to the correct pins of the VIA to do this in HW. If this is the case, understandably, they’re not going to redesign the board to leverage this. now I’m curious and gonna go look that up... lol Update: Confirmed - the emulator's via.h specifies that the DATA pins of the controllers 0..4 are connected to VIA1:PA7..PA4, and the common latch/clock pins are driven by PA2 and PA3, respectively. The shift register uses CB1 and CB2. Using these, it would've been possible to do hardware-accelerated joystick polling, but it would've limited the system to using one joystick per VIA, and would still have required one data pin to be an output for sending latch commands to the controllers. Using SR mode 2, the VIA would shift in 8 bits from the controller every time you read from the shift register. Mode 2 means shift one bit each clock cycle, and stop after shifting 8 bits. So in this regime, you can assume the latch holds the previous value shifted in (except for the very first time, which could be done once during system init to seed this). You would just read from the latch however many bytes you want from the controller, and prior to reading the last byte (every byte for NES, every other byte for SNES), you would set and clear the latch pin so the final read will simultaneously trigger the VIA to shift in the first byte of this latching.
  10. Doesn’t the system API give the ability to intercept these various hot keys and consume them in the application instead? In the case of ^X obviously this isn’t necessary for the emulator, but it would be nice if it could do this for the printscreen/ pause-Brk keys as those have X16 functionality planned if the custom key caps are any indication... Right now, both Linux and Windows use PrintScreen as a screenshot hot key, but the X16 seems geared to use that as 40/80 COL mode switch... I’d like it if the emu could override the screenshot function and consume the keystroke so the X16 can use that key as it appears on the X16 kbd.
  11. This is pretty awesome. One quick bug report: ^V does not do pageDn as documented in the online help - F8 works though. Is there a plan to support the Home/End and PgDn/PgUp keys? I use those like CRAZY whenever I'm coding (I imagine most ppl do). I think having a real editor like this, an assembler, and a few basic tools such as sprite / sfx editors would be hella-useful to have in the ROM of the system to encourage on-system development.
  12. The existing routine should work so long as the locations it reads values from have not changed. The SNES pad will work in NES mode - A, X, L, and R are inop in this mode, and B->NES A, Y->NES B. Start, Select, and D-Pad are identical.
  13. Version 1.0.0

    15 downloads

    This demo uses the real music data from Wolfenstein3d to play back on the X16's YM2151 FM synth chip. Some features of the audio translation are not yet implemented, but the program now plays correct pitch in R38 of the emulator. I will update this posting to my R39 build when that is released officially. The "Try It Now" feature works, but at least for me, the playback is quite choppy - the emulator itself has no problem with the playback, though. Next update will be to make the songs selectable at runtime.
  14. VOPL "Virtual OPL" Demo - realtime playback on OPM chip View File This demo uses the real music data from Wolfenstein3d to play back on the X16's YM2151 FM synth chip. Some features of the audio translation are not yet implemented, but the program now plays correct pitch in R38 of the emulator. I will update this posting to my R39 build when that is released officially. The "Try It Now" feature works, but at least for me, the playback is quite choppy - the emulator itself has no problem with the playback, though. Next update will be to make the songs selectable at runtime. Submitter ZeroByte Submitted 04/06/21 Category Demos  
  15. And thankfully, R39 seems to work just as well with SD images and with the host FS. The discrepancies between these two "modes" was making me pull my hair out because I wasn't expecting the results I was(n't) getting in various situations. My most recent demo works just as well in either case on R39 w/o any code changes. (Thanks for all the hard work, devs!)
  16. Thanks for explaining this - I've had similar thoughts and figured there were good reasons, and this is a really REALLY good reason.
  17. Okay, I've cleaned up the code to where I'm not totally ashamed of myself, and written a lot of documentation. https://github.com/ZeroByteOrg/vopl-demo/ There is still plenty to do with this - for instance make the main program load the music directly from the Wolf3d audio files instead of having it linked in as a C array in a big fat .H file. As it stands, you can extract any song from the WL1 data using the chunks tool and recompile the demo. There is a #define at the top which can be uncommented to use current pre-R39 support. The main differences are the banking register location (used to bank in kernal jiffy counter for waitvsync()), YM base address, and YM clock frequency. R39 will use a corrected clock rate. My program uses different LUT values for the two clock rates, so the output is pitch-correct, regardless of which version you build. I will probably work on my Flappy Bird game a little bit now, and after that, come back to this project to convert it to ASM and enhance the fidelity and hopefully get it into a state where it's available as a library to use in your own programs w/o the Wolf3d front end. @Jeffrey - feel free to cram this into your program if you want to try - it probably won't be easy in its current state, as it uses ram very very liberally right now. I'm working on a fast freq. conversion that should only need 128 bytes of RAM instead of 8k.
  18. I just found it a few minutes ago myself. I'm going to keep using my own C rendition of this function myvsync() until R39 is finalized - I am not having trouble with anything else at the moment, so I'm going to stand pat on my copy of cc65 until R39 has been out long enough for the cc65 gurus to patch that up to match.
  19. Annnnnnnd it's gone! Looks like the RTC is going to be supported now and the timej variable isn't being set in the same way - or at least the location your mod for waitvsync() uses doesn't work for me with a fresh download of the rom and emulator....
  20. Obviously, not to be confused with BASIC command SCREEN. $FFED looks like a Kernal API call - how stable are the locations of X and Y after SYS calls? Is that "written in stone" by now, or "subject to change if M.Steil needs to move them around? I guess they've gotta be read SOMEHOW. Thanks for the tip!
  21. The docs tell me there's a SCREEN command to set some screen modes, including SCREEN $FF to toggle between modes 0 (80col txt) and 2 (40col txt). I've perused the Programmer's Reference, but don't see any BASIC command to GET the current value of this. I ask because my BASIC program is going to set the mode, and at the end, I'd like to return it to whatever it was when I found it. Is there such a command, or is there some memory location I should PEEK() to determine this?
  22. It's really going to be the viability of the cc65 tool chain that dictates when I migrate, so this is good news.
  23. LOL - yeah, the BSD license reads to me kind of like they say strange matter behaves - it turns anything it touches into strange matter as well. It's like a viral midas touch. I'm not the biggest Richard Stallman fan, but his contributions to the world cannot be denied. I mean, hell, I'm on a Linux box writing this post, and a large portion of the stuff that makes it a usable OS is GNU software.
  24. I think I'm just going to release most of my stuff into public domain - lol.
  25. So what is it about GPL that is so incompatible? I mean, I haven't gotten out my legalese decoder kit and started reading to know what it is. Every time I read GPL, it seems like it basically says "anyone can do anything except not include the source and the list of changes" - is it this last proviso? I have been finding several emu projects that have good VIA support, but they all seem to be using GPL because, at least from my own perspective, that's "just the one everybody uses" - I think I'd rather go hungry than be a lawyer, so if there's a TL;DR version of why GPL is incompatible with BSD licensing, I'm very curious. I mean, I've even used plenty of proprietary closed-source commercial applications and devices which made use of GPL software, and there's usually a README or "ABOUT" page that mentions the presence of opensource code being available upon request / available in the "extra crap" folder, etc... Couldn't x16emu do the same thing - i.e. include a GPL license for the YM code and make that an explicitly-mentioned thing in the sources / license documents? Again, I'm not legal-savvy so this is an "educate me plz" post, not a "let's do this and everything will be fine" post. I suspect it's the part that says nothing more restrictive can ever happen to this code... (section 6)
×
×
  • Create New...

Important Information

Please review our Terms of Use