Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. What the vera absolutely needs is an alpha channel implementation for transparency of objects. I spoke with @Frank van den Hoef and he told me it should be possible to implement it. The palette indexing mechanism allows for it as there are 4 bits in the rgb palette unused! The 4 bits could be used to model 16 transparency levels.
  3. Looking good!! reminds me of battlesquadron on the Amiga one of my all time favorite vertical shoot em ups
  4. Yeah. Thank you ed. Most of the base logic is in place now Now comes the challenge of making great graphics and a nice game concept. Thinking about making the player and enemy ships "configurable" based on pre-rendered smaller sized parts like 8x16, 16x16, 16x32 or 32x16 dimensions around a base ship of 32x32. This saves memory and I think this is what @Frank van den Hoef had in mind when he created this sprite engine capable of controlling 128 sprites at the same time. The small pieces can have more extensive animations and "glue" to the base ship or other extensions. Stuff like cannons, lighting, engines, defense shields, radars, tractor beams, magnets, wings, ... It also allows for weapon loading, adding game experience. Enemies are also a challenge. What to model as enemies without doing "cliché" ... Am thinking on some drone concept or chopper concept. The game concept and making the game exciting should add some randomness and side challenges in addition to just shooting. Something like a puzzle to be solved might be interesting. So your brain must think of solutions while shooting and evading. The video vram of 128KB is a real challenge to manage in such a shooter game. Many may have a lot of comments about this and that's fine. But doing is another. A game like this needs animations otherwise this game will get boring quickly. I've put the tiles in 8bpp mode because it is impossible to tile with shadows and light effects using only 4bpp palettes, and have a smooth colour experience. Sven
  5. I had this in mind when I was making FASTMATH. I think I can find a way to do really fast conversion from 16.8 fixed point to the fractional notation and back so you can take full advantage of it.
  6. META/L assembly language editor View File The META/L editor is a direct assembly language editor. It shares some features of a Monitor program, with extensive use of metadata to take it well beyond anything a Monitor can do. Unlike a text editor that later compiles your code, META/L interprets it as assembly language opcodes as you type it. Unlike a Monitor, you can do things like copy and paste code, move it around, or insert or delete bytes in the middle of your code; the metadata allows the editor to adjust parameters as labels move. Every byte of RAM and ROM is accessible to you on the fly. Download the zip file, unzip it somewhere, and copy everything into the same folder as your r41 emulator. Full documentation is in the file docs/edit.html Submitter Ed Minchau Submitted 05/28/22 Category Productivity Apps  
  7. Version 1.3.41.0712

    5 downloads

    The META/L editor is a direct assembly language editor. It shares some features of a Monitor program, with extensive use of metadata to take it well beyond anything a Monitor can do. Unlike a text editor that later compiles your code, META/L interprets it as assembly language opcodes as you type it. Unlike a Monitor, you can do things like copy and paste code, move it around, or insert or delete bytes in the middle of your code; the metadata allows the editor to adjust parameters as labels move. Every byte of RAM and ROM is accessible to you on the fly. Download the zip file, unzip it somewhere, and copy everything into the same folder as your r41 emulator. Full documentation is in the file docs/edit.html There are also a number of videos in the forum here
  8. I took the month of March off from programming altogether, and then at the end of March r39 dropped with some breaking changes. So I've updated the editor to accommodate those changes, and while I was at it fixed a bunch of minor bugs and added some new features. The download is here:
  9. Equinoxe Demo View File Hi, Find a first playable demo of Equinoxe, my Commander X16 shooter ... I know it's not much yet, but I've come from very far making this. To make this, I had to learn how to: - implement a memory manager algorithm for vram on the vera - implement a memory manager algorithm for bram - implement a (fast) collision detection algorithm using spacial hashing technique - implement a fast method to shoot bullets to an angle direction - implement a fast method to calculate the angle between 2 coordinates (so calculate the unit vector) - sprite design using blender and spriter - tile design - implement a dynamic tile walking algorithm - vera library with all kinds of functions to paint sprites and tiles and control the video ram - dynamic level loading - memory banking - mouse control of the CX16 and more ... So as this demo may not be much, I've really learned a lot on this path to make this. And still continuing to develop this game as time floats... Let me know in the comments if this is something you like or not ... This demo must be downloaded as the emulator version on the web does not allow to load a card. So unzip the cx16.zip and a cx16.vhd file will be created. Load the game with x16emu -sdcard cx16.vhd In the emulator, type load "equinoxe.prg", 8, 1 Enjoy! Sveni Submitter svenvandevelde Submitted 05/28/22 Category Games  
  10. Version 1.0.0

    9 downloads

    Hi, Find a first playable demo of Equinoxe, my Commander X16 shooter ... I know it's not much yet, but I've come from very far making this. To make this, I had to learn how to: - implement a memory manager algorithm for vram on the vera - implement a memory manager algorithm for bram - implement a (fast) collision detection algorithm using spacial hashing technique - implement a fast method to shoot bullets to an angle direction - implement a fast method to calculate the angle between 2 coordinates (so calculate the unit vector) - fixed point arithmetic - sprite design using blender and spriter - tile design - implement a dynamic tile walking algorithm - vera library with all kinds of functions to paint sprites and tiles and control the video ram - dynamic level loading - memory banking - mouse control of the CX16 and more ... So as this demo may not be much, I've really learned a lot on this path to make this. And still continuing to develop this game as time floats... Let me know in the comments if this is something you like or not ... This demo must be downloaded as the emulator version on the web does not allow to load a card. So unzip the cx16.zip and a cx16.vhd file will be created. Load the game with x16emu -sdcard cx16.vhd In the emulator, type load "equinoxe.prg", 8, 1 Enjoy! Sveni
  11. Ed, may I ask, does the technique to process the VBLANK in the main loop (outside of the interrupt) help with the frame rate? I mean, I notice that during my IRQ processing, that if the CPU time goes beyond the available time to process one frame, then the logic "stutters" and is noticable. When processing the frames in the main loop, this might help, isn't it? because the main loop can just take it's time to paint, while the interrupt will handle the coordinates of the objects to be painted ... hmmm... might consider.
  12. Thank you, that fixed it
  13. Last week
  14. Yes ... the dominant move when playing the "let's make a game" game to try to make enough money to stay in business and be able to keep on making games. When the "let's make a game" game is being played to satisfy the instinct of workmanship (in Veblen's phrase), there probably isn't a dominant move.
  15. It really depends on the use case.
  16. If the only time you access VERA is during the VBLANK, then great, access it then. But if you're using VERA to store sequential data, like @Jeffrey did with the Wolf 3D wall images, then changing any parameters in VERA can really screw things up in a hurry. So I guess it all depends on how you want to use VERA. Asteroid Commander uses lots of sequential data stored in VRAM for various purposes. If I try updating the screen every VSYNCH or even every third one, it'll stomp all over a whole bunch of things. But if the only time you're accessing VERA is to push data to the screen and PSG/PCM, like I was doing with the Balrog video demo, do it all in the VBLANK.
  17. So the reason for VPOKE is that VERA uses vectored communication. What that means is that to communicate with VERA, you have to set one set of registers with the address and another register with the data. VPOKE hides these details by setting the address registers for you. So what you're doing with that first VPOKE is three things: This sets the VERA bank register to 1 Sets the VERA address L and H registers to $F9C0 Sets the VERA data register to 255 The VERA address registers live at $9F20-9F21, and the bank/increment register lives at $9F22. So to set an address of $1:F9C0 (bank 1, addr $F9C0) in VERA, you would need to do this in BASIC: POKE $9F25,0 : REM always set the ADDRSEL register to make sure you are using the correct port POKE $9F22,1 : REM Sets the bank register to 1 POKE $9F21,$F9 :REM high byte of address POKE $9F20,$C0 :REM low byte of address and then set the data value with POKE $9F23, 255 So now that we see how you can directly address the registers, you can easily translate this to assembly code: STZ $9F25 LDA #1 STA $9F22 LDA #$F9 STA $9F21 LDA #$C0 STA $9F20 LDA #$FF STA $9F23 (Note the STZ is a 65C02 instruction. If STZ doesn't assemble, you may need to enable the extended 65C02 opcodes in your assembler or fall back to LDA #0 / STA $9F25). That's just to write one byte. You actually need to write at least 3 bytes to set the frequency and volume, so you'll want to set the Address Increment. This is the upper 4 bits of $9F22, and you can set the increment to 1 by writing $1x to that register. Since you're already writing a 1 there, you can instead write $11 to automatically increment the address register every time: STZ $9F25 LDA #11 STA $9F22 LDA #$F9 STA $9F21 LDA #$C0 STA $9F20 LDA #$FF STA $9F23 LDA #$05 STA $9F23 LDA #$FF STA $9F23 LDA #$80 STA $9F23 The sound will now be playing. To turn it off, STZ $9F25 LDA #1 STA $9F22 LDA #$F9 STA $9F21 LDA #$C2 STA $9F20 STZ $9F23 I should mention that these are "off the top of my head" instructions. I don't have access to the emulator to try this, so it may need tweaking. If you get this to work, maybe you can post the code (and let us know which assembler) you used. I have actually been considering writing a Morse trainer. Maybe it's time to write one. --... ...-- / --- -- / -.. . / - --- -- -..- .--. ....- .---- .----
  18. ^^ This sounds like Commodore both pre- and post-Tramiel all right. They gamed the market by cutting costs and margins. Buying Amiga makes sense to a company; supporting a research facility maybe is less well understood and maybe more risky. It is clear that chip manufacturing became commoditized and off-shored, so at that point you plan to close the shop, taking your profits for a few more years.
  19. Not really. And to clarify, I was indeed talking about professional development being on other systems. Obviously, homebrew for the C64 was almost entirely on the unit itself until the advent of PC-based emulators like VICE. But this was because the C64 was a proper computer, if a really small one that wasn't good for much besides games. But it was at least good for SOMETHING besides games. Most 8-bit consoles can really do NOTHING other than play games. If you ever used the Atari 2600 BASIC cartridge, you'll know what I mean. With only 128 bytes of RAM, it's impossible to write code, much less run a compiler or assembler. There was BASIC for the FamiCom back in Japan, but again it was a really simplified thing, and not like the real home computer experience. You only have 2kB of RAM, so you still don't really have enough memory to work on code or run an assembler. Once we get to the 16-bit era, things turn around. The SNES has 128k of RAM, and I bet you could make that into a fairly serviceable computer that could at least do some real programming.
  20. Yes, it should be possible.The exact solution will depend a lot on the console chosen, so if you're going to pursue this, I think you should pick one, say NES, and focus on that. The NES is designed as a console, not a general purpose home computer, so you're going to have to add the missing pieces to turn it into a general purpose home computer. It's going to need at least a keyboard, a filesystem, and some working memory. The more you add, the less NES it becomes, however, so you're going to have to strike a balance. I think an FPGA that presents itself to the NES as a cartridge should do the trick. The FPGA has internal memory, can implement a PS/2 interface for a keyboard, an interface for a microSD card, and a serial port for file transfer to/from the device (so you don't always have to swap SD cards in and out). It sounds like a perfect retro computing project! A nice mix of hardware, software and reverse engineering. .
  21. Yes, this is what I was talking about. I wish to know whether there is a possibility to implement same experience on popular game consoles like NES, Atari 2600, etc. Or rather I wish to know whether somebody already went through all the trouble of implementing such working environment. How I imagine this to be done is one need to take original hardware (or reimplemetation of it). Then hack into it adding i/o controllers for keyboard, storage, etc. And create some OS for development environment. Resulting with a look and feel similar to C64 with its BASIC and MON. Full BASIC is not critical here. Any rudimentary peeking, poking. moning, asming is fine. It is a thing for fun after all. Not that there is any usefulness in this. It is very geeky thing to want.
  22. Yes, that was how most people worked on a C64. The same computer was both the host and the target. The result was not less advanced than commercial software. On the contrary. I was in the C64 demoscene in the late 80's early 90's, and the demos the scene was outputting at that time was consistently more advanced than 95% of the games out there. The whole point of demos was to push the limit of the machine. Most games on the other hand were on some kind of budget (money and time) and were being developed with many different home computer targets in mind, so they weren't explicitly pushing the limits of the C64. SlithyMatt's comment about cross development being the norm may have been true for the bigger studios, but there was a lot of indie development going on, e.g. sceners making games and tools, and that was almost always done on a single C64, the machine being both the development host and the target.
  23. Ok, I must admit I have a lack of knowledge about this. I'll try to paraphrase myself. I'm trying to talk about home experience. My point is that somebody, who had a C64 back in the 80's was able to code a game (or any other software) in assembly targeted for this same computer. I never had a C64, so I can't know for sure. But I judge from what I read in articles and from what I see in videos today: people could and people did code in assembly on 8 bit micros for this same 8 bit micros at home. They had only this one machine. Their resulting software would be much less advanced than commercial software - I understand this.
  24. I should read more carefully. Thanks for the pointer.
  25. MORSE6.PRG should be named MORSE6.BAS - it's a .bas file (plaintext BASIC) x16emu -bas MORSE6.PRG It doesn't have a trailing carriage-return either, so you'll need to hit ENTER on the last line before typing RUN
  1. Load more activity
×
×
  • Create New...

Important Information

Please review our Terms of Use