Jump to content

Michael Steil

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Michael Steil

  1. It would be cool to add 128 additional drawing characters instead of having the inverted copy of the lower half in the upper 128 characters like on the C64 etc. True, you can swap foreground and background colors and have the same effect as inverted colors. In fact, the following code: PRINT "HELLO "; CHR$(1); "WORLD"; CHR$(1); "!" (inverting fg and bg) produces the same output as PRINT "HELLO "; CHR$(18); "WORLD"; CHR$(146); "!" (switching to upper half of character set) The problem though is that the screen editor needs to be able to convert inverted characters inside quotes into control codes. If you type this: PRINT"{SHIFT+HOME}" It will show as an inverted heart. Once RETURN is pressed, the character gets converted into code 147. The editor can do this because it detects that the character in screen RAM is inverted, i.e. from the upper half of the character set. For this to still work, the editor would have to be changed: When the editor wants to show these kinds of control codes, it must swap fg and bg instead of using upper half character codes. When the editor has to convert screen RAM contents into PETSCII (control) codes, it has to check whether the codes have their fg and bg swapped. Now the problem is the last part: The user can change colors and swap fg and bg as much as they like. How would the editor know which fg/bg combination is normal, and which one is reverse? Today, you can hit Ctrl+A, then clear the screen, and all text has swapped colors. Yet a heart character should only be a heart, and not the clear-screen code. Maybe the editor should compare the color of the screen cell with the current cursor color – if has fg and bg swapped, it's a control character. But what if it's any other combination? Examples: The cursor is white on blue, and the text on the screen is yellow on blue. This should be regular text. The cursor is white on blue, and the text on the screen is blue on yellow. Is this inverted? The cursor is white on blue, and the text on the screen is yellow on black. What is this?
  2. Yes, the releases have matching ROM and emulator versions. Be careful to negate the number in case it's negative, and then compare it with e.g. 38 or 39. Future versions may use positive numbers. Non-official builds use $FF as the version, yes. The next ROM and emulator will be -39. In order to detect Proto #1 vs. Proto #2, check for abs(version) >= 39. This will work for all released emulator + ROM versions. I'm aware that this check won't work for non-official builds.
  3. Can you please put this comment into the pull request on GitHub? Thanks!
  4. The current "master" branches of the x16-rom, x16-emulator and x16-docs repositories now correspond to the "Proto #2" hardware, which is incompatible with the "Proto #1". banking is now done though zero page addresses 0 and 1 instead of VIA GPIOs the I/O area at $9F00-$9FFF has changed in layout (except VERA) the layout of the VIA GPIOs has changed 4 SNES controllers are supported there is now a real-time-clock – but it is not yet supported by the emulator or ROM If you have software that does manual banking or accesses I/O devices (other than VERA) manually, you will need to update it in order to be compatible with the next emulator/ROM release (r39) as well as real hardware. The Programmer's Reference Guide should have all the necessary information. Please file bugs on GitHub if you find any issues. Thanks!
  5. 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.
  6. 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
  7. @SerErris: I just merged all open x16-demos pull requests that had no conflicts.
  8. 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.
  9. 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?
  10. 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.
  11. 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.
  12. 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.
  13. 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!
  14. 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.
  15. 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).
  16. 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.
  17. 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.
  18. r38 of the X16 emulator and ROM have been released.
  19. 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.
  20. 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.
  21. 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.
  22. 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?
  23. 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.
  • Create New...

Important Information

Please review our Terms of Use