Pi Pico[W] Peripheral Expansion Box Side Port Device

[+chue]

I figured out the crash issue with my compiled XB program. It turns out that I had the original version of TI XB (version 100) on my SD card.  I used the updated version (110) and the program runs without issue.

[JasonACT]

14 hours ago, chue said:

- Bluetooth keyboard LEDs (CAPS lock, NUM lock) only working after the initial pairing. LEDs do not work on Subsequent connections.  Same behavior with and without additional USB keyboard connected.  If I delete the pairing and then pair again, same thing.  Works when initially paired but not on subsequent connections.

- I was unable to connect the keyboard using bluetooth 5 so I did not test the additional bluetooth libraries. This is probably just a problem with my particular keyboard.  Long story short, I am unable figure out the bluetooth MAC address without pairing it to my Windows laptop.  To pair it to the Pico I need to unpair the keyboard from Windows; at this point the keyboard randomizes (changes) the bluetooth MAC address.

That's annoying about the LEDs, I can't think why that would be.

 

With BT5, I don't think you need to pair HID devices, at least I don't have to with mine - so you could try pairing yours with Windows to get the address, power down Windows and try connecting with the Pico without pressing the pair button (just wake the keyboard the usual way).

 

It's a fairly good result in the tests though, thanks again for doing them 

[+chue]

I tried BT5 without pairing and could never get it to connect. As with the LEDs it isn’t a problem for me. BT3 works great so I will use that.

 

Thank you for all the work on this! The functionality that the Pico has is amazing!

[JasonACT]

2.5 weeks of tinkering hasn't helped, it's only confirmed (at least to me) that the PS4 gamepad gets too (RF) noisy when it detects other BT devices in range (I suspect it goes into overdrive to ensure the gamer has a chance for their signals to be detected, when there's other gamers around also playing).  But you can plug these gamepads in via a USB cable, which seems to work OK, so I'm releasing this firmware (after a lot of re-writes) with the caveat that you can't use both the PS4 gamepad and BT speaker wirelessly at the same time.

 

New options for autoload.cfg:

 

BT Speaker  "BTSPK=" (Specified in the hex format HH:HH:HH:HH:HH:HH)
ForTI Sound "FORTI=" (Sound gets sent to a BT Speaker - with the following options...
                      =0 off,
                      =1 means one chip emulated    - plays left & right channel in mono the same as the TI,
                      =2 means all 4 chips emulated - plays in stereo,
                      =3 means all 4 chips emulated - plays in mono)
 

I've got a cheap sound-bar which is mono (accepts data for 2 channels, but only plays 1, I guess.. unless you buy a 2nd and link them) which works best in mode 1 or 3.  I've got stereo headphones, which works well in mode 2 - but as I've written before, the ForTI sound card's stereo option is dependent on the author's senses...  Chariots of Fire is kind of better in mode 3, otherwise you get playback in "one ear or the other" for the 12 voices.

 

Pairing BT devices is now done 1 at a time, so I hope it's easier to connect them - just power up everything you have in pair mode - and 1-by-1 they should connect about 10 seconds after the TI is powered up.

 

Pico PWM sound (going through the console's sound chip) no longer gets the ForTI sound card signals, there was too much going on in the interrupt routine before, and I'm sure it was distorting the Speech and/or the PIO Digi-Port.  I think this is for the best.  Oh, and "FORTI=0" specified with a BT speaker connected still gets those 2 "original" signals as sound output.  But a final word of advice, BT speakers have a latency/delay, so while in mode 1 you can play TI games, the sound is going to be out of sync. much like most TI emulators on a PC.

PEB2.zip

[JasonACT]

Last September the Arduino-Pico project moved from GCC 10.3 to 12.3 - and I didn't upgrade because of the timing sensitive nature of the PPEB device.  I have in fact seen issues with the new compiler version, but after investigating, this is due to the size of the generated code.  Generally, it produces smaller code, but my CPU1 loop code (which drives the TI bus) becomes larger and overflows the 8KB of special/fast Pico RAM I'm using for it.  The Pico has 6 internal RAM busses of: 64k, 64k, 64k, 64k, 4k & 4k...  The last two areas are where I load the loop code & its stack.

 

While testing v12.3, I changed the GCC optimisation level from -O2 to -Os (small) and it fits again.  I actually have a small amount of extra space left which I didn't before.  I've run this build with my logic analyser connected to the PPEB and I don't see any significant timing differences, my analyser only works at 50MHz with the number of pins I need to test with, and I do see some variations in both the old code and new code - but they mostly exactly match, which gives me some confidence.

 

@chue can I trouble you to SAMS test this 2MB firmware version on your TI when you have the time please?

PPEB2.ino.uf2.zip

[+chue]

10 hours ago, JasonACT said:

 

@chue can I trouble you to SAMS test this 2MB firmware version on your TI when you have the time please?

I get the cyan screen of death.  When I turn on the TI, I get a blank cyan screen, no beep.  Is this the 8MB version by chance?

 

I did not test on my other TIs yet. I needed the space so they are currently in storage.

 

I loaded the previous firmware and that at least boots.  I will see if it passes the SAMS test.

[JasonACT]

6 hours ago, chue said:

I get the cyan screen of death.  When I turn on the TI, I get a blank cyan screen, no beep.  Is this the 8MB version by chance?

Oh, that's a fairly different result to everything else.  I reloaded that one onto my unexpanded board and it's come up as 2MB so it should be the right config.

 

Looks like I'll be sticking with GCC 10.3 then.

[+chue]

The prior GCC 10 firmware passes the SAMS burnin.

Tried the GCC 12 firmware on a second Pico and on a different TI. Same result. Cyan screen on startup.

 

I changed the Pico MHZ setting from 250 mhz to 266 mhz. The TI booted but the Pico didn’t seem to work. No cartridge in the menu and also no SAMS memory detected.

 

Are there different MHZ / NOP settings I should try?

[JasonACT]

19 minutes ago, chue said:

The prior GCC 10 firmware passes the SAMS burnin.

Tried the GCC 12 firmware on a second Pico and on a different TI. Same result. Cyan screen on startup.

 

I changed the Pico MHZ setting from 250 mhz to 266 mhz. The TI booted but the Pico didn’t seem to work. No cartridge in the menu and also no SAMS memory detected.

 

Are there different MHZ / NOP settings I should try?

Thanks again for doing these tests.  I can't think of anything else to try, at least for the moment.  I had previously gone over the code being compiled, making sure it was as efficient as I can make it - so there's not really anything I can see to do there either..  GCC 12 just wants to add ~300 bytes of extra code in the ~7KB loop function with -O2.  Even -Os on GCC 12 has about the same increase compared to -Os on GCC 10 which never worked for me previously, until I tried again yesterday with my latest code and it did, but that's making a ~6KB function, so everything fits nicely with a bit more to spare even.  All of these firmwares actually work on all 3 of my consoles (the Texas sourced NTSC unit, and 2 x Aus PAL units from mid '83) on the 2MB and 8MB SAMS Pico boards.

 

Maybe GCC 13 will produce smaller -O2 code, when Arduino-Pico incorporates that upgrade.

 

At least, for now, there's no urgent reason to upgrade GCC - it just would have been nice.

[JasonACT]

This is worth a laugh..  I ordered some 74LVC245 chips from China (on eBay, for cheap) and none of them worked in U4 & U5 position (address lines).  They did actually work in position U3 (the data lines of my Pico board).  The picture shows a single real TI chip at the bottom, which is what was advertised as the picture from the eBay item.  They wanted to refund me the US$8 but I chose to decline and just leave useful feedback for others.

 

[+dhe]

Hi @chue, can we start purchasing assembled units soon?

[+chue]

Sorry @dhe, I don't have any plans to sell assembled units.  Maybe someone else will.

[JasonACT]

On 5/27/2024 at 10:35 AM, RickyDean said:

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

I just remembered you were trying out a modified V3 board, how did you get on in the end?  Can we see a picture or two?  Those PSRAM chips are tiny.

[RickyDean]

5 hours ago, JasonACT said:

I just remembered you were trying out a modified V3 board, how did you get on in the end?  Can we see a picture or two?  Those PSRAM chips are tiny.

Didn't work out, I had the wrong footprint so I set it aside till I get some other stuff dealt with then will use regular PSRAM on them. I'm doing other TI hardware repair related stuff at the moment and have other "life stuff" happening too. Sorry

[JasonACT]

GCC 12.3 release candidate 2...

 

I'm back to using -O2, given the newer compiler speed improvements, I don't think everything I had inlined needs to be now, and it saves enough space.

NOPS= in the config file now executes double the NOPS, if you specified 4 before, make it 2 now, 6 should be 3 etc. (1 should still be 1).

NOPSW= is a new config item, it defaults to 5 "double NOPS" which should make it like the original firmware, but can be 1..9 (x2) NOPS

 

W means "Write", and I did have an 84ns delay after all writes before restarting the loop, which still looks correct on my scope readings, but can be decreased or increased now.  My particular TI-99's don't seem too fussed which value is selected, but it's the last variable I hadn't addressed previously, and may make a difference on some machines.

PPEB2.zip

[+chue]

On 8/4/2024 at 5:41 AM, JasonACT said:

GCC 12.3 release candidate 2...

This booted (unlike last time) and passed the SAMS burn-in on one of my Picos with the silver and black TI.  I ran it at 252 mhz and tested NOPS with values of 1 and 2.

I did not configure the new value NOPSW, so it ran with the default value of 5.  The new Pico firmware looks good to me.  Thanks for the update!

 

I also tried running the Pico at 266 mhz, but the SAMS test showed lots of memory errors.

[JasonACT]

12 hours ago, chue said:

The new Pico firmware looks good to me.

Thanks for confirming!  I'll try some faster speeds and see if I can track down the issue with that.  Then I'll post an up to date archive dump of the development directory for the project.

[JasonACT]

16 hours ago, chue said:

I also tried running the Pico at 266 mhz, but the SAMS test showed lots of memory errors.

I still can't reproduce this, except on my one unit that I know doesn't overclock past 264MHz without issues.  Actually, one of PSRAM chips I have doesn't go past 260MHz so I pulled it off the board it was on.  It's sitting on my things to do junk pile.

 

But, I did manage to find over 35ns extra in the past 2 days running at 250MHz - which is a lot when you consider the worst case timing for the PSRAM chips was less than 135ns before A15 drops from high to low (it's now up to 170ns before A15 drops - giving the TI-99's logic chips far more time to latch the low byte - which I'm fairly sure has been the issue all along).

 

I'm still aiming for all boards to work at 250MHz with all machines, and I hope this does it, but I have to say when I run my original boards (that didn't even need the R4 resistor mod) at 272MHz - the numbers on the scope look fantastic.

PPEB2.zip

[+chue]

On 8/6/2024 at 5:16 AM, JasonACT said:

I'm still aiming for all boards to work at 250MHz

I ran the SAMS burn-in at several speeds (250, 252, 254, 256) on this latest version and they passed.  NOPs was set to 1.

The firmware looks good.

 

It failed at 258 mhz with NOPs set to 1.  With NOPs set to 2, it almost passes the burn-in test - it failed at iteration 3.  I think it would probably work with NOPS with a higher value.

 

Should I be trying to run the Pico at as high a speed as it will go? Any disadvantage to running it at 250 mhz?

 

 

[JasonACT]

17 hours ago, chue said:

I ran the SAMS burn-in at several speeds (250, 252, 254, 256) on this latest version and they passed.  NOPs was set to 1.

The firmware looks good.

 

It failed at 258 mhz with NOPs set to 1.  With NOPs set to 2, it almost passes the burn-in test - it failed at iteration 3.  I think it would probably work with NOPS with a higher value.

 

Should I be trying to run the Pico at as high a speed as it will go? Any disadvantage to running it at 250 mhz?

That's great news @chue thanks for doing all that testing!  No, there's no reason now to be going any faster than 250MHz.  You get practically nothing for doing it, it was only for pulling in the long PSRAM access time.  I did some calculations today at lunchtime, and the 35ns I found is about the same as running the Pico a bit faster than 272MHz with the old firmware.  I think we're good with this one at 250 now.

I'll archive the development directory tonight and post up the snapshot.

[JasonACT]

Not for the faint-hearted.

 

File PPEB2.ino has the license, documentation and list of things I changed in Pico-Arduino to build the firmwares.

PPEB2_Src.zip

[JasonACT]

On 8/6/2024 at 8:16 PM, JasonACT said:

I'm still aiming for all boards to work at 250MHz with all machines

If anyone has issues running the PicoW at 250MHz with just 1 NOP on their TI-99, please let me know.  I've been experimenting with my project's currently underused PIO device's "state machines" on the Pico in the past few days and I think if I use more of them, I can make the PSRAM go ever so slightly faster.  I just don't know if it's worth the effort though, but it would be if someone has a machine showing memory errors in that configuration, and is willing to test something I come up with.  Thanks!

[JasonACT]

I've gone ahead and done it anyway.

 

Instead of 1 complicated state machine which can do everything I use for the PSRAM, I now have 3: write 1 byte, write 2 bytes and read 1 byte.  But there is a 4th SM available in the Pico PIO I'm using, so I've coded up a little timer that I can use for writes (instead of having lots of NOPs in a row, which saves a lot of space).  Having a state machine for each operation means I can widen the input fifo from 8 bits to 16, which means I can load more data on each fifo access, and I now don't need to test for fifo full (the fifos are only "4 values long" and I now never need to stick in more data than that for fast PSRAM accesses).

 

Next, I changed the tmp address variable to "be assigned" after the fifo address write by passing address calculations to the fifo address call (even though it's inlined) and return the address (same as passed in) to allow the tmp assign to be done after the fifo is loaded.  The fifo being loaded means I have 32 clocks extra going forward, as the address is being sent to the PSRAM chip by PIO, which I didn't have before.  That means the tmp variable write is done while the PSRAM chip is getting the address data loaded.

 

Then I modified some if statements so there's no branch on the longer code paths, which helps with SAMS reads, which have complicated (SAMS register) array look-ups.

 

It's now running at 210ns (worst case) before A15 changes from high to low (which is when the data is latched in the console).  Overclocked to 266MHz, it's 250ns, but that would change if more NOPs are configured, which I never seem to need.  250ns is TI's suggested timing for RAM expansion for the TI-99, but that's so conservative, and 210ns should be fine for even the oldest 74LS chips inside a console which have been used for so long and have degraded over time.  I'm assuming something like that is why there's differences between machines, because the 3 machines I have (which have no issues) seem to be fairly unused and have just sat around for a long time.

 

Finally, when I say "worst case", that hardly ever happens in my SAMS test case (it's not the memory tester, but rather program(s) using BLWP and RTWP in SAMS memory - RTWP does 3 reads in a row, which seems to be the worst case scenario, and getting the Pico to loop around that many times so quickly is troublesome for exact timing).  The actual average timing is 246ns at 250MHz, and 291ns at 266MHz, but it doesn't really work off averages.

PPEB2.zip

[+chue]

Just ran the SAMS burn-in on the latest firmware and it passed. 
 

The pico was set at 250 mhz, 1 NOP

[JasonACT]

Thank you @chue !!