Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 06/08/21 in all areas

  1. 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.
    7 points
  2. 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.
    2 points
  3. And to be clear, it's really a VIC-20 with only IEC and no VIC chip.
    2 points
  4. 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).
    2 points
  5. Version 0.5

    58 downloads

    I had been lurking on the forums for a few months when I found Prog8 and though this looked interesting. I.e. I could learn a new language and test out the emulator. I recently saw some good demos using C64 emulator but just based on PETSCII graphics and I though this looked surprisingly cool. Then I remembered the old Galaga game on the C64, the one using just (a few) petscii chars. I thought making something similar would be a nice challenge. The game is continuing to move toward what I consider a complete (but short) game. There are now 12 levels at which point the game will end in victory (bonus points for lives remaning). I am currently inclined to thinking that it's ok to end up with a fairly short and "completable" game. I still need to add some sort of simple high score handling. And there are always places that could use a bit of extra polishing but perhaps it would be better to spend that effort on another game.
    1 point
  6. A corewar VM could be implemented for the X16. That sort of fits the X16's target for software. Probably start simple... https://corewar.co.uk/standards/cwg.txt '86 versus '88: https://corewar.co.uk/madtutor.txt
    1 point
  7. Better keyboard, lot more RAM and with the YM2151 a heck of a lot better sound than a VIC, but text display over bit banged serial would be a real blast from the past.
    1 point
  8. Nice work @ZeroByte. It is fun.
    1 point
  9. Problem is an Fpga 65c02 could be six times faster. This matters.
    1 point
  10. I think everyone has their own "level of difficulty" as it were for these things. On the one extreme, you have the MONSTER 6502 team who created a 6502 from "discrete" transistors (I know they aren't really discrete, but they did what they could and details are not as important here). Then you have the all in FPGA models. FPGA can replicate existing chips exactly, though it is hard to accomplish. The more people push the limits of the original tech, the more difficult it becomes to replicate exactly, as they are depending on implementation details that were never part of the documented interface. I am personally not interested in pushing beyond the documented interfaces, and I'm happy to see the documented interfaces work properly without worrying about the implementation details that were never intended to be exploited. FPGA can also allow one to try their hand at designing something that's never been done before and that wouldn't be practical if one had to create a run of ASICs just to try out ideas. FPGA can bridge the gap between the two, to create "identical copies" of something in low quantities that would be too expensive otherwise. I personally am not bothered by decisions to attempt discrete component based computers that harken back to the past. Some feel this way about cars as has been listed here. We love the computers of our formative era. I am also not bothered by recreating things in FPGA format. Sure, you can't necessarily point at individual chips and tell people what they each do, but one can create a graphical rendering of it and do essentially the same thing. Or create a LEGO version to have a physical representation of the logical bits. Let's face it, if they'd had access to FPGA back in the day, they'd have used it where appropriate. There is nothing wrong with trying to create a system from discrete components, and there is nothing wrong with trying to make things in BASIC just to see how far that can be pushed. We all have our itches to scratch.
    1 point
  11. 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.
    1 point
  12. 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.
    1 point
  13. Yeah, was thinking about that myself. A single bank of RAM would be a natural arena, just wrap around from BFFF to A000.
    1 point
×
×
  • Create New...

Important Information

Please review our Terms of Use