Jump to content

Scott Robison

Moderators
  • Posts

    824
  • Joined

  • Last visited

  • Days Won

    37

Everything posted by Scott Robison

  1. That would be good. I was being pointedly snide in that comment. Though it does feel as though this has turned from a thread about X16 & X8 polling and opinions into an almost anything goes mailing list. The topic was effectively "do you think we should release X8 and in what forms should we release X16?" based on the subject and especially the poll. The team designed the systems and wanted input. Repeated admonitions from some to replace part of the established design as it exists today are out of place. Just my opinion of course, I am not a moderator or a member of the project. I don't get to dictate how the forum is used, but surely my opinion of certain topics being out of bounds and expressing such is no less valid than those who post critiques of the design choices made by the team. There are other message boards and the ability to create topics in most or all of them. This thread seems to have served its purpose. I guess I could just walk away from it and ignore it, but I do enjoy tilting at windmills.
  2. Understood. At inception less information was available. People with new information make appropriate (for them) adjustments to their plans based on new information coming to light. I'm all for people making whatever strikes their fancy. Claims that what David wants is simply a matter of optimizing a discrete alternative are taking liberties with the word simply. If it is simple, those who think it is should do it and show it to David. He is not unapproachable. Note that I'm not saying you are clamoring for this. It is a general observation from recent posts. Ultimately some posts seem like they belong in a different thread.
  3. Based on a comment from the Facebook page, the X8 is probably not going to happen as originally described because it wasn't quite similar enough to X16. Apparently a larger FPGA is being investigated. So I would buy an X8 if there was nothing else, but it doesn't appear it will be coming as originally described.
  4. Feels like AS500 is a leet spelling of ass-oo...
  5. Oh, I did. I just meant that while it is good to know that the game can still generate a new map, it still has that one flaw from my perspective. Downloading a few games from back in the day was something I did while my maxi was still on the boat.
  6. Almost definitely. It depends on the exact FPGA part and provisions provided by the team implementing it, but I would be surprised if there wasn't a way to update the FPGA to address potential defects or enhancements after the fact.
  7. I think that seems likely at this point, though we've not been told for a certainty. All in one FPGA solves a number of problems potentially. I think there will still be a less FPGA driven option at some point as well, just that decisions on how and when are still being evaluated.
  8. Exactly. "Possible" and "practical" are very different. MOnSter 6502 would be awesome to have, but it isn't practical from a "doing things" perspective. And the more parts exist in a design, the more things there are to go wrong and to troubleshoot. You can bet that if Amiga team would have used FPGA to do their design work had it been an option at the time. They used discrete wire wrapped components because they had to, not because they wanted to.
  9. That's good to know, thanks. Sadly, it still doesn't solve the PAL vs NTSC timing that makes the audio "wrong".
  10. Thanks for pointing that out. I'm a big proponent of FPGA for implementing things like this. It's bespoke artisan ASIC creation. Sure, if you're planning to sell a million of something, or even tens of thousands of something, it *can* be worth it to go the route of ASIC. Especially if you are willing to call all bugs "features" at some point. That's how the VIC II as we know it today came to be, really. There are things the demo scene has discovered about the chip that were not deliberate features, they're just artifacts of the implementation. The idea though that it is "simply a matter of optimization" to get what Ben Eater created (a cool educational project, to be sure) and transform it into something that checks all the boxes of what David wanted for his dream computer out of nothing but discrete parts seems like a stretch to me. Certainly on anything we'd consider reasonable for a given amount of time or money. The word "simply" seems like a gross understatement in that context. But I'd love to be wrong! It wouldn't be the first time, and probably wouldn't be the last. I'd love to see it, just like I'd love to see a complete C64 made out of all 7400 series chips as the C74 project is trying to do. But it won't be inexpensive or practical, and both those are at the very least unstated goals of the X16.
  11. Indeed. The proof is in the pudding. If it's easy, go do it and show us the better more enlightened way. I know it is hard for some people to find time to do such things when writing, derailing thread topics, and fighting to keep foreign governments from making us appear foolish take so much otherwise productive time... It seems it would be a great investment for the world if one could take the Ben Eater world's worst video card and turn it into something comparable to VERA.
  12. When I first read that, my thought was "I've heard about fast 6502 cores realized in an FPGA before." Fortunately, I went on the read the article. That is not what I was expecting. Awesome!
  13. There are different FPGA with differing capabilities. Not all are such low power, though mostly I think yes, you would need level shifters to interact with a 5V bus. For communication between a physical CPU and the FPGA (or really, anything interacting with the FPGA), your HDL defines a number of externally exposed IO lines to serve whatever purpose you want. For example, I have a Nexys 4 DDR board that exposes 40 pins to the outside world (and more IO is assigned to other IO devices on the board itself, such as switches, 7 segment displays, LEDs, network, VGA, etc, etc, etc). Some FPGA have a CPU sitting next to the FPGA, or IP is available to embed a soft core CPU into the fabric of the FPGA. Others just provide the FPGA and a processor (if desired) has to be created from scratch or sourced from another project or offering.
  14. I posted recently on my FB: "I think Shatner going to space is a bad idea. The Klingons said there would be no peace as long as Kirk lives, and Shatner bears a striking resemblance. Just inviting trouble."
  15. I think this thread has jumped the shark. Perhaps it needs to be locked, too.
  16. Yep, replace P+0 with P and replace %10001 with a variable defined earlier and I got the third loop down to 170 jiffies, or 0.36 ms per VPOKE/POKE. 46% speed increase.
  17. So by using VPOKE 8 times in a loop, each statement will average 0.67 ms per VPOKE (plus extra time for any calculations since I'm just poking values of 0). By using one VPOKE and 7 POKE statements in a loop, the average time is only 0.42 ms per VPOKE/POKE. 37% speed increase.
  18. Here is a better test case that is more apples to apples based on Ender's comment. So 322 jiffies to use pure VPOKE, 590 jiffies to use pure POKE, 218 to use hybrid approach that should autoincrement. Replace %10001 with a variable to make it even faster, probably. Edit: Oh, I put one too many POKE commands in the final loop. That is just a typo. Remove one of them to get the exact 8 VRAM pokes you wanted. That gets the time down to only 199 jiffies.
  19. Ah, good to know, thanks. In my testing just now, my version is definitely slower because the extra pokes do math on P that isn't necessary in the VPOKE version, so don't use it even though it is "technically correct" but "slow". And I realized that if P is greater than 32767 AND is going to fail with it and AND only works with valid signed integers. Edited: removed screen shot in favor of next message. There is the test code, and the numbers under RUN are the number of jiffies to execute the pure VPOKE and the number of jiffies to execute the pure POKE.
  20. VPOKE will set an address (I don't think it's documented as to whether it will set addr 0 or 1), but I don't think it sets the increment. Regardless, VPOKE will always reset the address every time it is used. By avoiding VPOKE completely you can set the address, pick whether it is 0 or 1, and target the port. Whether it is a net improvement will depend on how much overhead is involved in the multiple POKE statements and how many bytes you write with auto incrementing addresses. I feel confident that my solution is technically correct (though I didn't try running it), but it might not be more efficient than a series of VPOKE statements. That would probably be a good test. Run the 8 VPOKE based version 1000 or so times and time it, then run the 12 POKE only version 1000 or so times and time it and see if one is definitively better than the other. Now I'm curious. Testing.
  21. From my time in radio, "programmer" or "programming" has very different meanings in that context. Those of us with software experience think of it as meaning one thing when it actually has broader implications. Deciding upon the sequence of songs to be played is programming. Configuring a VCR to record shows at a given time is programming. And writing HDL descriptions is programming in that the HDL has rules and syntax of a sequence of keywords, which is subsequently transformed into a bitstream that has its own sequential format that is loaded into the FPGA, just as the programming of a ROM determines a set of values returned in a sequential manner based on address pins. Which is to say, you are correct. It is not programming in the limited sense many people think of programming, but it is surely a form of programming just as other examples are as well. In fact, one can (if one wants) consider Word or Excel or {insert example program here} an interpreter that allows one to write programs in a domain specific language using a rigid IDE. An expert with those (or comparable) tools can do incredible things. And old timer machine language programmers (those who coded in hex, not in assembly) can look down their noses at those of us that only know high level or assembly language because we're not doing it the right way either.
  22. If you didn't read the linked article, you really should. It's amusing.
  23. https://newsthump.com/2021/10/12/blue-origin-crew-concerned-by-new-uniforms-ahead-of-shatner-space-flight/?utm_campaign=shareaholic&utm_medium=facebook&utm_source=socialnetwork&fbclid=IwAR21TTPhN9rK7WWOXFdA6kdIkTDptgBABCeWCvpLg5BzSSqq1OfeEdu0XHA
×
×
  • Create New...

Important Information

Please review our Terms of Use