Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by StephenHorn

  1. Alas, the best I could come up on my own with were 1990s games or later. To supplement your list: Dragon Quest V (1992), the game protagonist marries one of three different women (the player chooses which). Super Mario RPG (1996), an antagonist named Booster attempts to marry Princess Toadstool. The ceremony is broken up at the last second. Final Fantasy X (2001), Summoner Yuna agrees to marry Seymour Guado, but it turns out to be a ruse that goes wrong and she is forced to flee from the ceremony at the last second. And the closest a quick internet search could get me was Phantasy Star III (1990), where the main character can marry one of two women in the game.
  2. Well, there's no rewrite planned that I'm aware of, just modification of the C64 kernal to match the hardware of the X16 and extend the API. Having contributed a bunch to the official emulator, forking my own, and poking with the CPU and memory mappings, my guess is that it's not so much a problem with VERA initialization as that the '816 either has a conflicting opcode with the 65C02 that the kernel is using, or is expecting some new piece of memory to be mapped in a way that conflicts with what the kernel is doing, and the kernal is crashing or entering an infinite loop before it gets to VERA initialization. (I would have guessed a conflicting opcode, but added memory wonkiness because someone on the unofficial Discord server suggested the 65816 has a hardwired memory requirement -- similar to the 65c02's CPU stack from $100-$1FF -- that the kernal isn't taking into account.)
  3. For the time being, that's my assumption, and I assume there are no plans to change that. After all, the project is supposedly close to being finished, the team had even hoped to have something available last year, so I very much doubt there are any plans for a major redesign at this point. If the KB/M interfaces moves to the microcontroller, I expect that means it'll be bit-banged through I2C. I don't know what will become of the VIA bits currently used there, if they'd be left empty or if they'd go to the user port or expansion slots, or what. But I'm guessing that whatever else changes, it'll be small moves.
  4. For my money, this is the most interesting point. Kevin added that there was debate whether going through the microcontroller would be faster or not. I had previously commented on Facebook, but this sounds like the team is experimenting with the difference between having the CPU communicate with PS/2 devices directly, versus communicating with PS/2 devices through I2C. The PS/2 interface requires a fair fewer bits, but the CPU spends a lot of time idling, and queries can take a significant fraction of a screen's scantime. I2C, though a much faster interface, requires a lot more bits. Since both interfaces are bit-banged, the difference may be a wash. Personally, I'm hoping we learn what the results ended up being.
  5. Well, with DDR5 promising 4.8GHz and up to 8.4GHz clock speeds, I guess I could start to believe in the possibility of a high-quality manufactured ASIC hitting the GHz range while running the 6502 set of opcodes, without having to be throttled by memory fetches. Would it run circles around modern Intel and AMD processors, though? Lulz no, we're talking about an 8-bit CPU that can't even do its own integer multiplication, much less floating point, and let's not even start on division. Even if you could clock it up to modern CPU speeds, your programs to compare against would be spending thousands of cycles performing operations that a modern Intel, AMD, or ARM cpu can do in as few as 30 cycles. And the memory efficiency of the program code would suffer greatly, as well, as the 6502 has no opcodes for floating point math, or different type sizes, or vector operations. Sorry, we're all fans of the 6502 here, but there's just no reality where a 6502-circa-2022 is going to remotely compete on performance.
  6. Just bringing over some related fun from a Discord channel:
  7. I guess I could only add my agreement that this seems a little doubtful without more documentation of the history of this setup. If nothing else, I agree that this seems inelegant, particularly with a vanilla ribbon cable connecting the keyboard to the mainboard - surely an official kit would have chosen a more professional-looking cable? Perhaps something a bit more rugged, if the idea is that it can be moved around relatively frequently? I certainly don't have the expertise to say either way. Sans that, I could only see myself valuing it as much as any other homebrew mod.
  8. I remember my first encounter with spinner tiles in a labyrinth/CRPG game. I was initially delighted with the game because it was hosted on a BBS and basically using RIPterm graphics, and that was novel. But the draw distance was only 2 tiles ahead, and spinner tile was on a 4-way intersection, and the level made sure all paths onto the spinner tile looked identical, and since we're talking about RIPTerm the game did no animation and so didn't gave any clue that the tile had reoriented the player until they had turned the next corner (or the next after that). My word choice for that kind of design these days is much saltier than when I was a child, but the sentiment remains the same: "F@#$. That. Noise." As a direct result of that experience, it would be the best part of a couple of decades before I would actually learn to enjoy the genre, in a much more contemporary and polished franchise.
  9. By the way, does LLVM-MOS include a way to implement interrupt routines in C++?
  10. My understanding is that the folks who have been volunteering their time into it have been holding off committing r39 updates to the cc65 source tree until there's an official r39 build, in part because the most current official release is r38 and they don't want to force folks to build their own emulator from source in order to test and run their C programs.
  11. "Two's complement signed" means it's a signed integer. If the "two's complement" part is what's confusing, it's the same way that C and C++ represent their signed numbers. To negate a value in two's complement, invert all the bits and then add 1 to the result. So, for instance, 0x0001 is "1", to create "-1" you would invert all the bits (getting 0xFFFE) and then add 1 (getting 0xFFFF, which is "-1" in two's complement). Similarly, negating -1 starts by negating all the bits (getting 0x0000) and then adding 1 (getting 0x0001, which is "1" in two's complement).
  12. It's at the tail end of the official documentation: Audio data formats Audio data is two's complement signed. Depending on the selected mode the data needs to be written to the FIFO in the following order: Mode Order in which to write data to FIFO 8-bit mono <mono sample> 8-bit stereo <left sample> <right sample> 16-bit mono <mono sample (7:0)> <mono sample (15:8)> 16-bit stereo <left sample (7:0)> <left sample (15:8)> <right sample (7:0)> <right sample (15:8)>
  13. I think a lot of this is because a successful business tends to interpret their success to mean that what they're doing is, in fact, strategically correct instead of just a consequence of some stroke of dumb luck or a temporary gap in the market. I wouldn't be surprised if Scott Robison has it correct and that C= leadership simply didn't know how to market anything that wasn't ultimately a "toy" - a non-upgradeable piece of purchase intended to be deprecated by a future model. Though I might look at it more similarly to the case of THQ Chapter 11, that even if they recognized that the "toy computer" market was drying up then they failed to understand how desperately they needed to reorganize under a new market strategy, perhaps telling themselves that it was a temporary market contraction and hoping that the toy computer market would pick up again. Perhaps they even convinced themselves that they saw signs of this turnaround on the horizon, fooling themselves into the belief that they didn't even need to change. ("THQ Chapter 11", otherwise known simply as THQ and originally known as Toy HeadQuarters, was a toy company turned videogame publisher, which made a killing in the 90s and early 00s on the back of mediocre licensed game franchises, particularly those made with Nickelodeon IPs. As an employee working for one of the studios they owned, my opinion is that they died as a result of multiple top-level failings: First, they continued to sign new, unprofitable licensed games deals, even years after having recognized that they were no longer able to negotiate competitive licenses with which they could break even, let alone make money. Second, they never really learned how to market their own IPs, having built their business on licensed IPs that needed little or no marketing whatsoever, and failed to more broadly adopt the successes and capabilities of their much more savvy European marketing teams. And third, they never learned how a well-run studio creating original IPs should operate, which wound up costing the company huge quantities of money as they went on an enormous buying spree to try and purchase their way into a more robust library of IPs, only for most of those studios to be shuttered within a year or two. These days, I refer to the company as "THQ Chapter 11", as they filed for Chapter 11 bankruptcy in 2012 and the THQ trademark was subsequently bought at auction by Nordic Games, who subsequently rebranded themselves "THQ Nordic" in 2016.) ((Huh. Well, that was a heck of an aside.))
  14. Banked Memory The currently enabled RAM and ROM banks can be configured by writing to zero page locations 0 and 1: Address Description $0000 Current RAM bank (0-255) $0001 Current ROM bank (0-31) The currently set banks can also be read back from the respective memory locations. Both settings default to 0 on RESET. The upper three bits of location 1 are undefined. https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#banked-memory Edit: Doh, I meant High RAM.
  15. The high RAM memory, 0xa000-0xbfff will be bankable. The prototype boards in Dave's videos probably date back to when banking was handled through one of the VIA controllers. Now it's on ZP address $00. (As already answered, ROM memory 0xc000-0xffff will be bankable, but only to other ROM memory. That is now on ZP address $01.) Edit: Low -> High. It's what I meant, honest.
  16. I think it would have been impossible to buy Microsoft from Bill Gates at any point in C='s lifetime. Gates knew exactly what he had, which is why he licensed his software to IBM in the first place instead of selling it. There's just no way he would have sold to C=, at most he would have agreed to partner with them to provide Microsoft Works or, prior to 1987, to port MS-DOS and/or Windows to a Commodore platform. This wouldn't have been any real competitive edge for C=, though, they would have to compete on price and hardware performance like all the other also-ran companies of the early PC era, most of which died (including C=, which moved into the IBM-compatible market in 1987). The big competitive edge of the C64 was its low price point, thanks to its relatively simple hardware design and the 6502 processor, something which C= were really never going to be able to replicate, and especially not without their own Intel-compatible CPU that they could manufacture without a license, and turn around to license and second-source to third parties. If C= could have bought AMD, that would have been prescient, but I suspect that AMD's long technical partnerships with Intel may have been written with poison pill clauses to prevent purchases and buyouts, and that their even longer feuds with Intel would have been another poison pill entirely and I question whether their administration under C= would have been willing or able to continue the legal battle with Intel into the 90s. But I think AMD is a model of what C= needed to do to survive: Lean into the MOS/CSG side of their business and partner with the winners of the CPU competition to co-develop and second-source the x86 platform, while developing their own clean room implementation of Intel's processor. This, too, is no guarantee of survival, just ask Cyrix. But I think that, shy of some miraculous encounter with someone who could drop a "Micralign"-level production advantage in their lap and undercut the competition by laughable margins, it would have been their best shot.
  17. At present, the official emulator can only directly load and save BASIC programs in their tokenized form. If you want to export a BASIC program to a text file, you'll need to launch the official emulator with the "-echo" command line option, load your program, and then "LIST" it. From there, you should be able to copy the text from the console window. If you have a BASIC program in text form that you want to "load" into the official emulator, you can use the "-bas <filename>" command line option to have the emulator automatically open the file and "type it in for you". You can also copy from the text editor and Ctrl-V to "paste" it, which works in a similar fashion under the hood.
  18. Not very PR-savvy, but absolutely something I would probably do at some point if it were my community to piss off. I try to keep a lid on my more acerbic tendencies when folks frustrate me, and walk away, but it does leak through here and there, and I'm sure there's no way I could manage a community around me without a lot of help (in the form of less-abrasive folks acting as a buffer). So I sympathize. She also seems to invest a lot of herself into her projects, and it's a rare soul who can do that and not feel like criticism is at least a little personal. Ah, yeah, I see that I made an implied assumption that my list was describing a CX16e, sans the 'p' or 'c' models, since I was specifically following up on an argument I was making in favor of the 'p' having value. If the project were to jump straight to the all-in FPGA simulator, do you think the niche still exists for that platform, moreso than an FPGA implementing a purely fantasy computer?
  19. It may sound dismissive of me to analogize the potential X16e with a Raspberry Pi, but I see them as having very similar niches. The key differences are, as they appear to me: MS BASIC console as a frontend Native 65XX-series machine language Everything else differing a Raspberry Pi from an X16e is about removing capabilities from the Pi: Less memory, fewer clock cycles per second, less powerful video and audio features, fewer standard peripherals, etc., etc. And even then, the MS BASIC console is "just software". Yes, it's important to the old school Commodore experience, but there's no reason someone couldn't create that on Linux and provide the same programming environment (or a vastly improved iteration of it that still feels similar).
  20. While Bruce beat me to the point about the unit cost, I do realize that import taxes and shipping, combined, can weigh heavily on the price to non-U.S. locations, and Perifrantic in particular has clarified that there are no plans to warehouse units outside of the U.S. to mitigate shipping and taxes. There was an entire thread about this problem back in February, though the specific costs were to do with the WASD keyboard: So I get it, that makes the potential X16e -- hopefully being much smaller and lighter, and starting from a lower-cost BOM to begin with -- look a lot more attractive. But the original hardware vision of the X16 was for through-hole parts, and I have the impression that if a viable, permanent silicon, through-hole video chip solution had been available then we wouldn't have an FPGA anywhere on the X16p board. At which point, I guess I'm left to wonder if the argument would be over why the X16 doesn't incorporate an FPGA to reduce the BOM, even though that's quite likely to be the case for future revisions of the X16 (if there even are future revisions, bearing in mind that the future models are not being designed yet and the team is focused on completing the X16p). Referring to the through-hole hardware vision as "absurd" is dismissing Dave's original vision as "absurd". Well, phooey, because to me that was a part of the original appeal: this wasn't going to be some magical "single chip on a credit card" device that was somehow a computer. I can already get one of those, it's called a Raspberry Pi.
  21. I suppose I should add, as well, that it is not my intent to be antagonistic. I just find Paul to be frustrating because I don't know what appeals to them about the X16, and I feel that they spend a significant amount of effort arguing that the X16 isn't meeting any particular goals.
  22. I found parts of that to be a little hard to parse, but I think I pretty much agree. Honestly, I have my doubts as to whether Paul will ever buy even the X16e, because the emulator is even less expensive and provides all the features of the X16 at an acceptable level of performance. With a little tweaking of the source code, it could even emulate the CPU (and various other components) running even faster than the real X16 will allow. I don't think Paul has ever indicated what, exactly, is interesting to him about the X16.
  23. I stand corrected. I truly didn't expect IEC or PS/2 signaling to be exposed in any way, shape, or form.
  • Create New...

Important Information

Please review our Terms of Use