Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 05/15/21 in all areas

  1. 14 points
    In this recent video I showed a first prototype of the X16's mini keyboard. As we edge closer to crowdfunding later this year, today we ordered final keyboard prototype samples with the PETSCII layout and X16 logo on. Can't wait to try them out and show you guys more!
  2. 13 points
    Hi! First time posting here. So basically I have a game project coming that targets a retro machine with quite capable graphics and sound. Which I found this system to be a good start. However, the current x16-docs hardware reference is quite hard to navigate and lacking in some details. Inspired by hardware references I usually use for Gameboy and SNES programming, I decided to spend few weeks and write my own X16 hardware reference. Which is now available in both (printable) HTML and plain text here: https://ayce.dev/emptyx16.html https://ayce.dev/emptyx16.txt Note that this will be updated once I can confirm more details and a hardware itself is finalized (no, please don't reply about that leak here). So please look forward to it. The document's source is also available here and everyone is welcome to contribute.
  3. 12 points
    STNICCC Commander X16 Demo Remake View File This is the release of a STNICCC Demo Remake for the Commander X16! I have been (silently) working on this for the last couple of weeks/months. It is time to release it :). Let's just say: the Commander X16 is far more powerful than I had thought! Here is a video of it running: Enjoy! Regards, Jeffrey --- PS. There was an earlier attempt to remake this demo on the X16 (done by Oziphanto on youtube). Oziphanto did a very nice comparison video of the X16 with several other machines of the 8-bit and 16-era: He also re-created this demo, but (in my opinion) did not do such a good job extracting everything out of the X16: his demo ran in 2:32. The remake I made does it in 1:39! His benchmark comparison should therefore be updated: Keep in mind the Commander X16 only has: - An 8-bit 6502 cpu (8MHz) - No DMA - No Blitter Yet it keeps up with 16-bit machines like the Amiga! (actually its even faster right now) --- Extra notes: - This only works on the x16 emulator with 2MB of RAM - It uses the original data (but its split into 8kb blocks, so it can fit into banked ram) - Waaaayyy to much time is spend on the core-loop to make it perform *this* fast! - My estimate is that it can be improved by another 10-15 seconds (I have a design ready, but it requires a re-write of the core-loop) - It uses a "stream" of audio-file data and produces 24Khz mono sound (this will not work on the real x16, since loading the files that fast is a feature of the emulator only) Here is a version without audio (so this should run on a real x16): And it runs even faster (1:36:90) Submitter Jeffrey Submitted 05/21/21 Category Demos  
  4. 10 points
    I've been noodling this game idea in my head for several years, and finally decided to do it on the Commander X-16. This isn't in a playable format yet; I spent several months just generating the lookup tables for it, and this is the first time I've had anything at all to show. I'm gong to use this thread to post updates and releases as progress happens. Asteroid Commander will be a game sort of like SimCity, in space, with a storyline. There's no sound in this video. The asteroid is procedurally generated, and the image is raytraced - for certain very limited definitions of raytracing. The shadows are very rough right now and I can see I have a bit of work to do on the ray maps, but the toughest part of the game engine is basically done.
  5. 9 points
    We’re aware of the issue caused by our host failing to auto renew or notify us. They’re a small provider who we like to support and are looking into the cause. Let’s encrypt is not an option they offer and we are limited to what they provide. Should be fixed within an hour. Thanks.
  6. 7 points

    Version 1.0.0

    83 downloads

    This is the release of a STNICCC Demo Remake for the Commander X16! I have been (silently) working on this for the last couple of weeks/months. It is time to release it :). Let's just say: the Commander X16 is far more powerful than I had thought! Here is a video of it running: Enjoy! Regards, Jeffrey --- PS. There was an earlier attempt to remake this demo on the X16 (done by Oziphanto on youtube). Oziphanto did a very nice comparison video of the X16 with several other machines of the 8-bit and 16-era: He also re-created this demo, but (in my opinion) did not do such a good job extracting everything out of the X16: his demo ran in 2:32. The remake I made does it in 1:39! His benchmark comparison should therefore be updated: Keep in mind the Commander X16 only has: - An 8-bit 6502 cpu (8MHz) - No DMA - No Blitter Yet it keeps up with 16-bit machines like the Amiga! (actually its even faster right now) --- Extra notes: - This only works on the x16 emulator with 2MB of RAM - It uses the original data (but its split into 8kb blocks, so it can fit into banked ram) - Waaaayyy to much time is spend on the core-loop to make it perform *this* fast! - My estimate is that it can be improved by another 10-15 seconds (I have a design ready, but it requires a re-write of the core-loop) - It uses a "stream" of audio-file data and produces 24Khz mono sound (this will not work on the real x16, since loading the files that fast is a feature of the emulator only) Here is a version without audio (so this should run on a real x16): And it runs even faster (1:36:90)
  7. 6 points

    Version v1.0

    4 downloads

    I was curious how well the 65C02 could handle modern encryption, so I wrote this program to test it. The program loads the 8bpp image from the old Mode7 demo and repeatedly encrypts then decrypts the bitmap data in VRAM using AES encryption. This provides a nice visual as to how quickly it's able to process the data. The download includes PRG files for 128, 192, and 256 bit key AES, with the Try It Now button using the 128 bit key version. To run it locally, make sure that the two .BIN files are available to the emulator in "drive 8" (either copied to the working directory, which is usually the folder with the emulator executable, or in the disk image used with the -sdcard option). The image was taken from the Commander X16 Mode7 Demo. Copyright David "The 8-Bit Guy" Murray and/or Michael "mist64" Steil. The implementation of AES is based on byte-oriented-aes ( https://code.google.com/archive/p/byte-oriented-aes/ ) by Karl Malbrain. Released into the public domain by the author. The source code is available on Github: https://github.com/LRFLEW/AES-X16
  8. 6 points
    There will be a standard 1/8" stereo jack (to the right of the SNES controller ports):
  9. 6 points
    Hello everyone, A little bit of my self, To be honest not really into Retro Computing before but after watching David's (The 8-Bit Guy) videos this past few weeks i'm getting more interested into it. While i do really want to get my hands on "Real" Commodore 64 and other kind of retro computer, but i'm still not sure if i will be able to find and get one here. But either way i think Commander X16 would also be a nice option too Been trying the Emulator for CX16 this couple of hours now and having fun learning Basic on it
  10. 5 points
    Hi all! I came here from Perifractic's YT ;-) My name's Cezar, you can find me on Twitter under @ikari and recently also as @RetroFunPL :) But the first YT video is in the long way of making still (featuring a CPC6128 plus). I've been a CPC literally *all* my life (the computer predates me), Amstrad is what taught me programming (so kinda got me a job in the end). Sadly, no Commodore experience (longer than 2 hours of gaming) until very recently when I discovered the C64 Maxi and added some original C64s to my collection. So don't just tell me "it's just like C64 BASIC, you know the drill" in the docs! :P I love to see the project grow and I hope to get my hands on one as soon as possible (which means both the machine being available AND i'm getting out of debt from buying the previous ones, lol).
  11. 5 points
    Purchased a C128 yesterday with a retro Commodore monitor supporting 40 and 80 columns. It is amazing.
  12. 5 points
    If your concern is that we’ll release the X16 with a keyboard that doesn’t work, needless to say that won’t be the case. Yes we are using a variant of the 409 PS/2 version, but again needless to say, we have them in house and Michael has tested it thoroughly with the kernel. Remember we have more control as we’re writing the kernel, as opposed to what’s happening at that thread. Any issues will also come out during beta testing which we hope to start soon. Long story short, worry not.
  13. 5 points
    Falling Snake (C) View File Simon Snake has fallen down a hole, you must rescue him, by avoiding obstacles on his way down. Controls: Cursor Keys, for left and right. Space to start or continue the game. Falling snake was a game that I wrote on the C64 in Basic, but now converted to KickC, because I want to add more features to it, and was running on the limits of what I wanted to squeeze into Basic. All graphics, except player sprite are Petscii. "Cut Scenes", are in "Lores Double Petscii". The Basic version you can also find below as a tutorial "How to create a simple game in basic on the X16" This time the game is written in Kickc, allowing more features to be added. Current status: 90% of all Basic features have been converted to C. Extra features have been added that were easier to add in C, like "cut scenes". Sound and more game play elements are to be added still. Video below. (music added in post production) Submitter CursorKeys Submitted 05/22/21 Category Games  
  14. 5 points
    Can confirm. This works. 10 N1=1:N2=256*60:P1=$9F23 20 C1=$32 30 VPOKE $20,N1,C1 40 FOR N=N1 TO N2 STEP 2 50 POKE P1,C1 60 NEXT Back when the emulator first came out, we did some speed comparisons between POKE and VPOKE. The end result was that VPOKE is a little bit slower, but most of BASIC's time is spent parsing values, so replacing all numeric literals like 40739 or $9F23 with variables speeds up the loop. We also determined that hex values parse faster than decimal numbers, but it's still faster to store values in a variable. For example, I ran this loop 3 different ways: 50 POKE P1,C1 : 240 ticks (4 seconds) 50 POKE $9F23,C1 : 367 ticks (6.1 seconds) 50 POKE 40739,C1 : 477 ticks (7.95 seconds) So, using a variable instead of a numeric literal can double the speed of a tight loop like this. Anyway, how does this compare to VPOKE? 50 VPOKE B,N,C1 : 312 (5.2 seconds) So POKEing with an auto increment is faster, by a good 30 percent. I obviously wouln't worry about this with a small number of writes, but for situations where you need to populate the entire screen, POKEing with an increment is definitely faster.
  15. 4 points
    I am new to the 8 bit computing world but I am very excited for this project and to learn more! My first computing experience was Windows 2000 so forgive my ignorance lol
  16. 4 points
    Current thinking is to include an SD Card with a few games and programs bundled. If we do that will be one of them.
  17. 4 points
  18. 4 points
    I've just released a new 7.0-beta2 version of the compiler https://github.com/irmen/prog8/releases/tag/v7.0-beta2 This version will likely be very close to the final 7.0 release because I'm not considering adding or changing anything new from now on (except bug fixes). Some of the most important fixes/changes since the previous beta release: string encoding and string interning bug fixes various compiler crashes fixed %asminclude fixed (scopelabel argument removed as well) repeat loop code gen optimized some more Once again: the CommanderX16 target targets the upcoming "V39" of the cx16 emulator and roms. Programs targeting the cx16 compiled with this new Prog8 version may no longer work on the previous version of the emulator (although if you're not using floating point and bank switching, they will likely still work) Detailed change list will be added when this 7.0 version is finalized, which will probably be shortly after the "V39" of the commanderx16 is officially released as well.
  19. 4 points
    Hi, my name is Nadia, and I am so happy to be making my first post here. I am new to the world of retro computing, I am only 22 so the 8bit computers were long fazed out by the time I was born, However I have a love for computers and computer Hardware. I discovered many retro YTubers and learned so much from them about the systems of Yesteryear. This new found passion has me excited for the new X16 and learning to code for it...(This will be my first coding experience :) ) I hope to meet many new people on here as I begin my journey in the world of 8bit computing. Here is some fun facts about me if you care to read: Likes: Synth Music, Paint Programs, and Video Games that dont require 100 hours to beat Dislikes: Modern Game Industry, Boring Business Design, Any windows OS above 2000 Favorite Movie: Hackers (1995)
  20. 4 points
    I was a C-64 kid in the 80s, and mastered BASIC during that time. I knew nothing of assembly language then, but since the Commodore fueled my interest in Computer Science, I'm very interested in writing some code for this new take on an old familiar favorite! If anyone else from my area happens to be lurking on this forum, shoot me a message, as I'd very much like to geek out with other fans. I have 2 sons, 14 and 8-years old, both of which love modern PCs. My youngest one actually spent some time learning BASIC on the C-64 and my Famicom BASIC setup, so he's a new generation of fan for these classic pieces of hardware. When the hardware releases, I'd love to show off my system at the Louisville Arcade Expo (Arcade, pinball, classic video game systems show).
  21. 4 points

    Version 0.8

    9 downloads

    Simon Snake has fallen down a hole, you must rescue him, by avoiding obstacles on his way down. Controls: Cursor Keys, for left and right. Space to start or continue the game. Falling snake was a game that I wrote on the C64 in Basic, but now converted to KickC, because I want to add more features to it, and was running on the limits of what I wanted to squeeze into Basic. All graphics, except player sprite are Petscii. "Cut Scenes", are in "Lores Double Petscii". The Basic version you can also find below as a tutorial "How to create a simple game in basic on the X16" This time the game is written in Kickc, allowing more features to be added. Current status: 90% of all Basic features have been converted to C. Extra features have been added that were easier to add in C, like "cut scenes". Sound and more game play elements are to be added still. Video below. (music added in post production)
  22. 4 points
    1. Hyperion, whatever you think of them, have recently released AmigaOS 3.2 for 68K-based Amigas. There will also be ROMs available for all 68K-based models. There's a press release on their website, and the few shops out there that are still carrying Amiga-related products should have it available for purchase by now. 2. Dave Haynie's self-made movie about the closing days of Commodore, The Deathbed Vigil (and Other Tales of Digital Angst), will soon no longer be available on Amazon's Media-On-Demand service, because Amazon is closing the service. Get your orders in before June 6, 2021, if you want professionally-produced physical media of this documentary.
  23. 4 points
    I feel like an idiot, this seems so obvious. They even tell you in the documentation. I'll probs add a pull request for the two line fix just so they can advertise that OpenBSD is a supported platform.
  24. 3 points
    The YM2151 can really do some interesting things if you go "off-script" with it. For instance, the KeyON register has an interesting way of gating notes. Instead of a single gate for each voice, you can gate the 4 operators individually. This means that if you're clever with the ADSR values of the 4 operators, you could make a sound that features a continuous tone but with a cyclic modulation - so something that kind of goes WooWooWooWooWooWoo... - It's hard to describe this in text, but I'll give it a stab. (I'd have to make a program to demonstrate this as your typical tracker / OPM DAW plugin isn't going to offer this function either). Suppose your tone-generating operators have a D2R of zero - meaning that once the envelope reaches the sustain level, it will not decay anymore until you gate in a release on the voice. You start your sound by triggering all 4 operators. e.g.: let's say operator 0 is the modulating operator Now let's say one of your modulating operators does have a full ADSR with a D2R so the modulation runs its course. Say the sound goes like oooOOOAAAAOOooo (and stays "oooo" thereafter). You can re-trigger only that one operator and get another cycle of the effect w/o the sound ever decreasing its volume. So if you have some sound effect that represents something like a plasma beam firing, or a UFO engine, or something like that, you can just keep re-triggering the modulating operator to generate the effect. Maybe I should try whipping something up in BASIC as a demo and do a "how-to" video on it or something.
  25. 3 points
    A little while back, while researching 6502 bytecode interpreters when I was working on the "SweetCX16" implementation of Steve Wozniak's venerable "Sweet16" virtual machine for the Apple II, I came across Pascal-M, an implementation of Pascal for the early KIM-1 8bit 6502 system based on a bytecode virtual machine (VM). The last update I knew of was the version 2 being ported to run on FreePascal. Recently the original V1 Pascal-M was restored (recently as in 2020! ... so there may have been a bit of a "lockdown project" to it like medievalist armorer Tod Cutler's "Lockdown Longbow" series). Now, Pascal-M is a lot more primitive than UCSD's bytecode Pascal. It's all upper case, no file I/O in version 1 (version 2 adds it), and of course it runs on a SLOW virtual machine. So why is this interesting as a target? One thing that is interesting about this is the porting process. Basically, write the bytecode interpreter, including a loader to load a compiled bytecode program, then you can load the already-compiled compiler, then use it to compile the compiler AGAIN from the source, and if the original compiler you started with and the compiler that you created are exactly the same, you can be pretty sure that your bytecode interpreter has worked. And while the interpreter should be written in assembly, a lot of it is straightforward. You write a bunch of primitives that do relatively straightforward things within the VM system model, each of them ending with a call to NEXTOP to execute the next bytecode. And while the Pascal-M documentation is rudimentary, it is originally based on the P2 VM p-code version of Pascal (which actually was NOT a bytecode) ... which is well documented, since in some computer science programs in some countries, students still "rebuild a Pascal compiler" as part of their first compilers class. And the loader could literally be written in Basic. While I have by no means started on the loader yet, I've got sketches for 35 bytecodes ... including the 8 that have an embedded parameter of 0-15 in the code, so occupy the first 128 bytes of the instruction set ... and have 21 to go. Now, that doesn't mean I'm 60% of the way done, because some of the ones I have not yet started on pack a wallop, like the opcode for the CASE statement which has the entire CASE jump table as it's operand. However, I may be over 25% of the way through the first draft of the interpreter in a combined few days of playing around with it. Now, no doubt Pascal-M would be very slow ... m-code is not optimized for the 6502 to any degree other than being a byte code, where Nicholas Wirth's original pcode was based on 30 bit wide codes. But once the VM interpreter is written, there will be another working "high-ish for the 70s and 80s" language for the CX16. Another appealing aspect of Pascal-M as a target is that almost the whole of Low RAM is available to it, and since it is a bytecode, the code density will be pretty good. The bytecode interpreter can actually be run out of a High RAM segment, so if any springboarding to other parts of High RAM can be done out of Golden RAM, the system will have 36K+ free for program code, stack, and heap. Of course, being a VM, the virtual hardware can be redesigned in hardware. There is actually a bit of flexibility here, because there are three logical things ... the procedure CODE, the procedure stack data, both of which grow up, and the heap, which grows down, to work with. That is, the m-code VM treats CODE and data, or "STORE", as different things, so if one is careful, it is possible to have in excess of 64K total addressable content, because CODE addresses and STORE addresses don't necessarily have to refer to the same memory location. One model to look at is a "Big CODE" model, where the interpreter is placed into the high side of Low RAM, nestled somewhere up right before the I/O page at $9F00 ... and the CODE is run out of the High RAM window. Then the Heap and the data part of the Stack has 30K+ to work with while the code can extend for up to 64K. The amount of functionality that could be included in a program is increased by the fact that the Pascal system is designed to be able to load and unload distinct segments so, for example, a main program could load a set-up/initialized segment, and then free it up to load the procedures that are going to use the initialized data. Another to look at is a "Big HEAP" model, where the bytecode operands that store things to general memory treat "STORE" addresses from $8000 up as coming from one of up to four High RAM segments, so the Heap extends from a virtual $FFFF to $8000, while the stack and program extends from $0801 until the start of the interpreter or $7FFF, whichever comes first. Indeed, although I need to get further into the project than I am now to see if its possible, it might be possible to combine both of those. The VM codes that pull data from code generally push it onto the stack, and the access to data in the Heap is generally to and from the stack or the direct MOV instruction. So it may be that the trickiest part of combining a "HighRAM CODE" and "HighRAM Heap" model was already done when the High RAM Heap is developed, including the various cases that MOV must handle when moving data from one place to another, especially moving data between different parts of the Heap when they are not in the same HighRAM segment. As some of us will recall quite well from Basic in the 80s, sometimes all that is needed to get something to run "fast enough" is to identify the worst bottlenecks and move them to assembly. So one of the appeals of starting with m-code is that it DOES have a "call assembled procedure" code. That's one of the 35 I have already sketched: Now, to be clear, I am not reckoning that Pascal-M on the CX16 will "take over and reform the world!!!" ... I am not even expecting that it would ever be heavily used by anybody. However, it's still an appealing project to take something that ran on the KIM-1, MOS Technologies first 6502 computer ... pre-PET, pre Apple II ... and port it to the CX16. Oh, by the way, that single KIM-1 card cannot possibly run Pascal-M ... it only has 1K of RAM! ... you would need something like a 32K RAM expansion card:
  26. 3 points
    Cosmic Ark is correct. The star field is the reason the game exists. I forget which graphic element is glitched to create the effect but when Furlop saw it, he designed Cosmic Ark around it to show it off. I guess what is meant by “highly regarded” is that it’s not an obscure title and it’s considered a good game. Well done. And the snubbed game was Demon Attack. https://web.archive.org/web/20091227184554/http://robfulop.com/blog/2008/04/14/making-david-crane-cry-the-origin-of-cosmic-ark/
  27. 3 points
    8BPP Cow View File This demo features 3D rendering to a 256x240@8bpp surface with full transformation calculation, texture mapping and per-pixel depth buffering. The model is a decimated Spot test model with 512 vertices, 1020 triangles and a 256x64 texture. So, I wrote this just to get familiar with this system and figure out how to write and optimize a 3D math for it. Also, it would makes a nice reason for me to get up and do some coding streams, as shown here: Only runs on r39 since I can't find documents for older versions. There's still bunch of incorrect pixels due to depth buffer precision problems. Controls: A/D - Move camera left/right W/S - Move camera up/down Q/E - Move camera backward/forward (Z value should be an unsigned number but the UI only displays signed numbers) J/L - Rotate left/right (yaw) I/K - Rotate up/down (pitch) U/O - Tilt left/right (roll) Submitter a9m Submitted 06/11/21 Category Demos  
  28. 3 points

    Version 1.0.0

    5 downloads

    This demo features 3D rendering to a 256x240@8bpp surface with full transformation calculation, texture mapping and per-pixel depth buffering. The model is a decimated Spot test model with 512 vertices, 1020 triangles and a 256x64 texture. So, I wrote this just to get familiar with this system and figure out how to write and optimize a 3D math for it. Also, it would makes a nice reason for me to get up and do some coding streams, as shown here: Only runs on r39 since I can't find documents for older versions. There's still bunch of incorrect pixels due to depth buffer precision problems. Controls: A/D - Move camera left/right W/S - Move camera up/down Q/E - Move camera backward/forward (Z value should be an unsigned number but the UI only displays signed numbers) J/L - Rotate left/right (yaw) I/K - Rotate up/down (pitch) U/O - Tilt left/right (roll)
  29. 3 points
    +1 on note to frequency table. Many apps will use it. The numerical values will be pretty much the same everywhere. I would vote for having all the low frequency bytes in an array 0...127 and after that all the corresponding high frequency bytes at 128...255, so that you don't need to multiply the note value by 2 to get the correct index, but access both via LDA freq_lo, y and LDA freq_hi, y. But that's a matter of taste. Either way, such a table would be nice. (I have to mention that Concerto uses more than 128 valid note values, so that the whole table requires more than 256 bytes and makes the aforementioned separation into low and high bytes strictly necessary to be able to access all entries)
  30. 3 points
    The whole "It's just a PET with a VERA" argument is kind of unfair. The NES is just an Atari VCS with a PPU and APU glued onto it. The Atari 800 is just an Apple 1 with a video chip glued onto it. Etc. Let's face it - from the perspective of anyone who played games or made / watched demos, the things that give the systems their unique character ARE the video and sound chips. They pretty much all had some kind of data ports, etc and peripherals were available or not, had different UIs and whatnot, but they're all essentially a 64K address space driven by a 6502, and having some assortment of peripheral ICs mapped into this space by glue logic on the bus.
  31. 3 points
    That sounds like a great guess. I'm thinking probably IV though, as that chapter is much more well-known and is featured regularly on 8-BitGuy's channel. Even if I'm right, give the credit to Matt because I wouldn't have thought of Ultima on my own. (never got into that series) I've got one to post, but want to wait until this one is solved, first.
  32. 3 points
    I think an FPGA can be perfectly fine as a replacement for an ASIC in a retro project if done properly. What is an FPGA? At it's heart, an FPGA is just a re-programmable ASIC. ASIC vs FPGA is analogous to ROM vs RAM. One comes from the factory a certain way, unchangeable, while the other is malleable. So having an FPGA video chip or I2C bus controller is ostensibly no different than having an ASIC like the NES PPU or the VIC-II tied to your bus. This is quite obvious when you consider something like the FPGA-SID, which has the same form-factor as a real SID, and fits right into the same socket, and does exactly the functionality of the SID, and only the SID. Hell, one of the reasons the YM2151 has been allowed into the X16 despite violating the "currently produced chip" rule is that there's an FPGA core available to use if real OPMs become impossible to source. i.e.: It's like having an FPGA SID in your C64. You would be able to plug an FPGA-OPM into the YM socket of the X16, tap it with your finger, and say "this right here's the FM synth chip." If you hooked a scope on the pins or the bus or whatever, it would look identical to having a real YM2151 on the bus. Apparently, FM synth is pretty much sample-accurate nowadays in emulation, and doing this emulation in silicon ala FPGA is no different either. So why not? The "problem" with FPGAs: It's when you start having a single FPGA that incorporates more and more functionality that it starts to just resemble a "north bridge" chipset as opposed to an ASIC that you can point to and say "that's the graphics chip." VERA pushes the line with this, being that it also does PSG sound, PCM sound, and SPI bus mastering. To me, though, this is an acceptable cost-saving measure. If you strictly adhere to a through-hole form factor + 1:1 chip to function parity, then you're buying 5 or 6 FPGAs and letting a lot of the unused capacity of each one just go to waste. Now, let's not forget that even ASICs often present lots of merged capabilities. Even the all-mighty SID itself (peace be upon it) is not a pure sound chip. It also does paddle controller decoding. A more extreme case is the POKEY which isn't just a square wave PSG. It has all kinds of GPIO pins and analog->digital input decoders in it. The VIC-II was also responsible for providing the system clock and DRAM refresh. Let's face it - computer manufacturers have ALWAYS done stuff like this to cut costs. It's just that now you can use an FPGA to merge whatever kinds of in-silicon functionality you want into a single chip. Now manufactures just make "generic chips" that can be configured to do whatever system builders want, instead of having to make a production process for each and every ASIC. The "endgame" with FPGAs: Why do many retro computing enthusiasts feel aversion to them? Obviously, as the power of an FPGA increases, you can build more and more of your system into a single chip. Eventually, you just have an FPGA on a PCB that's nothing more than a breakout board to route physical connector ports back to pins on the FPGA. At this extreme, you have the same computing experience and programming experience, but now the whole computer just exists inside the little black die at the center of a white board from PCB Way. If you want to fiddle around with the hardware, then too bad - it's all inside that one piece of silicon. At this point, you're only one step away from the entire thing vanishing as it is replaced entirely in software emulation running on a modern PC. So where is the line drawn? When does it cease to be a "real computer?" Bottom line: It really has nothing to do with FPGA vs ASIC. Given that it must exist as a physical device, what the question really boils down to (imo) is: how much of the system is in a black box (IC) and how much of it is traces on a PCB between individual chips? Let's not forget that even those simple ASICs and general-purpose ICs are just older-tech ways to reduce the amount of discrete components on the system. extremes: [100% discrete components] <-------------> [SoC] You could make a Commander X16 computer that exists anywhere on this spectrum. It's just a question of how much circuitry disappears into little black rectangles, and how many of those there are. Of course, the pure discrete component X16 would be huge and consume kilowatts of power, break down often, and be susceptible to interference from your toaster, but damnit it would work. (I saw a post on the /r/beneater subreddit where a guy made an NES PPU on breadboards).
  33. 3 points
    There are multiple examples of real chips being used in the X16. Examples include: The 65C02 CPU Two 65C22 VIAs The YM2151 FM synthesis chip RAM ROM The X16 would still be a functional computer without the VERA. Furthermore, the VERA does not have unlimited capabilities. Posts from those working on the hardware have indicated that the current design (which integrates video, PSG/PCM audio, and a simple SD interface) almost reaches the limits of what the current FPGA core can do.
  34. 3 points
    I'm working on a development to optimize the memory management for the CX16, allowing to dynamically allocate and free memory space at run time in CX16 BANKED RAM (BRAM) and VERA RAM (VRAM). The heap manager is being built using the kickc compiler of @Jesper Gravgaard, and we are working together to optimize this development for a larger audience (later). The idea came while making my "space game", I really needed a mechanism to dynamically load and free memory in both RAM types on the fly at run time. The complete source code of the heap manager van be found here: https://gitlab.com/Flight_Control/kickc/-/blob/CX16_VERA/src/main/kc/lib/cx16-heap.c This heap manager now allows to dynamically load graphics (files) into BRAM and when not needed anymore, to dynamically free these graphics from memory. Typically such activities would happen when switching between "levels" during gameplay, or at certain transition moments. The heap manager has not implemented the logic to load the files, but a loader routine using CX16 kernal calls has been made, that uses the heap manager to dynamically allocate memory as graphics files are loaded. This allows me to design the graphics flexibly, specifying the file properties, and the heap manager will allocate the required memory at run time in memory. During gameplay or "on the fly", the heap manager covers the needed functionality to dynamically manage the limited memory space in VRAM, for tiles and sprites and other graphic objects. The heap manager allows to dynamicall allocate required memory in VRAM during gameplay, and free up VRAM memory when the space is not anymore needed, freeing up memory for new graphic objects to be allocated in VRAM, on the fly. On top, I've added CX16 library functions to copy memory between RAM, VRAM and BRAM. One such important function is to quickly copy memory from BRAM into VRAM. Typically this is used for sprites during gameplay. In other words, the heap manager allows me to load up the graphics from disk during transition moments, filling the 512/1024/1536/2048 banked memory space in the CX16, which is slow loading. But then, during gameplay, it allows me to quickly manage the VRAM memory space and copy graphics in and out from BRAM into VRAM on the fly. The CX16 heap manager has been made with the following requirements in mind: The heap manager needs a small code footprint, supporting both BRAM as VRAM dynamic memory allocations using the same code base, which is located in RAM. Programmers will only use the heap manager to allocate larger portions of memory. For smaller dynamic memory allocations, other methods are to be used (like arrays, vectors). Align the allocated memory with the BRAM BANKS or VRAM BANKS structure. No header information polluting the data. This is also very important to avoid VRAM having any header information! (We don't want sprite or bitmap info polluted with header blocks, do we...) Minimize the size of the headers, as large headers quickly will consume a lot of memory. Avoid memory fragmentation, which is resolved by coalescing the freed data blocks. Relatively fast, but not super fast. Speed for dynamic memory allocation is not an issue. For games, allocating and freeing memory would happen between paused moment. Use helper function(s) to address the memory, while traversing the memory space. Easy use for the programmer, and improve the code readability, through a well defined API. (Later) Allow the heap manager to be used by programmers using other languages, using an assembler library. The CX16 heap manager has taken the following design decisions: There are 16 memory segments that can handle the allocation of various data segments in CX16 BRAM and VERA VRAM. Allocated blocks are aligned to 8 bytes in BRAM and VRAM. This should not be a problem, s Header information is placed in BRAM, to avoid any HEAP dynamic allocated memory to be placed in CX16 MAIN RAM. So no dynamic memory is allocated in CX16 RAM before 0xA000. Use handles instead of direct pointers to memory locations. This is important, since CX16 memory in BRAM is banked, and VERA memory cannot be addressed directly anyway! This will also allow for memory compression or re-alloc later. It also avoids the programmers code to have direct pointers being used, instead, using handles, the pointers will be "indirect". This has a small performance impact, but greatly improves memory management flexibility. The header blocks are separated from the data blocks. This is important for VERA VRAM. Header information placed in VRAM would pollute the graphics!!! We don't want sprites set to be polluted with header information, do we? Hope that this development will insprire others. Please contact me or @Jesper Gravgaard if the heap manager is of interest to you. Note that this development is still work in progress and is evolving till i'm satisfied with the design of the overall API.
  35. 3 points
    If I recall, there is a PCM playback channel in VERA. As to the DX7, that's an FM synthesizer, and it uses a similar chip as the Commander X16's YM2151. Most of this is covered in the FAQ, which is linked at the top of this page (although @Perifractic, the FAQ may need updating to cover the PSG.) As to whether the CX16 compares to SID chips... I may be the only one who will say this, but I think the Yamaha FM synth blows away the SID in terms of sound quality, and if you add the PSG on top of that, there's simply no contest. The only Commodore sound system that can come close would be an Ultimate 64 with an FM cartridge installed.
  36. 3 points
    Yes I think the idea was to have a bigger version of the SID. But the Vera's PSG and the SID differ in a few aspects: Obviously count of voices. The SID has 3, the PSG has 16. Volume control: the SID has analog ADSR envelopes. They sound nice and smooth, however, they aren't very flexible. The maximum volume cannot be changed. The PSG is more flexible: you can simply set a number as the voice's volume. This flexibility comes at the cost that the volume has to be updated manually. And the volume control is kinda coarse, so sometimes you can hear when the volume is updated to an adjacent level. These were the two points where the PSG beats the SID. The other points all go to the SID. It has analog sound generation, while the PSG is fully digital. The difference becomes noticeable at high pitched sounds, where the PSG output can start to sound really unpleasant due to aliasing. The PSG also has no ring modulation, and, most importantly, NO FILTER. I think those are the most important points. But let's not forget that the X16 also comes with an FM chip, which nicely complements the PSG, and you cannot really compare it to the SID.
  37. 3 points
    So, my monitor arrived, and I have thoughts... 15" is SMALL for a monitor these days. This feels a bit larger than a laptop display, since the aspect ratio is taller, but it's still the smallest monitor on my desk at this point. The panel is straight out of 1999 - complete with color gamut and gamma problems. Light colored stuff just gets washed out, and while the image is clear, the color is... unsubtle. It works great for a text display (which is what I got it for.) It will look great being used on my Altairduino Pro or my PiDP-11, and my Ultimate 64 looks very good on this screen - this is what it's meant to look like. Overall, it's a decent monitor, and if you want to use it with something like an Amiga, a 90s PC, the Commodore 64, MiSTer, or the Commander X16, I think it will fit the bill. It's not a replacement for your daily driver, but it's perfect for some casual retro computing.
  38. 3 points
    The foreground layer can use any of the 256 colors, while the background layer can only use the first 16 colors, but both foreground and background must be set. My script determines a palette and finds the best solutions using that palette. Improvements could be made finding a better/different palette. See a few examples below:
  39. 3 points
    What does a nostalgic feel have to do with anything unless it has a function. If you feel like your text is too close to the edge of the screen, adjust your screen. The feature is there, it’s just your screen does it. Sent from my iPhone using Tapatalk
  40. 3 points
    Here - run this BASIC program and you'll see it demonstrated quite clearly. Note that the default screen tilemap width is 128 tiles wide, 8px wide, which is 1024 scroll values to wrap once around. 4096 is the total number of possible scroll values. Thus the screen wraps 4 times during this program. The garbage you see during the scroll is the portion of the tilemap which is off-screen by default, but still part of the tilemap. Essentially, that's how much off-screen (horizontal) real estate you have to work with in a scrolling engine.
  41. 3 points
    Took me almost a year but I finally got it. Decided to go with Cherry MX Clear and no dampeners. I love it! Thanks for all the guidance everyone. Time to fill this thing up with Fritos crumbs.
  42. 3 points
    Hello, I'm 50 and very happy to discover this community of enthusiastic people. I did watch a lot of content from "The 8-bit guy" and "The Fractic family" which led me to (or is it a cap ? anyway!) start investigating. So I started to read a lot of 65c02 home brew computer thing as well (mostly David Buchwald, Ben Eater, Dirk Grappendorf, Willes mine Co., and so on) and finaly this X 16 is so cool ! I'm hope we'll soon be able to embrace this little jewel. I think I'll start to play with cc65 in a near future and contribute as well to share my humble stone with all of you. Woops! I forgot to mention the invaluable You tube channel from Matt Heffernan. Cheers.
  43. 3 points
    Remember reading about an upcoming computer in your favorite magazine and getting that feeling of anticipation? That desire to get your hands on it and see what it can do? Yeah... that's me, every time some new milestone is announced. I love having this feeling again! Nostalgia, my old friend, it's nice to see you again.
  44. 3 points
    A new update of Petaxian has been uploaded with the following main changes : Added random "attacks" for enemies (with increased bomb frequency) Updated to non-uniform waves. Remixed to 12 stages. Add stage start "announcement" Add stage completion time bonus points Unsurprisingly there is a lot work left after the basic gameplay mechanics is implemented. It certainly makes one appreciate all the other non-coding work that goes into games (I certainly see why having professional level designers and testers are necessary). I want to add some sort of proper "game end" (and show current high score) but after that I suspect updates to this game will slow down. I have a couple of other game ideas I'm considering (none especially original).
  45. 3 points
    You've managed to answer your own question, it seems, but I want to go ahead and confirm: Yes, you are correct, the DCSEL bit in $9F25 needs to be set to 1 for the DC_HSTART, DC_HSTOP, DC_VSTART, and DC_VSTOP registers to be accessible. If DCSEL is 0, these registers instead point to DC_VIDEO, DC_HSCALE, DC_VSCALE, and DC_BORDER.
  46. 3 points
    I would recommend assembly. BASIC is extremely limited, especially when you have to use line numbering and 2-letter variable names, not to mention extremely slow. Good news is that the X16 is an ideal platform for learning assembly, as I have laid out in my tutorial series on YouTube:
  47. 3 points
    My personal catchphrase
  48. 3 points
  49. 3 points
    My caption for the one with the woman at a Sparcstation with VR goggles and a Nintendo PowerGlove: "This is a UNIX system. I know this!"
  50. 3 points
    Not truly a meme, but jokes about some retro arcade games in this USSR cartoon at timecode from 2:52 to 3:26. Shown here are USSR arcade games Highway, Sea Battle, Safari and some shooting game unknown to me. But I know that most USSR arcades were clones of western ones, so I'm sure you will see familiar games.
×
×
  • Create New...

Important Information

Please review our Terms of Use