Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Stefan

  1. To be clear, in (2), the glue logic you are talking about could it be something like this? A sufficiently wide address decoder. The decoder output and the micro controller "request RDY" pin is run through a NAND gate The NAND output is connected to the 65C02 RDY pin (active low).
  2. Seems reasonable you could use the RDY pin for this purpose, if it can halt all operations as you describe. The first option---doing this without clock stretching---I do not fully understand. If the SMC is to drive the data bus without clock stretching, even to put just a one bit ready signal there, mustn't that be done within the strict timing limits that @Wavicle discussed above? And if the SMC was to drive the data bus outside those timing limits, wouldn't that corrupt the data bus? EDIT: Another thing. In (2) I suppose the SMC must drive the RDY line within the 65C02 timing limits, that is 4--5 clock cycles for a microcontroller doing 100 MHz, according to @Wavicle above. Could that be a problem, as the SMC has several interrupt driven tasks it's running in parallel---being a host=slave for two PS/2 devices? The SMC could easily spend more than 5 clock cycles handling an incoming PS/2 bit at the same time the 65C02 wants to read a value.
  3. Will that kind of solution require you to slow down the 65C02 clock? How would you do that?
  4. Just of curiosity, what timing requirements are there, if you would like to put a SMC on the data bus? Must the state of a pin be changed within half a clock cycle 1/8,000,000/2 = 62.5 ns? But there's also the clock stretching...
  5. OK. I was thinking of utility programs designed to work with the shell. At the moment you have the command that starts the editor. It will work only if the program is stored in the current directory. In the future you may have other utilities that can be started from within the shell. I just thought it would easier to store these programs using an absolute path.
  6. Great work, already a lot of convenient functions. Have you considered deciding an absolute path for a folder to store utility programs run by the shell?
  7. Version 0.5.2 released today. Mostly bug fixes. The built-in file browser would crash if you pressed a key that had no function in the browser. This bug was observed by @desertfish, and he also helped me with debugging. The editor will now select screen mode 80x60 on startup. If you compile the editor yourself, it's easy to select another screen mode. Just edit the source file "common.inc" and change the row ".define SCREEN_TEXTMODE 0". This was also request from @desertfish. Finally, @Wavicle helped me find a bug in the utility function that converts a value in BCD format to a string. The function did not terminate the string with a NULL character as advertised. It still worked in the emulator, as the memory location was initialized to zero anyway. But in would not work on a real machine where you cannot assume that memory is initialized to a specific value. Quite a nasty bug, with the potential of locking up the program completely. Many thanks to @desertfish and @Wavicle for helping me out with these issues!
    The assembler is already fully functional. Using it, you may get an effective workflow doing native assembly development on the X16. It lacks some advanced functions found in some other assemblers, such as calculated expressions, macros, and scopes. Those functions are convenient, but you can get by pretty well without them.
  8. You're a star @desertfish, making such a nicely working assembler!
  9. If you're doing multiple rounds of editing + assembling, you expect to overwrite the output file. I'm afraid that a confirmation prompt will not add any real protection. Another option is that the assembler does not allow the output file name to be the same as the input source file name.
  10. This is the test program I created with @desertfish's assembler. After using it for a couple of hours, it felt quite productive. The test program is the basis for an app switching utility living at $9000. If you press F1 it loads and starts one program (here X16 Edit), and if you press F2 it loads and starts another program (here the assembler). App switcher.mov
  11. After some further testing: I think the assembler skips assembling the last line of the source file, and you now need to add a blank line at the end It would be great if something could be done about entering the files names during assembly; from my short experience , it's easy to overwrite your source file by entering that file name as the name of the executable by mistake. Maybe the assembler should add ".PRG" after the name of the executable unless it already has that file ending.
  12. Yes. I suspected that supporting scopes would not be that easy. If only the symbol length is a problem, you could give each source file an index number, and internally prefix labels with the index instead of the whole file name. But I guess the solution requires some thought. I think the solution could work even if the assembler just inserts the text of included source files, verbatim as you say. Anyway, the assembler is already very impressive. In combination with the ROM based editor it's far more convenient than what I used in the good old days - the Commodore Macro Assembler for the C64.
  13. @desertfish I did download the latest version of you assembler and made a small program with it just to try how well it worked. It is very usable as it is, I would say. Some reflections: I tend (nowadays) to program by writing a small piece of code, compiling, and testing it, and then writing a new small piece of code, and so on. The assembler environment stores the name of the last executable that was run so that you need not type it again. Could it also store the name of the last assembled source file so that you could enter the "a" command without parameters. Could there be a command that both assembles and then runs the program, a combination of the "a" and "r" commands Have you given any thought to label scopes? Doing scopes like ca65 might be too hard. But maybe something could be done. For instance, the assembler could internally prefix all labels with the name of the source file, for example "kb.init" could reference the label "init" in the source file "kb.asm". I don't know if exactly that is a good idea, but maybe you could come up with something clever. The integration with ROM based X16 Edit worked fine after the update.
  14. OK. Will try it out. The ROM notes file is now updated with info on the application signature stored at $fff0.
  15. That is so true. It's not the load time, but all the extra typing of LOAD and RUN. A context switching application could be an alternative solution. I mean a program that lives somewhere in RAM or ROM, and lets you switch between programs that are loaded and run from the SD Card at the click of a shortcut key. The SD Card interface is plenty fast for that to work nicely.
  16. Hi @desertfish! Great work on your file based assembler. I tested it today in the R41 Kernal, and it seems to work fine even after all Kernal updates. The Kernal ROM bank layout has changed. Banks 0 to 8 are now used by the Kernal. X16 Edit will be in bank 9 or above. In reality, you cannot be sure where the program is stored. This has made the assembler's function to open the editor not work any more. There is an application signature (="X16EDIT") stored at $fff0 in the X16 ROM bank. You may use that signature to find in what ROM bank X16 Edit is.
  17. 0000041D Swedish It's very similar to 0000040B Finnish, I'm not even sure that there are any differences. Downloaded the XML specifications for each layout and run it through diff. As far as I can tell, only the local names of the various keys in the specification are different, which is not visible on an actual keyboard.
  18. The only way I know of to get finer control is to implement your own serial read/write function. Then LOAD would be replaced by calling these functions: SETNAM SETLFS OPEN CHKIN MACPTR (faster block read) or CHRIN (slower byte read) CLOSE CLRCHN It is, evidently, more code, but it's not that bad.
  19. That version runs on my Mac. Great work with the Kernal, by the way!
  20. It returned: zsh: bad CPU type in executable: ./x16emu Never seen that error, and don't really know what it means. Bad CPU type => Build target something else than the Intel Core i5 processor I have. Yes I know it's old
  21. As with R39, I get this error when launching R40 on my Mac (Catalina 10.15): dyld: Symbol not found: _GCHapticDurationInfinite However, works fine if I clone and build myself. Did not break X16 Edit from R39 in any way that in any way I can see quickly.
  22. Tested the new fast loader Kernal function ("MACPTR") in X16Edit. Haven't done any optimization, just getting it to work. Results (manual timing) opening/reading a file of 169 kB in size: Old byte by byte reading: 10.8 seconds => 15.6 kB/s New MACPTR block reading: 2.5 seconds => 67.6 kB/s Quite significant a difference.
  23. Version 0.5.0 uploaded to the download page with support for the new official R39 Kernal. Versions 0.4.0-0.4.5 do not work in the final R39 due to change of VERA memory layout.
  24. Trying the MacOS binary causes the following error: "dyld: Symbol not found: _GCHapticDurationInfinite" Haven't had time to investigate, but it seems to be a resource made available in MacOS 11 (released November 2020), which I'm not running. I could, however, clone the emulator master branch, and successfully build and run it on my Mac.
  • Create New...

Important Information

Please review our Terms of Use