Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


StephenHorn last won the day on September 3

StephenHorn had the most liked content!

Community Reputation

182 Excellent


Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Besides, kids already have iPhones and iPads. Suggesting that this would be something to choose instead of iDevices is basically denying reality, especially since iDevices have three key benefits over other portable electronics: Kids being able to stay connected to their friends. Parents being able to stay connected to their kids. Parents being able to track of their kids' location. Not to mention a devastating advantage in third-party software support. The only possible way you could come out ahead here is if you can somehow get Fortnite playing on your 6502 project, and then only because Apple and Epic have gotten into that giant legal fistfight... Also, the last time someone tried to make a low-budget console, it failed rather spectacularly. At least we got some ridiculous marketing out of it. It's not a selling point to kids that its based on a 6502. That's a selling point to adults who remember the 6502-based platforms of yestermillenia, and want to nostalgically relive some of those memories. Kids, broadly speaking, don't care about that stuff.
  2. 1. It's possible. 2. What's your demographic? Kids playing games? Or kids making games? If the former, why are kids going to want to ask their parents for a 6502 console when they already have iPhones and iPads? If the latter, why is the CX16 not a direct competitor who's going to beat you to market by an absolutely crushing interval? Or why would kids take your console over a variety of other products which are intentionally built to be easier to learn to program at a high level?
  3. I'll supplement some of these answers. 2.b: Performance is not impacted at all by hscale and vscale. Hscale and vscale do not actually change the output resolution of the Vera, the Vera will always, always, always output 640x480. Hscale and vscale only changes the decision of which pixels are drawn at any given screen position, in order to emulate other resolutions. Resolutions that are not a clean power of 2 from 640x480 will have scaling artifacts as a result. But also, performance of the Vera doesn't matter. Even if you attempt to max out its graphical capabilities, it will always draw the 640x480 display at 60Hz. This isn't a modern video card that you can overburden with work. 2.c: You can (and should!) do the math yourself to determine what can fit in the Vera's memory. If you intend to press the limits of the Vera, you will need to do the math yourself. That's part of the fun of working on a resource-constrained machine. The Vera has 128KB of memory, minus the PSG registers and sprite attributes. 640x480 is 307,200 pixels, so obviously an 8-bit color bitmap (307,200 bytes) is out of the question. So is a 4-bit color bitmap. A 2-bit color bitmap is possible, but you will not have enough room for a "back-buffer", meaning folks will see your drawing processes unless they are exceedingly fast. A 1-bit, black-and-white bitmap allows for a backbuffer, so you can draw to the backbuffer and then flip which section of memory is presented during vblank. Tilemaps are more complicated. If you are using 8x8 tiles with 8-bit color, you need at least a 128x64 tilemap to cover an unscaled 640x480 display, and this costs 16,384 bytes. From there you have room for 1,750 tiles. If you need all 1024 tiles, obviously this is ample and it leaves room for sprite data in memory, as well. If you are using 16x16 tiles with 8-bit color, that 640x480 display only needs a 64x32 tilemap to be completely covered, which is 4,096 bytes. However, you only have room for about 450 tiles. If you don't need that many tiles, great. You can put whatever memory is left into sprites. If you are using 4-bit color, your memory requires are cut in half, and again if using 2-bit color, and again if using 1-bit color, so there are boatloads of combinations here based on what you need. 3.a: It is possible to start a layer partway down the screen, but saves no work on the Vera. Instead, consider this: If you change parameters about layers partway through a screen draw, you could have a portion of the screen dedicated to UI elements (score bar, life counter, HP, inventory and/or power-ups, etc), followed by a gameplay area. And the gameplay area can scroll. And you could scroll layers at different rates, and choose which layer data is used and when, to create a variety of parallax effects. And you can pull other tricks and shenanigans. 4: Define what makes a game "superior". But in any event, it's unlikely. The X16 was envisioned as a modern take on a Commodore 64, and was designed in a similar fashion. The audio and video options are very beefy for an 8-bit machine, however, and when combined with the outrageously fast 8MHz clock speed (compared to era-similar 1-2MHz clock speeds) this may allow it to flex a little into the realm of 16-bit platforms. I've mentioned in my thread promoting the Coding Secrets youtube channel that the X16 is likely capable of many Genesis-era effects. If you consider the Genesis your "par" for superiority, it's possible you could make a clone of at least some Genesis games which are identical in every way to the originals, but that take advantage of the X16's sound solution, which is likely to be a bit better than the Genesis. But those are going to be relatively few cases. Really, instead of thinking of the X16 as a 16-bit platform like the SNES or the Genesis, you should think of it more like the PC Engine/TurboGrafx-16, in that it's still basically an 8-bit platform, plus some beef.
  4. A fully automatic load and should should already be possible by combining the -prg and -run command line options: x16emu.exe -prg "filename.prg" -run This will load the program "filename.prg" and automatically execute "run" in the console. What kind of interface does a debugger like C64Studio need? Honestly, what I'd like would be a debugging plug-in for Visual Studio Code, but I've never looked deeply into it. I more or less assumed it would require opening a pipe or something and then communicating with a tool-specific binary protocol.
  5. I could see a machine picker being able to place the components, provided it can calibrate the expected height of the surface, such as when dealing with PCBs with different layer counts. There may be a maximum value to that height calibration, however, which makes it impossible for the picker to adjust to a foam sheet. There may be other mechanical problems with feeding a foam sheet instead of rigid plastic PCBs, as well. Someone from the Shenzhen area might know if they're friendly with PCBWay (or the like). PCBWaaaaaaaaaaay.
  6. My guess is that this is probably an emulator bug. The real X16 would wrap the display once it reaches the edge of the tilemap, so you should see at least part of the X16 logo and whatnot towards the right edge of the display (it being a 128-wide layer, and a scale of 255 showing around 159 tiles). I would guess that one of the VERA speed optimizations broke this, and I worry we could be looking at some of the emulator's internal memory...
  7. If there's a kit version, I expect each chip and component will come individually boxed and labeled, because that's obviously the least expensive path, since they don't even have unbox any of the components before shipping! No, really, if I order a kit in addition to a fully assembled version, I'd be happy as long as it doesn't arrive as a single ziplock bag of assorted parts... like a certain other homebrew computer project that was once mentioned, long ago. I really liked the idea from the Mini PET, of placing each component in approximately the correct position on a sheet of foam. But I imagine that adds even more cost than full assembly... unless machine pickers can already do it.
  8. 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.
  9. 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?)
  10. Any read or copy of the 32-bit value can't be done atomically anyways, so I would advise against trying to use this value in a 65C02 program. The odds of a variable rolling over and presenting you with misleading results is pretty high. I had wondered about the runtime of my own code, myself, and had some modifications to add the cycle counter and a delta to the built-in debugger. I'll look into re-adding that and submitting a PR. Then I would recommend using that, since it can read and compare the cycle counter without altering the state of the CPU.
  11. These are variables specific to the emulator and will not work on the final X16, which is probably why they aren't in the official documentation. For the curious, the emulator-specific variables are: $9FB0: 1 if the built-in debugger is enabled, 0 otherwise. $9FB1: 1 if video logging is enabled ("-log v" command line option), 0 otherwise. $9FB2: 1 if keyboard logging is enabled ("-log k" command line option), 0 otherwise. $9FB3: The emulator's "echo mode" (see also "-echo" command line option) $9FB4: 1 if the emulator should save a dump of the machine's state on exit, 0 otherwise. $9FB5: The gif record mode. If set at runtime, this will begin writing a gif. $9FB6-$9FB7: Unused. $9FB8: Bits 0-7 of clockticks6502 (the cycle counter). (Read-only) $9FB9: Bits 8-15 of clockticks6502 (the cycle counter). (Read-only) $9FBA: Bits 16-23 of clockticks6502 (the cycle counter). (Read-only) $9FBB: Bits 24-31 of clockticks6502 (the cycle counter). (Read-only) $9FBC: Unused. $9FBD: The emulator's keymap (see also: "-keymap" command line option). (Read-only) $9FBE: Always $31 (ASCII code for '1'). Useful for detecting that the emulator is being used. (Read-only) $9FBF: Always $36 (ASCII code for '6'). Useful for detecting that the emulator is being used. (Read-only) Unused registers are read-only and will always return $FF.
  12. The vsync timer will definitely change if you replace the VERA entirely. Otherwise, no. The VERA is going to output VGA at 60Hz and NTSC at 60Hz. There is no 50Hz PAL support planned. Of course, if your interrupt code takes more than 16ms to execute, you're going to miss a VSYNC simply because nothing will check for it.
  13. That's another perfectly valid approach. It's not that storing a fixed value in the CTRL register is a bad idea, per se, I just felt that in a general case, TSB/TRB on just the bit you want to manipulate represents a best practice. If you know the other bits are irrelevant, STA is perfectly fine. But also, maybe I'm overthinking things, or making things difficult by choosing instructions folks might not be so familiar with. Everyone that's been introduced to 6502 assembly knows LDA/STA, they might have overlooked or be unfamiliar with TSB/TRB.
  • Create New...

Important Information

Please review our Terms of Use