Jump to content

Michael Steil

  • Content Count

  • Joined

  • Last visited

  • Days Won


Michael Steil last won the day on March 29

Michael Steil had the most liked content!

Community Reputation

109 Excellent

Recent Profile Visitors

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

  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'd just post details and updates in this thread.
  9. 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.
  10. 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?
  11. 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.
  12. 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.
  13. 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.
  14. 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!
  • Create New...

Important Information

Please review our Terms of Use