Jump to content

Stefan

Members
  • Posts

    340
  • Joined

  • Last visited

  • Days Won

    10

Stefan last won the day on July 31

Stefan had the most liked content!

1 Follower

About Stefan

  • Birthday 01/03/1973

Recent Profile Visitors

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

Stefan's Achievements

Enthusiast

Enthusiast (6/14)

Conversation Starter Dedicated Very Popular Rare First Post Collaborator Rare

Recent Badges

230

Reputation

4

Community Answers

  1. Are you referring to page page 14 and 20 here? https://archive.org/details/Commodore_1541_Disk_Drive_Users_Guide_1982-09_Commodore/page/n25/mode/2up Yes, I suppose they meant you should access sequential files using secondary address 2-14. But at least on the X16, you may also use SA 0 and 1, and then you don't need appending S,R and S,W. I don't remember if that worked on the C64 as well.
  2. It’s hard to find good documentation on the secondary address set by SETLFS. I only have my own experiments: 0 = read file 1 = write file 3-14 = read or write, set by appending S,R or S,W to the file name 15 = Command channel
  3. I think address 19 (decimal) was called CHANNL on the C64. On the X16 you can't really write code that directly uses that kind of RAM address, as it is subject to change between ROM versions. An example to illustrate this: In the last ROM image build I did some weeks ago, CHANNL was $03DD. POKE $03DD,32 removes the question mark from INPUT. But in the R41 ROM, CHANNL was $03DE. POKE $03DE,32 then removed the question mark.
  4. This might be a better trampoline for RAM bank to RAM bank calls. I think it should preserve all registers, which normally is a good idea. https://gist.github.com/stefan-b-jakobsson/e8b216086b4f3497cd0f4833180bc1f1
  5. I have this code, but it's very specific to my needs. https://github.com/stefan-b-jakobsson/x16-edit/blob/master/bridge.inc label "bridge_kernal" at lines 46 to 53. I'm using the macro "bridge_setaddr" defined here to set the target address: https://github.com/stefan-b-jakobsson/x16-edit/blob/master/bridge_macro.inc It's only used to call code in the Kernal ROM bank (0) from another ROM bank where the X16 Edit ROM version is stored. I think you can easily adopt this to your own code to make a very compact trampoline function. My code is a bit more complicated, as I'm using the same code both for the RAM based and the ROM based version of the editor. There's just an assembler option selecting if I'm building the RAM or ROM version. You might not need that. EDIT: Please note that my trampoline code isn't guaranteed to return the correct value of P (Processor Status). For instance if the called function puts its return value in X or Y, the Z flag will be affected by the trampoline pulling A from the stack.
  6. Lets say the PC is at 1:a000. The code does an LDA #2 and then STA 0. The PC is now a004. What happens next? I would say execution continues at 2:a004, and that the bank 1 code immediately loses control
  7. If at all possible, I would place all code in low RAM and only data in banked RAM. Switching RAM banks in this context is fast and easy to do. If the code doesn’t fit in low RAM, I guess your strategy to place code and connected data in the same bank could work, but it will be more complicated. You would at least need some bridge or trampoline function in low RAM when calling code from one bank in another bank.
  8. JSRFAR is fairly expensive. I've manually calculated it to be about 184 cycles calling code in another ROM bank. In many cases you could make your own "bridge" function with less overhead if you need to speed up bank switching
  9. Yes, I also noted a difference. The help text I successfully decompressed is pure ASCII of about 1.7 kB (uncompressed)
  10. This is the result of lzsa -r -f2 intro_back.bin intro_bg2.bin In the memory_decompress source code comment, it's said you should use the -r and -f2 options. intro_bg2.bin
  11. I've used the Kernal decompress function without any issues to unpack a help text to banked RAM. I've not tried to do anything else with it though. Looking at the source code for memory_decompress in the file kernal/lzsa.s: Line 52-57: If output address MSB (r1H) is $9f it sets register r3 to the address of putdst_io, else putdst_ram This will happen if the destination is anywhere in the $9f00 page putdst_ram stores a byte and increments the destination address. putdst_io will never increment the destination address I guess decompress will work only if the destination address is $9f23 (DATA0) or ($9f24, DATA1, if you're using that) And it will only work if you set an auto increment value Are you doing all of this, and it still doesn't work, we might have a bug in the Kernal.
  12. PRINT CHR$($0F) activates ISO mode
  13. The code for a BASIC BANK statement very similar to what TomXP411 mentioned above was merged into the Kernal master branch some 16 days ago. I suppose it will be part of R42. https://github.com/commanderx16/x16-rom/pull/340
  14. I've been working on an updated user manual for X16 Edit. https://github.com/stefan-b-jakobsson/x16-edit/blob/master/docs/newmanual.pdf As English is not my native language, I just want to reach out asking if someone would like to help me convert it to proper English.
×
×
  • Create New...

Important Information

Please review our Terms of Use