Jump to content

Scott Robison

Members
  • Posts

    740
  • Joined

  • Last visited

  • Days Won

    32

Everything posted by Scott Robison

  1. In a 6502 BRK generates a software IRQ. That sets up the stack properly so that RTI does the right thing.
  2. And I will not be critical of you for any decision you make. I was just answering the question as posed and trying to think of "ultimate flexibility" realizing that all engineering is about analyzing the problem and deciding which things are good to have and which are too much. Given my lack of musical / audio programming experience, I am mainly able to help answer questions in the "generic library" context.
  3. I think the problem with idea 1 is you don't know how many maximum loops a given application might care about. If it doesn't care you don't need it. If it does care, it might only need one byte, or two, or three ... I would be inclined to omit that default counter since it might not be used or useful depending on the consumer of the library. Idea #2 is okay, but it also assumes that you can always know in advance how many loops you will require, and that it will always fit into a byte / word / more. Idea #3 is best because presumably the application consuming the library can do whatever makes sense for itself. It can omit the callback in which case the library doesn't callback at all. If the application needs more or less space for such a variable, it will know how much room it needs. Or maybe it doesn't need to count, but some event might allow it to determine "now is the time to stop after this loop, which I could not possibly have known about before now". Presumably the callback could return a value that the library would use to know "I am looping indefinitely and shall continue to do so" or "I am looping but this should be the last loop" or "I am not looping, but I've reached the end, so the application can tell me to restart even though this isn't a loop" or even "I am not looping, but the user can tell me to start a brand new tune randomly or by some other criteria". Of course, this is easy for me to suggest, since I'm not writing the library. I just think one callback routine can provide infinite flexibility that isn't available for #1 or #2. If you *did* want to allow #1 or #2, it would be trivial for the library to provide built in callback functions that could be registered instead of a user defined callback that provided the easy functionality for applications that don't want to worry about it.
  4. Which reminds me, I'm supposed to look at that, @ZeroByte. I should have more time next week (taking off Thanksgiving week).
  5. So glad I included the disclaimer that maybe there were stubs in BASIC.
  6. I *think* that is problematic since BASIC is in a different ROM bank than the kernal. Maybe there are stubs in BASIC rom to forward to the real kernal calls, though.
  7. While it might not have a formal method called dynamic linking, that's more or less how program use the kernal. A jump table of function entry points. Not unlike how GEOS supported multiple printers and input devices: load a module to a well known address and use its jump table. Modern dynamic linking allows for more complexity, but at its heart it is the same thing.
  8. It's going to be a function of your tool chain. Are you using cc65?
  9. I don't have the R38 ROM on my system, but I did build the R39 ROM, and I think it is claiming that variable (tblx) is at $0383. It could be completely different in R38 (the current release) than in the R39 ROM (the yet to be release).
  10. I do wonder how it could look on a C64 if taking advantage of some memory expansion. I wouldn't be able to use the MMU to speed up block copies, and I wouldn't have a second screen for a map. Also, we never used 2 MHz mode so that is not an issue. It might be fun to try to make a 64 version that uses REU (or geoRAM or RAMlink or whatever) to see if it is possible.
  11. No need for crow, unless you really like it! When I first started working on this, my thought was to keep it true to the PET / C64 version legacy. It would have been a really pale imitation of what it turned out to be. David got excited about doing more and I was along for the ride! It turned out even better than I thought it would when I first pitched the idea.
  12. Welcome! I'm also looking forward to it!
  13. I'm thinking about printing a few shirts. Anyone know of a good place? BTW: Yes, it is a PNG.
  14. Thanks. It was definitely a team effort between artist, musician, David, and myself.
  15. Well, I did simplify it quite a bit. Most analogies fall apart at some point, and mine did. I think your desire still puts you in the tech loving crowd. Even if you don't want to understand the hardware at the chip level, the fact that you are willing to live with the limits of the tech and desire for good tools for it definitely excludes you from the "just web browsing and word processing" crowd.
  16. But I will say this: I think David has been clear that while Commander X16 is his idea of a dream computer, he's not the one doing the great bulk of the work. He's a bit at the mercy of variables beyond his control for X16 (while having spent five figures out of pocket to help push those variables along; that's not me sharing confidential information to be clear, that's what he wrote in the August info thread / poll). In contrast, he does control most of the variables for PETSCII Robots, so more news flows from that as he is more in control of that (realizing that even then, some people who commit to do a port fall through, and he does overestimate the appeal of the game in some quarters, such as Apple II). He's taken a bit of a gamble with all of the ports that he sells, and it's not fun to lose money on a venture. Hopefully with time he'll inch up the 87% or whatever to 100% and hit break even (or better) for what is undeniably a niche product in the year 2021. BUT COMMODORE 128 HAS A COOL GAME AND I WAS PART OF IT, SO YAY!
  17. It was a lot of fun. It's great not having to come up with the idea for the game, just implement it.
  18. I never had to deal with beta testers, as David dealt with that. And it's done! https://www.the8bitguy.com/product/petscii-robots-for-commodore-128/
  19. If you create a file ca65test.asm that includes the code from above and assemble it and create a listing, it shows: Note that the rr byte values are unknown because we won't know their final value until we link the object file into a program. On line 1 it shows offset 000000, as that is the index into the current segment at the beginning of that line. The ".data" directive doesn't generate any bytes for the program, so that offset 000000 is unchanged on line 2. Line 2 created three bytes, so on line 3 the offset has changed to 000003, where ".code" changes the segment, so on line 4 the offset is back to 000000 because it is a different segment. The linker will take that object file (and other information) and create a binary file that could look something like this: The link reorganized the segments so they're in a "good order" for the machine so it can start executing the program and all the code is together, and all the data is together after the code. Again, this is just an example for illustrative purposes.
  20. A program is a sequence of bytes and you determine how they are used. You can interleave code and data however you want. A segment is a way to organize the program more effectively. I'm not an expert with ca65, so this isn't a perfect example, but imagine you have something like this (useless) example: .data bytes: .byte 1, 2, 3 .code lda bytes+0 ldx bytes+1 ldy bytes+2 .data msg: .byte "this is a test" .code nop nop nop The first line says "stuff that comes after goes into the data segment". The data segment is just a sequence of bytes. The third line says "stuff that comes after goes into the code segment". The code segment is also just a sequence of bytes. The seventh line switches back to the data segment. Anything that comes after that is appended to whatever is already in the data segment. The ninth line switches back to the code segment. Anything that comes after that is appended to whatever is already in the code segment. So after assembling that file, you have two segments, CODE and DATA. The data segment will have 17 bytes: $01 $02 $03 and 14 bytes representing the text "this is a test". The code segment will have 12 bytes: 3 bytes for the LDA instruction, 3 for LDX, 3 for LDY, and 3 NOP instructions. You can have multiple source files that all use the same segments. When the linker creates your final program image, it will put all the stuff in CODE together, and all the stuff in DATA together, and the linker configuration will determine which segments come first and which come last (or in the middle if you are using even more segments). In the end, segments allow you to write your code in a way that is organized for humans to read it, but that will be better organized for the computer later. This is especially useful when you are writing code that will be eventually burned into a ROM. You can't just intermingle code and data, so in that case you can have CODE that is read only and suitable for a ROM, and DATA that is writable and sitting at some RAM address. You can do all of this without segment support in the assembler, but segments help you do less bookkeeping. I hope that helps.
  21. I think you are correct! Welcome.
×
×
  • Create New...

Important Information

Please review our Terms of Use