Pokun wrote: Mon Jan 13, 2025 8:33 am
I guess the pointer method would work something like this:
Looks pretty much like my second idea.
TakuikaNinja wrote: Mon Jan 13, 2025 5:04 pm
It should be noted that modifying ISR pointers at runtime, especially while NMI/IRQ sources are enabled, is prone to race conditions where an interrupt occurs before both bytes of the pointer have been written to. This is probably part of why the FDS BIOS opted for a vector selection system using the upper 2 bits of a separate variable (checking with BIT on entry to preserve registers). Taking the NMI as an example, it uses the value at $0100 to select between 1 BIOS ISR and 3 disk game ISRs (4 total). The disk game ISRs that are not selected can be freely modified before being selected using the variable. Just some food for thought.
Of course, I didn't think about that and would have ended up with the race condition. I have opted to emulate that implementation.
I'm thinking that some form of reset detection would be nice as well. Perhaps something like resetting the vectors but not clearing RAM so that the user can recover from mistakes in the absence of save states.
How to avoid a race when modifying a 3-byte NMI vector in RAM, without writing to $2000 to disable the vblank NMI:
Write rti opcode to address A.
Write the new jump destination to address A+1 and A+2.
Write jmp opcode to address A.
This won't work to avoid a race when modifying the IRQ vector because IRQ is level-sensitive and the IRQ will immediately fire again unless the interrupt source is acknowledged. Instead, use sei as usual.
I think that way of rewriting the interrupt addresses assumes that it is being done programmatically, so the program would continue to make the changes even if interrupted by the NMI, while it's probably more likely the user would be manually altering the bytes.
Anyway, I spent the last week porting msbasic and implementing Family Basic Keyboard and Keyboard Mouse Host support. Currently it is still targeting my single chip cartridge with 1k CHR-RAM, but I'll make a normal version with wider ASCII compatibility in the near future.
Nice! I guess the Famicom can't get enough of BASIC.
bitcores wrote: Sat Jan 25, 2025 2:36 am
I think that way of rewriting the interrupt addresses assumes that it is being done programmatically, so the program would continue to make the changes even if interrupted by the NMI, while it's probably more likely the user would be manually altering the bytes.
Maybe if you implement a BIOS subroutine that does it and can be called by the user with specified address instead of the user altering bytes directly.
I hope everyone's keyboard interfaces have been doing fine.
I haven't been working on the code for it lately because I have been working on implementing save/load functionality for the MSBasic fork based on Family BASIC.
What I am unsure of is how to do the circuit to add the line in/out portion (likely I will combine them into a single jack on my PCB designs).
I could copy the circuit within the Family Basic Keyboard http://cmpslv3.stars.ne.jp/Famic/Fcbio.png though some portion of it seems unnecessary outside of the larger keyboard circuit.
Or I could use the example circuit for the NES expansion port https://www.nesdev.org/tapedrv.PNG
Basically, I want someone to break my deadlock on which way to go.
The choice of LM358 (opamp used as comparator) vs 4069 (digital inverter) is immaterial here - both are fine choices. They'll both have some amount of voltage supply noise. I might even grab a LM311 or other explicit analog comparator...
I'd choose based on PCB size, total component count, or total component cost, whichever makes it easier.
lidnariq wrote: Sun Jun 08, 2025 4:43 am
The choice of LM358 (opamp used as comparator) vs 4069 (digital inverter) is immaterial here - both are fine choices. They'll both have some amount of voltage supply noise. I might even grab a LM311 or other explicit analog comparator...
I'd choose based on PCB size, total component count, or total component cost, whichever makes it easier.
Could you drop in replace the LM358 with a LM311 in that circuit? Or would you want to make use of other chip functionality?
Anyway, I now have more LM358s than I will ever need.
LM358 is two opamps in one package, while the LM311 is one comparator in one package, so they're not exact matches. LM393 and LM2903 are pin-for-pin compatible.
But if already have a bunch of LM358s there's no reason not to use them; in both opamps misused as comparators and strict comparators it's the recovery from railing that makes them slow.
I tried the circuit with the LM358 but although I could record the writes, there was no sign of the data coming back on the read. I probably did something wrong, but I tried the Family Basic circuit (74HC04s instead of 4069) and while I am getting a datastream out now, the code I have working in Mesen isn't working on my Famicom.
Before I get too into writing debug code, I'm wondering if I can get pointers for the capacitor types and values in the circuit the Family Basic Keyboard uses. http://cmpslv3.stars.ne.jp/Famic/Fcbio.png
I seem to get better results using electrolytic capacitors, but maybe incorrect values will stretch the pulses and screw up the timing for probing the output. I'm not too sure.
--edit--
Ok, turns out the 4016.d1 pin inside the D-sub 15 connector on my interface got damaged internally somehow, so that's why the datastream wasn't being picked up by the Famicom, so problem solved. That doesn't explain why it wasn't working with the LM358, but that can be investigated some other time.
I was working on an updated PCB design for my project when I got an idea, partly from talking with k6lcm, about making a cut down version for just the controller port and a way to test it with my Famicom (I don't have an AV Famicom or NES).
I decided to spin it into a separate project because it is just controller port integration (can cut out a lot of code) and also to build it around RP2040-Zero boards for compactness. This makes it even easier to build than the pico-usb2famikb. I will look at adding in USB gamepad reading and perhaps keyboard to controller inputs.
20251019_151319083.JPG
20251019_145709979.JPG
I'm keeping the i2c headers on it as well because that could provide some interesting capabilities, like communicating with other devices or even streaming TAS inputs.
