Jump to content

Stefan

Members
  • Content Count

    156
  • Joined

  • Last visited

  • Days Won

    6

Stefan last won the day on January 12

Stefan had the most liked content!

Community Reputation

94 Excellent

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.

  1. I think I finally got it. FETVEC should not contain the MSB of the address you want to look up, but a zero page address that in its turn points to the address you want to read. A working example reading bank 6/address $c000: ;Setup ZP pointer stz $22 lda #$c0 sta $23 ;Call FETCH lda #$22 ;ZP pointer ldx #$06 ;ROM bank ldy #$00 ;Index for the indirect load jsr $ff74 ;Fetch call address ;Store return value sta $6000 rts
  2. I've been trying to use the KERNAL FETCH function for some time. But I can't get it to work. This is my test code: lda #$c0 ldy #$00 ldx #$06 jsr $ff74 sta $6000 rts Reading the KERNAL source code, it seems that the calling address is $ff74, not $ff77 as stated in the PRG. Following the path of execution from ROM bank 0/$ff74, it seems that the value in .A is stored in the FETVEC, and that you need not store it yourself before calling the function as stated in the PRG. When running this, I expect the function to fetch the value in bank 6 (.X) at address $c000 (MSB in .A) + .Y and store it in RAM address $6000. But it doesn't. Neither does it work when I try following exactly what's said in the PRG.
  3. Hi @LRFLEW I think the technique described by @Lorin Millsap would not work for VERA D0 & D1, because it is write only communication to the connected I/O.
  4. I've now made a pull request to include support in the emulator for Delete, Insert, End, PgUp and PgDn keys. I've also updated X16 Edit to support those keys. This code works only if run in the current master branch of the emulator and Kernal, i.e. what will become R39.
  5. Some notes on my progress supporting END, PagUp and PagDn. From the emulator source code, it's apparent that those keys are discarded. See file keyboard.c, function ps2_scancode_from_SDL_Scancode. I made the following minimal change to that function, and recompiled the emulator: case SDL_SCANCODE_END: return 0x69 | EXTENDED_FLAG; That emulates PS/2 scan code E069 when the END key is pressed. The good news is that I could successfully detect the END key in X16 Edit. Most probably, this will work on the real hardware out of the box.
  6. X16 Edit supports that kind of function with the ESC key. You may press and release ESC and then any of the command keys.
  7. Hi @evlthecat. You cannot change the behavior of Ctrl+R in the Windows and Linux emulators from within a program that runs in the emulator. You would need to change the emulator itself. I hope that the real hardware will not have this problem. Finding other suitable shortcuts not interfering with any existing Ctrl+key sequence in Windows or Linux is a bit hard. I'm already using most available Ctrl+key combinations! And we would move away farther from GNU Nano. I don't know if it's a good solution, but it would be possible to support several modifier keys in parallel. That would make it possible to use, for instance, the Win key as an alternative to Ctrl. Which of the other modifier keys (Alt/Win/AltGr) would have least interference with Windows/Linux and the Kernal? I'm not sure. That requires some research.
  8. Thanks. Ctrl+V works in the emulator for me. I'm using MacOS. I know that the emulator behaves a bit differently on Windows and Linux. We would need to know if it works on the real hardware before changing it. END is supported for now by Shift+Home. This is because the Kernal ignores the END key. It seems R39 will include support for custom PS/2 scan code handlers, that let you catch a scan code before it's processed by the Kernal. This could be used to enable support for the real END, PageUp and PageDown keys even though the Kernal ignores those keys.
  9. I've been trying to adjust X16 Edit for the upcoming R39 Emulator+Kernal. As far as I can see, there are no issues whatsoever. I attach my R39-test (sources on Github in branch "prepare-for-R39"). https://github.com/stefan-b-jakobsson/x16-edit/tree/prepare-for-R39 Running it requires you to download and compile both the emulator and the Kernal from Github. If you haven't noticed, @Michael Steil merged most pending pull request for the Kernal during the end of last week and the weekend. I guess he is actively working towards R39. Happy times! X16EDIT-R39-TEST.PRG
  10. OK. Haven't tested it much, but there are no obvious artifacts.
  11. I tried to run my program X16 Edit on the emulator+Kernal at their current state on Github. It was easy to get it working. In my case, only changing the address in the definition of RAM and ROM bank select.
  12. This page has great info on the low level workings of the PS/2 interface: https://www.avrfreaks.net/sites/default/files/PS2 Keyboard.pdf There are only a few generally supported host to device commands. Most of them are not very useful. The two most interesting commands might be: 0xF3 <byte value>: Set key repeat rate and delay 0xED <byte value>: Turn on/off Num Lock, Caps Lock and Scroll Lock LEDs
  13. Hi @SlithyMatt The keyboard interface was discussed recently in these threads: https://www.commanderx16.com/forum/index.php?/topic/909-how-does-ps2-keyboard-interface-work/ https://www.commanderx16.com/forum/index.php?/topic/1156-are-ps2-host-to-device-commands-supported-in-the-emulator/ After reading the Kernal source for some time, I have come to the following conclusions: The Kernal doesn't control key repeat in any way PS/2 keyboards have key repeat built in In order to control the repeat rate, you need to send a command from the host (=X16) to the keyboard There is no support in the Kernal for sending commands to the keyboard, but you could implement it yourself. To test this you would need the real hardware, as the emulator doesn't seem to react to such commands. The counter initialized to 10 you refer to might by the one at kernal/drivers/x16/ps2.s line 56. If this is the point in the code you mean, it is actually initialized to 10 * 8 = 80. As far as I understand, the Kernal in this loop repeatedly polls the PS/2 lines looking for a start condition set by the keyboard. If no start condition is found before the end of the loop, the Kernal disables the PS/2 communication until next VBLANK interrupt. And the Kernal reads only one scan code during each VBLANK. One scan code may consist of several bytes though. I tried to manually calculate the time the Kernal spends in that loop waiting for a start condition, and came to 110 us. I've read that a PS/2 device should not start communication until 50 us after the clock line is released by the host, so 110 us seems to be a reasonable number.
  14. A small correction to my previous post The ps2_receive_byte doesn't poll the PS/2 state 10 times, but 10 times multiplied by processor frequency in MHz => 80 times in total Manually calculating the cycles spent in the polling loop, I got 11 cycles per loop (more if the code would be split over a page boundary) That sums up to 880 cycles equivalent to about 110 us @ 8 MHz I've read that a PS/2 device is required to buffer data to be sent if the host holds the clock line low, and that transmission should begin not before 50 us after the clock line is released The Kernal is waiting and polling the PS/2 state for about 0.66% of the total VBLANK (0.01667 s @ 60 Hz), if my calculations are right (= 0.00011 s / 0.01667 s). And probably double that time if we take into consideration the PS/2 mouse
  15. I think the Kernal (R38) currently does the following. At system startup: ioinit function is called (kernal/cbm/init.s:20) ioinit function calls ps2_init function (kernal/drivers/x16/x16.s:27) ps2_init disables all PS/2 communication by pulling clock pin low and data pin high (kernal/drivers/x16/ps2.s:27-38) As far as I understand, the PS/2 communication stays in this state until VBLANK: The function kbd_scan is called as part of the IRQ handler (kernal/cbm/irq.s:50) kbd_scan calls _kbd_scan (kernal/drivers/x16/ps2kbd.s:49) _kbd_scan calls receive_down_scancode_no_modifiers (kernal/drivers/x16/ps2kbd.s:126) receive_down_scancode_no_modifiers calls receive_scancode (kernal/drivers/x16/ps2kbd.s:261) receive_scancode calls ps2_receive_byte (kernal/drivers/x16/ps2kbd.s:225) ps2_receive_byte is the function that actually fetches PS/2 data: First it releases the clock and data pins (kernal/drivers/x16/ps2.s:51-53). As you might remember, these pins were pulled low and high at system startup. The function polls the state of the clock and data pins at most 10 times (kernal/drivers/x16/ps2.s:55-60) looking for a start condition (clock and data low). I guess 10 times is a timing issue. I haven't done the math on how much time is really spent in that loop before aborting. If no start condition found within the 10 loops: Branch to line 98 where the ps/2 disable function is called, the same that disabled PS/2 communication at system startup If start condition found: 8 bits and 1 parity bit are read and stored (kernal/drivers/x16/ps2.s:62-81) ps2dis is called to disable PS/2 communication again (kernal/drivers/x16/ps2.s:82). And finally the function returns after loading the received byte into A Some conclusions: The Kernal isn't faking it. It reads a byte bit by bit, as you would expect PS/2 communication is disabled almost all the time by the Kernal pulling the clock and data pins The Kernal only releases the clock and data pins every VBLANK to read the keyboard It reads the keyboard by polling the state for a period of time that is sufficiently long to follow PS/2 standard The above suggests that there is no special IRQ line driven by the keyboard. I'm sorry if I have misunderstood any aspect of how this works. It will be interesting to see what changes, as the team is redesigning this code according to @Lorin Millsap above in this thread.
×
×
  • Create New...

Important Information

Please review our Terms of Use