Jump to content

rje

Members
  • Posts

    1079
  • Joined

  • Last visited

  • Days Won

    34

Everything posted by rje

  1. Yeah. It's not any one particular thing that makes this seem painful. But it's every little thing. The bit-packed fields. Well I can manage that with bitfield structures, so that solves that problem. The VERA byte increment. That's the fastest way, but it's just another thing to do. Then there's the sprite updating. I'll update the X and Y values, so that's just setting the increment and then loading the four registers -- and maybe that's OK. I don't know, maybe it's just my old brain, and I'm used to -- well I *was* used to the C64. Which was sooooooo limited, I won't go back.
  2. I guess we could fix GET#. Meh, probably not.
  3. With me, it's a kind of reluctance to write VERA sprite code in C. That's my next project. We've got examples. It's not like there isn't any code. But there's something about it that just makes me wince.
  4. I think Tom's right. The Commodore 65 was far too late, but even the 128 was too late... Commodore just hadn't realized it yet. DIGRESSION I suppose Trameil sowed the seeds of his own destruction when Chuck Peddle was sent packing... Chuck saw higher-tech business machines as the future, and Jack saw a cheap game console in every home. (Of course the C64 WAS that cheap game console, so what do you do after you realize your dream?). Granted the Atari ST was a great system, so maybe I'm missing something there. OK BACK A 68K would have helped, quite a lot. And Tom's plan seems like a good possibility. Now let's get to work on that time machine.
  5. Mr. Heffernan has shown us that posting videos works well for explaining concepts, and I can see some concepts with Commodore BASIC that would benefit from a video or two. But if I'm going to follow along with a programming language, I'm going to read it, not watch it.
  6. I could swear I saw an easier way to handle those nulls. Ah something like this: ... 120 GET#8, A$ 130 A=ASC(A$ + CHR$(0)) :REM NULL PROTECTION PATTERN 140 IF ST <> 0 THEN 200 ... Here's where I found it, this time around. I think I've also seen it on the "C64 Programming" Facebook page. https://www.lemon64.com/forum/viewtopic.php?p=181978&sid=5e9b35d1a6b8e77a89c45bb383be70cf#181978 Quote: 30 print asc(t$): rem display the byte in ASCII code Make that Code: 30 print asc(t$+chr$(0)) so it won't barf when it encounters chr$(0) which get# returns as empty string. ===================================================================================================== * Upside: terser code. * Downside: string cat is probably slower. * Downside: might encourage the garbage collector to run. ^ So, good for small files, bad for big files?
  7. rje

    My X16 Case

    LOVE the Mister Wedge!
  8. You're welcome. And thank you review team! It's been decades since I did any file ops on Commodore equipment. Note that there's an "input pattern" required if you're expecting to have null values in the data stream -- I can't quite remember it, but I think it involves injecting a chr$(0) into the input to safeguard against it.
  9. Actually the process seems pretty thorough, to the point where anyone's work can be checked and tool-verified (by their metrics) to be "clean" -- again, by their metrics, which seems reasonably conservative.
  10. https://github.com/MEGA65/open-roms The Mega65 team were serious enough to document their goals, their process, build a repo, and start. I’m going to cruise over there and see what’s what. A project to create unencumbered open-source ROMs for use on selected retro computers. Besides this manifest, the following documents are available: implementation status of various APIs and functionalities configuration options for those willing to compile their own, customized ROM set BASIC extensions development guide for those interested in technical aspects license information and list of major contributors credits to people whose work was of great help to us To download pre-built ROM images, go here. Bruce has noted that our goals are simpler (although I hope still compatible): Can that be a separate compile target, or does it have to be a fork, or can it be something in between?
  11. Mega65 has a repo started for this, and a defined process to ensure IP is not violated. I was excited to see this, even though it’s not a priority. An open source KERNAL ... seems to have a lot of appeal. https://github.com/MEGA65/open-roms
  12. You know... his question got me to thinking about the relative value of 7400s versus CPLDs, and how different digital logic is today from back-when. I guess there's still value in doing it with 7400s.
  13. Oooh, the "Pros", and the "Antis". Not the first political rift here!
  14. Except for all the little bits that could be combined into a CPLD -- perhaps.
  15. I'll try to be more touchy and obnoxious.
  16. Imagine a VERA card for the PET. Someone already mentioned a VERA for the VIC-20.
  17. Ah, well, the first thing I should do is look at the x16-demo repo, since it has a cc65-sprite directory.
  18. I agree that the X8 sounds like a threat to the X16, AND that that's no reason to kill or cripple the X8. * 12 MHz, USB, and wifi? Where do I sign up? It ain't going to have an expansion bus, or a different memory model, or a crippled clock, or anything different than what it is right now. And that's okay. --- As for the X16. I've been coding on the emulator and I like those RAM banks. I REQUIRE at least 10 RAM banks for Core War (it uses a dynamic playing field taking up 80K RAM). I WANT to use ALL of those RAM banks for Traveller Trader (yes I could use files, but it already works as one gigantic 380K map so...). There is at LEAST one good use for those RAM banks, and at least two reasonable uses. And I "need" every spare byte of VERA RAM, because sprites just take up so much space. As a Neanderthal, I also do not fully trust flash drives to survive heavy use constantly. So when I'm running Ultima Retro II on the X8, I will be hearing tiny screams as the flash memory gets read and written to as the game churns through that gigantic map, fully expecting to waking up one morning and having it just be DEAD. On the other hand, since the X8 is the Raspberry Pi / Game Console version of the X16, that's not a problem. When I'm playing Cloud Diver Saturn, it's just one file and there's no save game, no complicated map, just a lot of twitch, so that's perfect for the X8. But if I want a machine for running The Seven Pirate Kingdoms of Gold, I'm reaching for the X16. Although I can't avoid saving state to disk there... I do agree that the Yamaha and SNES and PS/2 aren't my cuppa. But they ARE David's cuppa. So.
  19. Probably a dumb question. I've done VERA sprite programming in BASIC, and now I logically want to do it in C with CC65. I will peek through the X16 library for CC65, but offhand is there any convenience stuff for doing this? Is my C sprite code going to end up looking like my BASIC sprite code? I've loaded a font file directly to VERA in C, so I figure I can do that to load sprite data directly as well, right? Anything else I should be considering?
  20. Mmmm, fried potato! Don't get me wrong: I've soldered things before. I've even soldered things within the last three years. But they were 5-pin VL53L0X units, and a few Raspberry Pi Zero headers. But... solder an entire X16? Me? Fail!
  21. I guarantee that at least one person on this forum is a coder who would be terrible at getting an X16 kit working.
  22. I think the MEGA65 was using that critter early on...
  23. Ah, right! you know, I guess I just never expected to see that term in the x16 context.
  24. I’m writing games in C. Does that count as BASIC or assembly? XD While I totally grok FPGAs, I prefer not to see them. HOWEVER, I have fewer compunctions against a CPLD, even though it limits hardware hackability.
×
×
  • Create New...

Important Information

Please review our Terms of Use