Jump to content

John Chow Seymour

Members
  • Content Count

    55
  • Joined

  • Last visited

Community Reputation

39 Excellent

Recent Profile Visitors

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

  1. A Phase 4? The 'X16h'? (since p for pocket is already taken, maybe h for handheld)
  2. That makes sense. In my case, I never stopped the program to go do something else, I just shut off the monitor and let it run, and checked back at the end of the day. So it's possible that the act of running the clock loop itself is what incrementally bogged down TI$.
  3. Neat, thanks for sharing this. I tried it out on my C64 just now. I'd never worked with either the TOD clock nor with TI$ before, so it was interesting to see the different ways you had to handle them. Incidentally, line 130 as-written is 81 characters long, so I simply broke it up. I also modified line 1090 like so: 1090 PRINT"{CLR}";:RETURN Which clears the time-setting text before running the clocks. Now I'll leave it running for a bit and see how the two clocks do. EDIT: After about 10 hours, they've diverged by about a second. It appears that both have lost time (slowed down) compared to the clock to which I set them (on my modern computer), but the TI$ version has fallen only slightly behind, while the CIA's TOD is now over a second behind. This has been interesting, thank you for bringing it to our attention. I wonder how time like this will be handled on the X16.
  4. What a neat thing to still have around. Was that a free gift when you signed up for their service?
  5. So which setup did the NES have? Its CPU is a 6502 variant, and the other main chip is its "PPU" ("Pixel Processing Unit"). But was the PPU a second processor, or was it more the 'fixed-function hardware' approach? (Based on what I know about NES programming - which is only very little, only from reading - I'm guessing it's not its own processor, since it seems like the main CPU has to spend a lot of time on the graphics leaving game logic crammed into vblank. But I haven't studied it that closely.)
  6. Ugh, I know from past experience that keeping spam off of a forum can be frustrating and exhausting. I'll PM you about that other stuff. In any case, hopefully your comment at the start of this thread will help people think more critically about production. Between this forum and the X16 Facebook group, I've seen a lot of comments, criticisms, or feature requests from people who clearly haven't thought about how their request would impact the cost and feasibility of production. Hopefully reading some advice from someone who's been there will get people to think about that side of it more. That said - it is possible to machine-assemble a board with through-hole components, right? Anyone know more about that?
  7. Hi Jason! Another one of the hundred-and-fifty PE6502 users here. I didn't realize you'd stopped selling them -- hopefully that is only temporary. I'm glad I bought mine when I did, I'm quite happy with it. That automatic serial connection as a storage solution is just wonderful. (I'd get more use out of it if I could figure out how to get the CPU to address the GPIO header; then I could use it for breadboard experiments. But I've been hesitant to ask about it since I know you're getting burnt out on support and I didn't want to bother you.) In any case, it's good to hear from you and I'm glad to see you're a member of the X16 community as well. Anyway, my understanding is that most X16s will be sold preassembled, even the "X16p" model which has through-hole components. We've been told that unassembled kit versions will be available, for those crazy few of us who want to solder together our own computer. (Hey, my PE6502 worked after I put it together! I mean, not the first time I turned it on, but I eventually got it working ...and without having to bug you for support. I'm sure the X16 will go just as unsmoothly, but will be just as rewarding.) But for the majority of the X16p, even with through-hole, assembly will surely be automated, right? (I'm not on the design team, but I didn't picture David forcing his whole family to solder X16s together by hand in their spare time.)
  8. Wow, I've never seen a BASIC with double-underscore keywords before. That's more d'unders than Python! FreeBASIC looks pretty awesome. The world needs a better 'modern' BASIC than MS VBA. For the reasons others have mentioned, it wouldn't be a good choice for the X16, at least not as the built-in BASIC. Porting a processor-appropriate version of it might be a fun challenge for someone, though.
  9. I'm also considering spending my Christmas bonus on either an Ultimate II+, or an Ultimate 64 board. When I rescued my C64 out the trash, there were also two empty breadbin cases in there - no board, just the keyboard with top and bottom shells. So it needs a board to go in it, right Why not an Ultimate 64? ...well, because they're over USD$200. Money well spent on such an excellent design, but on the other hand maybe I should save that money and put it in my X16 jar. I don't want to be caught short when the Kickstarter launches.
  10. Anyone know any good podcasts about 8-bit era tech, or retro-oriented projects like the X16, Spectrum Next, etc? (Soon I'll be doing some work that will lend itself to listening to audio content, so I'm looking for some good ones.) Web searches turn up a lot of options, and I may audition a lot of them - but I'd love to hear recommendations from this community as well (feel free to plug your own, if any of you make them). Thanks in advance!
  11. Yeah, I strongly agree with all the points in this post (and not just the part I quoted). With later, fully developed MIDI systems which can have polyphony on a single channel, the piano roll does make more sense. But we're not looking at that here; and as @m00dawg describes, trackers let you more directly control what goes to which channel of which chip. You could still make it work on a piano roll; if you understood it would show one monophonic channel at a time, and there were an easy way to switch between which channel is being displayed. Is anyone even working on a mouse for the X16? Hey, we get SNES controller ports, right? Maybe you can make your music app compatible with the SNES mouse. (This is a joke, please don't actually do that: SNES mice are hard to find and awful to use.) I guess there's always the strategy where the D-pad (or the arrow keys for that matter) move the cursor like a mouse, instead of moving from one discrete screen character to the next. As much as I dislike the tracker-style interface, as much as I would rather see @kliepatsch make a piano roll, the more I think about it the more the tracker is starting to make sense. If you can find a good way to break the tracker out of its tendency toward (at least visually) locking the user in to a rhythmic grid, then maybe that's the best way after all. In any case, I wouldn't really get started until we know which sound chips we're getting. The FAQ is still vague about it. I mean, you couldn't even plan how many columns a tracker would have, or how many data points you'll need under the piano roll, until we know which chips we're even programming for. EDIT: @TomXP411's sketch is really good, I like the look of it already. I think you'll want to sacrifice 1-2 more rows in order to add a label to the X-axis (that'll be especially important if you manage to implement zoom).
  12. I'm with several other commenters here in that the tracker format tends to lock one in to square rhythms. One thing I very much value about piano roll views is their scalability: it's nice to be able to zoom in and out, both vertically and horizontally. Not sure how difficult arbitrary zoom will be to implement on the X16. The tracker interface generally doesn't need scalability across its tracks (that's horizontal in a tracker) but if someone could develop a tracker that's zoomable in the rhythm direction (vertical for trackers), and thus allowed for fine rhythmic granularity so you're not locked into a 16th grid, such a design might be the best of both worlds. I mean, right now some trackers have ugly solutions to the problem of getting out of the grid like a 'delay' property; you can enter a note event on what visually looks like beat 1 but also add a delay property that pushes is back to the middle note of a triplet. This is awkward to use and not a great solution. So yeah, as you design your interface, be it tracker, piano roll, or a hybrid, definately think about the ability to zoom in and out. On the other hand... the gridlike nature of the tracker interface may feel limiting, but it is also a sensible solution for a computer with keyboard-input and character-grid graphics (as many 8bit computers had). A zoomable piano roll system may seem nice, but may also be very awkward on a system without a mouse. Me too! The flexibility of the old Cakewalk was just great. I actually first learned to compose music as a kid by trying things out in Cakewalk Home Studio for Win 3.1 - I didn't know there was a DOS version until you mentioned it just now. It used to be, Cakewalk was the software, made by a company called Twelve Tone Systems. Then for a while, the Company name became Cakewalk and the software was called Sonar (as your article covers). About two years ago, the IP was bought by a startup called BandLab and now the software is called Cakewalk again. This modern version is my main DAW. Elements from the Win 3.1 version that I learned on, which were excellent interface decisions, are still present in the most recent version. (Their "Staff View" in particular is well designed: it allows people who are used to reading staff notation to do so in a MIDI sequencer, but it understands that its goal is sequencing and NOT notation; this has always made it better to compose in, in my opionion, than the dedicated notation programs like Finale or Sibelius. Too bad staff views are such a bear to program, or I'd recommend that to @kliepatsch) Not to get off track in the thread, but what strategy/hardware are you using to use the NES as an instrument? I've been looking for a good solution for that.
  13. I wonder how the faster CPU speed affects the use of the SoftSIDs. I have not done any work with SoftSIDs or with a SwinSID - I've only ever worked with the original SID in my C64 -- so, 1MHz. The SwinSID page at C64-Wiki says it can be clocked at up wo 32MHz, but with only a historical C64 to plug one into, I couldn't experiment with running one that fast even if I bought one. I can't seem to find out any information online about the possibilities of running SID clones at fast clock speeds. It seems like it would open up new possibilities... maybe I'll have to buy an Ultimate C64 and just do some experiments myself. But that would take money out of my X16 fund! When you write about needing to drop back down to 1MHz for I/O, surely that doesn't include audio and video I/O, right? I mean, can you only ever accelerate for offscreen calculation?
  14. Oh, I didn't know it would cost more. Grey it is!
  15. Oooh, nice. Those "half-height" keys are often my favorites. It's going to look great with the color and PETSCII symbols. EDIT: Please consider making blue, rather than grey, the secondary keycap color. But honestly it looks good even with the grey (in that render in the last pic).
×
×
  • Create New...

Important Information

Please review our Terms of Use