Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 03/14/21 in all areas

  1. 28 points
    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!
  2. 19 points
    Why we’re renaming the X16: Perifractic, X16 Visual Designer
  3. 10 points

    Version 1.0.1

    7 downloads

    This is a simple voxel demo written in 65c02 assembly. It has been tested in the r38 emulator. Press W A S D to move around. Press SPACE to quit.
  4. 9 points
    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).
  5. 9 points
    This is an unnecessarily critical and inaccurate comment, and isn’t the first time. It is not the tone we want for our forums. Please moderate your future comments before posting. I and others work extremely hard to keep the FAQ up to date and strongly dispute that “obsolete info is the norm around here”. In fact I do not believe there is one piece of obsolete info in the FAQ. And the FAQ is the single point that we send everyone to for the latest info. We are consistent about that. We cannot control somebody outside the core team mentioning to you something that they saw in a video by Kevin, and that person you chatted to labelling it an official announcement. Criticising a team who are working for free for not copying every thing that is said in a video into the already extensive FAQ is unreasonable. Michael is also not done with the new emulator version or the GitHub. You need to be more patient. The physical prototype will always be ahead of the GitHub. You also cite a wiki but as I have mentioned before, and as is clearly stated in the wiki itself, it is not official and we do not run the wiki. Would you prefer we have the fans who do run it take it down permanently if it does not meet your requirements? Finally please remember that this product has not even been released yet, nor have we taken a penny from anybody for it. We are offering unprecedented behind-the-scenes access to the development, which I don’t think has ever been done to this extent before even crowdfunding commences. Criticising us because we do not meet your high (and erroneous) standards will not be tolerated further. This thread has also run its course, with some unfriendly moments before today, so I hope everybody can just take a breath and perhaps move onto a different topic. Thank you for your understating.
  6. 8 points

    Version 1.0.0

    4 downloads

    This weekend, I decided to play with X16 BASIC using the emulator and wound up making an X16 adaptation/extension of a short program for the Plus/4 that appeared in 'The Transactor' journal decades ago. The program uses three parameters: "S" (squiggles/spokes/segments), "W" (wave factor), and "A" (amplitude). Using X16 BASIC's extensions in terms of bitmap drawing commands, it outputs a neat design with lots of color and a surprising amount of visual variety. The original Plus/4 program just plotted in black and white and had some built in limitations (and at least two bugs), but I decided to extend the program, add a menu, and upload it after I added color and decided these were fairly cool looking results from such a short simple BASIC routine. It strikes me as a cool demo because with just three core parameters, you can get an astonishing range of outputs. Of course, like many graphics demos based on stacking transcendental functions, there are combos of inputs where the functions will sort of fall apart and produce something akin to a kiddo scribbling with crayons , but there are also weird "islands" in the domain of possible parameter combinations where order re-asserts itself, both in terms of what gets drawn and how the colors play out. There are 4 'modes' of operation you can pick from the menu. You can specify inputs for S, W and A manually; the program can run a sequence with fixed S and A while incrementing W; there is a mode that tries to picks random parameters within several domains where the program produces nice outputs; and there's one that just reads the inputs from some "presets" in DATA statements. (You can of course add your own 'best of' examples by adding data statements between lines 432 and 499). I always considered myself a passable BASIC programmer, but this weekend showed me I'm really sort of rusty so please go easy on me if I did something inefficiently or especially 'dumb' in my implementation. The main output routine is extremely crunched (sorry, not sorry) and I did some further things to optimize from the original program for purposes of getting a bit more performance out of the main routine. Although it absolutely crawled on the Plus4, I think its fairly impressive on the X16 especially if you look at the sheer amount of sines, cosines, multiplications, and variable fetches /updates that occur during an entire cycle through the primary output drawing loops. The X16's 40 column mode (SCREEN $00) was used to key this in and format it, so its probably best if listed/ displayed/reviewed in that mode, Tested on emulator r.38, and I don't see anything in the pending updates for the next emulator release that would break anything here. If there are questions about why/how I did something I'll be happy to answer. In fact, if there's any interest in a more detailed write-up of this short and fairly simple program (e.g., section by section, and line-by-line), I would be happy to give it a shot, especially if there are folks new to Commodore BASIC that might find it useful. It seems to me there are many highly advanced programmers for the X16 posting on this site who are using assembly, C, and even languages they are developing themselves. Its amazing! However, its surely the case that part of the mission of the X16 is to get some newbies involved, and from where I sit, that really does mean getting some more content up here written in BASIC. Keeping that in mind, I'll probably be diving back into more old issues of The Transactor to do more conversions for the X16 and will continue to upload as long as I'm still having fun with BASIC. Cheers.
  7. 8 points

    Version 1.3.0

    199 downloads

    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
  8. 8 points
    I am planning the r39 release for this weekend.
  9. 8 points
  10. 7 points
    I just thought a little non-technical content might be nice - I came across this YouTube playlist yesterday. Its an album released in Japan, using the YM2151 as the main instrument. It obviously has some other sample-based tracks as well, but I think this is a great example of how awesome the YM2151 can actually sound when used well by a skilled composer. Tunes like this are exactly the kind of stuff I wanted to be playing in the BG of awesome retro games for the X16, and why I was such a cheerleader for having an FM chip in the system back when the FB group was the primary community.
  11. 7 points
    This demo is made possible by loading data from file directly to VERA. Each frame is three files: an audio file, an image data file, and a palette file. 20 frames per second is 60 files per second, so this is one heck of a lot of files, nearly 16000 for a four and a half minute video. They only dreamed of doing this on an 8 bit computer in the 80s, but they didn't have @Frank van den Hoef or @Michael Steil videodemo.zip
  12. 5 points
    Voxel demo screen View File This is a simple voxel demo written in 65c02 assembly. It has been tested in the r38 emulator. Press W A S D to move around. Press SPACE to quit. Submitter DrTypo Submitted 04/11/21 Category Demos  
  13. 5 points
    Another quick update. I really wanted to get the demotune working so spent some time working on that after I sorted out keeping track of the last instrument used and squishing a few bugs. It now uses 5 channels! (albeit only for a short bit). The first part is just showing the pattern changes, since you can no longer see those while the song is playing.
  14. 5 points
    Hi all, Just want to notify some progress has been made on the shoot'em up game in progress ... Space Flight - Demos - Commander X16™ Community Tile engine has been updated now, and new tiles were generated using various softwares... The explanations are in the game page ... I will post in this threat some of the details how this was all done ... Please have a look how this game is evolving ... Now that I have worked out how to use Blender, i can create bitmaps rendered from 3D models ... Sven
  15. 5 points
    Wait, I mean, Scott Robison (but since I don't use a pseudonym or handle, you probably already read that). Looks like this forum hasn't been updated much for a while, and it seemed lonely, so I thought I'd give it some love. I was born in Dallas, practically next door to 8BG. My family moved about 100 miles NE when I was 11, so still just a few hours away. I lived in Roxton TX (a tiny rural farm community in NE Texas) from 1979 to 1985 (where I graduated from high school in 1986), later still in Paris TX before moving to Utah for college and where I have remained ever since. As a kid I was fascinated with arcade games and wanted to do something like that. My little country school bought Commodore PET computers in 1982 that went virtually unused until 1985 when we finally had a computer teacher, at which point I'd already been using them extensively and knew more than she did (which is not bragging; I didn't know nearly as much as I thought I did, and she only knew what the text books told her to teach). My father bought me a Timex Sinclair 1000, and I later saved my own money to buy a C64, 1541, MPS801, a Commodore brand daisy wheel printer, 1520 plotter, and eventually a C128D & 1581. I've lost most of it to time, moves, etc. I went to college for computer science, where I was a poor student in classes that didn't interest me. All I wanted to do was program, so I ignored most classes that weren't related to programming, and left after 3.5 years having earned barely a years worth of credits. In 2016, after my children were grown and off living their own lives, I decided that if I was ever going to finish a degree, it has to be now, so I finally earned a BS in software engineering in December 2020. What I learned: college is a lot easier when you go after working in the field for 30+ years. It's still time consuming, but a few decades of maturity and life experience sure made a difference for me! I've been working as a computer programmer / software engineer for about 33 years now, for a number of companies. Some highlights of my career have been working for a DOS hard drive utilities company (Gazelle Systems, makers of QDOS [not the basis of MSDOS], BackIt, and Optune), a bulletin board software company (Clark Development Company, makers of PCBoard, where I was the lead designer and engineer of the PCBoard Programming Language), video game companies (Sculptured Software [worked primarily on a game you've never heard of called Stratosphere] and Access Software [home of many 8-bit Commodore titles, though that was before my time; I worked on Links golf simulator in the late 90s]), and radio station software (music scheduling, show preparation, music research), along with digital media sales and delivery software, software disaster recovery / business continuity for Windows based systems, and currently I work for L3Harris on defense contracting of communications systems. In addition to my software development experience, I've also worked in radio as a DJ and a talk show host on technology and politics / pop culture / general interst and have tried my hand at some YouTube videos, mainly before I went back to university and had a little more time. I have a home studio that is more geared toward audio production and voice over work, though I have done some videos. Mostly my videos have been a series titled "Messing with Scammers" where I take calls from scam callers and try to waste as much of their time as I can, working from the theory that the more of their time I can waste, the less time they are spending with others who are more likely to fall for their lies. My channel is CasaDeRobison if you are interested in seeing some of the stuff I've done. It is not nearly as compelling as RR or 8BG, probably, given the audience I'm addressing. Please note that the videos that include my face are less representative of me today, as I had gastric bypass surgery a few years ago and have gone from an all time high of about 450 lbs / 204 kg to my current weight of about 225 lbs / 102 kg (you might say I'm half the man I used to be). Some day I'll find some time to get back to YouTube, I just need to find my niche. I am still in Utah, in a town called Herriman near Salt Lake City. I miss my 8-bit days, back when you could know the computer top to bottom and left to right and everything in between. One of my university classes was on introductory digital design. I bought an FPGA trainer hoping to one day re-create my beloved C128D, perhaps my favorite computer ever. Commander X16 inspires me though to maybe go a different direction with it, and create something new but similar to the computers of old that do not have to worry about 100% compatibility with an existing platform implementation. Another idea I had about a year ago that I'd like to play with some time is to take a PC emulator, like PCem, and write a custom ROM BIOS for it that re-imagines the PC platform as a continuation of the PET / VIC-20 legacy. I think the name of this Frankensystem would be Kommodore K16 (the 16 representing the original 16 KB RAM available, of course). My thought is that it would have a fair amount of ROM for the X86 aspects of the system, plus maybe a 6502 emulator with "compatible" KERNAL / BASIC ROMS. The 6502 emulation would not try to be cycle exact, since there is no need to maintain 100% compatibility. This idea has no real utility other than curiosity and doing something unique with something ancient.
  16. 5 points
    Anybody who needs more than 128 bytes of RAM is just greedy. It was good enough for the Atari 2600!
  17. 5 points
    Short update: Now running at 10+ fps The optimizations I did (on top of the previous ones that got me to 7.5 fps) are: inlining 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 each time (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!!) I am quite happy with the speed. The demo plays quite nicely now.
  18. 5 points

    Version 1.0.0

    27 downloads

    A Sokoban clone for the Commander x16. This started out, mainly to see if I could grasp the concepts behind the x16. No sounds or music, since this is a pure puzzle game. I have put in a fun level set called 'Sasquatch IV', publicly available at http://sneezingtiger.com/sokoban/levels.html. The code for this game can be found at https://github.com/envenomator/x16Sokoban.git Have fun!
  19. 5 points
  20. 5 points
    Its starting to work in assembly: Right now its about 5fps. Can be improved quite a bit. I'll have to do some cleaning up and I would like to add some small features (maybe more than one texture). Then I'll probably release a new version. Have fun!
  21. 4 points
    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.
  22. 4 points
    Yes, the X16 is a very stimulating machine! And I'm not a 65c02 guru. I've written voxel engines on the Atari Falcon and Jaguar, and also in x86-64 assembly. But I'm new to this 8bit business. I started a couple of weeks ago with the excellent Youtube tutorials from Matt. So there may well be a few clever optimizations that could be done.
  23. 4 points
    OK. Thank you. I got it working now ...
  24. 4 points
    No, I've just started making it a few days ago. Here's a little preview of what I've got so far: edit: ripped out the keyboard control and replaced it with joystick control. But having a bit of a problem getting the buttons state in a reliable fashion atm.
  25. 4 points
    That looks great! But can you call it Flappy Chickenlips. Kthxbai. Perifractic, X16 Visual Designer http://youtube.com/perifractic
  26. 4 points
    They’ll be in touch hen-yway. Perifractic, X16 Visual Designer http://youtube.com/perifractic
  27. 4 points

    Version 1.0.0

    3 downloads

    What is double PETSCII? What is PETSCII you may ask first. PETSCII is the extended commodore text character set. This character set has been designed in such a way that it would enable simple graphics on the screen. Which would make it easy for would be programmers on the system, to make card games and so on. However easy to use, it is not easy to create very nice graphics with it.... But... This has changed somewhat. If you search for PETSCII art, you see people are trying to get cooler and cooler graphics out of PETSCII. Double Petscii is using the Commander 16's native graphics modes to overlay two layers of PETSCII graphics. This demo is an experiment in how that may be used. Tech info: -It was made with the cc65, in C. -The PETSCII mode used is lores text mode, with two layers. (40x30 chars) -All colors are standard colors. -1 Color is used as a color to be sacrificed for non black transparency, so there are 15 colors to work with, not 16. -Pictures drawn in hyperpetscii petscii online drawing program. https://hyperpyxel.com/?p=229
  28. 4 points
    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.
  29. 4 points
    Well, I guess I will kick this off with two of my favorite retro game memes that I really like. I'm a huge Doctor Who fan, so we have to start with... Ever wonder why space invaders follow their distinctive attack pattern? Invaders 101!
  30. 4 points
    The OPL->YM2151 playback driver is a success! It has some tweaking to be done, and I ended up cheating and generating a LUT for the YM equivalents of the OPL frequencies because I just couldn't think of a way to do the math in the X16 when I can't use floats or longs. You have to multiply two 16-bit values together and divide by 2^(20-x) - the OUTPUT of this is 16-bit but the process requires up to 32 bits. And concert pitches are almost all floats (226.84Hz, etc). So PHP to the rescue - loop through the entire possible frequencies the OPL can make and have a LUT that returns the YM equivalents. It could be better, as the YM can pitch shift between notes too, so this program is not a 100% OPL emulation, and actually can never be, as the OPL has some strange waveforms. The Wolf3d tune comes out sounding pretty damned close though - except that the emu still uses 4Mhz for the YM clock so the pitch is wrong. I'm going to touch a few things up tomorrow and post the results.
  31. 4 points
    The current thinking and state of play is that we will not offer a mouse in the package so we can keep the costs down. It’s not clear that the majority of users would use a mouse. If we do offer a mouse as an optional extra, it will be an unbranded white Perixx PS2 mouse that matches the case and keyboard shade of white. The middle wheel is not supported. Thanks. Perifractic, X16 Visual Designer http://youtube.com/perifractic
  32. 4 points
    Some of those are the kinds of functions I don't use often enough to remember them every time. Back in the day it is the kind of thing I might have stuck a repurposed label above those keys with reminders, though I would of course never suggest doing any such thing to such a lovely mechanism as this.
  33. 4 points
    Okay we now have a bare keycap set available via http://commanderx16.com/deluxekeycaps Currently this is not customisable as we want to keep the design standard (rather than have caps with our logo turn into a sort of MySpace free for all ) and we probably won't advertise it outside of this thread, but feel free to share it wherever you wish. Hope it helps!
  34. 4 points
    I wanted a CRT for my retro computers, but I didn’t want to deal with the weight and the size... so I found a 6 inches TV/radio combo for sale, that has video and audio input, and it was cheap! (€10, around $12). i’m really happy with my purchase, and thought you guys may appreciate it.
  35. 4 points

    Version 1.0.0

    24 downloads

    Variation of the quick sort demo, but this one using the 320x240x8bpp mode, which uses double the memory, and is that much cooler to watch Tap any key to progress from: Random Slowed down sort Random Full speed sort Back to Basic Note: that band of "non random" pixels below the middle of the screen is the default location of character tiles at $0f800 = $0ffff. This gets moved to right after screen memory at $04000 - $047ff (which is probably where it *should* default to, if you ask me :))
  36. 3 points
    I used my school art/math lab's Apple ImageWriter with a color ribbon to print out a report cover sheet for my English class. I made it using a paint program on a IIGS - the height of technology circa 1991. My English teacher was Blown. Away.
  37. 3 points
    @AndyMt I got VolksForth to work uniformly with R38 and R39 yesterday. While looking at my code, I realized that I have the simple and robust opportunity to just operate both bank switching addresses $0000/1 and $9f60/1 in tandem; this seems to work nicely and seems good enough to me for the transition period. See https://github.com/pzembrod/VolksForth/commit/fb100de9edc92dfb8db25ed97e6b7f0a4b3085fa for details. @Michael Steil One question about this approach: It seems clear to me that writing to $0000/1 has no adverse effects in R38 as there's just 2 unused RAM bytes there. How about $9f60/1 in R39? That would write to as yet unimplemented/uninstalled I/O devices in the expansion slots, right? Also, follow-up question: It seems that the release of R39 is imminent? If so, then I can hold back releasing the next VolksForth version (and, subsequently the next cc64 version) until R39 is out, and include the cleanup https://github.com/forth-ev/VolksForth/issues/33 of the temporary double switching in my next releases already.
  38. 3 points
    Hello everybody, I'm a new guy here, very interested in the CX16. I grew up with Atari machines: 800XL, ST, Falcon and Jaguar. I still have a working Falcon and Jaguar. The Jaguar is my favorite retromachine and I wrote a few small homebrew games for it. Now that makes me more of a 32 (64?) bit guy. However I came to appreciate the cleverness that went into the design of 8-bit machines. The CX16 really piqued my curiosity and I started learning 65c02 assembly with the help of Matt Heffernan tutorials. The CX16 is a cool machine to play around with and people are already done impressive stuff on it, let's see what the future will bring!
  39. 3 points
    I started on a TI-99/4A, then moved to Commodore, and of course Commodore won me over pretty quick. :) My TI was a gift from my uncle in 1981, and I was thrilled beyond belief to get it. My parents were not gonna drop that kinda money for something they had no idea if I would keep using... boy were they surprised. I spent every free moment behind that keyboard. From that point forward, they fully supported my interest in computers. Good times!
  40. 3 points
    Some notes on my progress supporting END, PagUp and PagDn. From the emulator source code, it's apparent that those keys are discarded. See file keyboard.c, function ps2_scancode_from_SDL_Scancode. I made the following minimal change to that function, and recompiled the emulator: case SDL_SCANCODE_END: return 0x69 | EXTENDED_FLAG; That emulates PS/2 scan code E069 when the END key is pressed. The good news is that I could successfully detect the END key in X16 Edit. Most probably, this will work on the real hardware out of the box.
  41. 3 points
    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.
  42. 3 points
    Hex dumper View File A hex dumper I wrote, because I wanted one like the one I've got on my UNIX machines. It should be able to handle "proper" address 0 RAM banking, as well as r38 RAM banking (it checks the KERNAL version). Set the color with the number keys. Change the view by $100 with left/right cursor, by $300 with up/down, and by $1000 by enter/left arrow. Submitter rje Submitted 04/06/21 Category Dev Tools  
  43. 3 points
    I am a bit late, and I should have posted this on april the 1st, but..... What is this "Desktop" that you are speaking of ;)???
  44. 3 points
    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.
  45. 3 points
    I branched the cc65 repo and started changing the cx16 lib. It now works with Invaderz and Brixx and both would now run on R39. In case anyone wants to check it out: https://github.com/AndyMt/cc65 I'll do some more testing myself before creating a pull request.
  46. 3 points
    Exciting News!
  47. 3 points
    Yes, the releases have matching ROM and emulator versions. Be careful to negate the number in case it's negative, and then compare it with e.g. 38 or 39. Future versions may use positive numbers. Non-official builds use $FF as the version, yes. The next ROM and emulator will be -39. In order to detect Proto #1 vs. Proto #2, check for abs(version) >= 39. This will work for all released emulator + ROM versions. I'm aware that this check won't work for non-official builds.
  48. 3 points
    okay - I finally hit a milestone with my IMF to YM2151 conversion experiment. After much banging around in registers and tracking down mistakes with bit shifting, etc, I have gotten "first light" - the driver produces sound and the voices are actually closer to the original than I would've guessed. I had to bootstrap it by just pre-loading a single pitch on all voices, so it's not actually playing the tune yet because I haven't implemented translating the frequency from OPL-speak to OPM-speak. (they're VERY different). Hopefully I can have that done tonight and post a video of it doing its thing - then it will be time to start improving the fidelity, using the LFO, etc. I plan to use the VERA PSG to do the percussion channels but that's going to come later. As someone else said in some other thread here recently - debugging audio sucks! It doesn't work until suddenly it does - lol.
  49. 3 points
    This one is really creative.
  50. 3 points
    Yes, you're overthinking it. Use an SD2IEC (not a Pi 1541). Since you don't need cycle exact timing or copy protection, the SD2IEC is actually faster and simpler to use. It also has the advantage of being a real mass storage device (not a floppy emulator) and handling 1541, 1571, and 1581 images.
×
×
  • Create New...

Important Information

Please review our Terms of Use