Jump to content

Stefan

Members
  • Posts

    339
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by Stefan

  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.
  15. This is the most minimal working example I can come up with. https://gist.github.com/stefan-b-jakobsson/1edce0e1278d62b6c0b137af8d267598 You must attach an SD card to the emulator when doing this. Sequential access to host system files hasn't worked well for me.
  16. What would you like that code to do? It's not writing anything to the file and it's not closing it. Opening a file for serial write might need you to append ",s,w" to the file name like this: lda #12 ldx #<Name ldy #>Name jsr SETNAM jsr OPEN rts Name: .byte "test.tst,s,w"
  17. I had one of those when I was a kid. As I remember it, there was a cooling flange sticking up behind the keyboard you could cook all your meals on. It got that hot. Not that I was doing any cooking at that age
  18. There's some tools written for the X16 that work with files. You may find them in the Download section. Written by myself: X16 Edit - Text editor similar to GNU Nano BASLOAD - Tokenizes BASIC programs stored as plain text files; uses labels instead of line numbers Written by others: File based assembler by desertfish Volksforth ported by pzembrod CC64 by pzembrod - a small C compiler BASIC Preprocessor by Scott Robison LED - a line editor by Michael Parson Maybe some of these are interesting for your project
  19. AFAIK it's not possible to SYS into another ROM bank. You need assembly for that. There's been some discussion on Discord about a BASIC command that addresses this issue. Michael Steil has said that he prefers a separate BANK statement that affects SYS, POKE and PEEK.
  20. To be clear, in (2), the glue logic you are talking about could it be something like this? A sufficiently wide address decoder. The decoder output and the micro controller "request RDY" pin is run through a NAND gate The NAND output is connected to the 65C02 RDY pin (active low).
  21. Seems reasonable you could use the RDY pin for this purpose, if it can halt all operations as you describe. The first option---doing this without clock stretching---I do not fully understand. If the SMC is to drive the data bus without clock stretching, even to put just a one bit ready signal there, mustn't that be done within the strict timing limits that @Wavicle discussed above? And if the SMC was to drive the data bus outside those timing limits, wouldn't that corrupt the data bus? EDIT: Another thing. In (2) I suppose the SMC must drive the RDY line within the 65C02 timing limits, that is 4--5 clock cycles for a microcontroller doing 100 MHz, according to @Wavicle above. Could that be a problem, as the SMC has several interrupt driven tasks it's running in parallel---being a host=slave for two PS/2 devices? The SMC could easily spend more than 5 clock cycles handling an incoming PS/2 bit at the same time the 65C02 wants to read a value.
  22. Will that kind of solution require you to slow down the 65C02 clock? How would you do that?
  23. Just of curiosity, what timing requirements are there, if you would like to put a SMC on the data bus? Must the state of a pin be changed within half a clock cycle 1/8,000,000/2 = 62.5 ns? But there's also the clock stretching...
  24. OK. I was thinking of utility programs designed to work with the shell. At the moment you have the command that starts the editor. It will work only if the program is stored in the current directory. In the future you may have other utilities that can be started from within the shell. I just thought it would easier to store these programs using an absolute path.
  25. Great work, already a lot of convenient functions. Have you considered deciding an absolute path for a folder to store utility programs run by the shell?
×
×
  • Create New...

Important Information

Please review our Terms of Use