Jump to content

rje

Members
  • Posts

    1281
  • Joined

  • Last visited

  • Days Won

    44

Everything posted by rje

  1. I didn't know there were fancy ways to load data into banks in CC65. I've been using things like this: // // Loads a file into banked RAM. // void loadFileToBank(char* name, byte bankNum, unsigned address) { POKE(0x9f61, bankNum); // r38 POKE(0,bankNum); // r39+ cbm_k_setnam(name); cbm_k_setlfs(IGNORE_LFN, EMULATOR_FILE_SYSTEM, SA_IGNORE_HEADER); cbm_k_load(LOAD_FLAG, address); }
  2. That sure does look like it to me, although *shrug* dunno for sure.
  3. I wrote text "compression" methods that are based on Z-text compression -- useful if you just need to mash text in a tight space without fancy algorithms.
  4. I'm probably not understanding, but: For the PSG, I think the biggest hurdle is the lack of envelopes. I'm starting to sound kind of whiny about it, which means I really really should TRY to do something about it instead of whining, but the API for a PSG-like thing is an essentially solved problem -- on the C64 that is. With envelopes, you could perhaps compose sound effects with fewer voices by varying the characteristics of each sound. I suppose an envelope could include tremolo and similar things... SuperBASIC, by Martin Kees, wrapped up SID sound commands into a very tidy, easy to use, and easy to experiment with syntax in BASIC: [SSND voice_number, ad, sr, wave, freq, pwidth "Set up voice" voice_number, with the given attack/decay and sustain/release encodings; wave with the standard wave value; a u16 value holding the frequency; and pulse width (when wave = 65). You're making me want to try to develop the envelope interrupt system again. Like Dusan did:
  5. Hmm now I have a picture in my mind of an RC2014 Classic II-like backplane/buss thing with X16 cards plugged in... including the VERA card... and using SPLDs or CPLDs...
  6. I wonder if a Classic-II style bus would work with a 6502-based project?
  7. That's interesting. I wonder what it's thinking it's matching in Debian? You can comment out that line (just insert a # sign at column 1) and the script won't suffer. For that matter, you can comment out lines 96, 97, 98, 99, and 100. Those are all semi-macros that I was playing with that just don't really matter.
  8. Just to let you know, a few of us have written scripts that will translate a "macro" version of BASIC on our home computers down to Commodore BASIC. Apparently we've all done this independently of one another, as well. Our reasons were: We liked using modern text editors to compose programs. We didn't want to use line numbers if we didn't have to. We wanted some convenience things that just aren't in X16 BASIC. There may be other reasons, but it's all about convenience and power. If you're interested, start a new topic, or perhaps go hunting for some of our topics (I don't even know where they are). Ah, you could start by searching on "My BASIC pre-processor". Just in case you're interested.
  9. Opinion is ... well you know how forums work. If I knew the 6502 well, I'd probably try it. I'm interested enough to want to do it, but too lazy to make all the inevitable learning-mistakes as I go. So when I voice an opinion it's ignorant of the technical solution. There's hardware needed to do this well. This all amounts to a large tech debt for me. But my opinion isn't business-based either. So, yeah, my opinion is not really worth much. We've all watched Michael Steil's video on speeding up the 1541, right? I watch that and I say that's what we need. But frankly the IEC port will mainly be used with something like SD2IEC or perhaps, if we're lucky, the Raspberry Pi IEC Mass Storage Device thingy that doesn't yet exist. So it has to play with them, and that's probably all it has to do.
  10. I always (almost always) did the GET thing. 100 ? "PRESS ANY KEY TO CONTINUE" 101 GET A$ : IF A$ = "" GOTO 101 :REM DE FACTO PAUSE Otherwise I would use input. 100 INPUT "PRESS ENTER TO CONTINUE"; I$
  11. Fabio, you're right though, and we have mused about how to best implement IEC on the X16. Since this is not a C64 clone, we're not bound by the ridiculousness of the 1541 disk drive, but rather the general IEC protocol... so we should consider burst mode and so on. That said, it's easy for me to say what "should be done," since I am not an assembly language programmer...
  12. rje

    My X16 Case

    Tom's comment is spot on, by the way. Mini-ATX is officially 244 × 244 mm. My vintage 'pizza box' has an internal open space that's about 330 x 240mm... which is narrow for a mini-ATX and might pose a problem. But there's still hope. The other side of the interior has the floppy drive cage and the power supply. If I removed them, then I'd have the entire interior for a board -- 330 x 380mm. Of course I'd have to de-rivet the drive enclosure. Not fun. But I could figure it out if necessary.
  13. Wait for the compact version that's the size and price of a Raspberry Pi, and then see if you've got the resources and room and desire for one of those.
  14. I don't. I will need something that's emerged out of the rigor of smart, capable, devoted engineers who know how to fix hardware issues as fast as they're found. I've debated whether I want the primary machine, but I think if I'm going to get one, I'll want one with expansion slots! I've also wanted to be able to fit one into my (vintage) ATX case. I think it'll fit after I (gently) remove the power supply.
  15. Unless VERA changed very recently, that's a misstatement. But maybe VERA changed very recently.
    Fantastic! It plays like a bona fide retro arcade game. The music track is peppy, the graphics are great, and the SCROLLING is smooth as anything. It's got just enough challenge to make me want to try it... just one more time... I'm sure I can get through the circuit without crashing... just one more try...
    This is really cute! I'm impressed by just about everything there so far -- the scrolling is nice and smooth. The graphics are engaging and not overdone. The characters are cute but not sappy. And the music has depth -- yes, it's a short clip, but it's not obnoxious. And.... and that airship. HOW DO I BOARD THE AIRSHIP AND FLY IT??? I want to know!!
  16. Bienvenidos Fernando! I'm glad you're enjoying the retro goodness!
  17. My commit levels have been at a lower level, but relatively consistent since December 2020 or so. I just seldom finish anything LOL
  18. Maybe. I'm also getting philosophical with how to do user interfaces. For example, there are different ways of presenting picklists. Horizontal is compact. Vertical could be used to indicate a more important choice (maybe). A scrolling picklist shows extreme economy and can look "cool" (assuming it also isn't annoying though). There's also the issue of list fatigue. If everything is a picklist, the user could get tired of seeing lists lists lists. Hick's Law "The more choices you present your users with, the longer it will take them to reach a decision." THAT makes me think that adding some wizard-like functionality at the beginning is a GREAT idea. AND there's one other implication: One-thing-per-page. This suggests I should always focus the content of the screen on the current task: if you are picking a jump drive, then I should only display the list of jump drive options on the page, and leave the clutter out. PETSCII is Horrible The reason PETSCII is actually not horrible is in the context. Since this is a retro-based program on a retro platform, the PETSCII look and feel is actually an asset. "visually appealing interfaces are better, faster, easier" Paradoxically, to a small extent, the PETSCII nature of this program is a visual appeal to retro. Nevertheless, usability is still important.
  19. I have little to contribute, except that I have worked with I2C on the RPi, gathering data from an ultrasonic motion detector, and a range finder. I found I2C on the RPi to be easy to work with, enabling fun. I've *seen* the SPI pins on the Pi as well, and I just assume it is also easy to work with. Because I'm not a hardware guy, I look for Ease Of Use when it comes to hardware projects. I can solder a header onto a Pi, if I'm careful. That's about my limit.
  20. This is a UX-style issue. The trick in UX is finding how best to manage inherent complexity for the user's benefit. I'm asking for UX suggestions with a base assumption that this is PETSCII on the X16. The rest of this post supplies context. --- I'm writing a game utility -- a design-your-starship utility for the Traveller RPG. And I'm doing it in PETSCII on the X16, because that combines two of my favorite things (Traveller and the X16) into one effort. Starship design is underlaid by a set of line items, each item a component in a ship. Each component is selected from a picklist. Thus a ship design minimally comes from ~12 picklists. I want to design an "ergonomic" interface for picking from those picklists. Define "Ergonomic" Ergonomic, I think, has to do with how the picklists are presented to, and accessed by the user. There is also the consideration of showing "progress" in the ship's design, kind of like ticking off items in a shopping list. Ergonomic ALSO has a lot to do with colors and empty spaces, and I am TOTALLY up for suggestions there! Mockup With Data A picture paints a thousand words. Here's a working mockup. On the right of the screen-shot is the "worksheet" with the current state of the ship being designed. On the left is where I'm trying to decide what to do. This mockup shows a "master picklist" of component categories; presumably the user would select which component to work on, and program control would shift to a form based specifically on that component. But there are other ways to do it: for example, the "master picklist" could in fact represent larger areas representing multiple choices -- for example, maybe there's an "engine room" choice that lets you manage drives and fuel, then a "defenses" choice for weapons and shields, and so on. I've attached that as the second image. Something I don't think I can do is allow EVERYTHING to be choosable from one menu. There are too many options for that -- hence, design has to be broken down into sub-areas. Maybe it's just a matter of organizing those sub-areas into menus in a rational way that supports the user's thinking process.
  21. Very true. Now, $300 still sounds like a lot of money for the project, and I'm always looking for the cheap angle. I'm still thinking about that Raspberry Pi 1581 emulator.
×
×
  • Create New...

Important Information

Please review our Terms of Use