Jump to content

rje

Members
  • Posts

    1216
  • Joined

  • Last visited

  • Days Won

    37

Everything posted by rje

  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.
  15. This is a good post; thank you for writing it. The time you take to explain the rationale and requirements behind using the 65816 does more heavy conceptual lifting than at first glance! And, I think this is along the lines of why 8BG rejected this very capable CPU for the CX16. I'll restate EMwhite's very useful post and extract the work I assume would have to be done to use this chip: * To do things properly you'd have to do multiplexing in hardware -- if I recall pins pull double duty as address and data lines, right? I can see immediately why this wouldn't appeal to the X16 project, whose goal is to be VIC-20 easy, more or less -- and yes, damn the torpedoes, half our assembly is in shifting low and high bytes around. I think 8BG's calculation is something like "mental load per effective supporting transistor". Cost and assembly effort are clearly in second place to simpler design. * Talk of a micro-kernel simply adds fuel to the fire. Writing one from scratch does not appear to be an intent of 8BG... I remember his original video talking about having to re-write 90% of the KERNAL, and you can tell that that does not drive his enthusiasm. Contrast with Frank, who writes VERA cores apparently at the drop of a hat. In other words, 8BG's drive is not about rewriting the operating system, and not about a clever and powerful hardware, but rather something like a platform for the demoscene (and games 8BG played) in 1990. * The neat stuff that I like to see -- UDP ROCKS!!! -- is just not the target of the X16. A card can always extend the base capabilities with moderner stuff. But that's not core.
  16. "Dropped" as in, an early decision that is made from initial brainstorms based on what you have at the time. The 65816 added hardware complexities that were odious. The project already has complexities. Adding one more is not necessarily a good thing, based on what your target is. But it's always worth revisiting... for example, here:
  17. So what sort of operating system did the SuperPET's 6809 use? Did it have a modified KERNAL?
  18. For example, the KERNAL doesn't do math. However, BASIC has 40-bit floating point math routines, including trig and log functions, and a not-terrible (?) random number generator. If you need math, then it's convenient -- but you can always roll your own. Arguably, maybe half of the BASIC interpreter is the math library (I've heard that Integer BASIC can be jammed into 4K). So, BASIC isn't just a barebones scripting system; it's also a utility.
  19. Actually I think that's the whole point. (HA!) Seriously, though, BASIC is perfectly fine for programs that are up to about 4K in size. So as a "scripting" front-end to a Commodore system, it's similarly perfectly fine. Tack on all the extensions that are in the X16 BASIC *and* KERNAL, and you've got plenty to work with. More involved programs will run to assembly as 8BG has done, and perhaps cc65 or similar as I have done. And then for those who have an additional love from the 80s, there's the open 16K ROM banks for alternate system software.
  20. Not a modding thought, but rather an application thought -- I remember early mentions were about adapting VERA for other Commodore machines. To me, that sounds like a good idea. Giving one of the more common PETs a VERA board could open up a new angle for the PET hobbyist world. Might even expand it... now you can have the classic PET look and feel, plus 80 x 60 multi-color video with sprites and a 16-channel PSG??? Where do I sign up? I mean, some borderline retro geeks might be interested in picking up a PET -- or the Tynemouth/FW8B PET card -- if VERA is there for it.
  21. ^^ This sounds like Commodore both pre- and post-Tramiel all right. They gamed the market by cutting costs and margins. Buying Amiga makes sense to a company; supporting a research facility maybe is less well understood and maybe more risky. It is clear that chip manufacturing became commoditized and off-shored, so at that point you plan to close the shop, taking your profits for a few more years.
  22. I've thought about porting a light, PETSCII-friendly version of AWK into a "X16 Shell"-like thing.
  23. LOL you had me going there until after the nine bit system. Regardless, I'm not worried.
×
×
  • Create New...

Important Information

Please review our Terms of Use