Jump to content

rje

Members
  • Posts

    1235
  • Joined

  • Last visited

  • Days Won

    41

Posts 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.

    • Like 1
  3. 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.

    • Like 1
  4. 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.

     

  5. On 10/31/2021 at 1:46 PM, EMwhite said:

    Interfacing the 65C816, due to its common 40 pin package (not enough pins) is not quite as simple from a HW perspective but doable if you know what you are doing.

    ...

    The bottom line is that if you don't mind blowing memory and cycles, you can do just about everything on the 65C816 using far/long instructions and yet, take advantage of some efficiencies along the way.  You'll need to be familiar with new compiler directives and macros in order to solve for the differences but it's an easy lift.  In the end, you'll be way ahead as you'll have access to 4MB of RAM if you want it, run upwards at 14 Mhz. and can claw back in simple ways with new Opcodes such as BRA (branch unconditional, saving a byte versus a [now] short JMP.

    Of course, and as mentioned, a simple processor instruction will switch the 65C816 into 65C02 mode so a front panel mounted switch could have selected this if the Kernel and BASIC Rom work could have been solved.  For that matter, a default of an ALL 65C02 based code base for Kernel and BASIC could have just been dumped in and with the boot-time switch, a micro-kernel similar to C256 Foenix could have opened the doors (assuming general Commodore compatibility of X16 was a design tenet.)

    I'm developing a tile and sprite based client for a game on the C256 Foenix, starting with a 6502/6510 based C64 Terminal emulator that I wrote in the 80s; it will ultimately talk UDP over the Foenix RJ45 Ethernet, but in 65C816.  I have a NodeJS based Express server running out on Heroku already so just need to pull the client together.  It will take me the better part of a year to complete; I just don't have the time due to other work obligations.

     

    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.

     

    • Like 1
  6. On 6/13/2022 at 6:34 AM, Moto Rola said:

    You're totally right; so even the 65816 has been dropped? Not too good.

    "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:  

     

     

  7. On 6/8/2022 at 8:35 AM, Scott Robison said:

    And some ML programs will use routines in the BASIC ROM.

    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.

    • Like 2
  8. On 6/7/2022 at 5:34 AM, Moto Rola said:

    No idea, why repeat Commodore's mistakes.

    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.

     

  9. 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.

     

     

    • Like 1
  10. On 9/12/2021 at 1:39 PM, Scott Robison said:

    I read something interesting a couple days ago that had not occurred to me. Another reason why z80 was okay to use and not a 65816 is that they probably had a lot of stock at their disposal after the C=64 CP/M cartridge didn't sell very many units. No new old stock 65816s were lying around.

    ^^ 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.

     

  11. 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.

    1173227695_ScreenShot2022-05-21at1_56_09PM.png.6470403db6b1879235a98c65cbfdaaa9.png

  12. 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.

     

    570861507_ScreenShot2022-05-21at1_49_04PM.png.6fd676a339925a421f0e3e8c3e522d22.png

  13. UI REBUILD 06: THE HIRING HALL

    This bit works well, but has some problems.

    1. If I'm moving to borders, it needs borders.
    2. Needs a little prettying up.  The colors are perhaps too muted.  Maybe an icon would be nice here.
    3. 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.

    2031429481_ScreenShot2022-05-21at1_45_36PM.png.fe1088e9f07fcdff5337bef6a9463e86.png

     

  14. 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.   

    2018204423_ScreenShot2022-05-21at1_29_30PM.png.8b862781a61c0190ca82a3e1e2d57120.png

  15. 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:

    1. 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.
    2. 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.

    1698437820_ScreenShot2022-05-21at1_22_54PM.png.35151784cff2a7e13361018f85f52be2.png

     

×
×
  • Create New...

Important Information

Please review our Terms of Use