Jump to content

rje

Members
  • Posts

    1235
  • Joined

  • Last visited

  • Days Won

    41

Everything posted by rje

  1. Gotta have Catalina. I upgraded just so I could run the r39 binary. I thought about building, but got lazy.
  2. Uh oh! Let's find out if my code is banking correctly!!
  3. I have a 400K data file I load into banked RAM. I've adapted nicely to using banks -- I can externalize a lot of data that way.
  4. At the time of that video, I wonder if the system used Bank 0 yet? If not.... I wonder if I/O could be shoved into an upper slice of Bank 0. On the other hand, that would make I/O less friendly. Although it could enable a 256 byte window into VERA.
  5. It was -- I seem to remember 8-Bit-Guy's second video laying out his suggested "flat + banks" memory model. The constraints worked like this: the design allows a banked 16K block to switch out "KERNAL + BASIC ROM", so that's $C000 to $FFFF. In retrospect that is a smart and potentially useful move. Then he has the 8K banked RAM window. That's $A000 to $BFFF. The only room left for I/O is either high or low main RAM, because he didn't want to bank that. Here: at time index 7:16 in his video
  6. rje

    Fast IEC ?

    I've downloaded and started browsing the SD2IEC codebase, and I agree that it's a wealth of goodness. I'm still wading through it all. At some point I'll grok it enough to try some things.
  7. rje

    Fast IEC ?

    I might also just look at pi1541 after all. If the exact emulation part isn't tightly coupled with the signaling logic then maybe I can rip out the 1541 specifics and have an IEC device there. Rasbpian on a Zero of course isn't fast enough. But I'm trying things out.
  8. rje

    Fast IEC ?

    The X16emu builds very nicely on the Raspberry Pi Zero. When I get a free moment, I'll hook the pi up to my monitor and see if it has enough oomph to render the screen. I suspect I'll have to move to the RPi 3.
  9. rje

    Fast IEC ?

    I currently like my "Meta-Plan #3" below. "Less Relevant" Meta-Plan #1. Build it on something else first. * Implement IEC controller code on a RPi Zero or Pico or ATMEGA or hardware-of-choice. * Test it against an SD2IEC or a real Commodore drive. * Not completely sure what this would accomplish, except for being good practice. "Not Testable" Meta-Plan #2. Build in the code. * Implement IEC in the X16 emulator. Write a socket adapter layer, loosely coupled, to emulate the lines, perhaps (?). * Implement an IEC soft-device from VICE or SD2IEC or whatever. * This would get code into the KERNAL, albeit emulated. * But this is not testable without heavy lifting on something like VICE. "Not Fast Enough" Meta-Plan #3. Put the X16 Emulator on a Raspberry Pi. * Port the X16 emulator to the RPi or equivalent. https://snapcraft.io/install/x16emu/raspbian * Write the IEC code on the X16, using a GPIO adapter layer for physical lines. * Test with SD2IEC or a physical drive etc... if fast enough... ^^ I like this one, except for likely speed problems.
  10. HOWEVER, if we really want to pull together in order to push this over the finish line, I know of one thing the X16 lacks and needs, and that's the IEC interface. If you really want to get the X16 closer to the finish line, then let's organize, elect someone foreman/referee, present your skillset, let him consult with the rest of the team and organize the features that need to be done, then the team breaks the features down, sizes each story, and delegates them out. That includes figuring out how to test them with the emulator. Perhaps on one of the dedicated IEC threads.
  11. Money goes fast. Surprisingly so. There can be so much more to a big project than taking a couple weekends with some electronic components ordered from Mouser and an oscilloscope. Especially if you have a particular vision. So does time, especially since life is complicated. And then if you have to coordinate with a few other volunteers. Do I have to mention how volunteer projects are different from work?
  12. Or we implement it with random TTL in our cabinets. What's a few million 2n2222's?
  13. I'm fine with whatever 8BG wants to do re funding. He's talked about it, too. I suspect the issue isn't money, but rather other resource needs, such as time and prioritization and organization. We can't really buy time. We can't really prioritize things for the principals. We can't really organize them. But I think your question is more like "what can we do?" ....and I think the answer is, do what you can, until we know more. If you want to collaborate on a project around the X16 (emulator...), I'm interested, and others probably are as well, but the trick is Project Management, not nerd skillz. Matching skills up Organizing a project Followthrough.
  14. This sounds pretty good, I think! If I understand it, you're wrapping direct commands to the sound producers with some control headers. The library decodes the flow control headers, and therefore knows how to inject the (sound) instructions directly to the target hardware. I'd have to read more to see how to use it, but it sounds quite promising -- something I would want to use. A missing bit of the toolchain. ** It sounds like the toolchain requires me to first encode the sounds using another tool. This implies that I *have* those sound samples in the first place. That makes sense for music (although I don't know how I'd do it). What if I just want to make sound effects with the PSG? Do I have to first create sound samples of them, and if so, how do I do that? Because of SID experience, I am very familiar and comfortable with creating effects by directly specifying settings. Is that something that can be easily packaged into a ZFX packet?
  15. And what software is there, is specialized to support the system. In other words, a necessary evil, if you would. Every component affects the price -- in fact it looks as though the number of components is in a linear relationship to the price -- but we already know that the point isn't to minimize price. My hope is that price is cheap, but their goal is for a platform, conforming to 8BG's vision, that will support and thrive in the 8 bit retro ecology.
  16. It's at "Create a simple video controller with a FPGA — Stefany Allaire" on Youtube. This is from VCF East 2021, day 1.
  17. I know "usability" is hard to argue for in an 8 bit system, but I think Michael and Frank honored the system while also improving it. Here's two subjective examples. 1. Michael added the ability for BASIC to translate hexadecimal values. I have used this a lot when writing sprite and PSG code in BASIC. In other words, it improved my experience and as a result I wrote more interesting BASIC code, which exercised the system more. 2. Frank added the PSG to VERA. As a result, I wrote, in both BASIC and C, code that generates sounds on the X16. I wrote a thing that plays "Invention No. 13", and then did some sound effects. I'm more likely to try to finish some of my games because I like the PSG. I started babbling about an envelope manager, even though interrupts scare me the way Alien scares me. Thus the X16 benefits at least from me writing code that exercises the system as a whole. Their adds didn't break the hardware. They didn't break the software. And they didn't have essential X16 tasks to do (that I know of). They added things that made it funner for us to exercise the system as a whole, and by bringing usability up, they encouraged me to exercise the system more than I would have. Testing is always a problem. But the more you make testing part of the creative process, the better tested the X16 will be.
  18. We could do a Geek Bits episode on this. This is me thinking about what Feature Creep is. It's related to: Parkinson's Law of Triviality: the amount of time given to a task is inversely proportional to its overall importance. *** In other words, two signs of "creep" is that: #1 a feature is not essential, and #2 it is sucking resources from getting the essential things done. *** With respect, the features added are not really feature creep. I say this because #2 is not in effect... especially in efforts that are driven by volunteer hours and the areas of expertise involved. It's even possible that, in adding these things, usability has gone up, and as a result, the system as a whole is getting exercised more than it would otherwise. It's not a paradox: craftsmanship drives usability. Now, if Frank had replaced VERA with a new FPGA with different requirements, yeah that would be feature creep. If Michael had completely replaced his CBM-DOS with the MEGA65 DOS, then yeah that would (probably?) be feature creep. If 8BG decided to add a USB hub, a UART, dual SID chips, and an IEEE-488 parallel bus just because they're cool, then yeah that's feature creep. *** I wouldn't even say that using a more capable microcontroller in order to grab keyboard input is feature creep -- the idea is getting a keyboard to work; therefore, do what you have to do. The thing is, Michael and Frank are essentially done with the bits they wanted to do. Thus any non-breaking things they squeeze into existing resources are icing, and not creeping. It's a sign that they enjoy the ecosystem enough to improve on their work, and craftsmanship is a very strong signal of interest and high quality. I could be wrong.
  19. Ideally I would like to collaborate. I can do some things well and some things badly. If your skill set is complementary, then theoretically we should have a better chance of getting something interesting done. And Tom has two good ideas.
  20. YES, I am/was aware of it, and had forgotten. Thanks!
  21. In this thread I want to discuss writing a hunk of C code for the Raspberry Pi Zero that can talk the IEC protocol. *** My biggest question is HOW CAN I TEST SOMETHING LIKE THAT? I have no clue. *** I want to start by using Debian (Raspbian), for example. In other words, start simpler. Also, this way it is actually possible that I might be able to write a proof of concept, because I can program applications that talk over GPIO. In other words, there's an actual possibility that I could write a prototype that kind-of works. *** I suggest the Zero, just because I want to start with the least-capable Pi.
  22. rje

    Fast IEC ?

    Michael Steil did a video on C64-to-1541 optimizations. He puts an absolute speed threshold between the C64 and 1541 at 7.5 Kb per second. This assumes using a real 1541 -- which has multiple bottleneck problems -- and old illegal 6502 opcodes that I think are removed in modern 6502s. 1. THE X16 IS NOT A C64 The nice thing about the X16 is that we can to some degree dictate the flavor of IEC that we support. 2. THE IEC PROTOCOL IS "DOMINATED" BY SD2IEC The less-nice thing about the IEC protocol is that THE go-to device is the SD2IEC, so we are tied to its limitations if we expect any sort of plug-and-play accessibility for the X16. Put another way: custom solutions suffer from availability bottlenecks. 3. POTENTIAL SOLUTION BASED ON PI1541 That said, the PI1541 is open-source and cycle-exact. A smart fellow could potentially gut the cycle-exact bits and produce a "fast" PI IEC device. It would have to be something like a PI because of pre-covid availability. Granted today everything is hard to get, but that will abate.
  23. rje

    Fast IEC ?

    So here's my Fast IEC + SD2IEC thread.
  24. Note that since the X16 is not a C64, it doesn't have many of the performance bottlenecks of the C64. It has to be able to talk to an IEC device, yes, but it can send a fastloader to said device. Binaries are not C64 binaries and so a fastloader won't have the software compatibility problems that C64 fastloaders had. Unless I am mistaken of course. Here's one place to start talking about that.
  25. My X16 WASD has clear switches. They do make some noise, but they're not obnoxious.
×
×
  • Create New...

Important Information

Please review our Terms of Use