Jump to content

ZeroByte

Members
  • Content Count

    127
  • Joined

  • Last visited

  • Days Won

    5

ZeroByte last won the day on April 14

ZeroByte had the most liked content!

Community Reputation

95 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. M00dawg is working on that as far as unique CX16 sound goes. Using Deflemask to make YM2151 tracks is immediately doable, and with some preprocessing, you could strip VGM down to something barebones like IMF which is very low overhead to play back.
  2. I'd forgotten what it was like having the ability to just type in "PRINT 640 / 2 / 30" or something like that when figuring out some value to put into a line of BASIC code. The X16 project brought back stuff like that for me. Right now, I'm doing all of my stuff in cross-assembly/compilation but sometimes if I just want to check something, I pop up an emu and throw in a little BASIC to do a proof-of-concept - to make sure I understand correctly how such-and-such register operates.
  3. I haven't done X redirection in quite a long while, but one thing I found back in the day was that the app (Netscape, if that's any indicator) actually ran FASTER over X because the host machine (a 386 in the Pentium era) didn't have to do all of the graphic stuff like layering the windows. I don't know how an SDL application would fare in these conditions. As far as sound, you'd need to run a remote sound session in parallel to the X session if you want the emu's audio to come through. I did this once with ess - not sure if modern sound stuff like Alsa, PulseAudio, Jack, etc have such hooks, but it wouldn't surprise me. Accomplishing the X portion shouldn't be hard though - install some kind of X server on your main PC (I don't have any recommendations - it's been ages) and configure it to allow remote connections. Then on the Linux box, before running the emu, just issue the command "export DISPLAY=ip.of.host.pc:0" - where 0 would be the display ID that your X server uses to refer to monitor 0. The specifics of that would be in the xserver configuration, not the Linux box.
  4. Just linked a short clip of it because the whole video is more cringe than I can handle.....
  5. I don't know about the rest of y'all, but back in the day, I was quite the little buccaneer when it came to my software library on my C64. I estimate that only 1:10 of my floppies were official game floppies, and the rest were Bonus brand single-sided disks having the write-protect notch cut on the reverse side using a hole punch. Fast Hack'M (also on a Bonus disk) stayed near the front of my organizer. Almost all of my games had loaders with better music than the ensuing game, plus some combination of raster bars, smooth-scrolling text (greets), or self-congratulatory paragraphs talking about how few minutes it took to crack this particular title / how many cracks the author had done, etc. Some of my fondest C64 memories include finding other games on floppies I'd copied while at a friend's house, or having a 'sleep-over' where sleep = hooking 2 drives to the computer and doing a "git clone" of each other's library. I never had a modem, though, or else who knows how many more boxes of floppies I might have needed...
  6. ZeroByte

    1980's Memes

    Good ol' dual-deck cassette boom boxes were everywhere back then - and to think how the RIAA howled that they enabled music piracy, yet it also enabled software piracy too! History shows that this didn't matter - people still got rich making music and video games anyway, piracy notwithstanding.
  7. Or make a faceplate that fits, but houses one of those modules with the SD+USB+speaker jacks combos like you find on the front of modern PCs.
  8. If I knew FPGA and ISA, I'd totally make a real 16-bit ISA video card that did all this, just to see a 286 that can belt out late-80s-arcade quality games with scrolling and sprites and such. -- of course, someone would have to WRITE said awesome arcade-quality-game to utilize this video card, but it would be cool if they did, right? I guess it's the Monster2d video card?
  9. My "inception" moment was when I needed to fix a borked startup_config.txt on a virtual Cisco router appliance. The chain was: HostPC -> VMWare Linux box -> qemu Linux box -> Cisco Virtual IOS To fix, I had to log into the qemu linux box, and then use loopback device tools to mount the qcow image of the router appliance's filesystem. THAT filesystem in turn contained yet another image file: the NVRAM image where the startup_config.txt is located. Unfortunately, this FS was of a type that Linux didn't support, so the inception stopped there. Fortunately, I could still "cat nvram.img | strings" to get the config out, and then rename the file so the router would boot as default (no nvram = default). Then I fixed the config on the host PC and copy/pasted the modified config into the prompt of the now-defaulted virtual router. EASY! The config was broken in a way as to disallow any and all command line access, and I couldn't find any docs on how to boot the router in "ignore start config" mode - plus this way was more fun.
  10. Version 1.0.1

    5 downloads

    This is a simple quality-of-life bash script I wrote. It makes it easy to install multiple versions of the emulator on the same system and run them from any arbitrary place. I have a directory ~/x16emu where I then create subdirectories for each revision, e.g. ~/x16emu/r38 The r38 folder is just the contents of the release .zip file (x16emu, rom.bin, kernal.sym, etc) I place this bash script in the path (e.g. /usr/local/bin) and rename it x16emu. Now you can launch any revision by typing x16emu -v r38 and all other arguments are passed through to the actual emulator. Furthermore, if you want to use a custom ROM image and put -rom /path/to/customrom.bin , then the bash script uses that and does not send its own auto-generated -rom argument.
  11. Multi version emu launch script View File This is a simple quality-of-life bash script I wrote. It makes it easy to install multiple versions of the emulator on the same system and run them from any arbitrary place. I have a directory ~/x16emu where I then create subdirectories for each revision, e.g. ~/x16emu/r38 The r38 folder is just the contents of the release .zip file (x16emu, rom.bin, kernal.sym, etc) I place this bash script in the path (e.g. /usr/local/bin) and rename it x16emu. Now you can launch any revision by typing x16emu -v r38 and all other arguments are passed through to the actual emulator. Furthermore, if you want to use a custom ROM image and put -rom /path/to/customrom.bin , then the bash script uses that and does not send its own auto-generated -rom argument. Submitter ZeroByte Submitted 04/14/21 Category Misc Apps  
  12. The TRY IT NOW function for this program fails now. I presume that it's not updated for R38?
  13. The way it happened was that I had a global variable holding the shadow copies of the sprite regs. uint8_t spregs[16][8]; The update_bird() routine knew the bird was sprite X and would go through spregs[x][0] = VRAM_ADDR_LO ; spregs[x][1] = VRAM_ADDR_HI ; etc.... While de-globalizing this array, I decided that update_bird needed a pointer to the bird struct and a pointer to the shadow registers. I realized I could pass a pointer to just the specific sprite slot index, and the bird code could just use reg[0]=VRAM_ADDR_LO etc.... and then the function returns a pointer at the next spreg[] index. So for those reading along who aren't quite following what all this means: My original version of update_bird() was essentially written such that calling it was like saying "hey bird, go do your thing" - and now it's like "draw THIS bird HERE" - and it's up to the main program to figure out where that might be. I could have 20 birds if I wanted, and the function wouldn't care, now. Previously, it was hard-wired to just the one bird, and it was hard-wired to a particular sprite slot.
  14. Update Looks like TYPE-A me has won out. I’ve ended up spending most of my time refactoring my code into a project and using better coding habits. I’ve almost gotten rid of all global variables that don’t absolutely need to be globals, and most modules are now moved into separate files such as bird.c/.h etc. The fact that it's been so long since writing the original code has ended up being a good lesson because it’s like I'm reading someone else’s code. There were plenty of What was I THINKING? moments. The plus side is: now that everything is properly contained within its own circle of functionality, it's much quicker and easier to make use of these things in the main program. For example, I was able to quickly re-task the scoreboard as a 2-byte hex debug output tool so I can see values during execution if I need to. I have made progress in the game though. The joystick works. I was able to get the title screen knocked out in very short (for me) time last night, now that my functions don’t use global variables. Most of that time was spent implementing the "banners" - the actual title screen game loop took less than 5 minutes. The cool thing was that I was able to make the banner's position controllable by the joystick, and the scoreboard showed the X/Y coords, so I used that to choose the spot on the screen I wanted, and then just wrote the value into my code. No need to change + build + run, then go - hmm - 2 pixels up? (change build run).. no - two more pixels. (etc.) I also stumbled upon a neat method to make sprite slots dynamic so I no longer have to think about which sprite is the bird or the scoreboard etc. Each object just uses the next available one in the order I render them. Thich let me do something cool - I made the bird leave trails of the last 6 renders by just altering which sprite it rendered to on each frame. That little 'demo' aside, the nice thing is I no longer need to keep track of which objects use which sprite slots, so it's faster and easier to add/remove things as I see fit in my main game code. I can put 8 scoreboards on the screen as debug outputs, showing various things if that's what I need to do, and I don't have to account for the sprite slots in my other objects. Once I get the basic flow through all of the game states running (which also means I need to draw a few more sprites), I’ll upload the alpha .PRG so folks can try it out while I implement sound and other polish I'm planning.
×
×
  • Create New...

Important Information

Please review our Terms of Use