Jump to content

Michael Steil

Administrators
  • Content Count

    30
  • Joined

  • Last visited

  • Days Won

    4

Michael Steil last won the day on August 27

Michael Steil had the most liked content!

Community Reputation

64 Excellent

6 Followers

Recent Profile Visitors

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

  1. GRAPH_set_colors is a KERNAL API, so there is an entry in the KERNAL jump table for it ($FF00-$FFF3), so that it doesn't matter where the implementation is located. $E18E in the KERNAL symbols points to the implementation, which will change in every new ROM version. The symbols in in BASIC and MONITOR are helper functions that bank switch to the KERNAL bank and call $FF29. They will also change with every version.
  2. The X16 supports all C64 control codes plus a few extra ones, some of them borrowed from the C128 and the C65: https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#new-control-characters
  3. @SerErris: I just merged all open x16-demos pull requests that had no conflicts.
  4. I'd just post details and updates in this thread.
  5. I don't have the permission to give you this permission myself at the moment, but I'm happy to merge all your pull requests in the meantime.
  6. Of course, a simple 20-chip or CPLD framebuffer is not in line with the original vision of the X16, but the design of the X16 had been finalized a long time ago anyway. I appreciate this discussion for the experimentation its potential as a solution to attach several monitors! @Yamazaki, you are familiar with the Gigatron TTL?
  7. Maybe this is not the best example, but I develop the Commander X16 ROM using the ca65 assembler from the cc65 project. Unlike assemblers like acme, the ca65 assembler requires separate assembly and link steps, but since it's designed as the backend of a C compiler, it is extremely versatile. For debugging, my setup is probably the most uncommon: I exclusively use the -trace function of the emulator. It prints one line for every assembly instruction executed, with the label, bank, address, disassembly and register contents. In this mode, the emulator is about 10x slower than normal, so I have to script the emulator (-bas, -run, ...) to reach the interesting code as quickly as possible. I pipe the output of -trace into the Unix less tool, so I can search for symbols ("/") – the equivalent of breakpoints. I can search for the next ("n") or previous ("N") instance, and search for the point when code returns to the caller by searching for the bank and the first two digits of the caller address (e.g. .,02:de if the address of the caller is .,02:de24). If I missed the correct spot, I can always rewind – after all, it's all one big text file with all CPU history. Instead of less, I can also use grep, wc, uniq etc. to get statistics.
  8. And unless you have disabled the default IRQ handler, you don't need to call $FF53. Also, the reason you have to call $FF56 to get the state is because I want to move away from magic memory locations. Even the VIC-20 had an API to query the size of the screen, but it lacked calls for more advanced functionality. For the X16, I want to expose as much as possible/necessary through calls, so I have more freedom changing the memory layout in the future.
  9. I'm maintaining it. Well, until just now. Now you are. I maintain all four repos: x16-emulator, x16-rom, x16-docs and x16-demos. I tend to not multi-task too much, and I had been busy with other projects for months recently, which is why I haven't maintained x16-demos for a while. I am happy about any help with any of these repos. Of course I'm interested in code contributions, but also code reviews and general cleanup patches. And in the case of x16-demos: Someone/people who help in keeping the repo in order; mark demos as working/non-working with the current emulator, accept new additions and maybe remove obsolete demos. My plan for x16-demos has always been to compile it into demo sd card image once day that comes with the emulator.
  10. The ROM is designed in a way that (unlike on the Commodore 64), it should not be necessary to read/write any magic zero page ($0080-$00FF) or KERNAL ($0334-$03FF) variables. Well, at least this is the plan. I'm aware that not everything that people want to do is possible just using API calls. Whenever you run into this, please file an issue on GitHub against x16-rom. In this case, what you want is an API to inject keys into the keyboard buffer, which is a fair request. File an issue!
  11. Try ß, +, -, = ... those keys near the backspace key... If you're okay with warp mode being enabled for the whole session, you can specify -warp on the command line. If it really doesn't work on non-US/ISO keyboards, I can change the shortcut to something else in the next release. In this case, file an issue on GitHub against x16-emulator.
  12. There should be no breaking changes... except for one thing. IIRC, I had to disable loading into banked RAM or VRAM using the LOAD KERNAL API ($FFD5).
  13. I'm very very happy about pull requests. If you look at the release notes of the emulator and the ROM, you can see that many different people are contributing these days. Most emulator changes are done by people outside the core team. All reviewing and merging gets done by me, currently. I work on all parts of the ROM: KERNAL, BASIC, FPLIB, DOS, GEOS, MONITOR, CHARSET – and that's where most of the remaining work for the final ROM has to be done, while the emulator is in quite a good shape. That's why I only task switch to the emulator about once a week or so, looking at all pull requests that have piled up. But to say that again: I an very very happy about pull requests. And I'm also very happy about people pitching in and commenting on existing pull requests, e.g. saying that the code looks good to them, or what they would change, so I can spend less time reviewing the code.
  14. r38 has been released and contains the new "CMDR-DOS" features when you use the emulator with an SD card image. Also, the following features are now included: Open file for appending (,P,A). Show/change disk name. mkfs (N) timestamp support It still doesn't do block read/write API because I need to think about what API should be implemented. The Commodore one is very limited. And there's a better sd2iec-specific one. And I don't plan to implement: validate/fsck (V) REL files as these features are not very useful.
  15. r38 of the X16 emulator and ROM have been released.
×
×
  • Create New...

Important Information

Please review our Terms of Use