Jump to content

rje

Members
  • Posts

    1080
  • Joined

  • Last visited

  • Days Won

    34

Everything posted by rje

  1. 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.
  2. In your library, what the heck is a widget? Is this another word for sprite?
  3. Long before, from the beginning, I wanted the X16 board without a case. Because.... I already had one. My old 386sx’s case, a 1U-sized (CORRECTION: 3U!) “pizza box”, is one of the few relics I’ve kept from my distant past. This beast, made of battleship-grade steel, has two 3.5” bays and a generous interior, quite sufficient for any version of the X16. Or an X16 plus an X8. And the X16 is totally so worthy of this case.
  4. I’ve been feeling that lately since writing C for the X16. Memory goes fast. There are two solutions though: 1. More RAM; that is, the RAM banks, which are fun to use! 2. Fast I/O if the SD card on the X16 is fast enough, then you don’t need RAM banks.... in fact even with RAM banks, if I/O is slow, loading up the RAM banks is painful in at least some circumstances.
  5. I started thinking about that too. I think the speed boost but the slight incompatibility and capability reduction (if that’s the term) creates two ecosystems for the price of one. Performant code — faster games and perhaps even a 3rd gen interpreter - use the X8. Bigger, perhaps more resource demanding code, as well as expansion based code, would use the X16.
  6. This at first sounds neat, but then I realized it would change how I code for the X16. I would code for only two banks.
  7. ^ Clever idea. I seem to remember hearing about a riser-like thing for expanding the expansion ports out, so to speak, way back when.
  8. That sounds like Patreon to me. I just doubled my monthly Patreon donation to you... well from $1 to $2, ha! Is that the right kind of help? If it's a matter of "need the money now", I could just bump it up for a month then settle it back down.
  9. Oh! I didn't quite understand your post, although it all read perfectly fine. That's my fault. 12 hours after first reading 8BG's post.... I now think that Phase 2 / 3 / X8 should be all about Ecosystem. I think that means the X8 is a true distraction, Phase 3 is emulation, and Phase 2 *could* boost the ecosystem.
  10. This is exactly right. But Phases 2 and 3 aren't *really* his Dream Computer, either.
  11. Ecosystem is in tension with hackability. Let's say Dave can move 1 kit a week and still have time to do everything he normally does. Say half are pre-assembled at a premium. That's 50 kits a year. Phase 2 and 3 are for filling out the rest of the ecosystem, whatever that is. The whole point of Phase 2 appears (to me) to be the expansion slot. Phase 3 is essentially no different than emulation.
  12. I can. If it's easier to use the VERA on the X8, then maybe I'd rather program on that instead of the X16. The hobby platform has to be hackable, but (in my case) accessible too.
  13. I've thought about this and struggled with multiple priorities, but I found others' suggestions to be very helpful. I feel clearer about the situation. So here are my suggestions, submitted to y'all for constructive criticism. $00. Make the REFERENCE version ** COTS **, and produce kits on a slow deliberate schedule. The core team is not allowed to burn out. $01. Do what's right for the ECOSYSTEM. $02. Make the PRODUCT as cheap and accessible as possible. [Tramiel] Tramiel was right with the C64. $03. Release an "X8 card" for Commodore hardware. This gives back to the Commodore community, and promotes X16 concepts.
  14. I wrote and deleted this response so many times since midnight last night. There are so many points I agree with in this topic already. What can I add? ****** Suggestion 1. Make the REFERENCE version ** COTS **, and produce kits slowly and deliberately. No burnout allowed. ****** Suggestion 2. Make the PRODUCT as cheap + easy as possible. [Tramiel] ...if that means an optimized emulator running on the Raspberry Pi instead of Phase 3, then so be it. ****** Suggestion 3. Do what's right for the ECOSYSTEM. *** Regarding the X8, I would prefer that it be on a card (or something) that could plug into other Commodore machines. To provide X16 capabilities to PETs and C64s for example. Make it a graphics card. Or make it an "X8 Card". Something like that. THAT sounds like a non-competing product that could EXPAND the X16's ecosystem.
  15. Ah, so you're leading the witness. Yes, I'll bite -- it sounds in the spirit of X16, sans VERA. What is it? What's the CPU? (The Gigatron runs at 6.25 MHz....)
  16. Wavicle, you're right, what I was thinking of isn't really an X16. It's just a "Commander" of some kind. And, you're also right about the KERNAL. It might well have to be written from scratch, and that sounds just painful.
  17. Granted. I mean, I get that. The X16's problems are Adrian Difficult. So, what about backing it to Amateur Difficult? Can I build a Neanderthal X16? I'll write before I think: how about the Ben Eater design (or for that matter the W65C02SXB) with the MIST KERNAL? The short answer is: no. The KERNAL really depends on hardware being a certain way. I suspect it won't work at all with bits missing. The whole POINT of much of MIST's KERNAL is that it makes use of all the special hardware in the X16, that is, VERA, and the banks. The longer answer is: this is what 8BG went through already. A KERNAL would have to be written, and almost none of it could be ported from the existing KERNAL.
  18. Seeing the technical depth of discussions from several engineers here has made me wonder. Many of you have 65C02s handy. Some have Ben Eater's kits. I watched his videos. And I've recently looked at SRAMs on Mouser. And you guys know all about this stuff. I mean some of you actually understand ALL of what's going on. Just by using Ben's videos, I could probably get a 65C02 connected to the KERNAL (on EEPROM) and a static RAM. Assume a non-banked memory model. I mean, the design is COTS on purpose. If I can get that far, some of you could get quite a bit farther. VERA notwithstanding. Am I right?
  19. All of this mooning about timing cycles and voltages and chip selection and Ben Eatering has got me thinking... I'm going to start a new thread for it though.
  20. Yeah, he mentions this on his website for sure.
  21. Summary of Matt's Videos, as I run through them Requirements: CC65 (https://cc65.github.io/) the X16 emulator of course (https://www.commanderx16.com/forum/files/) an editor such as Video Studio Code (https://code.visualstudio.com/) IF YOU'RE NEW TO THE 6502 OR ASSEMBLY LANGUAGE, START HERE Lesson One (27m): Foundations. What assembly language is, the 6502 architecture (and related processors), registers, memory addresses and how instructions work. The anatomy of an assembly language program at 14:00. lda, inc, sta, and rts. cl65 invocation at 18:00. Examining the .list and .PRG at 20:00. X16 debugger at 23:00. Lesson Two (32m): Addressing modes. X16 Memory Map intro. Addressing modes 4:00. Examples 11:30. Jump table 22:00. Build script 26:00, execute & debug. IF YOU'RE A NOVICE, START HERE Lesson Three (24m): Flow control. C versus assembly 1:00. Status register and compares 5:45. Loops (C versus assembly) 12:00. Functions (C versus assembly) 13:30. X16 KERNAL 16:00. Example program 16:45. Lesson Four (22m): Unsigned math and logic. Add- and Subtract-with-carry 3:00. 16-bit arithmetic 5:45. Inc and Dec 8:00. Mul and div overview 9:20. Shift and rotate 11:00. Bitwise ops 13:20. Logicals 14:50. Example 16:00. IF YOU DID SOME ASSEMBLY ON SOMETHING ELSE, START HERE Lesson Five (21m): The Program Stack. JSR and RTS 6:28. RTI 7:10. Push and Pull 7:45. Stack transfers 8:50. Examples of playing with the stack; also .asciiz 11:30. Lesson Six (22m): New bit test and branch opcodes in the 65C02. The old BIT 3:00. TRB and TSB 5:45. BBRn, BBSn, RMBn, SMBn 7:00. Example 12:00. Lesson Seven (19m): The rest of the 65C02's instruction set. Basically Lesson Six, part Deux. Also, ERRATA for previous sessions starting at 10:00. Example 12:00. IF YOU'RE NEW TO COMMODORE, BUT NOT 65C02, START HERE Lesson Eight (36m): The KERNAL. ROM banks 3:00. Jump table example: CHROUT 4:00. Hacking the jump table 6:00. CHRIN 9:25. GETIN 10:40. Keyboard buffer 11:30. SCREEN 12:50. PLOT 14:00. File load (SETLFS, SETNAM, LOAD) 15:10. Saving a memory block to file (SAVE) 20:45. Example involving screen mode, keyboard input, and load/save to file 20:50 IF YOU'RE NEW TO THE COMMANDER X16, BUT NOT THE KERNAL OR 65C02, START AT LESSON NINE.
  22. Welcome Matt! I look forward to your insights and ideas here.
  23. Matt, this is an absolutely GIGANTIC and USEFUL resource pile you've created. I'm going to have to find time to watch them all. Thank you!
  24. Welcome, Edmond! Many of our early years parallel yours: a school with PETs, and at home either a VIC-20 or a C64. I'm glad you're on board. We can always use another computer engineer. Your skillset sounds pretty wide -- my impression here is that most people here are hardware guys who know assembly language (and BASIC, but we won't talk about that). When I think of "computer engineer" I think of Ben Eater's videos, but then I'm one of the few who is just a software engineer with a small smattering of assembly language. Sounds like you've got both skillsets. As you probably know from 8BG's videos, the X16 is based on the VIC-20's memory model, with some important variations of course. The core team is debugging Prototype #3, and the current hot debate on these forums recently is over whether or not they'll actually be able to reach 8Mhz with the current prototype design. In short, there are smart people engaged with the problem on multiple levels. To me that smells like a recipe for success. I think you'll find plenty to keep you interested here.
×
×
  • Create New...

Important Information

Please review our Terms of Use