Jump to content

StephenHorn

Members
  • Posts

    440
  • Joined

  • Last visited

  • Days Won

    20

Everything posted by StephenHorn

  1. With that SoC, I'm not holding onto hope that anyone's going to mod a keyboard interface into it.
  2. I'd suggest you find a viable alternative, but you'd be years too late on that front. A number of video choices were evaluated and rejected, and in the end an FPGA of some sort was the only real option here. And part of me does lament the integration of the SD interface, as well as the PSG and PCM audio, into the same FPGA, exactly because those decisions run counter to the "purity" goal of the project. However, once the choice was made to go with an FPGA for video, it's easy to see how the scope of that FPGA's responsibilities grew, not only to keep the final cost of the X16p lower, but especially if the long-term plan would be to eventually release an X16e that might be reduced all the way to something like a single FPGA. I'm sure it also helped to keep the design of the X16's motherboard a little simpler. But as Elektron points out, there are still plenty of components that are good, old-fashioned silicon. The VERA has not become the be-all, end-all of the X16p.
  3. Huh. I'm familiar with MUDs (and have fond memories of SWMud, in particular), but was unfamiliar with LambdaMoo and the alternative acronym it uses. Pretty cool. Well... there have been a small handful of games that have advertised themselves as "real-time 4X" games, such as Stellaris or Sins of a Solar Empire. But games like Warcraft, Warcraft 2, and Command & Conquer are typically considered "real-time strategy" games, since they don't focus heavily on exploration and expansion. A map in those games is preset, with known base locations and perhaps natural expansions, instead of games like Civ which are procedurally-generated and require you to explore, improvise, and make do with the conditions you find yourself in. But it's true that the RTS and 4X/5X genres do have titles which blur the line, since moving to real-time can make the military, macro/micro strategies very similar to each other.
  4. Most likely, he is referring to "Master of Orion", a turn-based 4X game (genre named from the four 'X's in "Explore, Expand, Exploit, Exterminate", the gameplay pillars of the genre). Think of it as being like "Sid Meier's Civilizations", but in space. MOO was a hit in the mid 90s, as was its sequel, but after MOO3 arrived to very mixed reviews and modest sales, the series went dead. Atari later sold the IP to Wargaming, and a reboot "Master of Orion: Conquer the Stars" was released in 2016, but hasn't really made waves -- actually, I only just read about the latest entry while Googling to double-check my memory. It surprised me because I like 4X games and sci-fi and have tried to keep aware of new titles in that area.
  5. Sven, please accept my humblest apologies if that quote appeared targeted at you. It was not. My intent was simply to quote Lorin as an official source.
  6. And now you're just trolling. Have fun.
  7. Oh. So this is just a giant feature request thread. The VERA's design is final and it's only changes are bugfixes.
  8. It's possible to show all 4096 colors on a single screen, if you use line IRQs from the VERA to periodically swap out the palette. Obviously you would need to do this 16 times. But there is no way to show all 4096 colors on a single line. NTSC trickery may help you achieve more than 256 colors on a single line through color-mixing/smearing effects, but the emulator doesn't simulate that so you'll have to forge ahead and otherwise wait for final hardware. And swapping the palette back and forth between even and odd frames may create the illusion of color-mixing, which could greatly expand the number of apparent colors, but it is an effect with limitations: Sharp-eyed viewers will notice the flickering, others will develop headaches if exposed to the effect for long periods of time, and I'm not sure if it can cause seizures with photo-sensitive people. Otherwise, I don't understand what you mean by "multiplexing". The only context in which that term appears to apply to color is in using multiple wavelengths of laser light to encode multiple bits simultaneously for fiber optic communication. As far as any additional features for the VERA to understand new graphics formats, that's a non-starter, the VERA design is finished and the hardware/firmware/logic is in the final bugfixing stages. You'll just have to help the card sell well enough to convince Frank that there's a market in a bigger, better, stronger, Very VERA sequel card with support for fancier-pants graphics features, more color bits, 16-bit hardware multiplication, affine transformations, blackjack, and everything else on everyone's wish lists. And a pony, because why not.
  9. I would submit: This is 8 bytes and 14 cycles, and each call is 3 bytes and 6 cycles. But if you made it a macro, it would only be 7 bytes and 8 cycles per inlining, so definitely a candidate there, particularly since the cost of the lda/sta pair you might bracket it with could easily exceed the runtime of the actual operation. Of course, if you only wanted to "booleanize" the value, for whatever reason (about to store it into a packed field?), then you don't need the eor #1 at the end, which shaves 2 bytes and 2 cycles off of the operation.
  10. That's confusing a bitwise NOT for a logical NOT. Logical NOTs, even today, are primarily concerned with equivalency against zero, for the purposes of branching logic. Not that far back into the history of programming, C actually explicitly defined 'TRUE' as '1' and 'FALSE' as '0', making any other value either indeterminate or requiring a comparison by equivalency (e.g. 'if(2 == TRUE)' would evaluate to false and the program would not enter that if block). And I believe there have been a few languages which defined "true" as '0' and "false" as -1. Even today, the x86 instruction set does not specify a "logical NOT", and determining the logical value of an arbitrary number would typically be implemented by clearing the eax register ('xor eax, eax' to set its bits to 0) and then comparing it against the arbitrary number. If you wanted to assign the result, X86 implements the instructions 'sete' and 'setne' which set a value to 1 or 0 based on the status of the ZF (zero flag) bit on the CPU. The 6502 would need to jump through some additional hoops, unfortunately, because it lacks equivalent operations to SETE and SETNE. Most likely, I would imagine someone would lda, clc, adc #$ff, lda #0, rol to booleanize a value. But maybe someone knows a faster way.
  11. Oh, believe me, I'm well aware of the github repo, I've been one of the more active contributors. But there is no release tag for r39, because r39 is not released yet. It is nice, however, that the current head revisions of the emulator and ROM work together at the moment, and that they currently preview the next revision of the hardware that will be in r39. But if I were to, say, upload a new program for r39 right now, then relatively few people would be able to run it, and in particular it would not work under the "Try It Now" feature. I don't compile the Windows binary on Linux, personally. I actually have my own VS2019 solution setup, with some additional source files to handle the platform compatibility differences between the cross-compiling environment of the official build and a native Windows environment. It sounds like one of the folks on the unofficial Discord server has recently rolled their own CMake script as well for compiling on Windows.
  12. Additionally, the HSCROLL and VSCROLL layer parameters will not change the VRAM address of the window, just the portion of the window that gets drawn. If the window would "run off the edge" of the tilemap, the VERA just loops back around.
  13. Ugh... if that's what cc65's interrupt handler does, then in my opinion it ought to be changed. First, there's no guarantee that the kernal's interrupt exit routine will always exist at that address, until the kernal is finished and the final X16 is released. Even then, creating that dependency makes it possible to break programs later on if the kernal needs to be patched. Also, if there's logic that was interrupted and depends on a particular ROM bank being loaded, that bank gets clobbered if you let the kernal trampoline into ROM bank 0 and then fail to let it trampoline back to the appropriate ROM bank that had been loaded before the IRQ fired. The kernal loads a default interrupt handler address at $0314, and a default brk handler address at $0316. It's fine if someone wants to clobber those to run their own handlers, but to return control to the kernal they should be jumping to whatever the kernal had originally loaded at those addresses, not to the location of ROM that happens to perform the PLY, PLX, PLA, and RTI. If you really intend to immediately terminate the interrupt, expert-style, you should just go ahead and do it yourself. (Unless or until the kernal gets an official API function to do it on your behalf, saving your program the... 1 byte difference between a jsr and "PLY, PLX, PLA, RTI".)
  14. I know this isn't helping, but... every time this thread gets bumped, I keep hoping it's r39.
  15. You've managed to answer your own question, it seems, but I want to go ahead and confirm: Yes, you are correct, the DCSEL bit in $9F25 needs to be set to 1 for the DC_HSTART, DC_HSTOP, DC_VSTART, and DC_VSTOP registers to be accessible. If DCSEL is 0, these registers instead point to DC_VIDEO, DC_HSCALE, DC_VSCALE, and DC_BORDER.
  16. With my soft spot for retro translations, I came up with this one Valentine's Day a few years back: Ah, Zero Wing. So many memes. All my heart is belong to you. Edit: Oh hey, that wouldn't be bad, either.
  17. I mean, we already have banked RAM that can do all of this "putting data in/out of context" thing you're referring to, except in whole blocks of 8K instead of your subset of registers in the ZP. And if I'm working with heavy A/V data, I care about the quantity way more than the exact cycle count of accessing it, because all the cycle count savings in the world won't help if I have to slurp in new data from external storage - we're talking about multiple orders of magnitude difference to copy from memory versus copying from the SD card. And if I'm stuck with a loading screen, I want to be stuck only and exactly once, if possible. And honestly, if I'm in an A/V situation where I desperately need to maximize the bandwidth to, say, the VERA -- so much so that I can't afford the access penalty of banked himem -- then I'm going to be highly interested in an expansion card that provides hardware DMA. In fact, maybe a card that interfaces with its own SD card and caches the raw binary image of the card (or, ideally, a specified file in a filesystem on the card, maybe through some global launcher that comes with the card, but I'm happy to live within less sophisticated features), and that can then be instructed to use DMA to push selected regions of its local storage to a single address (piping it to the VERA or another device), to an address range (dumping it to RAM), or even to a series of RAM banks. Or hell, even if the card simply provided DMA to copy things between memory ranges and devices on the X16, with no additional memory, that would still be faster than any software copy by an order of magnitude, if it really came down to that. But then, there's already a lot about the X16 that wouldn't have been remotely possible on the C64, just because the X16 is 8x the clock speed. Pushing it further seems likely to run into more basic problems involving the finite amount of memory on the system, requiring different hardware solutions to expand the available memory so that the increased bandwidth is... well, useful. About the only special purpose where I'd even think I'd want DMA is game programming, to quickly transfer large quantities of assets to the VERA without having to sit on a black screen while 128K or whatever is spooled. Really, multitasking seems like the only significant purpose served by swapping the ZP and stack, and I have a whole essay I could go into about that (tl;dr, I'm not a fan and think you really want an entirely different CPU family and system architecture if you really want to look into multitasking as anything more than an extremely fragile parlour trick).
  18. Per the title, are there any plans to limit the number of units that a person can purchase at launch? I'm starting to warm up to the idea of possibly playing around with expansion cards, but since I'd be a novice to that area, I'd want a second unit so I don't need to worry (as much) about literally blowing up the unit. The topic of ordering limits doesn't seem to be addressed by the FAQ. Maybe this is still too early to discuss, but I thought I'd put the question out there. To be clear, I'm only personally thinking about ordering a second X16. I'm not planning to order 16 X16s, though that could lead to an entertaining Youtube video akin to the 3 PS3s, 4 PS4s, and 5 PS5s. So even if there are limits to the number that folks can order, I'm really just hoping the limit is greater than 1.
  19. It looks to me like you're missing a `void (*SystemIRQ)();` declaration somewhere... Edit: That having been said, I haven't done any interrupts in cc65, and I doubt it's safe to just clobber the system IRQ with a cc65 function (`rts` vs `rti`, and all that). Are there any IRQ-related functions in the x16 library for cc65?
  20. This may be a bit of "you had to be there", because at the time the poll was taken, there was no physical kit in the hands of anyone, except for a prototype being passed between the X16 team members. So the question was entirely how the community expected to use the SD Card slot once the final X16 was available for purchase. And the majority of the community (myself included) responded that SD Card swaps would probably be rare. Personally, I'm anticipating that I'll buy a wifi SD card and simply never think about pulling it out, except to replace it should it burn out.
  21. In fairness, that's perfectly reasonable and did happen. The example cassette should really already have a label instead of a blank white rectangle that screams "Write in me!"
  22. Ahh, that early 90s look and sound, such nostalgia... A friend recently managed to lure me into watching Carole & Tuesday, a Netflix original anime series about two girls on a future version of Mars who try to launch a music career together, in an industry that's now dominated by superstar artists and personalities who mostly perform AI-generated music. The biggest selling point of the series is definitely the OST - there's a lot of good music in the show, and some fairly disparate genres represented. I thought the first half of the series was overall pretty great, but the second half felt derailed by a B plot that wasn't central to the girls' journey, and I felt the ending was pretty weak as the B plot took greater emphasis and then ultimately resolved itself without the girls' help. Plus other confusing things that broke my suspension of disbelief at the end. Overall, worth watching at least the first half, for the music. This is what finally convinced me to try the series, if only for the OST. (Fair warning: Coarse language. Lots and lots of coarse language.)
  23. As much as I want to support ambitious projects that aim to push the limits of the hardware, it's only with the understanding that the hardware is what it is, and living on the edge means always being a half-step away from teetering over it entirely. It might be worth planning out what you want to do in your shooter, and figure out whether you have the VRAM to do so at 640x480... or else to drop to 320x240, or make cuts somewhere in order to fit your game into VRAM.
  24. No worries, could just as easily be my fault, on a re-read I see what you meant.
×
×
  • Create New...

Important Information

Please review our Terms of Use