Jump to content

Greg King

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Greg King

  1. What happens if you open and close the command/status channel instead of a file?
  2. Type a control-n. Then, load the file with lower-case letters: load"cx16*"
  3. I have upgraded my commander-r39 branch to the new Kernal code. I haven't pushed it to master yet because I have problems with file loading. Programs that want to load dynamic drivers can't get them. I haven't investigated it yet. https://github.com/greg-king5/cc65/tree/commander-r39
  4. You should call cbm_k_clrchn() before you call cbm_k_close(). It's the opposite of when you started to use the file: OPEN the file, connect to the file. When you're finished, you must: disconnect from the file, close the file.
  5. Tape files are opened by Kernal. Therefore, OPEN can know when they can't be found. But, Kernal asks DOS to open disk files. Therefore, OPEN can't know about them. With READST, bits 6 and 1 aren't connected to each other. It's a coincidence if bit 6 happens to be set when bit 1 is set. Always check bit 1 by itself. That bit is reliable. LOAD uses it to know when a file can't be loaded. The same is true for the other direction. If a file can't be created, or opened for appending, then an attempt to write into it will set bit 0 (write timeout).
  6. Don't forget to put "-t cx16" on the command line. The assembler needs to know it.
  7. Some cc65 tricks that will shorten pieces of your code: Change l++; if(l > 4095) {l=0;} to l = (l + 1) & 4095; Change while(!(VERA.audio.control & 0x80)){ //while(ii<256){ to while ((signed char)VERA.audio.control >= 0) { //while(ii<256){
  8. Your code waits for VSYNC, then does its work. It finishes just in time to catch the next VSYNC. If you add a little bit of code, then it can't finish in time -- it just misses the next VSYNC. Maybe, your code must wait for the second next VSYNC! It does nothing for almost an entire frame! Naturally, its frame rate suffers a huge hit. (Try not waiting for VSYNC. See what that does to the rate.)
  9. What cc65 does depends on the context (the code that surrounds those expressions). Most of the time, cc65 can recognize that they are simple byte fetches. It won't do the actual operations that are implied by the C code. cc65 will generate Assembly code that grabs the register that holds the desired byte. #define BYTE1(val) ((unsigned char)((val) & 0xFF)) #define BYTE2(val) ((unsigned char)(((val) >> 8 ) & 0xFF)) #define BYTE3(val) ((unsigned char)(((val) >> 16) & 0xFF)) #define BYTE4(val) ((unsigned char)(((val) >> 24) & 0xFF))
  10. No, the addition must be done last. It's used to move past numbers that Commodore already used to control Kernal's LOAD behavior: 0 -> normal load 1 -> normal verify 2 -> VRAM address high bit (0) 3 -> VRAM address high bit (1)
  11. @rje's code has a couple of problems. DOS commands must be lower-case. cbm_k_setnam() needs a variable-length C text string; but, the "p" command is fixed-length binary. cbm_k_setnam() cannot be used to pass the command to DOS. The following code will work: #include <cbm.h> #include <errno.h> unsigned char __fastcall__ cx16_seek(unsigned char chn, unsigned long pos) { static struct { const char p; unsigned char chn; unsigned long pos; } cmd = { 'p' }; cmd.pos = pos; cmd.chn = chn; cbm_open(255, 8, 15, ""); cbm_write(255, &cmd, sizeof cmd); cbm_close(255); return _oserror; }
  12. That's BASIC's way of doing it. In Assembly, SETLFS doesn't take anything in the accumulator for LOAD/SAVE calls. And, the "VRAM bank + 2" is put into the accumulator of the LOAD call (i.e., the 17-bit VRAM address is given directly to the LOAD call).
  13. What kind of data do you want to put in a file? Some text before it's printed. Or, something that you programmatically formatted and printed onto the display screen? (If it's the second kind, then you will have screen-codes in VRAM, not PetSCII in main RAM.)
  14. Answer #2: You must read the text through an indirect pointer. Use two nested loops. Increment the index in the inner loop. Increment the high byte of the pointer in the outer loop. entry: lda #clear-screen-code jsr CHROUT lda #<$8000 ldx #>$8000 sta r0 stx r0+1 ldy #0 loop: lda (r0),y beq done jsr CHROUT iny bne loop inc r0+1 bra loop done: rts
  15. Box16 uses OpenGL (Graphics Language) to speed up its display. But, Microsoft doesn't support it. The OpenGL driver is old, and doesn't work with some modern graphics chips. There's no workaround. Box16 runs, but we can't see what it does.
  16. That's dangerous. Printing something into the last spot on the screen will scroll the screen! The safest way is to go to the last spot on the line, delete back to the beginning, then print a space over what used to be the last character.
  17. "-t" sets the CPU. Therefore, if you want a different one, then you must put "--cpu" on the right side of "-t".
  18. You can go further. If several of your functions use the same data or variables, in a way that doesn't conflict with each other, then you can put that data/variables into their own source files (those files might not have any code in them). The idea is that your program won't have two copies of them even if that program is using two functions that need them -- it's less bloat.
  19. Their philosophies are different. stdio is stream-oriented, while conio is screen-oriented. A stdio program is expected just to print and print and print and... It cares little about the height of a screen. A conio program is expected to stay on a single screen. It reuses that screen's real estate. It overwrites old text with new text. That's why conio has ...xy() positioning functions. It's why there are cclear... functions. And, it's why carriage return and line feed are separate characters. We can use carriage return to type and retype on the same line.
  20. "(_printf.o)" is the common formatter function that everything uses. "(printf.o)" has the printf() function. But, it calls "(vfprintf.o)", which calls "(fwrite.o)", which calls "(write.o)".
  21. You should use printf(); in an example about stdio code.
  22. We use https://github.com/cc65/cc65/blob/master/targettest/dir-test.c to test our standard directory functions. (Ignore the comment at the top of the file! It describes the CBM library implementation, not the test program.)
  23. Yes, only the load and save functions work on the emulator's filesystem. Standard I/O and POSIX I/O work on the SD filesystem as the standards say that they should. However, subdirectories don't exist in CBM DOS. Therefore, those functions might not work in CMNDR DOS as you would expect.
  24. Currently, the increment/decrement must be or'ed into the address expression that's given to vpeek() and vpoke(). No one has taken the time to document a lot of the functions that are available in cc65's libraries. (Usually, someone finds a function in a header, learns that it's very useful to him, notices that it's not in the doc, then submits a patch to "funcref.sgml".) Yep. But, it isn't complete. For example, there are no constants for configuring sprites. "cx16.inc" (for Assembly programming) has much more of that stuff in it.
  • Create New...

Important Information

Please review our Terms of Use