Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/29/21 in all areas

  1. I am planning the r39 release for this weekend.
    6 points
  2. https://youtu.be/tPZNQcl0JYE I've written a proof-of-concept program that uses the actual AdLib music data from Wolfenstein3d and plays it back on the YM2151 chip by translating the register writes from OPL commands into their equivalent OPM (2151) commands if possible. There is still work to be done. The vibrato effects are definitely doable, but the translation is going to take some consideration on my part, as the two chips do it in very different ways. The Wolf3d title screen music does not make use of percussion mode (as far as I could tell) but obviously a true translation driver must be able to handle those, and I think I'll work on doing that with the VERA PSG voices. I will post a link to the sources once I get the ability to load the titlescreen graphics, etc. from within the program itself. (my vload() function doesn't seem to work properly).
    3 points
  3. Hey, Peri... my keycaps arrived on Saturday, and I just now got them installed. They look great on my Velocifire keyboard. As you can see, the white backlighting makes the keys usable even in a dark room, although I'll probably never use the backlight under normal circumstances. Thanks again for the option to buy the keycaps. I'm 100% pleased with them, and having a wireless PETSCII keyboard for my emulation machine is a dream come true.
    3 points
  4. Ran across a few more good ones that made me feel nostalgic. haha The "Konami Code", playing Phantasy Star online on my Sega Saturn, the glorious days of loading games from cassette, and how I feel about a lot of modern "retro" games. So many memories. :)
    2 points
  5. The current "master" branches of the x16-rom, x16-emulator and x16-docs repositories now correspond to the "Proto #2" hardware, which is incompatible with the "Proto #1". banking is now done though zero page addresses 0 and 1 instead of VIA GPIOs the I/O area at $9F00-$9FFF has changed in layout (except VERA) the layout of the VIA GPIOs has changed 4 SNES controllers are supported there is now a real-time-clock – but it is not yet supported by the emulator or ROM If you have software that does manual banking or accesses I/O devices (other than VERA) manually, you will need to update it in order to be compatible with the next emulator/ROM release (r39) as well as real hardware. The Programmer's Reference Guide should have all the necessary information. Please file bugs on GitHub if you find any issues. Thanks!
    1 point
  6. Wolfenstein 3D - raycasting demo with textures View File Raycaster demo (written in c and assembly) This version is a big improvement in performance: it now runs at 10+ fps! I am quite happy with the speed. The demo plays quite nicely now. See below description of version 1.3.0 for details. --- This is a raycaster demo written in c and assembly for the Commander x16. I've been trying out the x16 and thought it would be a cool idea to start working on a raycaster. Ultimately it would be great if "Wolfenstein 3D" can somehow be ported to the x16. That would be a BIG challenge though! This is how it looks now: Speed improvements in 1.3.0: Now running at 10+ fps! - Using zero page addresses for pretty much all my variables - Using fast multipliers that use "square" tables: https://codebase64.org/doku.php?id=base:seriously_fast_multiplication - Inlined the fast multipliers, so less copying of values, no jsr and rts - Re-using the somewhat "static" parts of the multiplications, so it won't be re-loaded/calculate each ray (this was harder than it sounds, quite of bit of refactoring done) - Cosine and Sine fractions are player-related, and even though they are negated sometimes, they (that is their squares) could be reused for (almost) each ray - The (square of the) fraction of the tile the player is standing in -to be used for calculating the initial x/y interception for each ray- could be reused - Cleaned up the main loop and several other parts - Replaced the 16-bit slow divider with a 512-entry table: distance2height (major improvement!!) New in this version 1.2.0: - draw functions have been ported to assembly. Much faster! - dda casting functions have been ported to assembly. Much faster! - drawing textures! - automatic generation of routine to draw ceiling and floor (only 4 cycles per plain pixel) - automatic generation of around 512 routines for drawing textures (only 8 cycles per textures pixel) - using joystick controls (you can use arrow keys and alt to control, you can hold down keys) - a few textures from Wolfenstein 3D (shareware version) have been added (loaded at startup) - changed the map to look like the first level in Wolfenstein 3D - added a border around the render area, just like Wolfenstein 3D Usage Unpack the zip. Make sure you have the .BIN files in the same folder as the source files. To compile: (this assumes cc65 is installed) cl65 -t cx16 -o RAY.PRG ray.c ray_asm.asm -O3 To run: x16emu.exe -prg RAY.PRG -run To play: up - move forwards down - move backwards left - turn left right - turn right alt-left - strafe left alt-right - strafe right To debug: p - turn on log screen o - turn off log screen t - turn on test ray l - rotate test ray left j - rotate test ray right Known issues (1.2.0) - Sometimes there is a corner of a wall not drawn correctly - Since there is no real V-sync you get "shearing" in the screen (requires double buffering) Next up: - Lots of speed improvements - Lots of cleanup of code (its messy now) - Add a time-per-frame indicator (using a vsync interrupt counter) - Mooaarr wall-textures! - Double buffer to prevent shearing - Show a map on the screen - Bigger map (limit is now 16x16) - Opening doors - Add (scaled) "sprites" - Lamps (scaled) hanging from ceiling - Stats in lower part, gun visible - AI, enemies Having fun! Jeffrey Submitter Jeffrey Submitted 02/19/21 Category Demos  
    1 point
  7. I will check. I probably didn't install CLANG since I do mostly c# development. ** yeah, I had to dig into the Optional Components to explicitly install it. I'm doing that now. I also managed to get the Linux version and the ROMs to compile, so I'm just working on a Windows executable.
    1 point
  8. Here is my speculation: It's the low impedance of the scope probe. Try switching to 10x mode.
    1 point
  9. Wow that looks even better than I expected. You’re welcome! Perifractic, X16 Visual Designer http://youtube.com/perifractic
    1 point
  10. Can you please put this comment into the pull request on GitHub? Thanks!
    1 point
  11. I've been trying to adjust X16 Edit for the upcoming R39 Emulator+Kernal. As far as I can see, there are no issues whatsoever. I attach my R39-test (sources on Github in branch "prepare-for-R39"). https://github.com/stefan-b-jakobsson/x16-edit/tree/prepare-for-R39 Running it requires you to download and compile both the emulator and the Kernal from Github. If you haven't noticed, @Michael Steil merged most pending pull request for the Kernal during the end of last week and the weekend. I guess he is actively working towards R39. Happy times! X16EDIT-R39-TEST.PRG
    1 point
  12. VLOAD is documented in a pull request. I'm surprised that Michael hasn't merged it yet. https://github.com/commanderx16/x16-docs/pull/46/files
    1 point
  13. alpha xForth Compiler View File NOTE: v0.1.4 seems to have fixed or reduced the severity of the corrupted dictionary in v1.3. Known Bugs: .S may give spurious results. DOES> is broken, do not attempt to use it. ________________________________________________________________ I just uploaded this to see if it runs in the try it now box. It appears to run fine, including the words that operate programmatically based on the width of the display. With some work with an effective in system Monitor program, it would be possible to save a copy of xForth including words you have defined on the console, but for practical purposes, this still requires a SAVE word to be able to save an image of the file after extending, and an INCLUDE word to load a script from a .SEQ file. Once those are written, I will be able to test to see how close to American National Standards Forth (ANS Forth) compliance this system actually comes. While it runs, it is not fully exercised, so I would be very surprised if there were not bugs. "Alpha" in the title means that there ARE bugs, though I fixed two substantial ones since the last release. Bug reports & suggested bug fixes both accepted, the first dutifully and the second gleefully. About upper and lower case: there is NO ASCII CONVERSION in this system. ANS Forth requires that ANS standard words be recognized in upper case, and its up to the individual Forth what they do about lower case. Most modern Forths are not case sensitive. This one is. So if you are in Graphics mode, do EVERYTHING in upper case. If you switch to Upper/Lower case mode, do EVERYTHING in lower case. If you enter the command WORDS to see all of the words in the dictionary, you will note some that look like /FORTH/ which is what I did when eForth had lower case words that were "platform" words that the standard Forth word in upper case was built upon. You will also see /DO/ /?DO/ and /LOOP/ as the "platform" words that DO ?DO and LOOP are built upon. No conversion also means the the line comment word \ is entered and shown as the English Pound Sterling, aka GBP, sign, _ is backarrow, and ^ is up arrow. On the command line, any character from $00 to space is treated as whitespace, as is any character from $80 to Non-Break-Space ($A0). For some brief usage examples and pointer to more about the Forth programming language, see the discussion forum posts attached to this upload. Submitter BruceMcF Submitted 08/28/20 Category Dev Tools  
    1 point
  14. This is one of the more admired YM2151 tunes, from the arcade version of After Burner II. Sega used the YM2151 with a multi-channel PCM for most of their cabinets from the mid-80s through the mid-90s. This has sampled drums coming from the PCMs, but most of the instrumentation is FM. You could get VERY close to this on the X16, if you are willing to dedicate most of your banked RAM to FM instructions and samples. The samples would need to be lower-bitrate, but for drums that doesn't really matter as much.
    1 point
  15. Well I decided to go with some PAL's to clean up the addressing logic, it runs for hours at 11mhz on the breadboard, and only a few minutes @ 12mhz. The data lines get an occasional weird artifact on high, but the address lines look pretty good, there is some small artificating here and there but doesn't seem to cause any issues, and may well be the cheapish scope.. The ROM is only 70NS so it's surprising it runs at all at 12mhz, with address setup time that's 100ns, in an only 83ns cycle. I did enable the rom on low clock to try to squeeze some extra performance out of it, all other OE/Write's are done on the rising edge of the clock. The flipflops do set the outputs low on reset, but I'm having trouble latching them, I get random results, not sure, but I think I may have fried them. I need to pull them out of the circuit to test them by themselves. Also strangely enough, I bought a 8mhz crystal and it says it's a hcmos output, but the wave looks like a shark tooth and my computer wont run with it, but using the wave generator I've had it running all the way up to 14mhz, although not very stable. The wave at 11mhz on the signal generator isn't very square, but it still works. Trying to figure out why the 8mhz oscillator doesn't..... Should I be shooting for something that produces more of a square wave, or is that even possible at those speeds? Or maybe my scope lacks the resolution??
    1 point
  16. THANKS!!! One small thing wrong with your solution, the first argument is 2 for bank 0, and 3 for bank 1. My previous code used bank+2 in that spot. The thing that was broken about my previous code was my values for SETLFS, which I had previously used 2,1,0 - not sure where the heck I came up with those numbers. The code I lifted that from was last built/used in 2019 (in my X16 port of Flappy Bird, which I'm about to dust off and complete now that this AdLib driver proof-of-concept works.) So for those reading along, I used this: static void vload(const char* filename, const uint8_t bank, const uint16_t address) { cbm_k_setnam(filename); cbm_k_setlfs(0,8,0); cbm_k_load(bank+2,address); // bank+2 is a special functionality of X16 LOAD } Now my program doesn't have the garbage across the bottom, and it auto-loads correctly without the VLOAD bootstrapping I used in my video. Now I'm going to extract a few more songs and see how they sound. I think I'll make a video with the various songs. Lastly, I'm cleaning up my code for public display and will post it to GitHub for the community's use.
    1 point
  17. I hacked together a test to see the impact of sprite-level alpha blending on one of those cheap Cyclone II EP2C5 FPGA boards that I had lying around. The good news is that it didn't it consume any hardware multipliers; the bad news is that the impact to the number of logic elements was much higher than I think is reasonable - ~50 LEs per color channel. Visually the results looked about right. (The "sprite" is the square between the yellow and cyan bars. It's 100% white, but here has an alpha of either 75% or 25%, I forget which way I set the logic.)
    1 point
  18. In short, the 6502 doesn't do floating point at all. You need to implement it with 8-bit integer math. That's what BASIC does. You could absolutely implement IEEE 754 as a cc65 library, it's just going to be very slow same as any FP implementation.
    1 point
  19. Something I'm planning on doing is ordering transparent labels for my label maker; then I can add back the media control and PC-specific labels on my keycaps when they arrive... I'll stick them on the front of the key, rather than the top, much like the keys that came with the keyboard.
    1 point
  20. I've mostly been learning with gforth in the mean time. It seems like eforth (and by extension xforth) doesn't have a greater than word as default, is there any particular reason for that? All the ">" word seems to do is push 7 onto the stack.
    1 point
×
×
  • Create New...

Important Information

Please review our Terms of Use