Jump to content

pzembrod

Members
  • Content Count

    52
  • Joined

  • Last visited

  • Days Won

    1

pzembrod last won the day on November 16 2020

pzembrod had the most liked content!

Community Reputation

51 Excellent

1 Follower

Recent Profile Visitors

140 profile views
  1. Update: I've uploaded version v0.9 of cc64 that is based on VolkfsForth 3.9.3 and should work in R39 and proto2 just as well as in R38 and proto1.
  2. Update: I've uploaded version 3.9.3 of VolkfsForth that applies the above and should work in R39 and proto2 just as well as in R38 and proto1. An updated version of cc64 will follow soon.
  3. I got hold of a surplus VIC20 main board and a C16 keyboard at a local electronics outlet in Freiburg, southern Germany, around 1990. I mated the two and patched the keyboard table so the layout matched. Alas, I don't have it anymore, but I guess this would qualify as odd and rare to some degree ... And one of my more priced possessions is a Sharp PC1260 complete with CE-125 docking station with micro cassette recorder, printer and extra battery.
  4. Hi Phil, in case you're interested: Both VolksForth and my cc64 Small C compiler run on the Plus4, too. The 59 kB of contiguous Basic RAM there are great for both; cc64 was, in fact, easier to port to the Plus4 than to the X16.
  5. Welcome, & greetings from southern Germany!
  6. Hi Wouter, welcome! Your intro makes me curious: What other languages have you programmed in? Cheers /Philip
  7. Hi Scott, I'm sorry myself if I came across as miffed or something. You had described so precisely the approach I had taken to avoid the pitfall that @ZeroByte correctly pointed out that "That's exactly what I'm doing" jumped into my mind and keyboard. Rereading it, I realize that it has a ring to it that I hadn't intended. Thanks again to both of you, this was very helpful input.
  8. That's exactly what I'm doing: I'm treating each assumed bank registers separately, storing and restoring each independently of the other one, and setting them both to a desired bank when I want to access that bank. Half of that code is, of course, an elaborate noop, but one of the two halves should get the job done, and the two halves shouldn't get into each others' way.
  9. Ah, that's great, thank you for looking into it, @ZeroByte!
  10. Hi all, and @Michael Steil I hope you don't mind if I loop you into this directly, as it involves a bit of KERNAL API design thoughts. While preparing to wrap up work on the R39-compatible v3.9.3 of VolksForth (and subsequently cc64), I thought I'd try to fix one ugliness that I accepted when initially porting it to the X16: Switching cursor blinking off cleanly. Here's what VolksForth does on all CBM machines when fetching a character from the console: It switches on the cursor and goes into a loop until a key press is detected, then get that key and switch the cursor off again. (Why like this, why not just a JSR BASIN? Because, in that loop, there's also a PAUSE which hands off control to VolksForth's cooperative multitasker.) Now for the most part this works nicely on the X16. I'm using the KERNAL var BLNSW at $037b (I know, KERNAL vars are potentially subject to change), and the cursor comes online nicely and stops blinking again, as expected. The problem is: If it gets switched off while in inverse mode, that inverse character on the screen stays. So far this hasn't caused real problems, but it's ugly. On the C64 this is solved simply by taking the original character under cursor from GDBLN (C64: $ce, X16: $037d) and storing it at the screen address pointed at by PNT (C64: $d1/d2, current screen line address) and PNTR (C64: $d2, current col in screen line). Obviously, with VERA this is a bit more involved on the X16. Now, today I've dug again pretty deep into the relevant KERNAL code in editor.s and screen.s, and it seems the only way I could achieve the same would be by replicating some of the code in cursor_blink: and pretty much all of screen_set_char:. But doing that seems pretty wrong to me. Now my first question is, of course: Did I miss anything? And the follow-up: Would it make sense to make some more screen-related VERA functionality available via KERNAL API? Semi-related: I would e.g. also love it if I had direct screen output and keyboard input calls available, bypassing the CBM channel I/O. Any input appreciated Cheers /Philip P.S. Here's the code: Key reading loop: https://github.com/pzembrod/VolksForth/blob/master/6502/C64/src/vf-sys-cbm.fth#L8 C64 curon/off: https://github.com/pzembrod/VolksForth/blob/master/6502/C64/src/vf-sys-c64.fth#L50 X16 curon/off (as yet): https://github.com/pzembrod/VolksForth/blob/master/6502/C64/src/vf-sys-x16.fth#L70 (note that 6502 VolksForth's inner interpreter that calls these words leaves X=0 and Y=1)
  11. @AndyMt I got VolksForth to work uniformly with R38 and R39 yesterday. While looking at my code, I realized that I have the simple and robust opportunity to just operate both bank switching addresses $0000/1 and $9f60/1 in tandem; this seems to work nicely and seems good enough to me for the transition period. See https://github.com/pzembrod/VolksForth/commit/fb100de9edc92dfb8db25ed97e6b7f0a4b3085fa for details. @Michael Steil One question about this approach: It seems clear to me that writing to $0000/1 has no adverse effects in R38 as there's just 2 unused RAM bytes there. How about $9f60/1 in R39? That would write to as yet unimplemented/uninstalled I/O devices in the expansion slots, right? Also, follow-up question: It seems that the release of R39 is imminent? If so, then I can hold back releasing the next VolksForth version (and, subsequently the next cc64 version) until R39 is out, and include the cleanup https://github.com/forth-ev/VolksForth/issues/33 of the temporary double switching in my next releases already.
  12. Thanks, @AndyMt, for the thread pointer; I'll join the discussion there. Thanks, @rje, as well for the code snippet.
  13. Hi all, is there any pragmatic way how a program could easily tell whether it is running on proto#1 or proto#2, i.e. where the bank switching ports live, whether at 0000/0001 or 9f60/9f61? This could be handy for the transition period. I'm thinking whether I can avoid providing two different versions of VolksForth and cc64. Even just setting up two different build targets just for an interim period could turn into a major hassle, hence my question. Cheers /Philip
  14. Update: I haven't created a new release yet, but I would encourage folks to give the current v0.9-dev version a try, as it features a significant compile speed increase: https://github.com/pzembrod/cc64/blob/v0.9-dev/cc64-x16files.zip https://github.com/pzembrod/cc64/blob/v0.9-dev/cc64-x16files-sdcard.zip
  15. Hi, after contributing a bit I figured I'd follow up with an introduction after all. My first programming environment was Pascal on our high school's PDP-11, and 2 months later I got a C64 as my first own computer. A desire for Pascal on the C64 may have been part of the reason for my early fascination with programming languages and compilers, which led to cc64, which in turn led to encountering Forth, my areas of activity on the X16. By education I am a physicist, but I have mainly ever made software for a living. I wrote a lot of assembly for 6502 but little for any other processor. Building an RC2014-style 6502 homebrew and dabbling a bit in microcontrollers is on my hacking wish list for the future. Cheers /Philip
×
×
  • Create New...

Important Information

Please review our Terms of Use