Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by rje

  1. On 11/22/2021 at 12:25 AM, TomXP411 said:

    I like Pi2IEC. Since this would basically be the Pi version of the SD2IEC, but with some added benefits.

    I surfed around the YouTube "net" over the past week, and it struck me how like the SD2IEC this project is, except using a Pi.


    • Like 1
  2. On 11/15/2021 at 11:16 AM, ZeroByte said:

    And I can say that for X16 - if you can write your library in pure assembly, it will run much faster than if you write it in C. (obviously)

    I'm getting close to the point in my zsound.lib project where I'm going to make some C stubs to translate C's function calls into what my routines ACTUALLY need to run. (basically, pull stuff from the stack, put them into whatever ZP / regs I want, and then JSR the real routine). That's why it's useful for C space to use _symbol.

    I can export playmusic and _playmusic
    _playmusic will just pull the C parameters and call playmusic

    I'm interested -- do you discuss this somewhere on this site?

    And, regarding pure assembly (inline?) -- I'm also interested.

  3. I think this is going to turn into a major reorganization of my code, and potentially a reworking of my Makefiles.

    Although I can get away with a simple shell script for now which builds the library and creates the /include directory.


    But... I see the usefulness of splitting my utility code into multiple libraries.  Eeek.

  4. And I note that AR65 is an archiver of object files... which sounds just like a Library.  So then:


    cc65 -c file1.c ...

    ...creates object files.  Then:

    ar65 r mylib.lib file1.o ...

    Adds the object files to mylib.lib (and creates it if needed).


    When using mylib.lib, I guess cc65 needs to know the path to (a) the headers, and (b) the library.  So that would look like this:


    cl65 -I include_files_dir -L path_to_libraries [and all the rest of the command line stuff]



  5. I'm 99.9999% sure these would be statically linked libraries.  After all, I seriously doubt 8-bit machines will dynamically load object files.

    If I remember and read right, I can use -c to create the object files.  I suspect my header has to declare accessible functions with extern.

    Then, if I stored my object files in a central location, I can use -L with the compiler to specify a library path.

    Or, maybe, use -I for the include library path?

    In "normal" C you have different switches used by the linker and loader.


    Time for more reading.


  6. I now have code that I want to share between my projects -- sprite and PSG code mainly, but there's other stuff too.

    I've never created a library ... or I can't remember doing it, anyway.  Can anyone point me to the right place to learn how?

    Is it done exactly the same as "normal" C code?  

    I'll assume that it is, and go to Stacktrace.  If someone has further enlightenment, please let me know.


  7. Thanks for engaging.  Actually I'm by default thinking the envelope manager is going to be 100% assembly.  Doing something in C moves me forward, gives me some success, and helps me understand the problem. 




  8. Well, what I am working towards, slowly and painfully, is an interrupt in assembly which uses memory locations for holding ADSR data.

    At the moment, I am first trying out some POCs, like this one, which is in C 



  9. Proof of Concept sprite, PSG, etc tools

    View File

    This file demonstrates a grab-bag of utility code I wrote recently.  The library includes two versions of Burtle's small noncryptographic PRNG, PSG code, sprite code, a timer, and a a Z-text decoder, among other things.  

    Largely, this is code that I kept writing for several projects -- or code that I wanted to write but hadn't gotten around to, yet.  I consolidated these little odds and ends because I tend to use them a lot but want them all in one place.

    The repo is https://github.com/bobbyjim/x16-c-tools


    • Like 2
  10. As a coder, I'm not even thinking up at that level.  I'm thinking on a much lower level.  If you've seen SuperBASIC you'll know what I'm thinking of.  ... Actually I'll attach the text tech documentation for it.

    [SSND is simply fantastic.  [DSPR is similarly just 100% useful.



  11. PSG API

    Every six months or so I fret about this.  I rotate between a few central topics to fret about -- this keeps me from burning out.  Or maybe it keeps me from being productive.  Whatever.

    I think to myself that a "simple" (?) set of small (?) assembly routines, based of course on Dusan Strakl's tiny sound library, would be just the thing I need to put some kind of SIDlike sounds in my games.

    It's one thing to want it, and quite another to do it.  I've tinkered with BASIC sound code just to prototype something, anything at all, but I never get far because it's just not trivial.  Of course, nothing easy is worth doing, so I come back to it and remember that if I want anything to get done, I should do it.

    A PSG API is basically an ADSR envelope manager for the PSG.  I think this means each Voice is assigned to an envelope and has a state.  Then there's ADSR envelope definitions.  The manager itself would have to run on an interrupt, just like Dusan's library.


    Assume each Voice gets an envelope, defined exactly by the length of each stage: Attack, Decay, Sustain, and Release.  It also gets a value identifying its current "position" along the total envelope. 


  12. The two things that seem to slow me down with working on my ridiculous little games are toolchain items:

    (1) Sprite tools
    (2) A PSG API

    I am going to try to use this thread to unify my toolchain thoughts and efforts.


    The X16-Demo repository has a very useful Python script in /tools:  png2sprite.py, which converts a PNG image to a C-style array of bytes.  Its most useful thing is how it does its darndest to match the PNG image's colors to the X16 default 8-bit palette.

    I could use that.  So I wrapped a Perl script around it.  The script calls Python, and takes the output and generates a binary file that can be loaded straight into VERA.

    This is useful, because there are plenty of image editors, and all of that work can be done on modern computers.

    Both files are attached just because.


    There's also a sprite editor on the X16 -- so you can draw sprites directly and it outputs BASIC statements.  I've used it a bit, but it's not yet part of my toolchain.  I'd like to edit it and add a routine that writes a binary file.  


    c2bin.pl png2sprite.py

  13. On 11/2/2021 at 10:58 PM, Scott Robison said:

    The biggest problem is that there are two (in general) audiences that use computers. There are the technical people who love to use and understand the internals, and there are those who just want or need to use it as a tool. People who only have an interest in web browsing, word processing, etc, want cheap and fast.

    I'm in neither category, and you're right, I'm probably a niche in the niche.

    I'm a software developer who doesn't really want to understand all of the internals if I can avoid it; I just want a simple toolchain that lets me write games that aren't three orders of magnitude worse than most things written for the target platform (I'm fine with being two orders of magnitude worse though).

    With some minimal software*, the Commodore 64 gave me that toolchain.


    * The ubiquitous Sprite Editor, Butterfield's Supermon, and Martin Kees' SuperBASIC 64 (which made it trivially easy to use sprites and the SID), helped me write a dozen half-finished BASIC games in the 1980s.


    • Like 2
  14. On the other hand, my nostalgia isn't so strong that I want to code on the Commodore 64.  The limitations of that platform are painful.

    The 40 column display always irked me, even in the 80s.

    Eight sprites (without raster interrupt) is painful, and 21 x 24 one-color no longer seems all that great.

    Data management was always a problem; the 1541 and I never got along.

    I suppose I could write in C for the C64, but the X16 showed up before I tried it, and gave me a beautifully capable system.  In many ways, it improves on the Commodore hardware in ways that are highly attractive.

    Yes, there are things I don't know anything about.  The YM sound chip, I will never be able to use.  Fine, I'll ignore it.  Much of the video modes I am really unschooled in.  That's no big deal; what I do know is enough to do what I want.


    • Like 1
  15. It's Commodore's ease of use that ignites my nostalgia.  Not just simple, but also usable.

    • The pipeline on Commodore machines was smaller.
    • It didn't require a full team to develop something that people might appreciate and enjoy.
    • Artwork!  Bah!  If you could draw pixels on a grid, then you could do about as well as anyone.
    • Music?  Bah!  SID made it easy -- a decent range of sound effects was reachable.


    ==> Note.  I cannot today create a "game" -- especially not one that anyone will be interested in.  I don't know how to do sound and music, and I don't know how to do graphics.  I don't have an art degree, so my graphics will look like crap compared to anything done in the past 30 years.  I don't have a music degree either, so I won't be able to craft sound effects and the obligatory soundtrack.  Also, I'm not going to buy the Studio Softwares required to do these things.


    And, yeah, BASIC stank, but Commodore used it very well, and that interface was both simple but also effective.

    And yeah, the 1541 disk drive was terrible and good riddance.


    In short, you could create something like PETSCII Robots, and the big software houses weren't making stuff two orders of magnitude better for most of the 80s.


    1. You need a Linux, with GIT, GCC, GNU make, and libpng development libraries (libpng-devel package on Debian, if I'm not mistaken). If you only have Windows - you can use Windows Subsystem for Linux, it should work. I'm not sure about Mac OS - I don't have a Mac.

    Maybe this is why.  I have OSX.

    Maybe I'll have to try this on a Raspberry Pi running its Debian-ish thing.

    Or... or a container.


    • Like 2
  16. Meh, still produces errors.  Setting it on the back-burner and letting my hind brain think about it for awhile.

    I suspect the flags aren't getting picked up.  

    Or something.


    On the other hand, ACME builds just fine.

    • Like 1
  17. Maybe it's not that -- it's that clang complains about the syntax.  For example, with nested templates, it errors out when the end-brackets aren't space-delimited.  It errors out on these:


    But is okay when I edit them to this:

    > > >


    It is also erroring on C++11 extensions.  I'll have to enable that in the makefile, I think.  I'm weak on Make.

    Found this on Stack Overflow, and will try it out:


    CXXFLAGS = -std=c++11
    • Like 1
  • Create New...

Important Information

Please review our Terms of Use