Jump to content

Leaderboard


Popular Content

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

  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. 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).
  4. 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.
  5. 8 points
    I am planning the r39 release for this weekend.
  6. 8 points
  7. 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.
  8. 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
  9. 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  
  10. 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.
  11. 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
  12. 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.
  13. 5 points
    Anybody who needs more than 128 bytes of RAM is just greedy. It was good enough for the Atari 2600!
  14. 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.
  15. 5 points
  16. 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!
  17. 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.
  18. 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.
  19. 4 points
    OK. Thank you. I got it working now ...
  20. 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.
  21. 4 points
    That looks great! But can you call it Flappy Chickenlips. Kthxbai. Perifractic, X16 Visual Designer http://youtube.com/perifractic
  22. 4 points
    They’ll be in touch hen-yway. Perifractic, X16 Visual Designer http://youtube.com/perifractic
  23. 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.
  24. 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!
  25. 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.
  26. 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
  27. 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.
  28. 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!
  29. 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.
  30. 3 points
    Those are fair questions and I’ll answer as clearly as I can. I’ll start with why IO devices of the normal type like the VERA are impractical to put there. So to begin its good to clarify that it’s important that most of ZP be reserved for the intended ZP usage using a couple registers is fine because it leaves the bulk of the space free. Two registers which were also reserved on the 6510 is not a big deal. But tying up lots of registers is. I won’t disagree that having the VERA there wouldn’t be very useful, the main reason is you need to create a logic exclusion case where a 32 byte range are read or written from the VERA instead of RAM. This requires a fair amount of logic and that introduces timing delays which can cause lots of problems especially on reads. And creating an exclusion case for VERA (a 32 byte range) is more costly from a component/complexity than turning the entire ZP into IO. But turning the whole range into IO is too costly from a software/overall functionality standpoint to be considered either. So how then do we do an exclusion for two registers in ZP? The simple answer? We don’t. The bank registers are in fact RAM and latches. We don’t disable the RAM on reads or writes. The RAM at those locations is always active. However what we do implement is a shadow technique where on a write event to those locations a pair of latches (one for each address) will capture the contents of the data bus on the falling edge of the clock. This does not disable the RAM from also latching those same values, and in fact when you read those locations what you are reading back is the RAM, not the latches themselves, since they can’t actually be read. This isn’t a problem since the RAM will always (with one small exception) contain the last written value. The exception is on a hard reset. On a reset the latches always return to zero whereas RAM does not. So in theory after a reset the value stored in RAM and the value in the latch will mismatch. In practice this isn’t a problem since the reset routine will write to those locations which corrects the mismatch. So the trick we are doing while it does add a few parts, has no impact on the timing of the system. It’s very simple and it’s inexpensive. The parts used cost much less than devoting a relatively costly 65c22 to do the same task. And we aren’t eliminating the 65c22 gets freed up to do more important things. End result is the X16 has more free IO for the user than the Commodore machines did. Sent from my iPhone using Tapatalk
  31. 3 points
    I bought a color dot matrix printer (so awesome at the time) to go with my C128D, and I had one of those cassette port adapters. I'm very fortunate that it was either keyed or that I happened to insert it right side up!
  32. 3 points
    It is possible I had some hardware defect with the cassette interface. I suspect the problem was either the cassette player I had at my disposal at the time, or my inability to fine tune the volume to successfully play it back. Never underestimate the incompetence of a 15 year old who knows very little about how computers work using a fire sale priced discontinued bit of hardware (I think my father paid $35 for it in 1983). Really, the more incredible thing in my mind is the price. $35 in late 1983 is about $90 today according to https://www.bls.gov/data/inflation_calculator.htm, which pales in comparison to modern tech such as a RPi.
  33. 3 points
    So stop using 640x480. Drop down to 320x240 and all of your problems will go away. Sent from my iPhone using Tapatalk
  34. 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.
  35. 3 points
    I'm seriously considering planning this! Right now both my games use slightly different variants of a lib for sprite handling and music - due to "historical reasons" and lessons learned. I want to migrate both to the same code base. Then I think it would be time to release it to the public.
  36. 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.
  37. 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  
  38. 3 points
    During the last few days I've spent a lot of time debugging my software in the emulator, running from an SD card (VHD file). This is because some things in the emulator behave differently when loading stuff from SD card instead of the host file system. Anyway: in Windows I found it quite fiddly to update the SD card VHD file for every debug cycle, so I came up with a solution to do speed things up. After a cc65 build I now only have to run a single cmd file which even puts the LOAD"MYPROGRAM.PRG" and "RUN" into the clipboard. Now I just have to press CTRL+V and the PRG is loaded and started. Prerequisites: VHD Attach tool (OSFMount wasn't flexible enough for this, but maybe someone else figures it out) an SD card VHD image (this is the one from the X16 github repo) X16-emulator install directory is added to the system PATH environment variable VHD Attach install directory is added to the system PATH environment variable compiled PRG and BIN files of your software are to be found in the "out" subdirectory Preparations: attach (aka mount) the vhd file once by right clicking and selecting "attach" note the drive letter which is assigned (in my case X:, it will stay the same) put a first set of your files into the VHD detach the VHD file (right click) Now create a batch or cmd file which does the following: attach the VHD file wait 2 seconds copy PRG and BIN files to the assigned drive letter wait 2 seconds detach the VHD file (so the emulator can use it) put the load command into the clipboard run emulator Here is a sample .cmd file I've used: VhdAttach.exe /attach test.vhd ping 127.0.0.1 -n 2 > nul copy out\*.PRG X:\ copy out\*.BIN X:\ VhdAttach.exe /detach test.vhd ping 127.0.0.1 -n 2 > nul (echo LOAD"INVADERZ.PRG",8 && echo RUN) | clip x16emu.exe -sdcard test.vhd -scale 2 -keymap de-ch Replace "test.vhd" with the filename of your VHD file, the PRG name with yours and also select the correct keymap parameter (or remove it). This saved me a lot of time, maybe it helps others, too.
  39. 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.
  40. 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.
  41. 3 points
    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  
  42. 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.
  43. 3 points
    Prog8 6.4 was just released. As always the documentation is here and the git repository is here. It contains fixes for the bugs mentioned above, further optimizations, and the code generator is now finally fully completed. There's also a cx16.vload() function now that is similar to basic's VLOAD. Have a look at the release notes on Github if you want all the details
  44. 3 points
    We do not repurpose the keys on a hardware level. So they will do their original functions on other systems. Hopefully that answers your question. Sent from my iPhone using Tapatalk
  45. 3 points
    Not customizable? Dang. I was hoping to replace one of the big-X keys with a key marked ANY.
  46. 3 points
    I think the best you could do for transparency on VERA would be to make every second pixel on a layer 1 tile or a sprite color 00 in a checkerboard pattern.
  47. 3 points
    @Jeffrey - I've managed to dig up the locations of the AdLib music data from the original game files. Fortunately, it's not compressed in Wolf3d so loading it will be easy enough. I've been making a few notes for myself, and tonight's project is going to be a quick and dirty player routine with my "first best guess" at a naive 'translation' between OPL and OPM and see if anything resembling the actual Wolf3d music comes out of the box. Hopefully, all of my time is not spent reading the register layouts for the OPL w/o any sort of code being written. We did catch a very lucky break as far as the game music is concerned - OPL has 9 voices, and Id seems to have always reserved voice 0 for SFX by convention, so that means no more than 8 music voices in the data. Woot! If it works, then I'll re-write it in assembly and donate the player code to you for your project. The playback rate is strange tho - 700Hz. Not sure how easy that will be to generate amidst the frenzied raycasting. Update: I wasn't able to get far enough to get actual sound out of the program yet, but I did make a lot of progress. I've got the IMF traversal going (which was trivial I must admit) and I've wired a bunch of registers together, but didn't get as far as freq. / keyon registers. Those work pretty differently. Unfortunately, there's just no way the YM is going to sound super-close to the OPL, depending on what features the tunes use because the OPL has several features the OPM just doesn't have - most notably it can use different waveforms than sine waves. There's also the matter of the percussion voice mode, which I think can be kludged using the VERA PSG. Hopefully I'll have a demo to post tomorrow night.
  48. 3 points
    This one is really creative.
  49. 3 points
    i love that invaders one
  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