Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

981 Excellent


About vitoco

  • Rank

Contact / Social Media

Profile Information

  • Gender

Recent Profile Visitors

7,715 profile views
  1. Three different controllers can be used by this other project: Wiimote, PS3 and PS4... simultaneously!
  2. The same happens with the latest ROM available through the PlusCart (currently 6_29_21) in my 7800. BTW, there is a way to detect the QuadTari device. Is there an attempt to detect it before allowing the selection of the J/Q options? I also noticed that if I move the joystick in J mode while the button is pressed, no trigger action is displayed, only the buzzer is heard. The same happens when the Reset button of the console is kept down.
  3. Hi! I tried it with a Quadtari in my 7800, and it didn't work in Q mode like in the show. I had to keep pressed the PAUSE button (replacement for the TV type swithch), but I just want to let you know...
  4. I'd named it "Jawbreaker J" Thanks!
  5. In another post, I wrote the following while testing keys and buttons in 5200 mode: I think this is a bug in Altirra, because the same "lock" behavior also happens when using the Cold Reset option from the System menu while pressing the shift key in the keyboard (before going to the menu).
  6. I'd like to see "Where's my Cheese? II"
  7. Thanks for all that info... I could write a deferred VBI to map all the controller buttons into shadow registers and map almost all of them to existing Fastbasic functions. To test them, I wrote a small program that checks for every input using that functions. Cartridge image attached... SKSTAT bit 2 doesn't work for 5200 controllers (bit 3 is the latched SHIFT state). A typo... I meant bit 2 as you pointed out. Because of that, I had to replicate the CH, CH1 and KEYDEL shadow registers for each of the four controller's keypads. I found that sometimes a pressed key from one stick was also assigned to the next one. To avoid that, I finally had to disable all the IRQ at the beginning of the VBI and reenable using POKMSK ($40) at the end, with the change of CONSOL in between. Even though this seems to work in Altirra, my test program was run in real hardware and it still happens. How could I be sure that the keyboard was readout before changing CONSOL? I'm not sure I understood that statement. BTW, there is a strange behavior with the 2nd button of the sticks. Even though I could read them and assign to shadows, when I perform a Cold Reset (pressing Shift-F5 in Altirra), it seems that bit 3 of SKSTAT remains high even when bits 0-1 of CONSOL change, so all the upper triggers appears as pressed... until one of them is really pressed. It seems to be an issue in Altirra due to the fact that the Shift key was pressed at the moment of the Cold Start. It does not happen when I use the option from the System menu. Thanks again! iotest.car
  8. What about the multiple keypads? Can each joystick create its own keyboard IRQ? What happens when a key is pressed almost at the same time on different joysticks? Does this depends on the current bits set in CONSOL register to select a keypad? What should I expect when checking bit 3 (key still pressed) of SKSTAT? BTW, I'm iterating through all the controllers by changing bits 0 and 1 in CONSOL (yes, four controllers), one per frame, through the deferred VBI. Thanks for the help!
  9. Thanks! That gave me a hint of what was happening. The problem was that Fastbasic runtime was resetting SKCTL register and enabling the debounce bit each time I played a sound. This is from 5200 ROM: ;Keyboard Interrupt lda #$BF ; (this is $40 EOR $FF) sta IRQEN ;Clear IRQ lda $00 ;Get POKMSK sta IRQEN ;Set IRQEN from shadow ($40) jmp ($0208) ;Jump to Keyboard IRQ vector Which is the idea behind the double store in IRQEN, once with the inverted bits and once with the value at POKMSK? This happens on every kind of interrupt.
  10. I decided to keep the NMI and IRQ handlers from the 5200 console, but I'm quite frustrated. I added a deferred VBI to handle some of the required feaures, and that seems to work OK, but problems started when I tried to manage the keyboards, starting with the one of port 1 only. I set up a small keyboard routine for the NMI and sometimes I can read all the keys I press, including the 2nd action button, but sometimes I can read just the first key I press, and then nothing!!! There is no interrupt for the following keys. The only difference is that DLIs are enabled when they don't work. I've set in Altirra some write breakpoints into registers like IRQEN to find unintended bit changes, but now I'm thinking that there is some correlation of events I'm not aware. Hints?
  11. Cool! I was surprised with the bottom half of the case. How long this project took? There were too many t-shirts... Where did you set the "Alt" key for the Pi?
  12. When I type an address in the Disassembly window of the debug mode, I got a source listing with that address in the middle. The problem appears when I want to set a breakpoint some pages below: at the click on the required instruction, the listing scrolls back to the typed address, and that was because the focus remained in the combo box. A workaround is to click once in the listing after typing the address to change the focus and then scroll the window looking for where to set a breakpoint. This issue does not happen with Memory windows. I'm not sure if this has been reported... or if it's WAD.
  13. Just guessing: It looks like this "multicart" is just a RAM cartridge for systems with less than 48K, so the dumped ROM could be loaded back into the computer.
  • Create New...