Jump to content

Leaderboard


Popular Content

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

  1. 12 points
    Hi all, I've spent that much time rummaging through documentation for vera trying to find how to set things up and which blasted $9f!*'@! did what, I thought I'd make myself a crib sheet with all the info on a single page (well, most of it!). I've attached a .png and a .pdf here for anyone to download and use if you want. I'm working exclusively in tile mode at the moment, so this crib sheet only covers that - I might do another one for bitmap mode when I start trying that. Hope it's useful to someone else! vera register info sheet.pdf
  2. 7 points
    I'm excited to be here. I can't wait for the X16 to bring out the inner child in me. My life in retro-world only started a year ago, inspired by Perifractic and the 8-bit Guy. But I also dabble microelectronics, mostly microcontrollers, as a hobby. Hence my alias Micro Hobbyist.
  3. 7 points
    Just a small clarification: When David mentions a Kickstarter he's using the word in the generic sense, meaning "crowdfunding". We're not yet decided what the home will be for the campaign. It may well be done within this website. Kickstarter is great for unknowns but The 8-Bit Guy brand carries some value and trust already that may make that unnecessary and help keep the end user price lower without Kickstarter's fees. More info when we have it!
  4. 6 points
    If you are trying to get started developing for the X16 with C and/or assembly, I've created this video to help: If you just want to get the "Hello, World!" repo and start hacking, you can get it from my GitHub: https://github.com/SlithyMatt/x16-hello-cc65
  5. 6 points
    So one thing I noticed a while ago is that in screen 128 mode, the layer 0 data actually overwrites the PSG registers. This means theoretically you could create sounds by drawing in screen 128 mode. Sure enough, if you do a certain pset, you can turn up the volume of the PSG: You'll notice that makes a pinkish pixel towards the bottom right, and also makes a buzzing sound. You can also change the other registers, to make whatever sound you want, like a simple square wave.
  6. 6 points
    Some pics of prototype cardboard form with mock panel applied. Call it "The shape of things to come..." if anybody here remembers the old TR-7 campaign. The wedge shape is not just style, it's necessary in order to sandwich multiple PCBs (one for power handling, one for inversion of the component video, one for LCD driver) Centered on the front edge will be an external keyboard DB25 port which, when fitted with an adapter will reduce down to a 9 pin joystick mapped to specific Pet keys. At least that's the plan. Still trying to work out whether I"ll get my hands on TFW8bit's 'deluxe' kbd (just released) or stick with the dreadful buttons that 8bitguy''s build showed (this is standard on the Minipet). In other news, I received a Cherry switch set from Mouser and all of the surface mount parts for the shift lock circuit. That will be 'together' by next week with any luck; if I don't have luck, I'll build using through-hole on breadboard and wire into the pads on the back of the Petskey. Eyes, age, experience (three excuses) I can solder through-hole all day long, surface mount hasn't been for me but I'll give it a go. More later...
  7. 6 points
    We're all passionate about the things we like (or don't) but always remember, no piece of technology is worth getting irritated over. Or getting others irritated. We're all here to enjoy the same hobby.
  8. 6 points
    I'm 99% sure we will release the first wave with a kit option. Worst case it will have a clear message at the point of purchase that we are not responsible for any issues/damage during assembly. There will be plentiful community support available to everyone (as I said in another thread about this same topic recently), and you can bet team-members will also jump in and out to offer help and guidance. David's main concern is that he not have to offer direct support via email. All support will be via the Support button at this very website.
  9. 5 points
    Just fooling around with C64 BASIC and the new X16 BASIC commands! Code is too simple to share compared to some other games and demos you guys made! It's been a while trying to use variable names with only 2 unique characters! "PALETTE.BAS" "MANDELBROT.BAS" - Took forever to generate this 150px by 150px by 16 greyscale. 6502/200MHz please!
  10. 5 points
    3d wire frame animated spaceship View File 3d animated Cobra MK3 ship from Elite! Uses 16 bits integer math and has hidden-line removal.. This is an almost 1-to-1 conversion of the same program I wrote for the C64, but it runs a lot faster on the CommanderX16 Here is the (prog8) source code https://github.com/irmen/prog8/blob/master/examples/cx16/cobramk3-gfx.p8 I haven't figured out how to wait for the Vertical blank yet, to reduce the flickering perhaps... Submitter desertfish Submitted 09/07/20 Category Demos  
  11. 5 points
  12. 5 points
    New Version 1.0 Yes - I consider this game complete as of now . Powerups now appear at the spot the last brick disappeared. Added one last bonus level with the X16 logo Works on emulator R37 and R38.
  13. 4 points
    Hello everyone. I'm Daniel from Sweden. I'm a network engineer with ten years experience but I'm currently trying to steer more towards development. I have started taking som colleague classes in programming and found assembly to be great fun. I figured Commodore was a great platform to learn more about it and I was very excited to learn about the Commander x16 project as it seems like the perfect platform for what I want to do. I've also started to learn to solder and about digital circuitry, and I've picked up some old Commodores and Amigas that need some TLC. I was slightly too young to learn any programming on our C64 as a child so I'm eager to learn this time around. If I can I would love to contribute in some way. I am not yet proficient enough with anything besides Python to be of any real use, but I'll get there :) Please let me know if there's anything I can do to help, perhaps cloud infrastructure or translating anything to Swedish? Thanks!
  14. 4 points
    Hello everyone! My name is TechUr, I am a streamer on Twitch, electronics hobbyist, and collector of vintage games (primarily Atari products). I found out about the CommanderX16 from The 8-Bit guy, as would be expected. I felt I missed out on the Microcomputer era, so it was exciting to hear about this project! My intention on this forum is to learn more about creating programs for the CX16. I have some experience in BASIC, but I'm hoping to learn more high level programming on the platform. I wish the best for this project, especially considering the world is on fire right now, and for everyone involved to making the CX16 a reality!
  15. 4 points
    So after piecing together the memory map of the Commander X16 and getting the emulator working I set out to make the necessary changes in my programming language Prog8 compiler to support a second target machine architecture beside the C64. Prog8 is a cross-compiler that works on any modern machine and compiles into a machine code binary for 6502 8-bit machine targets such as the Commodore-64. I've just released an updated version that supports CommanderX16 as a second compilation target! Prog8 documentation: https://prog8.readthedocs.io Prog8 project website: https://github.com/irmen/prog8 you can download it from there as well. Here is one of the simple programs that I made in Prog8 for the Cx16, it renders the well-known Mandelbrot fractal (using floating point calculations): For those interested this is the source code of the above program: %import textio %import floats %zeropage basicsafe main { const uword width = 60 const uword height = 50 const ubyte max_iter = 16 sub start() { txt.print("calculating mandelbrot fractal...\n\n") ubyte pixelx ubyte pixely for pixely in 0 to height-1 { float yy = (pixely as float)/0.40/height - 1.3 for pixelx in 0 to width-1 { float xx = (pixelx as float)/0.32/width - 2.2 float xsquared = 0.0 float ysquared = 0.0 float x = 0.0 float y = 0.0 ubyte iter = 0 while iter<max_iter and xsquared+ysquared<4.0 { y = x*y*2.0 + yy x = xsquared - ysquared + xx xsquared = x*x ysquared = y*y iter++ } txt.color2(1, max_iter-iter) txt.chrout(' ') } txt.chrout('\n') } } }
  16. 4 points
    Hi all, Drawing bug is fixed, and I've added the "only draw the hexes that have already been visited" thing. So now you start with a blank map with no idea where anything is until you start exploring! Next on my to-do list is to implement tracks, rivers and walls drawing routine. The entire map is 64 x 64 hexes - 4096 hexes in total. I've managed to encode rivers, tracks and walls into 1 byte per hex, 4kB for the whole map
  17. 4 points
    You need to use SEC before SBC, not CLC
  18. 4 points
    I have covered most of the topics you are asking about in the series of tutorials on my blog: https://www.8bitcoding.com/p/commander-x16.html I go pretty deep into explanations on how VERA works, different video modes, sprites, sprite animations, scrolling, layers and even some simple libraries to add music to your programs. Examples are written mostly in BASIC and some in Assembly but of course all the hardware related subjects are applicable to all programming languages.
  19. 4 points

    Version 1.0.0

    17 downloads

    3d animated Cobra MK3 ship from Elite! Uses 16 bits integer math and has hidden-line removal.. This is an almost 1-to-1 conversion of the same program I wrote for the C64, but it runs a lot faster on the CommanderX16 Here is the (prog8) source code https://github.com/irmen/prog8/blob/master/examples/cx16/cobramk3-gfx.p8 I haven't figured out how to wait for the Vertical blank yet, to reduce the flickering perhaps...
  20. 4 points
    Hi all, One step forward, two steps back. It seems very much that This Is The Way for software development. Either that or I'm just inept I got the save / load bank feature working, and added a creation tool so I can make maps within the software itself rather than handcoding with a hex-editor (which would be UGH!) BUT, having started to draw the first map, a bug has manifested itself in the code that draws the layer 1 16x16 graphics over the hex backgrounds so now I've gotta go fix that before I can carry on. *Sigh* at least the map creation tool works! Onwards and upwards...
  21. 4 points
    In a perfect coincidence, I just created a Hello World repo exactly for the purpose of helping folks use the cc65 tool chain. I have examples in assembly, C, and a mix of both. And the README goes through the whole setup and build process in detail. Get started here: https://github.com/SlithyMatt/x16-hello-cc65 I'm going to be making a video going through it very soon. It may be up as early as tonight.
  22. 4 points
  23. 4 points
    It will be a 'one-off' but once done, I'll be happy to share the FPE and design details; In short, it's a MiniPet repackaged in a braked aluminum and sheet metal enclosure with an external 12" monitor (repurposed from a '82 Northstar Advantage; see below), optional external Petskey Keyboard, 10" LCD screen from China, internal SD, and a few surprises. Will not be battery powered (currently running off an 8 lb. linear differential power supply : ) Though depicted as a rounded corner traditional laptop (see FPD mock-up below), I plan on honoring the circa late 70's office furniture/vintage Pet look; call it, Tesla Cybertruck meets Atari Battlezone styling (said another way, I have a garage full of sheet metal brake, punch, shear tooling so outside of a wood enclosure, this is my only option - be prepared for something that looks more like a piece of aircraft than a computer) The good news is that I procured the monitor (below) and the LCD panel and controller for next to nothing (about $60 each) from eBay/Amazon. The bad news is that you get what you pay for and it looks about as good as what LCD technology offered in 1979-1982. Will post pics and info to this thread as I make progress. IMG_2052.HEIC IMG_2284.HEIC
  24. 4 points
    No. Assembly language is something you need to learn from other sources - like Jim Butterfields book for the C64 still one of the best books to read. Here are some links (depending on the language you speak/read) German: https://www.retro-programming.de/programming/assembler/ English: https://skilldrick.github.io/easy6502/ Here is Jim Butterfields book... http://www.1000bit.it/support/manuali/commodore/c64/ML_for_the_C64_and_Other_Commodore_Computers.pdf Also a good thing to understand the C64 book. It is actually everything that is referenced from the X16 dokumentation (e.g. BASIC, KERNAL calls etc.) http://www.zimmers.net/anonftp/pub/cbm/c64/manuals/C64_Programmers_Reference_Guide.pdf And this documentation to understand all the different inner workings of the Commodores ... very extensive and also quick reference. https://archive.org/details/Complete_Commodore_Inner_Space_Anthology_The_1985-03_Transactor_Publishing The Monitor is covered in this document: https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#machine-language-monitor
  25. 4 points
    Greetings Everyone, Danny from Missouri City, Texas here. To everyone involved in this endeavor, thank you so much. I downloaded your emulator and wrote my first BASIC code in 30 years! I can't wait to see how this develops and get one of these machines.
  26. 4 points
    Hello. I'm new here. Excited about this project (just stumbled upon it after tripping over 8-Bit guy's YouTube channel). In the mid-80s I wrote and operated a BBS from campus area @Berkeley California; still have the source code from a Terminal Emulator that I wrote way back then and plan on porting it to the X16 in addition to contributing code otherwise. I have a small handful of 6502/6510 based machines including the MiniPet which I'm fashioning into a vintage style laptop (don't laugh but yes feel free to laugh); it's all fun and games but this revival and the collaboration that I see for the new project is amazing to read about. Thanks.
  27. 4 points
    Sea Battle View File Sea Battle is a variation on the classical game "Battleship". Sea Battle is a cc65 application currently compatible with revision R38 of the Commander X16 emulator. The graphics and computer targeting could both stand some improvement, but the game is fairly playable in it's current state. I believe computer targeting is strongest when "HIT NOTIFICATION" is configured as "IMMEDIATE" and "SHIP NOTIFICATION" is configured as "SHIP" which are the default settings. I'm at the point where I've had to optimize the code several times to squeeze in more functionality, and adding any significant additional functionality will likely require an investigation into the possibility of taking advantage of memory bank switching. Configuration Options: The "P" key is used to toggle the player-mode between single-player, two-player, and computer-vs-computer modes. The entity names on the bottom of the left and right grids illustrate the currently selected player-mode. The "S" key is used to toggle the fleet size between 5 and 6 ships. Player-mode and fleet size can only be changed before player-1 accepts configuration of their ships after which the "Q" key must be used to quit the game in order to change player-mode or fleet size. The "F1" key is used to select the number of "TURN GUESSES" which consists of an initial number of guesses for the first turn and also the number of guesses for each subsequent turn. In "1/1" mode each player is allowed one guess per turn including the initial turn. In "n/SHIPS LEFT" mode the entity (player or computer) taking the first turn is allowed "n" guesses, and the number of guesses allowed on each subsequent turn is based on the number of ships left in the attacking entity's fleet. The ability to configure the number of guesses for the entity taking the first turn is intended to be a way to offset the advantage of taking the first turn. The "F2" key is used to toggle the "HIT NOTIFICATION" between "IMMEDIATE" and "END OF TURN". This configuration is only relevant when "TURN GUESSES" is set to the "n/SHIPS LEFT" mode described above (since both "HIT NOTIFICATION" options are equivalent when "TURN GUESSES" is set to the "1/1" mode described above). The "F3" key is used to control the "SHIP NOTIFICATION" related to the sinking of ships. When the "NONE" option is selected there is no notification of sunken ships. The "NONE" option only applies when "TURN GUESSES" is set to "1/1" as described above. When the "COUNT" option is selected the notification is limited to the sinking of a ship. When the "SHIP" option is selected a hidden ship is displayed on the grid when sunk. Fleet Setup: Two-Player Mode: In two-player mode player-1 selects their ships using the "1-6" keys, moves their ships using the cursor keys, and rotates their ships using the "L" and "R" keys. Ships of odd length are rotated about their center, and ships of even length are rotated about the the first segment behind their center. The currently selected ship is indicated by the cursor. Movements and rotations that result in part of the ship being off-grid are disallowed.The space bar may also be used to generate a random ship configuration. When player-1 presses the "ENTER" key the display of player-1's ships is turned off (assuming a valid ship configuration with no overlap of ships) and then player-2 configures the location of their ships in a likewise manner. When player-2 presses the "ENTER" key the display of player-2's ships is turned off and player-1 then takes the first turn. It is assumed each player looks the other way when their opponent configures the location of their ships. Single-Player Mode: In single-player mode player-1 configures the location of their ships as described in the preceding paragraph. When player-1 presses the "ENTER" key the locations of the computer's ships are randomly generated and hidden. The location of player-1's ships remains visible to player-1 and the referee part of the application but are hidden from the computer opponent part of the application. Game play begins after player-1 chooses whether to take the initial turn or let the computer take the initial turn. Computer-vs-Computer Mode: In computer-vs-computer mode the player configures the location of the ships for both computer opponents. Both ship configurations remain visible to the player and the referee part of the application for the entire game, but each computer's ships remain hidden to the opponent computer part of the application. After accepting both configurations with the "ENTER" key, the left computer takes the first turn. Computer-vs-computer mode is intended as an aid to explore the strengths and weaknesses of the computer targeting system and the effects of "n" on the game outcome when "TURN GUESSES" is configured to "n/SHIPS LEFT". Game-Play: Player: The cursor may be moved on the opponent's grid using the cursor keys. The "0-9" and "A-J" keys may also be used to select any column or row respectively. The space bar may be used to select a random untested coordinate, and the "T" key may be used to select a coordinate preferred by the computer targeting system. This last option is intended as an aid to explore the strengths and weaknesses of the computer targeting system. When the user presses the enter key the selected coordinate is fired upon. Hits are indicated by red, misses are indicated by white, the last hit that sinks a ship is indicated by orange (assuming "SHIP NOTIFICATION" is not configured to "NONE"), and yellow is used to temporarily indicate selected targets when "TURN GUESSES" is configured to "n/SHIPS LEFT" and "HIT NOTIFICATION" is configured to "END OF TURN". Computer: When the computer takes it's turn the player is prompted to press a key to acknowledge each of the computer's guesses. Support: If you encounter a problem that you think is related to a bug in the source code please take and submit a screen shot in a problem report illustrating the configuration where you're having a problem to aid in diagnosis of the problem. Future Strategic Mode: My ultimate goal is to develop a game mode with a much deeper strategy than the classical "Battleship" game. The basic concept is to allow each player to see the position of their opponents ships at all times, and also to allow movement of each of a player's ships on their turn. Each ship may be moved one position backward, starboard or port on a single turn, or it may be moved multiple positions forward on a single turn. The number of positions forward is based on the length of the ship (smaller ships which are presumably faster can move further than larger ships). Alternatively a ship can be rotated 90-degrees clockwise or counterclockwise. Movements and rotations that result in part of the ship being off-grid are disallowed. At the beginning of the game player-1 (who takes the first turn) configures the position of their ships, and then player-2 configures the position of their ships. This is intended to partially offset the advantage of player-1 taking the first turn. This player-1 advantage can be further offset by configuring the number of shells that can be fired on player-1's first turn to be less than the fleet size (which is the maximum number of shells that can be fired on each player's subsequent turn until their first ship is sunk). Each ship segment is initially loaded with a shell, and each ship with a remaining shell can fire each turn. Shells are only fired horizontally along the same row and limited to a range of 10, so a only a shell fired from the closest column adjacent to the enemy's grid can reach the furthest column of the enemies grid. The probability of a hit can be adjusted such that it decreases with range, and also can be adjusted such that it decreases when a shell is fired after a ship moves (instead of before it moves) on a player's turn. A ship's shells can be reloaded when part or all of the ship is on the column furthest from the enemy's grid which is considered home base (which is column-0 for player-1 and column-9 for player-2). When a ship segment is damaged that segment can no longer be reloaded, and when all segments are damaged a ship is considered sunk. A player's ship shells are reloaded at the beginning of their turn assuming one or more of the ship segments is on the home-base column. When only a single segment of the ship is on the home-base column a single shell is reloaded to the first undamaged and empty segment of the ship closest to the home-base column. When the entire ship is on the home-base column all undamaged and empty segments of the ship are reloaded in parallel at the beginning of a player's turn. I was originally thinking of integrating the future strategic mode into the current Sea Battle application, but due to memory constraints mentioned above I'll probably end up making it a separate application. I'm planning on implementing two-player mode first since the computer targeting strategy required for single-player mode is much more complicated for the future planned strategic mode than it is for the currently implemented mode which is only a slight variation of the classical "Battleship" game. Collaboration: I'm defining an API for the computer targeting function which I'm separating out from the rest of the current Sea Battle application, and I'm planning on taking a similar approach with the future strategic mode application. The intent is to support collaboration on enhancing the computer targeting function of the current Sea Battle application as well as collaboration on the development of the computer targeting and ship movement functions of the future strategic mode application (which I consider to be the most difficult part), so let me know if anyone is interested in collaboration on the computer functions of either of these two applications. Submitter CX16UserSteveC Submitted 09/06/20 Category Games  
  28. 4 points
    Appreciate the input here chaps, and by all means chat about it, but we won't be doing a Mouser kit as stated. It'll all be supplied by us. Very likely it will all be assembled in house where possible, by an appointed team. We do not want the pitfalls you've seen with other projects where some aspects not in house led to major production issues, only realized when batches arrived. Where possible things will be done in a hands on manner where we can oversee. This likely includes kit assembly. Naturally it excludes production of parts that can only come from a factory. Obviously nothing is official until made as an announcement and launch, so hold fire until we announce the final details. Cheers!
  29. 4 points
    Where to start... I am an old school tech enthusiast (and modern too). Growing up on machines like the Commodore VIC20/C64, Texas Instruments TI-99/4A, and the Tandy Color Computers. While I love modern PC hardware, and have been building them since the 80386 era, I often miss the classic BASIC powered, command line driven, machines of the 1980's. I still play with many of them, via emulation on Windows and Raspberry Pi, but my wife and I simply don't have the space for me to keep a collection of the original hardware. Then I heard about the X16 project and who was all contributing to it, and I have been following it ever since. I normally don't have a lot of time to mess around on forums and such these days, but I wanted to join this one. If I could own one "classic" inspired machine, then the Commander X16 would be it. It seems like it would be the only machine of it's type that would fit my needs and wants of an 80's style computer today. Speaking of 80's computers, I got my first one in 1981, the TI-99/4A, and from there my love of these machines grew. I was lucky enough to either own, or got to use via friends, several different computers back in the 80's, including the Commodore VIC20 and C64, two of my all time favorites! I moved into the Amiga line of computers and Tandy 1000 series before moving completely to DOS/IBM PC machines. My least favorite machines of the era were the Tandy TRS-80 Color Computers, I know they are more commonly called "CoCo", but my friends and I back then called them "Trash 80's", we just never liked them compared to Commodore. They grew on me much later, after they were long since obsolete, and today I wish I had given them more of a chance. Now I use all modern Windows based, Ryzen powered, machines for myself and family. Doing a lot of emulation for classic computers and consoles for the above mentioned reasons. Most of my console emulation is done on Raspberry Pi, and classic computer emulation in Windows. I really enjoy using VICE, FS-UAE, WinUAE, DOSBox, and now I messing around with the X16 emulator of course! I think that's about it...
  30. 4 points
    I've written a tutorial a while ago on how to use BASIC to generate webpages, as how you would use PHP, it's almost useless but thought you guys'll want to see that https://toasters.rocks/esoteric-uses-of-cgi/
  31. 4 points
    Haha well, our user guide certainly has an incredddddible colour front cover. But the insides are 95% done, and are black and white, because there's no real need for colour imagery. It sounds cool, but perhaps it's just a gimmick? Either way, it's not a competition They are both great and different projects
  32. 4 points

    Version 1.0.0

    13 downloads

    A basic PDF template for a 320x240 screen so you can print up and draw your ideas the old fashioned way.
  33. 4 points
    One more thing (sorry for the double post, this occurred to me a few minutes too late, haha). You mentioned that you're not much of an artist so you'll design the game with simple graphics. That makes sense, but the other route would be to find an artist and team up. Not only will the game look nice, but doing so will have the arguably more important benefit of giving you experience working on a game with other people. When it's all done and you begin looking to join an indie studio, your artist friend can write you a letter of recommendation vouching that you're a good person to work with, you understand how to work as part a team, etc., all of which will be attractive to smaller studios.
  34. 4 points
    So, maybe a person needs a few loose screws to stay in the games industry in the long-term, but I want to try and offer some positives about the game industry, reasons that I have stayed for as long as I have: I found a great studio that looks after its employees. That's not to say that Volition has never crunched, and never made mistakes along the way. Actually, the first Saints Row had an infamously long and hard crunch period, worse than anything the studio had ever experienced. I started at the tail end of that, and I think it kind of traumatized everyone. For the first decade or so working there, I'd describe the attitude towards crunch as "we're never letting Saints Row happen ever again." The studio invested in more and better project management, experimented, and we're continuing to try and improve planning and cut earlier, specifically so we never crunch that hard ever, ever, ever again. Games are fun to work on, and their teams are fun to work with. Yes, it's a job, and it's common to have a very narrow view of what you're working on on any ordinary day-to-day work, and so that does take some of the "fun" out of it. Especially when you're dog-fooding on your own work. But I remember the internship positions I had doing "real jobs" before going into games, and they were B-O-R-I-N-G. I found my internships to be hideously awful, soul-crushing, "why-did-I-ever-think-programming-would-be-interesting-or-fun" affairs. Writing 100 or so trivial database queries over the course of a summer and then watching the resulting application for 8 hours/day to make sure processes are running is my literal definition of purgatory. And then there was the office politics... you know your internship is at a winning employer when your direct supervisor is suddenly fired, with two weeks left in your internship, and everything you've worked on all summer is completely forgotten and discarded, and you're told to still show up for work but to sit there and twiddle your thumbs until the end. And then there was the other internship, in which a senior programmer had an inexplicable grudge against me on Day 1, and wasted dozens of hours over the course of the summer trying to get me fired. The only reasons that was tolerable was my boss appreciated the schadenfreude when that senior programmer would accuse me of something new, only to be shown contradicting evidence and documentation. I thank the mighty Pastafarian noodleship that programmer was even more incompetent than they were malicious, because that paycheck was going towards my college tuition. I guess we all choose our demons, and I prefer being paid less to work harder on something I find interesting, alongside people I can actually like. Finding a silly bug, poking my office neighbor, and having a brief laugh and seeing if we can reproduce it. Playing board or card games over slightly-longer-than-usual lunches. I've become friends with a number of my coworkers - by which I mean more than just professionals working well together, these are folks I invited to my new place for a housewarming party, and that I've turned to when I needed help with a flooding basement, and that I've helped when moving across town. Folks I've gone drinking with, not just for team-building, but because they're great people to hang out with. Watching a project succeed is hugely satisfying After working hard to deliver a product, seeing it appear on store shelves - and then disappear from those shelves, with plastic markers indicating where it would be if only the store still had units in stock - is a remarkably cathartic experience. And reading positive reviews of the project is energizing. And even the negative reviews can be motivating, recognizing weakness in your own contributions and planning how to do better the next go-round. I think the proudest moment of my career was relatively early on, watching Red Faction: Guerrilla briefly bump up to a 9.0 metacritic score around launch time. I worked on its multiplayer, as part of a core team of 3 programmers and 1 designer. What I wouldn't give to relive those days, with just a few tweaks of benefit from a more experienced perspective.
  35. 4 points
    Neat, I hadn't realized MattGrandis was from the industry. Myself, I've been working at Deep Silver Volition, a modestly-sized studio in Champaign, IL, since 2006. So, close to 15 years in the industry. I have coworkers who have experienced every corner of the industry, from tiny indies who came looking for job security, to publishers like Activision and Ubisoft who have more artists working on flotsam like cola cans and dining props than Volition directly employs across the entire studio. About the industry in general Everything Matt said about the industry is absolutely true. I think the AAA side really hits its low point around the time of the infamous "ea_spouse" letter, which accused AAA mega-giant Electronic Arts of abusing their workforce with 70 hour work-weeks, as their modus operandi before talking about "crunch". EA was rumored to have 50% year-over-year turnover in their employees around that time, as in 50% of their workforce was leaving and needed to be replaced, each year. Crunch is still an infamous issue in the industry, whether we're talking about CD Projekt Red crunching to release Cyberpunk 2077, Ubisoft crunching to release Prince of Persia: Forgotten Sands, or Activision crunching to release the next Call of Duty, it's a practice that is endemic to the industry. To some extent, my understanding is that it's endemic to software development, but it's especially acute in gamedev. It's a complex problem to solve, and unionization would probably force the issue, but unions have their own problems and many gamedevs are understandably worried that if they attempted to unionize then they'd just get fired and replaced by younger, more naive kids. Job security is also still an issue today. Even the largest publishers are only 1 or 2 big flops away from ruin at any given time, and many studios don't functionally survive their first flop (they lose key employees, or are reorganized, or hemorrhage people until they can't operate, or simply shutter their doors forever), even if they have long histories of success. Also, it's still common for folks, artists especially, to finish a project and be immediately laid off because their studio won't have work for them to do for several months. Thankfully, Volition doesn't work like this, and never has, but my understanding is that we're an outlier. And yeah, in spite of some 27 years of being in business, we got hurt badly by the failure of Agents of Mayhem, our most recent release, which was just completely dead on arrival. This industry, I tell you. Saying "it's not for everyone" is a level of understatement I'd almost exclusively reserve for British characters from historical fiction. If V shutters, I'll probably exit the industry entirely, myself, go back to gamedev being a hobby that can exhaust my creative urges, and eventually reclaim the ~30% pay difference I'm told I could be making by plying my trade anywhere else in town. Oh, and that reminds me: Since nobody else has mentioned it, be aware that AAA gamedev absolutely comes with a fun tax, in that I mean you can expect to be paid less for what you're doing than if you were doing it for anyone else. Because getting in is grand, but there's no shortage of kids willing to absolutely kill themselves to get in behind you, and that drives down wages. (My story of breaking in out of college involved driving 5 hours to an in-person interview from out-of-state and booking my own room in a local motel. It really didn't bother me, in part because I didn't have any idea what to expect from the interview process; but since V tries to be better than most, our recruiter at the time was rather embarrassed by it. It helped drive my resume to the top of the pile, though.) Game-development options I also agree with Matt that, of those options, Godot is the closest to approach direct relevance for a game programming career, though you really want to look into Unreal if you're looking at a programming path. Failing that, at least C++. It's not that our industry has no need of low-level CPU and hardware guys, it's just that we're talking about a team of maybe 3 dedicated guys amongst a programming staff of 46, and it wouldn't even be that many except that we roll our own bespoke game engine for our franchises, instead of using a third-party engine. And besides, almost every platform is X86 these days... and have you seen that instruction set? Even in the heydays of Michael Abrash writing articles about VGA programming, optimizing that stuff was an art in trial and error, and these days really is best left to compilers. I would also echo Bruce's advice that you should probably think of your first game as a learning experience, and to decide whether you like gamedev enough to want to get in for the long haul. (Of course, if it turns out well, I don't think there's anything wrong with using it as a portfolio piece.) Whatever path you go, just remember these things: Keep it small. Keep it focused. Have fun! (Otherwise, what's the point?)
  36. 4 points
    Yep, that might be a thing and the approach is different. However the Z80 had so much other thing (other than the memory access issue) like 16bit index registers and other stuff. The concept of pages in memory was also completely new to me, as the Z80, did not know any pages. But anyhow .. the beauty of the 6502 is that it is very easy to learn. On the other hand it is at the same time very difficult to master. You need to be either very bright, or read a lot of stuff that is not officially documented, but hidden everywhere (like in this thread now ). Thanks @BruceMcF for the knowledge sharing .. appreciate it.
  37. 4 points
    Okay, what I'm going to say is neither meant as a motivation nor as a dissuasion. Just some (opinionated) insight into the games industry. I've been working for Eidos for a couple of years back in the day, and I've been a freelance developer for 20 years. I know the games industry intimately. But there's a reason I never went back, and why I usually pick jobs outside the industry. I'm close to people working predominately in the industry though. And what I'm seeing is mostly people going from one anxiety attack to the next as soon as they reached their 30s. Sounds harsh, but it's true. First off, I completely understand and empathize with not feeling fulfilled in your day job and looking for alternatives. That's a good thing. But never lose sight of the fact that job security and a solid income are essential. The games industry, sadly, offers neither. It's a hire and fire business. No job security at all. There's some pushes for unionization, but in general, it's a highly volatile industry. Pay generally isn't great. Of course, there's always counterexamples, but I'm talking about the general situation here. Think of it as most other creative endeavors. Some people make it big, but the vast majority is scraping by. As a writer, I can tell you that practically all of us have a day job to pay the rent, because writing simply doesn't, unless you're Stephen King. Which several millions of us aren't. Which brings me to the next important point. Some things are more fulfilling as a hobby. As a professional game developer working on a AAA title, you're just a tiny cog in a huge machine. Often times you don't actually get to see the complete project. You're just working on abstract mechanics. All you might be doing all day long is taking care of NPCs not running into a wall. You don't have any input. It's never going to feel like your game, because you're not even kept in the loop about the direction the game is taking. That is AAA game development. In smaller studios, this is can be completely different. But see above, the smaller the studio, the more volatile the job situation. Because you're absolutely right. Getting noticed has become the hardest part about making a commercial game. And smaller studios have to fight so much harder. Financial success is often compared to winning the lottery. And it's an apt comparison. Marketing advice is almost always based on survivorship bias. No one truly knows the secret to success. So with every new project, the same battle is starting all over again. Every time. It's exhausting, and burnout is the main reason why people are leaving the industry after a couple of years again. Making games as a hobby on the other hand -- that's HUGE fun. That was the general "beware of the industry" disclaimer. Now to your actual question. What job exactly do you want to do? It sounds like programming. If you want to get a job as a programmer, learn C++ and the big engines out there, Unreal and Unity. Godot is sadly still an outlier, and probably is not going to help you get noticed at most places. C++ is still the industry standard, and it's what recruiters are going to want to see in a new hire. C# is the other favorite, if the studio is using Unity. Undoubtedly, there are niche studio selling 8-bit games, but in general, high proficiency in 6502 assembler is of absolutely no interest to the regular games industry. Same with DOS. You need to be proficient in modern development environments. You're competing with millions of young people who got actual game development degrees, which basically every college in the world is offering now. And those degrees are focused on skills the industry wants to see. You'd have to give them really good reasons for picking you. THAT SAID. A really good 8-bit game might get you noticed after all. Maybe programming isn't your thing, but game design is. In that case, it's a huge bonus to know about the technical structure of a game, even if it's an "outdated" environment. Some game designers aren't technically oriented at all and are at constant odds with their programmers, who then need to explain why some things work or don't. A great game designer should be knowledgeable about that. So, if you want to go with making an 8-bit game, don't expect to get hired as a programmer over that. But maybe as a game designer. But again, you're competing with people who have studied that for years and have actual degrees with specialized skills. All of that said, if you want to make an 8-bit game, go ahead and enjoy the ride. But be realistic about where this is going to take you professionally. If you want a job in the games industry, go learn Unreal or Unity.
  38. 4 points
    Made a bit of progress on the ol’ game engine recently. Pleased with the quality of progress, if not the quantity. Gettting there though. Added a few game enginey features, so can now accelerate and decelerate the player, as well as have him jumping on top of bits of scenery. Can also do smooth lerps between screen positions, so the bad guys will get moving around soon.
  39. 3 points
    My latest video on YouTube looks at how to use ca65 for another system: the Atari VCS/2600:
  40. 3 points
    I just released a new version (4.2) that contains a lot of bug fixes. Most if not all issues I've ran into while attempting to compile for the Cx16 have been solved in this version . I've updated the initial post. Download links can still be found there.
  41. 3 points
    Nice new video popped up about programming in C on X16 from @SlithyMatt
  42. 3 points
    Both the LOAD and the SAVE functions don't need a logical file number. SAVE needs a secondary "address" only when saving to a Datasette (tape). Therefore, the secondary address isn't needed on the Commander X16 -- only index register .X needs to be set before calling SETLFS. Your subroutine works in R38. But I, also, was fooled because I didn't know where the "working directory" was. When I launched the emulator from CBM prg Studio, it's working folder was the same as the Studio's working folder. I looked at the CBM prg Studio's desktop icon's properties. For me, it's "Start in:" field is blank; therefore, the Desktop is the "working" location. If all of that is true for you, then you should be able to find "BANKXX.PRG" on your Windows Desktop.
  43. 3 points
    Version 38 based web emulator build https://github.com/sebastianvog/x16-emulator/releases/tag/1.0.0-beta.5 e.g. https://x16emu.s3.amazonaws.com/x16emu.html https://x16emu.s3.amazonaws.com/x16emu.html?manifest=https://x16repos.s3.amazonaws.com/chasevault
  44. 3 points
    I'm also one of those using cc65 and implement my games for the X16 in C. Sometimes there is a need of implementing some optimized parts in assembler (interrupt handlers, sound effects player, etc.). cc65 has the advantage that combining C and assembler is easy. I sometimes check the generated assembly code, to see what the C compiler does and the hand-optimize some of it. Or I change the way I do my C code. I also didn't experience any case of cc65 being really broken... if so, it was possible to fix it myself as the source is on github. Basic was too limited for me and I wanted the comfort and usability of cross development tools on a PC - and then run it on the emulator. So I went for Visual Studio Code and cc65. But hey - the beauty of the X16 is that there are different ways of programming for it.
  45. 3 points
    As one of the folks using C for the X16 I'd say don't discount it. There are a couple of C examples in the x16-demo repo (https://github.com/commanderx16). I've done a Lode Runner port and a utility library in C (https://github.com/CJLove/x16-LodeRunner). The number of available registers on the 6502 don't make it a great cpu for compiled languages like C. But just like the X16's higher clock speed enables a lot more to be done in BASIC that couldn't be done on the C64 it gives a margin for cases of less than stellar code generation by CC65.
  46. 3 points
    Edge cases are not useless: they're interesting.
  47. 3 points
    By contrast my approach to soldering where soldering was absolutely necessary would be "get it working in a breadboard then go to Shenzhen and leave the soldering to the pros" Since there are going to be assembled boards, I am just going to take the economies of scale cost reduction that implies and say"thank you very much, let's get some programming tools on this thing".
  48. 3 points
    X16 Edit - a text editor View File X16 Edit is a text editor for the Commander X16 platform. Design goals: Use plain text files as the program's interface to the outside world Use banked RAM (about 2 MB) to store currently edited document Be able to handle large texts efficiently No limit to the number of characters per line or the number of lines in a document (other than the available RAM) Simple user interface inspired by GNU Nano Implement basic editing functions well - refrain from making it too feature-rich Support both ISO and PETSCII mode Consider supporting syntax highlighting, if it can be done efficiently Tested with emulator version r38. Run with the following command: x16emu -sdcard sdcard.img -prg x16edit-0.0.3.prg -run Source files available at https://github.com/stefan-b-jakobsson/x16-edit Released under GNU General Public License v 3 or later. x16edit-0.0.4.prg Submitter Stefan Submitted 08/29/20 Category Productivity Apps  
  49. 3 points
    Plus, I want a real 65*02 CPU. I know that's not really rational, but I also know that I'm not alone with this.
  50. 3 points
    That custom case looks so good... but I'm sure it's part of what's making the price so high. I know there are people who wanted a keyboard-computer style case for the X16 as well, but I agree with the decision to go with the Micro ATX if it keeps the cost down! That said, that Spectrum Next design looks so cool... I don't even have any Spectrum nostalgia, and I still want one.
×
×
  • Create New...

Important Information

Please review our Terms of Use