Jump to content

Michael Steil

Administrators
  • Content Count

    30
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Michael Steil

  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 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.
  5. 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?
  6. 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.
  7. 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.
  8. 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.
  9. 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!
  10. 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.
  11. 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).
  12. 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.
  13. 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.
  14. r38 of the X16 emulator and ROM have been released.
  15. The current implementation in the repository can read about 140 KB/sec if you go through the LOAD or macptr KERNAL calls. The fast path doesn't currently support high RAM or VRAM, but I plan to fix this. The theoretical maximum if the hardware is about 300 KB/sec by reading full sectors to the target addresses instead of going through a buffer. I might look into supporting it. The byte-by-byte slow path will max out at about 13 KB/sec.
  16. Here's a handy PETSCII/Screencode/Charset reference (disclaimer: my site): https://www.pagetable.com/c64ref/charset/ The X16 uses the same encoding and an almost identical charset.
  17. I had put some NTSC support into the emulator originally, but I'm afraid this has bit-rotten away after many optimizations to the VERA code. Someone would have to start fresh with this feature. The biggest difference is interlacing, which messes up raster line timing enough to easily confuse games that use raster interrupts, for example. That's any implementing NTSC in the emulator is actually important.
  18. There is currently no support for RS232 in the X16 KERNAL. Initially, the VIC-20/C64 software 6551 emulation was still in the source, but never working, because it needs tight integration with a timer on the 6522 and NMIs. When VERA got an RS232 port integrated, the emulation was replaced with a VERA driver When VERA removed the RS232 port again, that driver was removed from the KERNAL. So we don't currently have any support for RS232 in the KERNAL. That said, I'd love to have a software implementation, but it should be based on something like UP9600 rather than Commodore's VIC-20/C64 code. Pull request, anyone?
  19. Yeah, SCREEN $80 changed the fg and bg colors. The bg color has to be 0 (transparent, so the graphics below shines through), and the fg color has to be something other than 1 (white, otherwise it's white-on-white), so SCREEN $80 sets the colors to light blue on transparent, ignoring what was set before.
  20. Yeah, assembly in-line with a BASIC program is a great concept, but I agree with @TomXP411 that this overlaps significantly with the other assembly IDE in the system. Then again, maybe the core code there could be reused and called from BASIC?
  21. TI$ and DA$ are BASIC frontends to these exact functions, so you should rather use them. If the time is too fast, that's surprising. If your computer is too slow for real-time emulation, time will run too slowly (which is expected and correct), but it shouldn't be too fast. Can you measure it, and a file a bug on GitHub against the emulator?
  22. The Emulator and the ROM have been adapted for the new board. You can check out branches x16_board_r2 in the source of the two projects. The official reference manual has also been updated. In short, these are the major breaking changes: RAM and ROM banking is done through magic zero page locations 0 and 1. Up to 512 KB of ROM are now supported. VIA#1 is now at $9F00, VIA#2 at $9F10 YM is at $9F40 All I/O (PS/2, Controllers, Serial) has been moved to VIA#1 PA and PB.
  23. I don't personally use built-in debugger for my development (I use "-trace" for everything), so it's unlikely I'll get around to adding this myself, but I'd be happy about a pull request!
  24. Maintenance releases? How about more regular releases? I'll try that!
×
×
  • Create New...

Important Information

Please review our Terms of Use