Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 07/08/20 in all areas

  1. 11 points
    Hi all, I started developing a game for the X16 last September - coming up on a year ago now! I come from same the 1980s 8-bit BASIC programming vintage as Director-in-Chief Murray and probably most of you lot too, but I've never developed a whole game before. The X16 project has inspired me to learn assembly, with the goal of writing this game. More than a whiff of nostalgia about it all too - fond memories of passing POKEs to schoolmates to get infinite lives in Manic Miner and Jet Set Willy. Loosely, my game is a turn-based strategy/resource management thing with a passing resemblance to the hex-based board game settlers of catan. But the resemblance is only skin deep - this game has a strong story-based adventuring/survival/exploration leaning, all mixed together and served up with a hearty dose of good old fashioned text adventure. Blimey, I'll tell you what - it's been a steep curve. Simultaneously learning assembly; learning the vera / X16 hardware whilst developing how the game is going to work: combat systems - resource / asset / fatigue management - display; writing the code ; creating the graphics; writing the prose. It turns out taking on a game (even an 8-bit style game) single-handedly is a HUGE undertaking. I doff my hat to @SlithyMatt - you sir are a legend I've no idea how you churn out the code with such amazing regularity!! But the great thing about the X16 is - IT CAN BE DONE. It might take ages, but if I can do it, anyone can! It's been a long time coming, but I've got to the stage now where I've finalised the gameplay, memory management, and the overarching story of the game. I've also battered my head against my assembly inadequacies sufficiently (with lots of help from proper programmers - again, hat tip to @SlithyMatt , @StephenHorn, @Greg King , @togster510 and others - sorry if I've missed you out!) such that the code for the main game loop is now (pretty much!) in place. Things I've learned so far: 1. Planning everything out on paper before starting to code ABSOLUTELY VITAL! I was keen to get into the 'interesting stuff' straight away (drawing the graphics, putting things on screen) but in the long run, having the whole game pretty much drawn out in principle on paper first meant I've avoided a number of unpleasantries in the coding thereof. How are you going to address the screen - one layer? two layers? What is going onto each layer? How many bpp will you need for each layer? How many sprites will you need? How many frames of animation? How much vram will all that take? How are you going to encode the various aspects of gameplay? Which memory banks are you going to put them in? Which leads me onto - 2. Plan out your memory management. The X16 only has 40k of low memory + 64 x 8k memory banks to play with (in the base model) plus 128kB of video memory, so you can't just splurge on huge 256 colour graphics all over the place - the limitations of the system require some thought on how much you're going to fit in, and how you're going to fit it in. I've used up three memory banks just storing the hex tiles for the whole game board (64 x 64 hexes in total, although not all visible on screen at once) - made up of 32 different types of hex terrain, each with its own individual replenishing resources, roads, rivers and bridges. 3. Assembly is HARD but not IMPOSSIBLE. I've lost count the number of times my eyes have glazed over whilst looking at what I've lda'd and what I've sta'd wondering why the hell it doesn't do what I've CLEARLY just told it to do... persevere, and post questions on the software support forum. There are kind people out there who will help you (me included, if it's within my power to do so!!) 4. You will probably end up writing programs that help you write your program. This one was a bit of a surprise for me - but I've done it twice so far already. For example, I wrote a bitmap converter that loads up 16x16 pixel .bmp graphic files I've drawn in photoshop, and it spews them into memory as four sequential 8x8 tiles for storing in the vram tile map (my graphics are 16x16 but they need to be placed on an 8x8 tile grid because of how the hexes work). It took me an afternoon to write but it would have been immensely complicated and taken a LOT longer to hand-convert every terrain and item graphic in a hex-editor! 5. Things change. Roll with the punches. If the gameplay has to change slightly to fit within the limitations, so be it. The people playing the finished game aren't bothered about what you thought the game was going to be like. Deciding on the layout of the main screen was a hassle for me - there's more stuff I wanted to show than there was room for, and I tried various ways of cramming it all in, whilst still getting it to look attractive. Eventually I decided I couldn't do it, so I've split the information across two screens that can be toggled between. The main screen now shows a bar that fills up as the amount of stuff you're carrying increases. A handful of grain fills up one backpack 'slot'; an apple fills up 3, and one load of stone fills 16 slots etc. so you have to be careful about choosing what to carry around with you. But you can toggle to the backpack screen that itemises all the resources and equipment you're carrying so you know for example how many apples you've got and how much stone you're carrying etc. I should add this game is a bit of a nod towards the now legendary Planet X2 - if you've got half an hour spare, David's 'making of' video https://www.youtube.com/watch?v=NB_VBl7ut9Y is really helpful and has some great tips particularly about memory management - it's aimed specifically at the C64, but a lot of it is pertinent to the X16 too. I hope this is of some help for others considering embarking on a similar coding journey. At the very least, I'm writing all this down now in the hope that you lovely X16 people will hold me to account and spur me on to actually finish writing this blasted game..! The hexes await... in the meantime, have a peek at the notes in the photos below, it'll give you a flavour of what kind of things are included in the game. Also a screenshot of how the game currently looks. Ta ta for now!
  2. 5 points
    The Emulator and the ROM have been adapted for the new board. You can check out branches x16_board_r2 in the source of the two projects. The official reference manual has also been updated. In short, these are the major breaking changes: RAM and ROM banking is done through magic zero page locations 0 and 1. Up to 512 KB of ROM are now supported. VIA#1 is now at $9F00, VIA#2 at $9F10 YM is at $9F40 All I/O (PS/2, Controllers, Serial) has been moved to VIA#1 PA and PB.
  3. 4 points
    Look what Lego are about to release...
  4. 4 points
    YM2151 SYNTH UI View File A simple user interface for the YM2151 synth. Usage: LOAD "SYNTHUI.PRG",8,1 SYS$1000 Use the keys as any tracker to play. Use the sliders an buttons with the mouse to adjust synth params. Submitter Miklós Pathy Submitted 07/11/20 Category Audio Apps  
  5. 4 points
    The debugger doesn't currently allow you to fill values in memory... that said, I happen to be in the middle of some changes to the debugger based on a separate suggestion to make it possible to dump VRAM, so I think I'll go ahead and add a "fill" command while I'm at it. So hopefully it'd make it into r38, which shouldn't be too far off on the horizon.
  6. 3 points
    Hi all, I'm Ron Rhodes from Sunnyvale, California. I first started programming in Fortran on punched cards at U.C. Berkeley. Then I learned IBM Assembly on a 360. I worked at Radio Shack so I learned BASIC on the TRS-80, Color Computer and the PC (the Tandy Pocket Computer came first). My first programming job was CBasic on an 8 inch floppy system running Chromix. Then Captain Kirk told me to buy a Vic-20, so I did. My first real program used up all the memory so I got a 5K extender, and then a C64 and eventually a C128 (still have them). I longed for an Amiga for a long time until it was too long. So I got a PowerPC Mac. Of course I used PCs at work. We also used an HP 3000 (IMAGE database), DEC VAX VMS, Silicon Graphics and finally some generic hardware running RedHat Linux. Got heavily into Oracle relational DB and Informatica, Spotfire and whatever else worked. I once wrote a bar code reading script that ran in Reflection terminal emulator for a drug testing robot. I can remember typing in hexcode programs from the magazines, and trying to download programs from Quantum-Link at 300 baud. (I still have my 5 inch floppy notepad with the hole in the middle of it). I played around with a FORTH cartridge and ended up instead sending PostScript to a Laserjet. I created my own barcode labels. Joined the Stanford Macintosh Users Group to get the monthly shareware diskette. Saw Jay Minor at an Amiga meeting in Palo Alto. I kept trying to learn JAVA but the environment changed so fast at the time. I did more JavaScript coding. Wrote a useful program in HyperCard for a presentation at work. Wrote one side scroller game in Flash when I had some time off (laid off actually). Currently, I'm playing around with Arduinos and circuits using C but would like an excuse to learn Python, maybe an ESP32 app. I don't know if I'd buy a Commander X16 but I love the enthusiasm of the retro community.
  7. 3 points

    Version 1.0.0

    2 downloads

    This is a remake of a game called Snake Byte by Sirius Software Inc. published in 1982 for, according to Moby Games, the Commodore 64, Vic-20, Apple II & Atari 8-bit. This remake has minimal audio (added by Frank Bass as a proof of concept on Oct 25, 2019). This version is written in "C" using cc65, originally for the Commodore 64 in 2011, and the Commander X16 port was done in 2019. From Wikipedia: The player controls a snake, crawling into a rectangular area. The aim is to eat 10 apples per level. If an apple is not eaten during the given deadline, three extra apples are to be eaten. The snake becomes longer with each apple eaten. The snake loses a life when crashing a wall or its tail. Higher levels have more fences, making the game more difficult. An optional difficulty are the "plums" (one or two pieces), which kill the snake when hitting its head.
  8. 3 points
    If you have a Best Buy or similar store nearby, they have Corsair keyboards on display that you can try out. Granted, you'll want to wash your hands thoroughly afterwards (or wear rubber gloves), due to COVID. But the Corsair keyboards will use Cherry MX switches of some sort, and you can get an idea for how they feel. If it's not evident, just pop a keycap off and look at the color of the stem, and you'll know what kind of switch it is. I'm typing this on a keyboard with MX Reds. I'd prefer Blues, but I spend too much time on conference calls for the noise level to be acceptable. I used to get comments from coworkers when I was on calls and typing on an old IBM keyboard with buckling springs (best keyboard ever).
  9. 3 points
    Hi I'm Ed Minchau. I started programming in 1981 on the Apple II and quickly bought myself a Commodore Vic-20. Due to financial difficulties, I ended up using that Vic20 until 1999 or so. As a result, I got a lot of practice programming in 6502 assembler. Oftentimes while I was in school taking FORTRAN77 or Pascal or C courses, I'd write the program first on the Vic in BASIC just to get the logic right and then translate it into whatever language I was studying! I've been spending the last ten months or so writing an assembly language editor for the Commander X16. Version 1.0 came out in January, version 1.1 came out in April, and the new and much bigger and vastly improved version 1.2 is nearly done.
  10. 3 points
    I had originally planned to leave this topic alone if there wasn't much interest, but now I want to plug just one more video from this channel, because the exact parallax technique Sega used in Sonic the Hedgehog is something that I've discussed a couple of times in the Facebook group, as a viable technique on the VERA. And, in fact, this video shows just how similar the VERA's capabilities are to the Genesis' video processing, right down to the limitation on how many sprites can be drawn on a single line. (However, line IRQs are broken in r37, but the github repo has the fix so you can either grab and compile from there, or wait until r38.)
  11. 3 points
    Just for fun and because it has been asked a few times I want to explain what would be required to use a VIC-II or SID or really any chips that are too slow under normal circumstances. I’m not saying either of these is really a useful idea, but it makes a good introduction to how to use such things on expansion cards. Also up front this article is going to use layman’s terms but is still geared at those interested in hardware. Since it’s the less complex option, I’ll start with how you would use a SID chip. Probably the best point to emphasis because it affects any chip you want to interface to the bus is the access window. The CPU in the x16 uses half cycle access for memory or IO. This means that in each clock cycle the first half of the cycle is spent doing internal processor stuff and setting this up for the actual bus access. During the second half of the cycle the cpu performs either a read or a write access to memory or IO. This time we will refer to as the access window. And all chips on this bus need to be able to respond to read/write operations within that window. So how long is this access window? Well it is measured in nanoseconds. To give you some context, if you have a clock running at 1 MHz, there are exactly 1000 nanoseconds in that one cycle. So if our cpu was running at 1 MHz our access window would be slightly less than half that, about 500ns. If we increase to 2 MHz that access window decreases to about 250ns. However I’m doing a rough approximation because there are some factors that also affect how much of that access window is really usable. There is address deciding aka glue logic that reads which address the cpu is trying to address and then selects or enables the appropriate chips. This process is not instantaneous, and the amount of time it takes for the inputs address lines from the cpu) to the outputs (chip select lines from the logic) is going to be referred to here as propagation delay. This delay is also in nanoseconds and for the sake of simplicity we are going to state this value as 20ns. So with this value we will then see our usable access window at 1mhz is closer to 480ns and at 2mgz would be closer to 230ns. So let’s consider this for the 8MHz that the x16 runs at. We get an nominal window of 62 nanoseconds but an effective window of 42 nanoseconds. So what this means is that any chip that will connect to the bus, be it RAM, ROM, IO chips, video chips, audio chips, etc. must be able to respond to a read or write in less than 42 nanoseconds in order to work reliably. There are ways around this and I will get to them later, but I’m just making the point that any chip that connects directly to the system bus must be able to respond within that access window. In the case of a SID chip I’m not sure what it’s access time is, but it’s likely in the 150-200nS range. So it would work at 1-2 MHz reliably and might work with 4mhz. But it won’t work reliably on an 8mhz bus without some type of buffering. So if you were to implement one, you have several option on how to go about it. If you aren’t concerned with reading the chip, then you could use latches. You would need to latch the data and the address and implement some type of timer to extend the hold time. What you are doing in this case is that instead of interfacing to the SID directly you are instead interfacing to a simple latch which just captures the relevant address lines and the 8 bit data. This buffer then outputs those values for as long as needed. To enable the chip to be read requires some additional circuitry. This method can actually be used for both reads and writes and involves halting the CPU to extend the access window across one or more CPU cycles. Basically when an access occurs the RDY line needs to be pulled low while the BE (Bus Enable) line is pulled high. This causes the CPU to be halted in its current state. Using binary counters we can hold this state for as many cycles as we need. Keeping in mind for an 8 MHz bus if we extend the acces by just one cycle what we actually get is 42ns+125ns for a total of 167ns and if we need more time we get an additional 125ns for each cycle we extend that window by. Keep in mind this method does require the use of bi-directional tranceivers or equivalent. Now to use the VIC-II chip is quite a bit trickier. Basically the main issues is the VIC-II needs access to memory. Since there is no way you could make it play nice with the X16 memory space you’d need to give it its own memory. You would need to design some kind of circuit that would act as a bus bridge. this bridge would have to facilitate both reading and writing to the Vic-IIChip-II chip itself but would also have to act as an indirect memory window. This is doable but is not a lighthearted undertaking. I’m not suggesting anyone actually tackle this I’m just saying that it is possible and that this is what would have to take place. I feel I should also add though that doing these things would not make the X16 capable of running C64 software. i’m merely laying out what would need to take place to make it possible to interface with these chips not what would need to take place to emulate another system. This is just a fun thought experiment and a good opportunity for me to explain how it would be done. One follow up too, this is by no means a definitive guide on the actual timing requirements. The reality is the timing is probably more forgiving that what I’ve stated here, my 20ns example is more like a worst case scenario. We don’t have hard figures on the actual timing yet, for that we need to finalize all details of the board and measure multiple samples at different temperatures and voltage ranges. . Sent from my iPhone using Tapatalk
  12. 2 points

    Version 1.0.0

    3 downloads

    This is a Commander X16 remake of the ZX Spectrum game "Penetrator" by Phillip Mitchell and published by Beam Software in 1982. This, version 1, does not have any audio.
  13. 2 points
    I want to write a programming language for the X16 called Base Camp. I want to write a language because although BASIC is an awesome language the one issue I have with it is that its interpreted so I want Base Camp to be similar to BASIC but with components of modern languages(for example functions) I also would like it to be compiled. Before I can start I have a few questions: 1. Is it practical(should I create Base Camp or is it a bad idea)? 2. Is it possible(is it possible to write Base Camp)? 3. Are there any text editors for the X16 and if not how could I write one? 4. Should I write Base Camp in BASIC or assembly(I'm pretty sure ill write in it assembly but I want to hear other peoples opinions.) My skills: I have worked with x86 assembly and am learning 6502 assembly. Any comments would be appreciated. Thank You!
  14. 2 points
    Hi Commandos, I'm Igor from Sao Paulo, Brazil. I'm just an enthusiast of retro computers, but I don't work on anything tech related (I'm an attorney). But I feel quite happy to be surrounded by such tech-minded people! I have an Atari 800XL computer and I'm eager to lay my hands on the Commander X16 ! Regards. Igor
  15. 2 points
    Hoo boy, that unofficial documentation I wrote so long ago is somewhat out of date. I never updated it for VERA 0.9 (which is rapidly looking like it'll turn out to be VERA 1.0). I wouldn't use it anymore, and in fact I thought I'd made the document private... hrm... Anyways, to most directly answer your questions: Switching layer 0 to "text mode", where the text starts at VRAM address $00000 and glyph data starts at VRAM address $0F800: You can set layer 1, instead, by moving the registers $9F2D-$9F33 to $9F34-$9F3A. In either case, you may need to copy glyph data into VRAM, but apparently the kernal can do this for you if you call the screen_set_charset function: Adding characters to specific parts of the screen: Each cursor location in VRAM is stored as two bytes: Character index (a.k.a. screencode, a.k.a. tile index) in byte 0, color data in byte 1. So if you've configured a layer into text mode per the assembly above, then $00000 contains the character at <0, 0> (top-left corner of the screen), $00001 contains that character's color. $00002 contains the character at <0, 1>, $00003 contains its color. If you inspect the configuration options carefully, you'll see that the text mode setup here is 128x64. This is the same as the default text console on system startup, you'll have to handle the 80-column limit yourself, just as the kernal does. Or not, use layer scrolling and have up to 128 characters per line. Besides being a technical limitation of the VERA (it can't specifically do an 80-wide map, the map sizes are all powers of 2), 128 is convenient because it means a row of characters is 256 bytes wide (128 characters * 2 bytes per character = 256 bytes). So for any coordinates <X, Y>, the lowest byte of VRAM is always 2*X, and the next byte is always Y. $00708 is <4, 7>. $00F10 is <8, 15>. In general, any character's address in VRAM is 2*X + 256*Y, and its color is 1 + 2*X + 256*Y.
  16. 2 points
    Hello everyone. Name is Jeremy but go by Keiyentai online minus FB. Been following this project since I first saw the video David made about it and heard about on Facebook groups. I can't wait til I can get a hold of one. Love the design and I am trying to think of something to program for it especially now that were I live quarentine has given me a lot of free time. Been going over the new documentation and it's detailed and easy to read which is a huge plus. Also the 3D concept looks awesome @Perifractic what 3D software do you use to make your renders?
  17. 2 points
    Yeah, assembly in-line with a BASIC program is a great concept, but I agree with @TomXP411 that this overlaps significantly with the other assembly IDE in the system. Then again, maybe the core code there could be reused and called from BASIC?
  18. 2 points
    I've been entertaining the the idea of getting my first mechanical keyboard for about a year. After seeing the availability of the Commander X16 Deluxe Keyboard on WASD I think I'm inspired to finally commit. Even if the project doesn't make it for some reason, I still think it's a cool looking keyboard and the key labels don't matter to me, I can touch type on a blank keyboard. Since I have never owned a mechanical keyboard, and it's a rather pricey purchase, I'm hoping some people here might have some answers and suggestions. 1. I absolutely need a Scroll Lock key, it's the shortcut key for my KVM. Does the 40/80 Display key function as a Scroll Lock key on a standard PC? 2. I don't need perfect silence but I code all day and game all night in an area often occupied by other people. I'm thinking of going either Cherry MX Red or Cherry MX Silent Red. This comparison video has me leaning towards Silent Red. Does anyone have a experienced opinions on the difference between these 2 or suggestions on why another type might be better? 3. Does purchasing this particular keyboard support the Commander X16 project directly?
  19. 2 points
    While the library and the X16 rom/emulator have been under development and changing it's been nice for the library to be decoupled from cc65. That certainly could be considered once things stabilize.
  20. 2 points
    libX16 View File libX16 is a utility library for those using C with the CC65 toolchain for the Commander X16. Library documentation is available from the github page: https://github.com/CJLove/libX16. Currently it supports loading/saving files to banked RAM and VRAM, playing sound data for the YM2151, and providing a VERA header file with additional constant definitions beyond those provided by CC65. This is a beta v0.1.0 release of libX16 for the Commander X16 rom version r37 and CC65. The attached artifact includes the library header files and library file for linking. Alternatively the library can be referenced as a git submodule in a github repo via the .gitmodules file: [submodule "libX16"] path = libX16 url = https://github.com/CJLove/libX16 Submitter ChrisL Submitted 07/11/20 Category Dev Tools
  21. 2 points
    Thank you both for your very detailed answers. You’re right, I wasn’t thinking of the tile map as a character screen. It makes sense, now that I see it. Again thank you for your patience.
  22. 2 points
    Hi all, I came a bit late to the Commodore 64, getting the C64C World Cup Football bundle, which means it must have been around 1990. At age 14, I was already into programming by then and read every BASIC book I could find, but never made anything worth sharing on the C64 itself. A few years later I got a 386SX and the C64 was put away. I have been a software developer professionally for over 20 years, working on everything from embedded to desktop and cloud software. What I like about embedded/microcontrollers is the relative simplicity of the system and peripherals. Having enough ongoing, shelved and future projects to fill several lifetimes, I'm hoping the constraints of the Commander X16 will be liberating. I have been following the 8-bit guy YouTube channel for a while, but didn't watch the Commander X16 videos until the other day. I had dragged the old C64 and 1541 drive out of the closet. While hooked up to the TV, there was suddenly a bang and smoke came out of the 1541, blowing the fuses in the house, not the drive itself. It looks fixable, since the smoke actually came from the noise filter in the Euro plug socket. Must have been a capacitor in there that exploded. Anyway, this sent me Googling/YouTubing for solutions and I somehow ended up on the Commander X16 videos. The work that has gone into the Commander X16 is already impressive and I will certainly purchase at least one system when it is available.
  23. 2 points
    Yes, I've noticed that problem with the auto populated fields, too. I'm looking into a config option to change that, it seems to be a "feature" of the Invision Community system we're using.
  24. 2 points
    I think it is rather assuming (and probably correctly) that given the wide range of technical backgrounds in its audience ... there WILL be people who WILL plug cards in backwards.
  25. 2 points

    Version 1.0.0

    1 download

    Written in "C", in 2014 for the Commodore 64 and ported to CX16 in 2020. I wanted to know how hard it would be to make a chess AI. I am not a great chess player, nor did I research chess engines, so I made things up as I went. The end result is this chess which by any standards of chess, is not a good AI opponent. However, it's there and it's playable. Use and keys The user controls an on-screen cursor. The cursor changes color to indicate a state. The colors for selection are: Green - the piece can be selected Red - The piece cannot be selected as it doesn't have valid moves Purple - Empty tile or piece on the other side Blue - The currently selected piece Cyan - A valid destination for the currently selected piece To move the cursor, use the cursor keys. To select a piece, press the RETURN key while the piece is selected. To deselect the piece, press RETURN on the same piece again, or press ESC. To bring up the menu, press the M key, or the ESC key when no piece is selected. Pressing ESC in a menu backs out of the menu, to the previous menu or back to the game. Press RETURN to select a menu item and use the up and down cursor keys to change the selection. While a side is under human control, there are a few more options. Press B to toggle on/off a state showing on every tile how many of both black and white's pieces can attack that tile. Pressing A will toggle a highlight of all of the pieces on the opposing side that attack the selected tile. Pressing D will toggle a highlight of all the pieces on the side currently playing's side that can defend the selected tile. All three of these options basically give a visual representation of the Game Database. The colors are: For attackers Cyan and for defenders Red. Lastly, the game has an Undo/Redo stack that tracks the last 254 moves. Pressing U will undo the last move and R will redo the last move. In an AI/Human game, the undo will undo the last AI and human player move, so the human player can make a different move.
  26. 2 points
    cc65 Chess View File Written in "C", in 2014 for the Commodore 64 and ported to CX16 in 2020. I wanted to know how hard it would be to make a chess AI. I am not a great chess player, nor did I research chess engines, so I made things up as I went. The end result is this chess which by any standards of chess, is not a good AI opponent. However, it's there and it's playable. Use and keys The user controls an on-screen cursor. The cursor changes color to indicate a state. The colors for selection are: Green - the piece can be selected Red - The piece cannot be selected as it doesn't have valid moves Purple - Empty tile or piece on the other side Blue - The currently selected piece Cyan - A valid destination for the currently selected piece To move the cursor, use the cursor keys. To select a piece, press the RETURN key while the piece is selected. To deselect the piece, press RETURN on the same piece again, or press ESC. To bring up the menu, press the M key, or the ESC key when no piece is selected. Pressing ESC in a menu backs out of the menu, to the previous menu or back to the game. Press RETURN to select a menu item and use the up and down cursor keys to change the selection. While a side is under human control, there are a few more options. Press B to toggle on/off a state showing on every tile how many of both black and white's pieces can attack that tile. Pressing A will toggle a highlight of all of the pieces on the opposing side that attack the selected tile. Pressing D will toggle a highlight of all the pieces on the side currently playing's side that can defend the selected tile. All three of these options basically give a visual representation of the Game Database. The colors are: For attackers Cyan and for defenders Red. Lastly, the game has an Undo/Redo stack that tracks the last 254 moves. Pressing U will undo the last move and R will redo the last move. In an AI/Human game, the undo will undo the last AI and human player move, so the human player can make a different move. Submitter Getafix Submitted 07/12/20 Category Games  
  27. 2 points
    I'm not sure if you're asking to read the tilemap data (which would specify which characters to display, and with what colors), or whether you're asking to read the tile data itself (which would specify what the characters look like). So I'll answer both. Reading tilemap data (which characters and their colors): The tilemap data is described in the VERA documentation at the following link: https://github.com/commanderx16/x16-docs/blob/master/VERA Programmer's Reference.md#tile-mode-1-bpp-16-color-text-mode The starting address of tilemap data is stored in the layer's MAPBASE register ($9F2E for layer 0, $9F35 for layer 1), and contains the upper 8 bits of the 17-bit address. The lower 9 bits must be 0 and are not stored anywhere. The height and width of the tilemap are stored in the CONFIG register for the layer ($9F2D for layer 0, $9F34 for layer 1), each as two bits selecting a map size of 32, 64, 128, or 256 tiles. Per the documentation, each tile/character in the map is described by two consecutive bytes, the first being which tile/character to display and the second being color data. If you launch the X16 emulator, you can see how this works for the default console. The default console uses Layer 1, so let's inspect those registers: `PRINT PEEK($9F35)` gives us 0. This means the tilemap starts in VRAM at address $00000. `PRINT PEEK($9F34)` gives us 96. Converting to binary, this gives us %01100000, which means a map height of %01 (1, or 64 tiles) and a map width of %10 (2, or 128 tiles). From this, we know that the characters and colors start at VRAM address $00000, and each line of characters 256 bytes (128 tiles). Finally, we know that there are 64 lines, so we can multiply all this out (2*128*64) to see that the tilemap data is 16KB, starting from VRAM address $00000 and going through $03FFFF. `PRINT VPEEK(0, $0000)` gives us 95, which is the character at the top-left corner of the "X" logo (this logo is just PETSCII art, so it's just a text character). Let's suppose we wanted to swap it with another character. If we `VPOKE0, $0000, 3` we see that it swaps to a 'C'. If we wanted to change the next character, we could `VPOKE0, $0002,3` to change the next character to a 'C', as well. Since the default console is 128 tiles wide, we know it's 256 bytes wide. This is convenient, it means that if we wanted to also the change the character beneath what we just VPOKE'd, we can add $0100 to the address. `VPOKE0,$0102,3` will change the character. Another way to look at this is to think of some tilemap coordinate <X, Y>, where X is how many tiles from the left, and Y is how many tiles from the top, both starting at 0 for the left-most column and top row, respectively. Any character at <X, Y> is located at 2*X + 256*Y, and its color is located at 1 + 2*X + 256*Y. If the default console moved its starting location at some point in the future, you'd have to add that starting location, but for now it's $00000 so we can just forget about it. Now, to make sense of the tilemap when reading, you need a map that tells you which tile IDs map to which characters. It turns out, the X16 is using the same map as the default Commodore 64 did, and that's well known. They're called screen codes: http://c64os.com/post/c64screencodes Reading tile/glyph data (what each character looks like): The glyph data for character modes work the same way as tile image data for the other tilemap modes: The layer's TILEBASE register ($9F2F for Layer 0 and $9F36 for Layer 1) contains the upper 6 bits of the 17-bit address (and the lower 11 bits must be 0 and are not stored anywhere). The data there will be 1bpp, with a height and width determined by the Tile Height and Tile Width bits at the same registers (0 for 8 pixels, 1 for 16 pixels). We can observe this with the default console when you launch the X16 emulator. It uses layer 1. Let's start by looking at the registers: `PRINT PEEK($9F36)` gives us 124. In binary, this is %01111100, which gives us a tile height of %0 (8 pixels), a tile width of %0 (8 pixels), and a tile address of %011111 00000000000 (keeping in mind that we had to add 11 bits of 0 to what was stored there), or $0F800. So we know that tile data starts at $0F800. We know that the X16 uses the same tiles, in the same order, as the Commodore 64, so we can look up where, for example, X should be: At tile 24 (the first tile being 0). Since the tiles are 1bpp, 8 pixels wide, and 8 pixels tall, we can multiply this out and know that each tile is 8 bytes. Tile 24, then, starts at $0F800 + 8*24, or $0F8C0. Let's take a look with a little basic: FORI=0TO7:PRINT VPEEK(0,$F8C0+I):NEXTI gives us: 102 102 60 24 60 102 102 In binary, this looks like: %01100110 %01100110 %00111100 %00011000 %00111100 %01100110 %01100110 That looks like an X to me.
  28. 2 points

    Version 0.1.0

    0 downloads

    libX16 is a utility library for those using C with the CC65 toolchain for the Commander X16. Library documentation is available from the github page: https://github.com/CJLove/libX16 This is a beta v0.1.0 release of libX16 for the Commander X16 rom version r37 and CC65. The attached artifact includes the library header files and library file for linking. Alternatively the library can be referenced as a git submodule in the .gitmodules file: [submodule "libX16"] path = libX16 url = https://github.com/CJLove/libX16
  29. 2 points
    I recently bought a Cherry MX Red keyboard, I don't really know much about keyboards but I can say that the big difference between Blue and Red from having tried both is that the mechanism on the Blue makes a click when pressed down while the Red don't, but they're stiffer. Brown is kind of a compromise between both. So the noise on Reds comes more from the keycap clacking against the body than anything, which is kinda loud, but if you try to type softer it gets better. Maybe if there's cushions inside the caps, but eh, I don't really know how it works. And I don't really know how Silent Red makes it silent, so yeah.
  30. 2 points
    To answer your question about different key switch types, I would highly recommend taking your next move carefully lol. Once you feel mechanical switches under your fingers, you can't ever really go back and enjoy membrane keyboards . For somebody that types all day, I would actually recommend a switch that allows you to feel the tactile point of actuation such as Blues. It's much more satisfying in my opinion and they generally are regarded as the best to type with. Red switches don't have a tactile feel for the actuation point and so they just slide until they bottom out. A more silent version of the Blue switch would be Brown switches and are sort of a happy medium between the two as they aren't super clicky clacky, but still have that tactile feel when depressing the key. However, regardless of the switch type, if you are plunging the keys hard enough to bottom out with every stroke, no mechanical keyboard will be truly silent. When at home I use Blue switches as the sound makes my heart happy and the feel is the best out of any switch type I own. I personally use Brown switches when in an office environment and I have never gotten any complaints from co-workers. I know that this is a lot of words to not really answer your question, but I hope to give you some things to think about that videos sometimes don't convey about different keyboard types since mechanical keyboards aren't inexpensive. Hope this helps!
  31. 2 points
    Hi, Yes I believe so, it should behave normally in that case. Only the keycap text is changed. Silent Red is a good choice. Others may have other opinions. A very small amount goes towards the development costs of this keyboard. The majority goes to WASD for manufacturing & profit. So the answer is yes, but minimally. Your friend in retro, Perifractic
  32. 2 points
    You can have all metal cases cut, bent, and painted for maybe $100 per unit, and industrial monitors should go for a similar number. It's not especially cheap, but not crazy expensive, either. I'd definitely pay the extra $150-200 for something with a 7-10" monitor in a Kaypro II / SX64 form factor. These guys will do custom enclosures, for example: https://www.protocase.com/price/instant-output.php Now those are simple, metal boxes.... but it's one way to get a simple, portable enclosure. I've been thinking of building a NuPro (KayPro clone) using one of these enclosures, but a one-off is $300. If I do 10, the price comes down to around $200 each. If we could get 100 or 1000, the per-unit price would drop. Maybe that's something to prototype and investigate for the third, FPGA design, since we (interested customers - I don't speak for the CX16 team) could build it in a smaller case - something closer to an oscilloscope, rather than a suitcase sized PC.
  33. 2 points
    It's specific to CBM prg Studio. There was no standard convention for handling screen codes.
  34. 2 points
    So I managed to implement my first 3 power ups . Wasn't that hard. I also started some refactoring of the code. Looks already better now. Now I have a basic sprite move/collision detection engine. The next power up will be a double laser cannon . I'm thinking about implementing Space Inavaders
  35. 2 points
    A quick update with some music by @m00dawg and speed control
  36. 2 points
    This is the exact kind of thing I'm looking for - a little higher level than pure 6502 assembly with the ability to still inline assembly as needed. I'm definitely going to check this out. For those interested, the GitHub for the project is https://github.com/KarolS/millfork EDIT: Since the native version of Millfork on Github is based on a release from April, and doesn't appear to include support for the latest VERA, I just spent the last 3 hours fighting Java/Scala, GraalVM, native-image and Windows to create a native copy of millfork.exe based on the latest commit on master in the repo. I tested it out in VSCode with the CommanderX16 plugin and it runs a simple Hello World app just fine. If you want to grab it, I've popped it in my Google Drive here.
  37. 2 points
    Hello. I'm Jason. Though on the internet I'm known as CyberYoshi64. I'm an almost 16-year old german who enjoys programming in BASIC. Mostly SmileBASIC (3DS/Switch) but also CBM BASIC lately with the CX16. I stumbled upon the 8-Bit Guy in early 2017 when I was wanting to get started on programming and the 8-Bit machines were peeking my interest, so I started programming in SmileBASIC and ended up with SKKBAUI (a Windows-like desktop) and a bunch of fonts that everyone on SmileBASIC Source could use and share. (The 3DS runs BASIC code like the Maximite 2 that David showed off, so a ton of things are possible.) Though for some reason, I want a restriction on what I can do per jiffy with BASIC. So that's why I downloaded the emulator and joined the CX16 community. Now I'd like to write some tools and improve my BASIC knowledge with the different syntax that the CX16 gives me. I'm also wanting to write assembly but that may remain a dream for now. Thanks for reading and letting me being a part of this community and I hope I can bring out some cool BASIC projects that someone may use.
  38. 2 points
    Argis Paint View File "Argis" is a very simple paint program. I i made it mostly to test programming with the VERA chip and it is currently not very well optimized. It supports brush and fill tools and 16 colors from the C64 palette. Instructions: The first button is to select brush tool and the second is to select fill tool. Click on the color on the down right to select a new foreground color. Submitter Zen1th Submitted 07/09/20 Category Graphics Apps  
  39. 2 points
    Hi Everyone, If you happened to see David's video on the Color Maximite 2, then you probably noticed that the new Commander X16 PCBs have arrived! David @The 8-Bit Guy just happened to swing by my house the day they arrived, and he picked them up before I was even able to get all of the parts in. I am still waiting on a few things, so I haven't been able to complete assembly yet. The VERA is also not complete for this reason, but I had to mock it up for the pics! Bear in mind, this is not the correct case, this is from an old tower ATX case I had sitting around. It's a nice platform to mount the board and make sure I have the placement of screws, slots & of course the rear ATX panel aligned correctly. I will likely make a few placement tweaks but overall I am quite happy with the physical layout so I just had to post some photos! So far, it's working but my ATX soft-start circuit is a bit squirrelly. Not only that, I kinda wired it wrong and didn't catch it before the run. Worked great on the breadboard, but I will have to revamp that before the final. There are also a few other little things discovered since this proto was run, but the real tests will be coming when @Michael Steil is able to get the Kernal up and running. (I would write some test code, but one part I'm missing is the ZIF socket for the ROM. Should be here in a day or two.) @Perifractic is also sending me the X16 case, so I should be able to install the board in there later this week. Happy Sunday, and Take Care Everyone! -Kevin Williams https://TexElec.com
  40. 2 points
    More progress, starting to get closer to real map mechanics, as shown in this demo:
  41. 2 points
    Hi there, I´m Andi and living in Berlin. I´ve grown up with the C64 first in the 80s and later with the Amiga. Over the last year I realized that modern IT isnt´t everything and most of the soft- and hardware stacks are meanwhile too high: I could´t "feel" the bits any more. That was the point I remebered the origin of my profession and startet to look for old C64 stuff, but emulators were'nt the real thing ... so I bought my first original C64 on eBay. That was the point the fun began ... And what should I say: Meanwhile my "collection" ist a little bit bigger, I´m following lots of retro people on Youtube, support them on Patreon and ... ...try to find a way to use my newly retrobrighted C128DCF as an 80 column 16 colour internet terminal together with the Ultimate II+ ... still not successful, but still motivated and trying hardly. Best Regards to the old and new Retro-Community, may the Commander x16 be as successful as the old C64 (the Pi has shown there is a way!), Andi
  42. 2 points
    Look closely at the second picture just above here. Notice that the program printed more than 16 characters across the line. There is a reversed graphic character in between each punctuation mark after the quotation mark. Those are the PetSCII color control characters. They're displayed instead of obeyed when Kernal is printing in "Quote mode". Apparently, COLOR doesn't store color numbers directly into a Kernal variable. Instead, it prints PetSCII control codes. That method of changing colors can't work in Quote mode! Your little random program could test which character just was printed. If the code number is 34, then print that character again. That will turn quote mode off; and, you'll get the many-colored screen that you want.
  43. 2 points
    Just a note that my open source implementation of the venerable Sweet16 VM by Woz for the AppleII has a SweetCX16.asm version oriented to the GoldenRAM at $0400-$07FF. All of my testing was of the C64 version assembled to the C64 $C000-$CFFF Golden Ram location, but if anyone wants to assemble it and run it in the CX16 emulator, I'd welcome feedback ... and bug reports, of course, in case my testing didn't cover as many edge cases as it should have done. https://github.com/BruceMcF/Sweeter16
  44. 2 points
    Hello I've been slowly trying to learn 6502 assembler by building an X16 game engine. But better than that - you can watch me do it on twitch as I stare confused at my screen whilst mumbling to myself next to a microphone! Please visit the channel and say hi or follow
  45. 2 points
    Game jams are community events that typically give 24-48 hours to create a game with a certain theme or special rule. The games don't have to be big or complete, most entries in a typical game are little more than prototypes showing a single idea, maybe even on a single level. Obviously, the X16 can pose unique challenges due to its limited resources, but that would be part of the fun, yes?
  46. 1 point
    Ya was watching the vid. I need to find one and not blow the PSU in it >_> lol sorry
  47. 1 point
    If you are interested in doing pixel art, I am working on a project that needs a lot of pixel art, and you wouldn't have to be involved on the programming side. DM me if you want details.
  48. 1 point

    Version 0.1.1

    2 downloads

    "Argis" is a very simple paint program. I i made it mostly to test programming with the VERA chip and it is currently not very well optimized. It supports brush and fill tools and 16 colors from the C64 palette. Instructions: The first button is to select brush tool and the second is to select fill tool. Click on the color on the down right to select a new foreground color.
  49. 1 point
    The Monitor lets you do it, but that won't help you if you are running in a graphics mode.
  50. 1 point

    Version 1.0.1

    4 downloads

    A little gameplay-ish and graphics demo of a car on a road. You can control the car with the D-pad on your controller. There's parallax! And a glitchy road, demonstrating why you shouldn't naively depend on sprites to create additional layers of parallax... you'll need to be more clever. The source code for this can be found in the following github repo: https://github.com/indigodarkwolf/x16-racer
×
×
  • Create New...

Important Information

Please review our Terms of Use