Jump to content

Greg King

Members
  • Content Count

    65
  • Joined

  • Last visited

  • Days Won

    3

Greg King last won the day on August 19

Greg King had the most liked content!

Community Reputation

44 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Two questions: Are you using the host file-system or an SD card image? Does Kick Assembler's .text directive translate ASCII into PetSCII, or does it assemble that text as ASCII?
  2. I prefer the VIC-20's fonts. The C64 (fat) fonts were designed for televisions, not monitors. The VIC-20 gives us (thin) fonts that are better suited for VGA. They are the Pet fonts except for the backslash (a British pound sterling sign on the VIC-20).
  3. Please try an experiment. Execute this command: cl65 --print-target-pathDoes it show "/home/rick/workspace/cc65/target"?
  4. Do the ld65 configure files exist on your system? They should be in "~/workspace/cc65/cfg/".
  5. Hmm, now that I think more about your example, I see that it, also, cannot work if the files are on separate devices, and the program wants to change the data before writing it. If the program told the first drive to talk, and told the second drive to listen, then the first one would send its data directly to the second one. The program wouldn't get a chance to alter the data. Another hmm. I guess that people who are used to PCs will be confused by this discussion. Well, ... a Commodore 8-bit system is a network. The computer, the disk drives, and the printers are independent microcomputer nodes on that network. The computer is the boss. But, drives can be told to talk directly to each other. Drives can talk directly to printers. They don't need to send their data through the computer. They usually do go through the computer, but they are able to bypass it. And, if file I/O switching isn't managed properly, then bypasses or collisions could happen by accident.
  6. To me, it's more logical to tell a drive, "stop talking/listenning about the files" before it's told, "close the files". (You wouldn't tell someone to put a book back on a shelf before that one stopped reading it.) A better two-file example is this: A program reads two files together. It interleaves data from those files. It reads some data from the first file. Then, it reads some data from the second file. Then, it reads some more data from the first file. Then, it reads some more data from the second file. Then, it reads some more data from the first file ... and, so on. The program must use CHKIN calls to switch between the two files. The files are on separate devices. If the program tells the first drive to talk about its file, then tells the second drive to talk about its file, then both drives will talk at the same time! The computer will hear garbage. Each drive must be told to stop talking, so that the other one can have its turn to talk without interference. The program really must pair a CLRCHN with each CHKIN. OPEN and CLOSE are a pair. The two CHK... functions and CLRCHN actually are a pair! I recommend that people get into the habit of thinking about them that way. Then, you won't have trouble when you start to write programs that handle several files together.
  7. A misunderstanding by some people doesn't make it "normal" or proper. Here's what the BASIC interpreter does: 10 OPEN 1, 8, 2, "0:FILENAME,S,R" 20 INPUT#1, Y$ 30 CLOSE 1 calls SETLFS and SETNAM calls OPEN calls CHKIN calls CHRIN repeats step 4 until a carriage-return is seen calls CLRCHN calls CLOSE BASIC doesn't call CLOSE before it calls CLRCHN!
  8. NO! DEFINITELY NOT! $0289 holds the count of open files. CLALL doesn't close files; it "drops" them -- it makes the computer forget that files still are open! DOSes aren't told to close their files! When CLRCHN resets the computer's I/O selections, it tells peripheral devices to reset their channel connections to the computer. DOSes like to do that before they're told to close a file.
  9. Think of a stack -- Last In, First Out. CLRCHN is the opposite of CHKIN/CHKOUT; CLOSE is the opposite of OPEN. Therefore, we should use this sequence: OPEN CHKIN ... CLRCHN (cancels CHKIN) CLOSE (cancels OPEN) CLRCHN means: clear (cancel) the current input channel selection, and clear the current output channel selection.
  10. Call c64.CLRCHN() before calling c64.CLOSE().
  11. That "N" in the "N0:" will be ignored; don't put it in the string. And, don't bother to spell out the "SEQ". Just use the initial letter: 100 OPEN 2,8,2,"0:MY-NEW-FILE,S,W"
  12. I tried some tricks, but no luck. It seems that "multiple strings" is the only way that works: text 'You don',$27,'t know where you are.' text 'You don',"""','t know where you are.'That second line looks odd, but it works!
  13. That part of LOAD might be broken in R38. Try VLOAD (although, the bug might be in Kernal, and common to both LOAD and VLOAD). https://github.com/commanderx16/x16-docs/pull/46/files
  14. I meant that you should use "\\s*" to ignore spaces when looking for a match. (So that it won't matter how many spaces are, or are not, at that spot in matched text.) It's exactly what you did. There must be whitespace between a mnemonic and the "A". Otherwise, it's a macro name (such as "RORA"). Therefore, you should use "\\s+" instead of "\\s*".
  15. There are two C demoes: https://github.com/commanderx16/x16-demo/tree/master/cc65-audio https://github.com/commanderx16/x16-demo/tree/master/cc65-sprite
×
×
  • Create New...

Important Information

Please review our Terms of Use