Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


rje last won the day on June 15

rje had the most liked content!

Recent Profile Visitors

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

rje's Achievements

Rising Star

Rising Star (9/14)

Dedicated Very Popular Rare Conversation Starter Rare Reacting Well First Post

Recent Badges




Community Answers

  1. I am VERY HAPPY that cc65 was updated so that conio works with r41. So now I'm thinking, there might be a #define in there somewhere that would let me switch between r38 and r41... Oh but then I'd have to have a separate binary of cc65 itself that builds for r38... ugh! Well that's ok. I can't do the "Try it now" button with r41 binaries, for now at least. OK.
  2. I've seen the X16 proto boards on several videos, but I didn't get full-nerd with the video and try to figure out the parts list and cost. Lately, talking about the SRAM chips got me wondering what the current parts inventory costs. Anyone try this?
  3. Total? Somewhere around there, it seems. Nickels and dimes add up. But yeah.
  4. Lowest Common Denominator is what I'm thinking about. I would REALLY want to use the full 2MB, and if I do that, I won't want to write code that accommodates a 512K system... except I'm kind of hamstrung, aren't I, into coding to LCD, in which case forget the 2MB version... But the developer inside of me says "make a decision, do one or the other and stick with it". Note that I wouldn't have been thinking this way if Eight Bit Guy hadn't specifically TALKED ABOUT IT in his videos on the VIC-20, Plus/4, et al.
  5. Do tell. By spring 2021 I migrated to C programming for the X16. I've slowly been getting back some of the C-chops I lost over the decades.
  6. Very clever of Braben/Bell to tokenize. Let me think about THAT.
  7. Pointers are fine. It's malloc() and free() that I do not use at all. Text data stored in char* in RAM banks are perfectly fine, as are struct* in those banks. Heck, Core Wars uses ten banks of struct* to represent the playing field.
  8. ...18 months later... Traveller Trader uses a single file that contains a starmap. The map has (appx) 1,200 star systems in it, and the map is 388K. I ditched the idea of having the map distributed among several files. For now. And it's fine -- for most people who play this game, those 1200 systems are plenty. *** @Starsickle got me thinking, what are the Big Three Things of Star Trader? I'm going to define "Big Three" in existential terms. In other words, if it wasn't there, would it still be The Game? If there wasn't a canonical map, it wouldn't be Traveller Trader. If you didn't make money by taking on passengers and cargo, it wouldn't be Traveller Trader. If the starships were different and/or generic, or if they worked in non-Traveller ways, it wouldn't be Traveller Trader.
  9. That's sort of what I am thinking, except on the opposite side. TOOLS as well as games will be written for 512K. They COULD do RAM cache, but I suggest it's easier to make do without, unless you absolutely have to. As you say, it is an embarrassment of riches, and so we can live without the other 1500K, and I think we will. Your examples have some merit though. I could see a music or effects cache, and if there's a cheap and easy way to leverage that, then I could see it. Assuming ... well assuming lots of things. This is a weird ecosystem. But the part that's NOT weird is how like Commodore this process is. Take a stab at things, have possibilities, but in the end you don't really know what sort of impact it will make. *** I use the banks statically: I load them once and use them. But I could see a cached solution. Hmm.
  10. Thank you! I've shied away from sequential files so far because of the not-knowing. Your function will be helpful when I finally have the time and inclination to wrap these sorts of functions myself. BUT ALSO... even after the X16 is released, I will still be writing cc65 code on my Mac. This means SD card access will STILL be inconvenient. Which makes me think....
  11. I'm writing a C function that processes banked text with two markup symbols: ASCII newline (0x0a) converts to PETSCII newline (\r\n). ASCII brace "}" converts to a cursor-right character. I'm working on this solution, because it's terribly convenient to edit the text files using a text editor, and at the same time is close-enough to optimal for "externalizing" strings into banked RAM. I'm currently fooling with a method like this: // // Print "externalized" string. // void printBankedText( int address, // location in (banked) RAM to begin printing unsigned char len) // number of bytes to process { char* addr = ((char*)(address)); while(--len) { switch(addr[0]) { case 0x0a: cputs("\r\n"); break; case '}': cputc(0x29); // cursor right break; default: cputc(addr[0]); } ++addr; } } *** BORING DETAILS *** As my Space Trader's binary grows past the 36K mark, I've started "externalizing" string data into the RAM banks. I've found that I can shave 8K off of the binary this way, and that's worth it. The strings are of two types. (1) A few words. (2) Longer, expository text which may be multi-line. *** ORIGINALLY, I processed these string data into null-terminated plain old PETSCII strings. BUT LATELY, I've found it VERY convenient to leave them as ASCII: this makes them extremely easy to edit. FINALLY, though, I have some multi-line, indented strings.
  12. The FAQ notes that 512k banked RAM is the planned shipping configuration. i reckon this is a cost consideration. But isn’t it likely to cap programs to only use 512k? It feels like a handicap, however minor.
  13. Here's a brainstorm, which can quickly be dispatched so I can get on with my normal life. Tynemouth cooperates with 8BG to produce a modified MiniPET, which accepts Michael's KERNAL, Frank's VERA, and banked RAM (yeah I know, that's not a PET any longer, I'm just spitballing). 8BG labels it the Commander X16. Ridiculous I know. Probably nothing on the PET that's reusable for the X16 anyway.
  14. 8BG is trying to design X16 based on a conceptual mental load for understanding the entire system, right? (1) There are single components that are just going to be there. The CPU, ROM, and SRAM. These are essentially invariant. (2) VERA for all intents and purposes is also invariant, since it's the mulligan for expired 80s tech. (3) Supporting circuitry is the conceptual load. This includes banking logic, the keyboard interface, the user I/O lines. For example, when we talk about an 65816 system, we're really talking about a completely different machine, aren't we, since the only thing the two systems apparently would have in common... is VERA. I can't even assume it could use the KERNAL.
  • Create New...

Important Information

Please review our Terms of Use