Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by rje

  1. 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....
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. "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:
  8. So what sort of operating system did the SuperPET's 6809 use? Did it have a modified KERNAL?
  9. 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.
  10. 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.
  11. 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.
  12. ^^ 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.
  13. I've thought about porting a light, PETSCII-friendly version of AWK into a "X16 Shell"-like thing.
  14. LOL you had me going there until after the nine bit system. Regardless, I'm not worried.
  15. Ha! There's a final release? I'm behind the times... please stand by.
  16. Since most of my X16 coding is in C using cc65, it's a given that I use cc65 for what little assembly I do.
  17. UI REBUILD 08: REFUEL This is a late addition -- the ability to refuel from either the mainworld, or a local gas giant, or asteroid ice, or oort cloud ice. The latter two don't have "artwork" yet. The mainworld and gas giant are procedurally generated, and so are slow but not horribly so, and result in the same pattern given the same world data. Again, this screen would benefit from borders.
  18. UI REBUILD 07: SHIPYARD This is where you trade for another ship. This used to be a flat list, but instead I went to a page-flipping scheme where you see ALL of the stats for each ship on the entire page. It's great for when you need detail -- and when you're ship shopping I figure you need detail. HOWEVER... I started out with as much detail as I could fit into a 48 byte structure, in order to give me options. Now that I've filled up system RAM, I'm thinking there are some details which are not important. I'll have to think about that for a long time of course. One major thought I've had lately is that I shouldn't list a ship unless I have an icon for it. This limits my number of ships down to maybe 19 ships... maybe two dozen if I get a couple more designs squeezed in. I currently have maybe 46 ships, and I think there's sufficient overlap still, so this is probably OK. I have over a hundred unique ship designs on hand, but their differences aren't necessarily large enough to be important.
  19. UI REBUILD 06: THE HIRING HALL This bit works well, but has some problems. If I'm moving to borders, it needs borders. Needs a little prettying up. The colors are perhaps too muted. Maybe an icon would be nice here. The menu doesn't work like the others. I either need to use the standard menu system, or else make this one look and act more like the others.
  20. UI REBUILD 05: STARPORT The starport is where you repair and upgrade your ship. This needs to be more engaging, centered, nicer... right now it is a mess. I have no idea why I put the ship's data line at the top of the page, either. Most of that data has nothing to do with repair and upgrade.
  21. UI REBUILD 04: TRADE The trade menu is still fairly primitive... it's not centered, and the colors are too dark. Also, if I'm using borders, I need borders. I plan to use Tom's mockup as a guide for improving it.
  22. UI REBUILD 03: MAIN MENU This screen suffers from not really being anything other than a dumping ground for actions. It currently holds details of the source and destination systems, but it's not really an appropriate place for these data. It IS convenient to know that a destination is set, but I don't know if the full details are important here. Second, the current and destination worlds need to have borders, as does the alarm bar. Third, like Tom's mockup, I'd like the game's name on the page -- maybe at the bottom.
  23. UI REBUILD 02: ASTROGATION This will be the fourth re-imagining of the astrogation interface. My assumption is that a player would enjoy moving a reticle on a small piece of the big map. But, I'm not longer quite so convinced that it's a good idea. I also suspect it takes more main RAM than a list -- after all, there is placement code for the features of every system in the view. But I don't know if that's a major concern; I don't think it would make more than 1K difference. Here's the current view. And here's what I am thinking: If I keep this interactive map, then I need to center it, put a border around it, and find a reasonable way to represent the "metadata" on the left side. Replace the map with a short but expandable selection list (per Tom's suggestion), and include the current + destination system details in this view. I'm currently leaning towards #2.
  • Create New...

Important Information

Please review our Terms of Use