Jump to content

John Chow Seymour

  • Content Count

  • Joined

  • Last visited

Everything posted by John Chow Seymour

  1. Growing up in the 80s my house had an Apple ][e and my best friend's had a C64. But, sitting unused in one corner of the 'office room' at that friend's house were two slightly older computers that I didn't really appreciate until it was too late. One was a HeathKit that, supposedly, his parents had assembled themselves. The other was a CompuColor. When I was 6, my father had bought a decent-quality VHS camera, and by the time I was 10, I was using it to film home movies, usually sci-fi stories starring my stuffed animals. So, when I got word that my friend's family was throwing out their old computers, I asked if I could keep the keyboard to the CompuColor, because it was really cool-looking, and I thought I could use it as a prop in my little movies - as the bridge of a spaceship, or something. Alas, and to my eternal regret, 10-year-old me did not foresee that 40-year-old me would have a hobbyist's interest in old computers, so I didn't ask for the computer part of the CompuColor, just the keyboard! But it is cool looking: Look at all those keys! Although the keyboard unit is as thick as a C64 breadbin, it contains only the keyboard: the guts of the CompuColor was built into the monitor. The 'gimmick' of the CompuColor is that they built the computer to fit inside an already-existing line of color TVs, with the front control panel of the TV replaced with the disk drive. From what I've read, turning the CRT monitor on or off created an EMP that would wipe any disk in the drive, which was positioned right next to the CRT. To counteract this, they simply put a line in the instruction manual telling user not to have a disk in the drive when turning the monitor on or off. Solved! I don't know how I've been getting along all these decades without a dedicated BL/A7 OFF key. The idea to have (apparently) dedicated keys for certain common commands is interesting. Apparently "poke" is too hard to type, so let's give the user a "poke" key? At least this way one can literally poke 'poke' with one's finger. Still kicking myself for not asking for the monitor+cpu unit. It probably ended up in a landfill, what a shame.
  2. I can see how "retro" might mean ''actually old' or 'in the style of something old', but surely "vintage" only ever means 'actually old.'
  3. I get where Matt's coming from, but I disagree in this case. I think you can make an 'engine' for the kind of game you describe, right in BASIC, without really adding another 'layer' of interpretation or slowing things down too much. (Keep in mind, speed doesn't matter much for a text-based game like this.) In BASIC, your 'engine' would be a bunch of subroutines that handle the common tasks of your roleplay system. For example, if your game has combat, you might have some subroutines that handle what happens when a player attempts to attack an enemy. One for handling how the player selects what kind of attack to do, another for handling how the player selects which enemy to target, another that resolves the attack and assigns damage, etc. Other subroutines might handle buying from a shop, equipping armor and changing the player's stats accordingly, branching with dialogue trees, navigating from room to room, etc. Then when you go to write a new chapter of the game, you re-use all those same subroutines, but have new enemies, equipment, room descriptions, etc. Admittedly this may not be what's typically meant by an 'engine'. But it would be a set of tools that you could use over and over to make new games in this genre. Of course, this is exactly how you would do it in Assembly as well, but BASIC will be easier to learn as a programming language. The downside to BASIC is that it will always run more slowly compared to Assembly, but for a text-based game like you describe, speed really won't really matter. Speed starts to matter when you want to have graphical gameplay.
  4. I don't know... yes, there are revisions where the SID is just below the processor (or, from the point of view of the camera, to the left of the processor). But in this case, I think that's probably the PLA. If that's not the PLA, then which one is? Looks like there's an unpopulated spot next to that chip (toward the camera) that would've had the SID. I'll have to watch Robin's video later and see if he mentions it.
  5. A Phase 4? The 'X16h'? (since p for pocket is already taken, maybe h for handheld)
  6. 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$.
  7. 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.
  8. What a neat thing to still have around. Was that a free gift when you signed up for their service?
  9. 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.)
  10. 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?
  11. 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.)
  12. 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.
  13. 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.
  14. 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!
  15. 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).
  16. 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.
  17. 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?
  18. Oh, I didn't know it would cost more. Grey it is!
  19. 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).
  20. I have no interest in a GUI for the X16. It's just not that kind of computer. That said, part of what's fun about the X16, for hobbyists, is to tackle various difficult programming challenges. If someone (or a team) wanted to make a bespoke X16 GUI, I'd probably follow the project's progress with interest, even if I never actually used the end product. Do it for the challenge!
  21. Thank you for teaching me that! So, the Mega65 page at C64 Wiki says "Dual soft-SIDs + dual 8-bit DACs". But, the Mega65 page itself says "four soft SIDs (and the ability to use hard-SIDs in a cartridge) plus four-channel stereo 16-bit digital audio." So I guess sound design is still being decided in that project as well.
  22. I agree with the general sentiments in this thread so far. The community, the simplicity, the price, etc. A few points to add: I enjoy soldering. The X16 will ("99% sure") be available in kit form; looking at the Mega65 it seems unlikely with all that SMD. Yes, soldering your own computer is impractical. But this is a hobby, it's okay to have fun doing something impractical. I want something really cool-looking on my desktop. (I almost bought a Spectrum Next just because of how great that design looks, even though I don't know Z80 assembly and have no Spectrum nostalgia.) I know the clear Mega65 is only a developer prototype, but I really don't like that beige render they have on their website now, either (with the disk drive sticking out the front!). The X16 is going to look great, though, especially with the custom keyboard with the PETSCII characters. Moving on: Wait, the Ultimate C64 runs at 48MHz? I don't remember that from Gideon's website, so I checked again again just now and I still don't see anything about CPU speed. I assumed it emulated the C64 at the usual speed. Last I heard, SID emulation was not a sure thing in the X16. The FAQ still says there are "3 designs being considered and tested." Or, did I miss some more recent news about that? I'm sorry, what?
  23. Just think, if you install something that can run a flight simulator, you can: in weather too poor to fly, sit in your actual plane and pretend you're flying try taking off and landing the real plane and the simulated one simultaneously (Note: if you try this, I am not responsible for any accidents) tell your friends your ride got pimped ("Yo Dawg, I hear you like planes, so...") post "aerial photographs" that are just screen grabs of the simulator. "But they were taken from a real plane in flight!", etc. I'm sure someone will make a flight sim for the X16; I think that's your best bet. That plane looks awesome, by the way. Best of luck with this whole project. Keep us posted.
  24. My computers' desktops are not very interesting, and have too many file names I'd need to hide or blur out. I change the photo with every season, right now it's an autumn scene. But here's my physical desktop: The actual desk is a glass door that was once one of a pair at the entrance to a men's wear shop in Detroit. My grandmother worked there, and when the storefront got remodeled my dad had the idea to take one of the doors to use as his worktable. He used it for many decades for his hobby of repairing antique clocks. I inherited it when he moved across the country and couldn't bring it, and now it holds my various computers. The C64 I rescued already had that weird after-market plastic cover over the keys (it flips up). I hated it at first but, to be fair, it does keep dust and sunlight off the keys! Barely visible (not very well lit, under the window) is the PE6502 kit. Not sure where I'm going to fit the X16; probably under the desk. The case is so pretty though, I might have to make space up top.
  25. While not exactly what you want, you might also check out Space Brothers (Uchuu Kyoudai), set in the very near-future (2025) and focusing on JAXA (Japan's space program). The tech level is realistic, and it's well-written, but it's more about the people than the tech. And, well... I can't recommend it, but there's also Ubunchu!, in which a high school computer club decides to learn about Ubuntu Linux. It's now over a decade old and out of date (can't watch YouTube on Linux, what?), but besides that it just isn't very well written. It's kinda lame in my opinion but you can always decide for yourself: https://mangadex.org/title/24228/ubunchu
  • Create New...

Important Information

Please review our Terms of Use