Jump to content

Search the Community

Showing results for tags 'vera'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Commander X16 Forums
    • Introductions
    • X16 Discussion Lounge
    • X16 Help & Support Lounge
    • Off-topic Lounge

Categories

  • Official Software
  • Official Docs
  • Community Downloads
    • Games
    • Productivity Apps
    • Graphics Apps
    • Audio Apps
    • Demos
    • Networking Apps
    • Dev Tools
    • Tutorial Apps
    • Misc Apps

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 25 results

  1. On The 8-Bit Guy's video "Building My Dream Computer Pt. 2", after the Gameduino path didn't work out due to obsolete design of Sparta 3 FPGA and other things, so David needed plan B for video, Ross Andrews sent him Project Vulcan, while Frank Van de Hoef submitted the project VERA, and David chose VERA as a solution to the video hardware question. How different would things really be (realistically), had David picked Vulcan instead of VERA? You can make your own alternative timeline based on that as long as it sounds realistic.
  2. Hello everyone, Here's my 3rd experiment on the x16. It's a 32x32 pixel scroller like you'd see in a demoscene intro. I wanted to share what I've learned so far in case it might help some other newbie along. While watching slithymatt's tutorials about VERA I wanted to play around with the layering, tiles and scrolling systems. Attached is an animated gif, the prg and the source code in KickAssember format, since that's what I'm used to using on the C64 for my cross development. The best thing about using KickAssembler in my opinion is that is has a strong macro language build in, so the source code loads the png font and converts it to a VERA compatible format... no need to write conversion helpers in other scripting languages. Hope you enjoy. p.s. Not sure if this is the best forum to post this? Is there somewhere more appropriate? p.p.s. IS the jittering in the emulator avoidable? I tried a few things but was unable to reduce / remove it? scroll32.prg src_scroll32.zip
  3. Version 1.3.0

    248 downloads

    Raycaster demo (written in c and assembly) This version is a big improvement in performance: it now runs at 10+ fps! I am quite happy with the speed. The demo plays quite nicely now. See below description of version 1.3.0 for details. --- This is a raycaster demo written in c and assembly for the Commander x16. I've been trying out the x16 and thought it would be a cool idea to start working on a raycaster. Ultimately it would be great if "Wolfenstein 3D" can somehow be ported to the x16. That would be a BIG challenge though! This is how it looks now: Speed improvements in 1.3.0: Now running at 10+ fps! - Using zero page addresses for pretty much all my variables - Using fast multipliers that use "square" tables: https://codebase64.org/doku.php?id=base:seriously_fast_multiplication - Inlined the fast multipliers, so less copying of values, no jsr and rts - Re-using the somewhat "static" parts of the multiplications, so it won't be re-loaded/calculate each ray (this was harder than it sounds, quite of bit of refactoring done) - Cosine and Sine fractions are player-related, and even though they are negated sometimes, they (that is their squares) could be reused for (almost) each ray - The (square of the) fraction of the tile the player is standing in -to be used for calculating the initial x/y interception for each ray- could be reused - Cleaned up the main loop and several other parts - Replaced the 16-bit slow divider with a 512-entry table: distance2height (major improvement!!) New in this version 1.2.0: - draw functions have been ported to assembly. Much faster! - dda casting functions have been ported to assembly. Much faster! - drawing textures! - automatic generation of routine to draw ceiling and floor (only 4 cycles per plain pixel) - automatic generation of around 512 routines for drawing textures (only 8 cycles per textures pixel) - using joystick controls (you can use arrow keys and alt to control, you can hold down keys) - a few textures from Wolfenstein 3D (shareware version) have been added (loaded at startup) - changed the map to look like the first level in Wolfenstein 3D - added a border around the render area, just like Wolfenstein 3D Usage Unpack the zip. Make sure you have the .BIN files in the same folder as the source files. To compile: (this assumes cc65 is installed) cl65 -t cx16 -o RAY.PRG ray.c ray_asm.asm -O3 To run: x16emu.exe -prg RAY.PRG -run To play: up - move forwards down - move backwards left - turn left right - turn right alt-left - strafe left alt-right - strafe right To debug: p - turn on log screen o - turn off log screen t - turn on test ray l - rotate test ray left j - rotate test ray right Known issues (1.2.0) - Sometimes there is a corner of a wall not drawn correctly - Since there is no real V-sync you get "shearing" in the screen (requires double buffering) Next up: - Lots of speed improvements - Lots of cleanup of code (its messy now) - Add a time-per-frame indicator (using a vsync interrupt counter) - Mooaarr wall-textures! - Double buffer to prevent shearing - Show a map on the screen - Bigger map (limit is now 16x16) - Opening doors - Add (scaled) "sprites" - Lamps (scaled) hanging from ceiling - Stats in lower part, gun visible - AI, enemies Having fun! Jeffrey
  4. I'm learning VERA hardware programming, mainly in assembler but via BASIC where investigation may help. In BASIC the VPOKE command pokes video ram. But I'm unsure about the bank parameter. Experimenting with VPOKE bank, address, 1 it looks like valid values are: 0 <= bank <= 255 0 <= address <= 65535 But VERA only has 128k RAM, right? So are banks 0 and 1 only used at present ? Are bank values >= 2 superfluous ? I'm just trying to understand how the hardware works and the fact that BASIC doesn't complain if bank >= 2 made me wonder if more than 128k was available somehow...
  5. Unless I'm mistaken (I WAS !) the VERA docs seem to show the wrong addresses for DC_HSTART, DC_HSTOP, DC_VSTART, DC_VSTOP (and the rest presumably) Should not DC_HSTART be $9f2D, etc. Wanted to check as trying to understand how to change screen layout. I managed to switch to 320x240 by setting DC_HSCALE and DC_VSCALE to 64, but I'm having trouble settings the left/right, top/bottom boundaries. UPDATE I needed to set the DCSEL flag to change screen layout, which is actually hinted at in the docs (DCSEL=1).
  6. Is it possible to manually (not from software) re-program the VERA's on-board FPGA to perform different kinds of tasks? This can perhaps allow the video modes to be changed, or even allow a virtual 2nd CPU to be created if there's enough spare logic blocks. I might as well replace the default PSG/PCM audio with my own Amiga-like sampler, to be paired with the otherwise hard-coded YM2151 and SAA1099 audio. I know users will be able to re-program the X16's flash ROM with their own software, to be paired with their custom VHDL/Verilog code if only @Frank van den Hoef makes this possible.
  7. 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  
  8. Still around, just having loads of fun creating a random tile generator ... lol ... It's harder than i thought it would be ... . Anyway, getting there, i also need to incorporate an evaluation of the diagonal tiles to be able to plot the right new tile.
  9. I know you're very far along when it comes to the design and implementation of the VERA sub-system. However I figure I'd throw this out just in case. Is there any chance block clear\fill functionality could be included so we can clear out blocks of VRAM? Right now the bitmap mode has considerable limitations as we can't just clear the previous frame without resorting to a pixel by pixel approach. It will sadly mean this mode is left to mostly showing static images. One possibility would be to add a bit to the CTRL register, so if set when we write to DATA0 it could fill the 256 bytes at ADDR_H, ADDR_M with the value. (As a programmer, obv I'd prefer something even quicker! It would open up the possibility to do something a little inventive with the mode.
  10. Chonky Text in 6502 Assembly View File A little demo of rendering giant text in assembly. It takes the data from the Lower/Upper character set in ROM and renders it in a large, "LCD-style" font. You can use .asciiz in CC65 for letters, or use a zero-terminated array of bytes to reference the character codes, as below (thanks to https://www.commanderx16.com/forum/index.php?/profile/5-jimmydansbo/ for the character set reference). Submitter gavinhaslehurst Submitted 03/03/21 Category Demos  
  11. Version 0.8

    112 downloads

    A little demo of rendering giant text in assembly. It takes the data from the Lower/Upper character set in ROM and renders it in a large, "LCD-style" font. You can use .asciiz in CC65 for letters, or use a zero-terminated array of bytes to reference the character codes, as below (thanks to https://www.commanderx16.com/forum/index.php?/profile/5-jimmydansbo/ for the character set reference).
  12. Version 0.0.3

    105 downloads

    I have been playing with the VERA chip in assembly, and have come up with a cheeky little demo screen that is reminiscent of some 80s demos I can remember as a kid. No music or fancy interactive stuff, but some of you might find it amusing. Warning: As a GP I feel I ought to point out this demo contains flashing / strobing effects! Thanks to the excellent tutorials of SlithyMatt - Commander X16™ Community, especially the latest one demystifying the VERA chip. I have used a lot of his code from the latest tutorial to create this demo.
  13. Vertical Bar Scroller View File This is a demo to try out how far VERA can be pushed: it is quite hard to have vertically (independently) scolling bars using VERA. What this demonstrates is that it is in possible. But only just. It turns out I had to use 80 sprites in combination with a lot of LINE-interrupts. Here is what I did: - Create a 64 pixel by 5*64 pixel colored data rectangle (in this example filled with 4x4 pixel squares) - Place 80 sprites (of 64x64 pixels) from left to right, overlapping mostly, but showing the 4 left pixels of each sprite - These sprites are (vertically) grouped in pairs, so that each pair is placed one pixel lower than the pair next to it on the right - The data address of each sprite (where they get their colored pixels from) are initially set to the same point (they all start with an vertical offset of 0) - For each low-res LINE-interrupt (that is: 240 times per frame) we do the following: - move one pair of sprites (that are *just* out of view) 64 pixels down - change the data address so that it matches it individual vertical-offset - At the end of all the LINE-interrups (after the 240 lines) we do the following: - Adjust the vertical offsets with the individual change-per-frame numbers - Move all sprites back to the top, with negative y-coordinates (according to their offsets) It runs a maximum fps: every frame there is an update. Warning: this demo contains (what amounts to) flashing / strobing effects. # Known issues - There are small horizontal lines visible at certain places. This is probably because the LINE-interrupt code is not fast enough # Comparing hardware with emulator I think this demo will probably not work (exactly) the same on real hardware. It's probably a good way to check whether the emulator is accurate (for certain aspects of the VERA board). # To Compile: cl65 -t cx16 -o VBS.PRG -l vbs.list vbs.asm # To Run: x16emu.exe -prg VBS.PRG -run Regards, Jeffrey Submitter Jeffrey Submitted 02/24/21 Category Demos  
  14. Version 1.0.0

    30 downloads

    This is a demo to try out how far VERA can be pushed: it is quite hard to have vertically (independently) scolling bars using VERA. What this demonstrates is that it is in possible. But only just. It turns out I had to use 80 sprites in combination with a lot of LINE-interrupts. Here is what I did: - Create a 64 pixel by 5*64 pixel colored data rectangle (in this example filled with 4x4 pixel squares) - Place 80 sprites (of 64x64 pixels) from left to right, overlapping mostly, but showing the 4 left pixels of each sprite - These sprites are (vertically) grouped in pairs, so that each pair is placed one pixel lower than the pair next to it on the right - The data address of each sprite (where they get their colored pixels from) are initially set to the same point (they all start with an vertical offset of 0) - For each low-res LINE-interrupt (that is: 240 times per frame) we do the following: - move one pair of sprites (that are *just* out of view) 64 pixels down - change the data address so that it matches it individual vertical-offset - At the end of all the LINE-interrups (after the 240 lines) we do the following: - Adjust the vertical offsets with the individual change-per-frame numbers - Move all sprites back to the top, with negative y-coordinates (according to their offsets) It runs a maximum fps: every frame there is an update. Warning: this demo contains (what amounts to) flashing / strobing effects. # Known issues - There are small horizontal lines visible at certain places. This is probably because the LINE-interrupt code is not fast enough # Comparing hardware with emulator I think this demo will probably not work (exactly) the same on real hardware. It's probably a good way to check whether the emulator is accurate (for certain aspects of the VERA board). # To Compile: cl65 -t cx16 -o VBS.PRG -l vbs.list vbs.asm # To Run: x16emu.exe -prg VBS.PRG -run Regards, Jeffrey
  15. VERA Demo Screen written in assembly View File I have been playing with the VERA chip in assembly, and have come up with a cheeky little demo screen that is reminiscent of some 80s demos I can remember as a kid. No music or fancy interactive stuff, but some of you might find it amusing. Warning: As a GP I feel I ought to point out this demo contains flashing / strobing effects! Thanks to the excellent tutorials of SlithyMatt - Commander X16™ Community, especially the latest one demystifying the VERA chip. I have used a lot of his code from the latest tutorial to create this demo. Submitter gavinhaslehurst Submitted 02/24/21 Category Demos  
  16. Version 1.0.1

    85 downloads

    This demo program provides an overview of what the vera card can do in terms of the different configurations in text mode, tile mode, and bitmap modes. The demo is nothing really fancy, but the workhorse underneath is the new API library (veralib.c and veralib.h, conio-cx16.c etc. ) that allows to configure and control the vera card of the CX16 using the kickc compiler of Jesper Gravgaard: camelot / kickc · GitLab. The veralib library and source code of this demo program has become an integral part of the compiler and test programs, and can be downloaded also from src/test/kc/examples/cx16/cx16-vera.c · CX16_VERA · Sven Van de Velde / kickc · GitLab. If you're a C-programmer, and you're interested in using this library, please beware that this is still work in progress. However, if you're motivated to try it out, i'm really interested to get feedback on this c-library to understand if the API is useful and clear. Feel free to try out the program, by running it in an emulator in windows; the mobile phone emulators won't be able to run this program properly because the keyboard is needed to run this. More features are planned to be added. One of the features planned is to provide mouse support, so it can be run using the android emulators too. kind regards, Sven
  17. Hi All, I’m considering how to include a simple particle system in an X16 game - eg for explosions, with each particle being a single pixel. I can’t find any examples of how to do this (assembly). Does anyone have any suggestions or links? Many thanks T
  18. Hi all, Just trying a few things before starting on a basic game. One thing I'm up to is loading a file into VRAM. I see this is supported in BASIC, but is there any existing code to do this is ASM? I can see how to implement this myself by opening the file, reading it a byte at a time and using the auto-increment of both the file handle and the vera, pipe it through. But, is there a repository of helper functions to do things like this? Cheers Troy
  19. Vera Modes - Demo View File This demo program provides an overview of what the vera card can do in terms of the different configurations in text mode, tile mode, and bitmap modes. The demo is nothing really fancy, but the workhorse underneath is the new API library (veralib.c and veralib.h, conio-cx16.c etc. ) that allows to configure and control the vera card of the CX16 using the kickc compiler of Jesper Gravgaard: camelot / kickc · GitLab. The veralib library and source code of this demo program has become an integral part of the compiler and test programs, and can be downloaded also from src/test/kc/examples/cx16/cx16-vera.c · CX16_VERA · Sven Van de Velde / kickc · GitLab. If you're a C-programmer, and you're interested in using this library, please beware that this is still work in progress. However, if you're motivated to try it out, i'm really interested to get feedback on this c-library to understand if the API is useful and clear. Feel free to try out the program, by running it in an emulator in windows; the mobile phone emulators won't be able to run this program properly because the keyboard is needed to run this. More features are planned to be added. One of the features planned is to provide mouse support, so it can be run using the android emulators too. kind regards, Sven Submitter svenvandevelde Submitted 01/23/21 Category Graphics Apps  
  20. I've created a blog post about using tiles in BASIC. Going over the fundamentals of getting a Tiled map and graphics in to the X16 and displayed. https://justinbaldock.wordpress.com/2020/10/09/commander-x16-basic-tiles/ Feel free to comment here when providing feedback.
  21. I'm thinking about the XDC player (or '8088 domination') when writing this topic, if it's not clear. I'd like to discuss about how good the X16/VERA can be at video playback. First, let's compare the X16 with an IBM PC: the 8088 can needs more cycles to execute a command, but the 6502 does much less in one instruction, and it's 8-bit. Therefore I don't quite agree with the idea that the X16 would totally outperform a PC in general tasks. However, when it comes down to video playback, it's all about clock speed and cycle count. An LDA-STA-DEX-BNE cycle (which acts like a REP MOVSB command widely used in XDC) would cost 11 to 13 clock cycles (depending which kind of LDA you're using, as explained below), at 8MHz frequency, this would give us around 615KB/s to 727KB/s transfer rate. Well this is an ideal case and in reality we'll also be dealing with audio and resetting counter and stuff. However, it is arguable that we will able to get over 480KB/s at most times, which is double the limit of XDC. Since the author of XDC said that the graphics I/O is the ultimate bottleneck of the player (the MFM disk could only do 90KB/s but this can easily be solved by using a XT-IDE card instead), we can expect the X16 to do much better, if not double the fluency. Second, the X16 has 256 colors from a 4096-color palette. which means don't need dithering to achieve the same effect of XDC. No dithering will result in more chunky data which is good for run-length compression. Plus, we can use only the STA-DEX-BNE cycle similar to a REP STOSB command. It needs only 9 clock cycles which will give us more than 1MB/s raw transfer speed! What makes things better? The VERA chip! The auto increment feature allows us to implement dithering AND have chunky data (along with the benefits of run-length compression and higher transfer rate). This is because ordered dithering changes a single color into a pattern, which is usually 8 pixels long. Then we can set the auto increment value to 8 and fill in pixel 0,8,16... in the first run and pixel 1,9,17... in the second run etc. By doing so we can achieve good color, high compression rate and fluency simultaneously. There are two ways to play the video: first, the player reads the video file and copy it to VRAM (that means we will use LDA [addr],X which is 4 cycles at least). The second is the player just JSRs to the video and 'execute' it (that means we can use LDA #value instead, a 2 cycle command). Despite being a bit slower, I believe the first is a better solution as users might be sharing videos online (probably on this forum) and the second method has essentially no way to protect the device from 'Trojan video'. You would definitely not want your movie erase all the files on your SD card, do you?
  22. IRClock View File IRClock shows a digital clock in the upper right corner of the screen. This way it is possible to keep an eye on the clock even while being productive on the Commander X16. The program copies it self into golden RAM, starting at $0400 and takes up a total of 195 bytes. After initialization, the program does not need any of the memory usually used for BASIC and can be overwritten. When the program is running, the current hour, minute and second can be poked into addresses $400, $401 and $402 respectively. The values must be BCD encoded which essentially means, just poke them in as hexadecimal values i.e. 11:04 would be poke'd in like this: Result is immediately visible. Souce can be found here: https://github.com/JimmyDansbo/cx16stuff/blob/master/irclock.asm Submitter JimmyDansbo Submitted 01/14/21 Category Misc Apps
  23. Version 1.0.0

    15 downloads

    IRClock shows a digital clock in the upper right corner of the screen. This way it is possible to keep an eye on the clock even while being productive on the Commander X16. The program copies it self into golden RAM, starting at $0400 and takes up a total of 195 bytes. After initialization, the program does not need any of the memory usually used for BASIC and can be overwritten. When the program is running, the current hour, minute and second can be poked into addresses $400, $401 and $402 respectively. The values must be BCD encoded which essentially means, just poke them in as hexadecimal values i.e. 11:04 would be poke'd in like this: Result is immediately visible.
  24. @Frank van den Hoef What would happen if a DC START register is greater or equal to its matching STOP register? Will it flip the image or not render it at all? Flipping would make the VERA's logic design a bit more complicated, so I assume it's the latter. Does a sprite with a lower Z-depth value and lower position in memory actually render behind a sprite with higher Z-depth and position, or will it display garbage like the GBA? (E.g. sprite 0 has Z=2, sprite 1 has Z=3) Note that lower positions mean higher-priority sprites if their Z-depth is the same. Will the PSG's noise wave use a predefined sequence? The emulator's PSG code doesn't seem to implement one, and just takes a random number from 0 to 63. Maybe it uses a true-random supply from somewhere in your FPGA?
  25. So in my other post here: I wanted to make a programming language and a IDE to be used in the X16. So for creating the text box I have 2 options: 1. Using the GNU Readline library pros: Allows me to program in c cons: May not work on the X16, Lack of documentation, Might need to be ported to the X16 2. Directly editing the video memory pros: Gives me full control over graphics, Wont require extra code to be ported, cons: Even though I do have experience in assembly(x86 and 6502) it will be very hard to get right. So I have chosen to interface with the video memory directly. I'm having a bit of trouble understanding the Vera video card. I have read through parts of the unofficial documentation but I have a couple questions: 1. How do you switch to text mode? 2. How do you add characters or etc to specific parts of the screen? As development continues more questions may arise if so they will be added on to the list of questions. Thank you and have a nice day!
×
×
  • Create New...

Important Information

Please review our Terms of Use