Pi Pico[W] Peripheral Expansion Box Side Port Device

[JasonACT]

4 minutes ago, chue said:

what is a Digi-Port?

 

On 5/10/2024 at 6:57 AM, Gary from OPA said:

Digi-Port - The Sound Solution

AUDIO-BYTE  v1.03.9109.14 (BETA VERSION)

(c)1991 By Oasis Pensive Abacutors and Western Horizon Technologies

 

Originally, sold by Western Horizon Technologies, was a small hardware device that plugged into your TI99 PIO port which allowed you to play the '90s PCM 8-bit sound file format found on the PC, Amiga, Atari ST, Mac.

 

Now, here is the TMS9900 Assembly Language Source Code release of the BETA VERSION which Oasis Pensive Abacutors wrote as test software for the device back in 1991, I don't recall there being another version released back in the day, there might have been, but anyway here is this version that makes use of the 32k (for short 10 second files), or expanded 128k VDP, or Rambo and Geneve memory for much longer.

 

You can also play the sounds via the TMS9919 chip, but not as well, the sound quality is less, but it is easy today to build your own Digi-Port hardware device, see these pages for more info:

 

* https://en.wikipedia.org/wiki/Covox_Speech_Thing

* https://github.com/necroware/silly-sound-bastard

 

 

GITHUB Release Link: https://github.com/gary99opa/Digi-Port

 

DIGIPORT.dsk 360 kB · 15 downloads DIGIPORT-Sound-Samples.zip 2.18 MB · 51 downloads DIGIPORT-Source-Files-Only.zip 15.68 kB · 14 downloads DIGIPORT_1_03_GaryOPA_05_09_2024.zip 2.65 MB · 16 downloads

 

When I build another firmware, I'll make an option in the config file to turn this off (and make it passive when on - so it doesn't clash with the RS232 card).

[JasonACT]

I've done a bit of a clean up.

 

The Digi-Port now needs to be enabled by having an entry in the SD card's autoload.cfg file "PSNDO=1" and it's now a passive device.

 

Included in this archive is the 2MB & 8MB firmwares, along with all the latest 'required' ROMs for the SD card.  I've modified the main DSR.ROM to include "PIO/2", "RS232/3" & "RS232/4" which 'just return'...  If you have a real RS232 card connected, it should now act like a 2nd card, without changing the CRU base.  Since the DSR.ROM binary is now different, so is the location to hex-edit for a modified QI machine to use Pico PEB cartridges.  Hex file offset @>4EE & @>4EF should be changed from >0000 to >FFFF.  Previously described here:
 

On 3/27/2024 at 6:51 PM, JasonACT said:

In the other thread: "QI model schematics" I suggested a theory, and that's all it is, I don't want anyone breaking their QI model TI (I personally would try it, if I had one, but they are hard to come by where I am) of a mod that may make it work like an original model:

 

 

 

 

Red X (2) is a cut, blue lines (1 + 8 ) are joins.

 

Anyway, I thought to make a new DSR.ROM that can be edited for the one last QI difference I think there is, pull-ups on the 8 bit bus data lines, rather than pull-downs on an original.  So here is an updated DSR.ROM version that also "more carefully" checks for an inserted cartridge - for the original TI.  It checks for the >AA byte in all 5 cartridge GROMS now (the old version only checked for one @>6000) and it checks >100 words @>6000 ROM too, instead of just 4 words - for value >0000.

 

The value >0000 is located at position @>50A & @>50B within the file - the idea being it can be hexedited to >FFFF should someone want to test a modified QI console.  But I stress, this should not be tried on an unmodified QI console, because there will be clashes with the U32 74LS245 chip with my 74LVC245 data lines chip.

 

Remember!  This is all just theory!

DSR.zip 2.42 kB · 8 downloads

 

PPEB2.zip

[JasonACT]

Tonight's lesson is, you can't dither sound.  Or at least, without it sounding bad.  I've been experimenting with the ForTI card specs. to see what can be done with the Pi Pico.  I'm kind of locked in to 32KHz for the speech though, and this limits me with what I can emulate for the 4 x TMS9919 sound chips in the ForTI.  Also, the Pico PEB routes it's sound through the console sound chip, and it's become quite apparent that the ForTI sound card requires you to turn down the volume on that to experience quality sound directly from the ForTI card from a stereo.  So I'm bypassing it here for my USB powered speakers:

 

I didn't implement the noise channels at all, only the 12 voices, and the frequencies being generated are not really correct (a 32KHz issue) but, it's something worth putting up here, even if I don't take this any further.  It's been a bit of good fun.  With the slightly off frequency generation, it does make ordinary TI sounds quite different, if you go through the console's audio output to hear all 5 sound chips playing together.  (Really it's only the 2 though.)

 

I had hoped the ForTI sound software set the console sound chip to silent after programming the 4 ForTI chips on each note, but it doesn't and is quite clippy if you don't bypass it like I did in the photo.

 

Attached...  Something to fool around with.  2MB PPEB version only.

PPEB2_2MB_ForTI.zip

[Gary from OPA]

54 minutes ago, JasonACT said:

Tonight's lesson is, you can't dither sound.  Or at least, without it sounding bad.  I've been experimenting with the ForTI card specs. to see what can be done with the Pi Pico.  I'm kind of locked in to 32KHz for the speech though, and this limits me with what I can emulate for the 4 x TMS9919 sound chips in the ForTI.  Also, the Pico PEB routes it's sound through the console sound chip, and it's become quite apparent that the ForTI sound card requires you to turn down the volume on that to experience quality sound directly from the ForTI card from a stereo.  So I'm bypassing it here for my USB powered speakers:

 

I didn't implement the noise channels at all, only the 12 voices, and the frequencies being generated are not really correct (a 32KHz issue) but, it's something worth putting up here, even if I don't take this any further.  It's been a bit of good fun.  With the slightly off frequency generation, it does make ordinary TI sounds quite different, if you go through the console's audio output to hear all 5 sound chips playing together.  (Really it's only the 2 though.)

 

I had hoped the ForTI sound software set the console sound chip to silent after programming the 4 ForTI chips on each note, but it doesn't and is quite clippy if you don't bypass it like I did in the photo.

 

Attached...  Something to fool around with.  2MB PPEB version only.

PPEB2_2MB_ForTI.zip 396.38 kB · 1 download

Might be better to try emulate the sid blaster instead if possible to allow for better sound effects and music instead of the forti design.

[+FarmerPotato]

2 hours ago, JasonACT said:

I had hoped the ForTI sound software set the console sound chip to silent after programming the 4 ForTI chips on each note, but it doesn't and is quite clippy if you don't bypass it like I did in the photo.

It sounds like you have the original FORTI software? I've been hoping to find that--I only have half of it. (My half is mostly demos.)

 

So I recreated most of the words from documentation.

As you found, FORTI software makes the internal sound chip sound bonkers.  

The console decodes the whole 1K at 8400 to go to the sound chip. 

FORTI hardware decodes separate addresses. They are actually a bit mask: 

 

8400 writes to all 4.

841E should not do anything. 

8402 masks off chip 0.

841C writes only to chip 0.

841A writes only to chip 1.

8416 writes only to chip 2.

840E writes only to chip 3.

 

So the internal sound chip follows whichever chip  (s) were last written to.  
 

The Bach "Little" Fugue in G Minor uses only one chip so it sounds ok on the 4A.  

 

Demos which do not sound ok are Chariots of Fire, Ricercar. Chariots uses percussion and more than one chip, so on the 4A it chops off the noise channel and tones "stutter."
 

Ricercar uses 12 voices and sounds awful except maybe where parts double up. 
 

All of them continuously modify the attenuation of every tone, possibly even tone 3 when it should be silenced. Super clobberation. 
 

I designed by FORTI sidecar to have CRU bits which mask whether it responds at 8400 or 4400 or not at all.
 

The original software stores the sound address in each voice's workspace.  
 

(The other 6 bits are my DSR ROM select, and additional effects.) 

You could fix the "choppiness" by replacing  8400 in both software and hardware.  

[Gary from OPA]

9 minutes ago, FarmerPotato said:

It sounds like you have the original FORTI software? I've been hoping to find that--I only have half of it. (My half is mostly demos.)

 

So I recreated most of the words from documentation.

As you found, FORTI software makes the internal sound chip sound bonkers.  

The console decodes the whole 1K at 8400 to go to the sound chip. 

FORTI hardware decodes separate addresses. They are actually a bit mask: 

 

8400 writes to all 4.

841E should not do anything. 

8402 masks off chip 0.

841C writes only to chip 0.

841A writes only to chip 1.

8416 writes only to chip 2.

840E writes only to chip 3.

 

So the internal sound chip follows whichever chip  (s) were last written to.  
 

The Bach "Little" Fugue in G Minor uses only one chip so it sounds ok on the 4A.  

 

Demos which do not sound ok are Chariots of Fire, Ricercar. Chariots uses percussion and more than one chip, so on the 4A it chops off the noise channel and tones "stutter."
 

Ricercar uses 12 voices and sounds awful except maybe where parts double up. 
 

All of them continuously modify the attenuation of every tone, possibly even tone 3 when it should be silenced. Super clobberation. 
 

I designed by FORTI sidecar to have CRU bits which mask whether it responds at 8400 or 4400 or not at all.
 

The original software stores the sound address in each voice's workspace.  
 

(The other 6 bits are my DSR ROM select, and additional effects.) 

You could fix the "choppiness" by replacing  8400 in both software and hardware.  

Yes, better to use a different set of addresses unless you add hardware in the 4a console to limit the address decode range, or remove the tms9919 chip totally inside the console and just jumper the audio in to audio out.

 

Would be good if @JasonACT shares the forti software he has well, I been looking around for it as well.

[+chue]

On 5/12/2024 at 11:16 PM, JasonACT said:

Included in this archive is the 2MB & 8MB firmwares, along with all the latest 'required' ROMs for the SD card.

Passes the SAMS test. I will run the burn-in on the new ForTI firmware next.

 

Edit: the ForTI firmware also passes the SAMS test.

 

7 hours ago, JasonACT said:

I'm kind of locked in to 32KHz for the speech though, and this limits me with what I can emulate for the 4 x TMS9919 sound chips in the ForTI.

Maybe make the two (speech, ForTI) mutually exclusive? That way you can have different frequencies.

 

 

[JasonACT]

13 hours ago, FarmerPotato said:

It sounds like you have the original FORTI software? I've been hoping to find that--I only have half of it. (My half is mostly demos.)

13 hours ago, Gary from OPA said:

Would be good if @JasonACT shares the forti software he has well, I been looking around for it as well.

Sadly, no, I've only got the 2 demos (Chariots & Ricercar).  But I can tell from playing those how it's working.

13 hours ago, chue said:

Passes the SAMS test. I will run the burn-in on the new ForTI firmware next.

 

Edit: the ForTI firmware also passes the SAMS test.

Ah, good to know, thanks.  I was worried about the ForTI one, it added a fair few lines of code to CPU1.

13 hours ago, chue said:

Maybe make the two (speech, ForTI) mutually exclusive? That way you can have different frequencies.

Well, there's lots more speech software out there, than there is for the ForTI, so I'm probably not going to take this a lot further.  That, and this implementation is mono and will always be.  But I think maybe how I've implemented the square wave generator is why I don't like the "dithered" sound output, because 32KHz for mono should be OK, at least up until making 16KHz tones.  This isn't something I've really played with before though.

 

The thing I do like about the ForTI design though is, on a real card you get 4 channels of (still mono) output which is compatible with all '99 software.  Writing to >8400 writes to all 5 chips.  My implementation also has the limitation that when speech is being played, I stop processing the ForTI mixer, so the music mutes.

 

Like I said though, a bit of fun.

[JasonACT]

I found what my wave generator (and mixer) was doing wrong, this has improved things quite a bit, but I still didn't like the dithered sound, so I stuck with the cleaner version which only gets close to the desired frequency.  The mixer has a compression algorithm now too, because with 12 voices all yelling, it can get loud and needs to be dynamically attenuated.  I'm not implementing the 4 noise generators, there's already too much going on in the PWM interrupt and they are a little bit more complicated than the square wave.

 

The feature is not turned on by default in this version, use "FORTI=1" in the config.  2MB and 8MB versions + ROMs attached.

PPEB2.zip

[+chue]

Latest ForTI firmware passes the SAMS burn-in test.

[JasonACT]

Beta Wireless Firmware: the "autoload.cfg" config file allows "BTJ1=", "BTJ2=", "BTKM1=" & "BTKM2=" to specify a bluetooth MAC address (in the format: 00:11:22:33:FF:EE).  You have to pair your BT device(s) with a PC first to get the 6 byte MAC address, every device is different, and mine don't have the addresses written on the labels.  I don't expect any of them do.

 

I only have 1 bluetooth GamePad (the Sony PS4) and 1 combined keyboard/touchpad device that I've tested.  So I'm configuring BTJ1= & BTKM1= in my config file, but it should support up to 4 devices - 2 joysticks, a separate keyboard and mouse.  If you specify "BTJ1=" then if you plug in a USB GamePad, it will configure itself as Joystick 2, I.E. it locks out joystick #1 for BT usage only.  Since I couldn't find any simple examples of bluetooth for the Pico W, my implementation of the keyboard packet parser (and possibly the mouse one too) may not work with all devices...  Being tested with a sample size of 1 (of each) and all.

 

Once all your devices are paired (start them all in pair mode, then power up the TI, and test each works) then go into TI BASIC and run "CALL UNMOUNT" - this will flush the bluetooth config data area to a file called "bluetooth.bin" which you should be able to see all your BT MAC addresses present (somewhere within) when viewed in a hex-editor.  It gets re-loaded when the TI powers up, so you don't need to be in pair mode each time going forward...  It can be a bit slow for your paired devices to be found though.

 

2MB & 8MB firmwares + ROMs attached:

PPEB2.zip

[+chue]

15 hours ago, JasonACT said:

Beta Wireless Firmware: the "autoload.cfg" config file allows "BTJ1=", "BTJ2=", "BTKM1=" & "BTKM2=" to specify a bluetooth MAC address

Passed the SAMS burn-in test.

 

Bluetooth functionality works well too.  I was able to pair my PS4 controller and a bluetooth mechanical keyboard (Redragon K618).  CAPS LOCK doesn't seem to work when using the keyboard (SHIFT does though). The keyboard has two profiles - bluetooth 3 and bluetooth 5; only the bluetooth 3 worked for me.  The MAC address differs based on the profile, so I had to make sure I had the correct MAC.

[JasonACT]

1 hour ago, chue said:

Passed the SAMS burn-in test.

 

Bluetooth functionality works well too.  I was able to pair my PS4 controller and a bluetooth mechanical keyboard (Redragon K618).  CAPS LOCK doesn't seem to work when using the keyboard (SHIFT does though). The keyboard has two profiles - bluetooth 3 and bluetooth 5; only the bluetooth 3 worked for me.  The MAC address differs based on the profile, so I had to make sure I had the correct MAC.

Ah, thanks again for testing.

 

I'm currently seeing a few issues, which I'm trying to fix (but only having slow progress)...

1/ I've broken .zip/.rpk cartridge loading, bluetooth takes up 20KB of Pico RAM and I don't think there's enough left for my current zip library.

2/ WiFi dies, and I don't get the "CLOCK"/"PI.CLOCK" device set from my time server PC, at least not reliably.

3/ My 8MB SAMS PPEB is crashing on some games when I use the bluetooth GamePad.  Not even close to looking into this one though, 2MB SAMS PPEBs all work OK.

 

I'm currently trying another zip library (lowzip) but it doesn't let me request 8KB chunks of decoded archive file, it wants enough RAM for the whole file, so it isn't playing well with the PSRAM that I need to load in chunks.  I'll keep working on it though.

[RickyDean]

46 minutes ago, JasonACT said:

Ah, thanks again for testing.

 

I'm currently seeing a few issues, which I'm trying to fix (but only having slow progress)...

1/ I've broken .zip/.rpk cartridge loading, bluetooth takes up 20KB of Pico RAM and I don't think there's enough left for my current zip library.

2/ WiFi dies, and I don't get the "CLOCK"/"PI.CLOCK" device set from my time server PC, at least not reliably.

3/ My 8MB SAMS PPEB is crashing on some games when I use the bluetooth GamePad.  Not even close to looking into this one though, 2MB SAMS PPEBs all work OK.

 

I'm currently trying another zip library (lowzip) but it doesn't let me request 8KB chunks of decoded archive file, it wants enough RAM for the whole file, so it isn't playing well with the PSRAM that I need to load in chunks.  I'll keep working on it though.

I've been out of this picture a bit, been building and working on other things and a lot of doctor visits and stuff. But I am using this last file and just went back and caught up a bit on how the mhz and nops can be changed in the cfg file so I used this setting on a 2mb one: MHZ=262 and NOPS=4, and it seems to be testing well on the one unit. I will not be able to play around and test more till Monday, as we have family activities planned for tomorrow.

[JasonACT]

Issues 1 and 3 have been fixed, issue 2 (WiFi) I was working on late last night, and I couldn't get it to fail...  Today, this morning, it won't connect to my WiFi at all again - so I feel this may be due to signal noise around my home (neighbours).  I.E. BT being activated making WiFi on the shared little antenna less able to cope.  There's an issue still open on the Arduino Pico github too, so I'm not going to keep looking for solutions, seems like it's a known problem.

 

@chue My capslock works OK, but I'll ask around at work to see if I can borrow some more keyboards to test.  I did have to change CPU1 code again to fix the 8MB SAMS firmware, which affects the 2MB SAMS version ever so slightly - I hope it still passes the tests.

 

Updated 2MB & 8MB firmwares + ROMs attached: (See next post of mine below...)

 

Edited May 27 by JasonACT
Remove attachment

[RickyDean]

My first three units passed the SAMS Burn in on the settings, listed just before this last post of Jason's, so they seem to be good. My forth Blue one is not booting since I built it, maybe a dead Pico, and my fifth one, the first white one with two Ram chips mounted on board V3 is not seeing the ram. I believe a bad resistor, or a bad solder point, will be checking tomorrow

Edited May 27 by RickyDean
spelling

[+chue]

20 hours ago, JasonACT said:

1/ I've broken .zip/.rpk cartridge loading, bluetooth takes up 20KB of Pico RAM and I don't think there's enough left for my current zip library.

2/ WiFi dies, and I don't get the "CLOCK"/"PI.CLOCK" device set from my time server PC, at least not reliably.

3/ My 8MB SAMS PPEB is crashing on some games when I use the bluetooth GamePad.  Not even close to looking into this one though, 2MB SAMS PPEBs all work OK.

1. I have a small sample of 2 cartridge files that work. One is an rpk (8k before compression) the other is a zip (64k before compression).

2. Clock is broken with mine too.  The couple times I tried to read the clock I saw incorrect dates and times (morning of Jan 1, 1970)

3. Gamepad works on my 2 MB Pico as well. I don’t have an 8 MB to test.

 

edit: I see you put out some new firmware - I will take a look.

[JasonACT]

1 hour ago, JasonACT said:

issue 2 (WiFi) I was working on late last night, and I couldn't get it to fail...  Today, this morning, it won't connect to my WiFi at all again - so I feel this may be due to signal noise around my home (neighbours).  I.E. BT being activated making WiFi on the shared little antenna less able to cope.  There's an issue still open on the Arduino Pico github too, so I'm not going to keep looking for solutions, seems like it's a known problem.

I've moved the BT start-up code to be after a successful WiFi connection (or after 30 seconds, whichever comes first).  This makes BT a bit slower to start, but I've been able to get the CLOCK device working again, and it seems I can ping my Pico successfully after the bluetooth device(s) are connected.

 

New attachment:

 

PPEB2.zip

Edited May 27 by JasonACT
Re-attached non-debug build.

[+chue]

The latest firmware update is looking good, although the console hangs up in a certain situation when using bluetooth.  More details below.

 

Configuration:

1 2MB Pico

1 TI (Silver & Black)

1 PS4 joystick

1 Redragon K618 bluetooth keyboard

 

Results:

1. The SAMS memory test ran 3 times successfully.

 

2. Network clock is now showing the correct date and time.

 

3. When connected, both the keyboard and joystick work great.  Initial paring of the joystick is always easy, same with connecting after pairing.  The keyboard seems to be a little more finnicky, although it might just be my particular keyboard.  Initial pairing seems like black magic, I just keep trying until the keyboard and Pico find each other. Luckily, initial pairing is just a one time thing.  Subsequently connecting after pairing seems tricky too, although I did find that if I do things in a certain sequence, that I can usually get the keyboard to connect to the Pico:

- with everything off

- turn on the PS4 joystick (press the PS button)

- turn on the TI

- After the PS4 and Pico connect, the PS4 light will stop blinking

- turn on the keyboard.  It will usually pair right away.  If not, turn off the keyboard and turn it on again.  If that doesn't work go back to the first step.

 

4. In an earlier post, I said that CAPS LOCK doesn't work on the bluetooth keyboard.  It actually does work, just that the CAPS LOCK LED doesn't toggle on / off. I may have been fooled by this previously, and thought that it didn't work.

 

5. Zip and RPK cartridge files work, although I have a small number of files to test.

 

6. I have a very specific scenario where the console will hang (usually, but not always).  It happens like this:

- connect the joystick and keyboard to the Pico via bluetooth

- In TI BASIC type CALL TIPI, and then choose a zipped cartridge file.  The specific file I use is a test cart that I have which runs some unit tests.  I can post this file here if needed. 

- after the console resets, I run the cart and it will hang part way through the unit tests.

 

The hangup seems to only occur with both joystick and keyboard connected.  If only one of the two are connected then the hangup does not happen.  And I think the hangup only occurs with a compressed (zipped) cart file.

[JasonACT]

56 minutes ago, chue said:

Initial paring of the joystick is always easy, same with connecting after pairing.  The keyboard seems to be a little more finnicky, although it might just be my particular keyboard.

It's my keyboard too, I think it's because keyboards only send wireless messages when keys are pressed - where the GamePad is a constant stream of data.  I work around it by pressing keys on my BT keyboard until it connects, it can take a while - but I've also sometimes resorted "back to the first step" like you.

 

58 minutes ago, chue said:

I can post this file here if needed.

I'm just about to go to work for the day, but yes, post it up and I'll take a look when I get home this afternoon.

 

All in all, that's not a bad result, thanks again for the tests.

[+chue]

Here's the aforementioned unit test cart.  The tests run are for my own code and are not related to the Pico PEB.  Therefore, this is probably not of any interest to anyone but you Jason.  On completion, you will see a green background with the words "ALL TESTS PASSED" at the bottom.

 

snazzle-8.zip

[JasonACT]

7 hours ago, chue said:

Here's the aforementioned unit test cart.  The tests run are for my own code and are not related to the Pico PEB.  Therefore, this is probably not of any interest to anyone but you Jason.  On completion, you will see a green background with the words "ALL TESTS PASSED" at the bottom.

 

10 hours ago, chue said:

6. I have a very specific scenario where the console will hang (usually, but not always).  It happens like this:

- connect the joystick and keyboard to the Pico via bluetooth

- In TI BASIC type CALL TIPI, and then choose a zipped cartridge file.  The specific file I use is a test cart that I have which runs some unit tests.  I can post this file here if needed. 

- after the console resets, I run the cart and it will hang part way through the unit tests.

 

The hangup seems to only occur with both joystick and keyboard connected.  If only one of the two are connected then the hangup does not happen.  And I think the hangup only occurs with a compressed (zipped) cart file.

I've tried running it over and over for about 40 minutes, following exactly these steps, and it always passes for me.  I spent about 20 minutes on my NTSC console and 20 on my PAL console.  I'm also running at 250MHz and 1 NOP.  I actually spent time on the PAL unit because it's got an original power supply, since BT will be using a bit more power, but no difference.

 

When it finishes, I note you can press <FCTN>= to reset, but my bluetooth keyboard often has trouble with that (USB keyboard has no issues).  In fact, <ctrl><alt>del (which is a load interrupt reset, for when you really want to reset and you are being locked out) often doesn't work at the end or in the middle (again USB keyboard had no issues).  This is strange, because I'm actually "injecting" the BT packets into the USB parsing functions (for keyboard, mouse and joystick) so they should all act the same.  And they do all act the same in all my other testing with other programs 

 

Does the issue get any better/worse if you change to 2NOPs and 256MHz?

[JasonACT]

3 hours ago, JasonACT said:

When it finishes, I note you can press <FCTN>= to reset, but my bluetooth keyboard often has trouble with that (USB keyboard has no issues).  In fact, <ctrl><alt>del (which is a load interrupt reset, for when you really want to reset and you are being locked out) often doesn't work at the end or in the middle (again USB keyboard had no issues).  This is strange, because I'm actually "injecting" the BT packets into the USB parsing functions (for keyboard, mouse and joystick) so they should all act the same.  And they do all act the same in all my other testing with other programs 

Ah, it looks like my BT keyboard goes into power saver mode and needs to reconnect when you press a key - and it caches a few of them up when it does it.

[JasonACT]

16 hours ago, chue said:

4. In an earlier post, I said that CAPS LOCK doesn't work on the bluetooth keyboard.  It actually does work, just that the CAPS LOCK LED doesn't toggle on / off. I may have been fooled by this previously, and thought that it didn't work.

But, if you have a USB keyboard plugged in at the same time, the BT keyboard will switch that one's LED on and off 

 

Sorry, but I don't know how to send the command back to a BT keyboard to make that work   So few examples around.

[+chue]

12 hours ago, JasonACT said:

I've tried running it over and over for about 40 minutes, following exactly these steps, and it always passes for me. 

Just tried to reproduce the hang issue... it no longer happens.  The only thing that I can think I am doing differently is that I had let the console run a long time previously.  Maybe the console or the Pico was hot.  Anyway, just pure speculation and I will keep an eye on it...

 

12 hours ago, JasonACT said:

When it finishes, I note you can press <FCTN>= to reset, but my bluetooth keyboard often has trouble with that (USB keyboard has no issues).  In fact, <ctrl><alt>del (...) often doesn't work at the end or in the middle (again USB keyboard had no issues)

FCTN= doesn't work on my bluetooth keyboard, but CTR-ALT-DEL does.  I've tried the latter at the end of my test cart program, as well as when my console locked up.  Worked in both places.  The lockup is something I am still investigating, and is unrelated to the one you have been troubleshooting.  I will post details here if I can repro it.

 

9 hours ago, JasonACT said:

Ah, it looks like my BT keyboard goes into power saver mode and needs to reconnect when you press a key - and it caches a few of them up when it does it.

Mine seems to not sleep unless it is inactive for a long time, probably a few minutes. I can tell it wasn't sleeping during my testing because it is backlit and will go dark (obviously) when sleeping.  Anyway it doesn't seem to matter as I can not reproduce the hang issue anymore.

 

6 hours ago, JasonACT said:

But, if you have a USB keyboard plugged in at the same time, the BT keyboard will switch that one's LED on and off 

 

Sorry, but I don't know how to send the command back to a BT keyboard to make that work

No worries, having a CAPSLOCK LED toggle is not a necessity. The typed letters being in all CAPS is enough of an indication for me 🙂