The P2 Thing

MXX · 2025-09-09 09:47

Dear All,

let me introduce the latest (final?) version of my P2 board, You can find the first version at P2EDGE gaming/standalone breakout discussion.

It briefly consists of:

96 MB RAM with 16bit Bus (previous 8 bit bus)
USB port for programming and power supply (USB type B )
Additional PROP PLUG header
Additional 9 - 24 V power supply input (for 5V 15 W)
Additional leds for power supply and rtx signal (previous rtx only)
Front panel connector
High precision RTC (supercap backed up)
Selectable boot from 6 different flashes (previous 4 flashed)
SD card high speed 4 wire bus (previous slow mode)
USB hub 4 ports for joystick, keyboard and mouse (previous 2 ports)
VGA connector
Stereo Analog audio out (headphones or line)
HDMI connector (previous not available)
ESP-01 or ESP-01S connector (previous not available)
Shared 16 bit expansion connector (previous not shared)
ESD protection
Optional dedicated heatsink Code 345-1744-ND (previous not available)
6 Layer PCB (previous 4 layer)

A major difference compared to previous PCB is about heat dissipation. The two additional layers increase heat transfer to external connectors (acting as heatsink).

I designed this board in an attempt to reduce the connections mess between P2 and the various peripherals typically used.
Furthermore, this board will make it easy to experiment with all those fantastic software related to the world of retro consoles and audio-video systems in general.

Special thanks to:

@rogloh
@evanh
@Rayman
@Wuerfel_21
@JonnyMac
@pik33
@cgracey

for the efforts put on the P2 platform, this board is based on and inspired by their work .

Another difference is the front panel which is now interchangeable with various options such as the 3.5" display and the 4.3" display which will be coming soon.

In the photo we can also see other accessories such as the heatsink and the ESP-01 module....

The LCD display is driven with 16 wires but in 24bit RGB configuration thanks to the help of latches so it does not require any initialization.

I also prepared a modified version of the Burn-in RAM test software created by Werfel_21 in order to quickly test the other peripherals on board.

Rayman · 2025-09-09 10:34

Looks good!

rogloh · 2025-09-09 12:50

Neat-o! This is a very feature rich platform and looks like there's gonna be a lot of things in there to test as it's a big upgrade from before.

What do you have working so far? I see the front panel parallel LCD is already working in your youtube vid and it's responding quickly, and your test software screen looks useful. Any tricky problems you had to resolve or is it all coming up nicely?

Wuerfel_21 · 2025-09-09 12:51

I have one of these and can vouch for it as a great unit! If I've not given much feedback on it, it's because it's just been so good to me. (though I never tried messing with the RTC or the ESP module)

I've been using it as my main development system lately, it's just so nice and tidy. Did most of the work for MisoYume beta 11, P1 Classics Collection and this silly music thing on there. (and the Teapot demo on the previous version)

Maybe we can workshop, like, a catchy name for this capital-T Thing? I've just kinda been calling it the "MXX box" or something to that extent. (Because I need

I also prepared a modified version of the Burn-in RAM test software created by Werfel_21 in order to quickly test the other peripherals on board.

Nice re-use of the RAM tester text driver thing!
(BTW, I think(?) the version of the FUNSCII font there has the full set of Parallax P1 ROM font PUA glyphs, so you can draw fully connected boxes if you want - you may need to add --charset=oem to the compiler command line if not already there to get 8-bit extended characters, otherwise it will attempt to use UTF-8)

JonnyMac · 2025-09-09 14:48

Wow, Massimo, that is really nice. Congratulations.

Wuerfel_21 · 2025-09-09 16:18

But that's Massimo, Marco is @macca , you need to get your Italians straight.

JonnyMac · 2025-09-09 16:51

Wuerfel_21 · 2025-09-09 16:55

OK, I need to get my Italians straight

Rayman · 2025-09-09 17:09

@Wuerfel_21 Are your emulators going to work with this LCD?

Wuerfel_21 · 2025-09-09 17:16

@Rayman said:
@Wuerfel_21 Are your emulators going to work with this LCD?

IDK I don't have one or any specs. I think we talked about this once in some e-mails, but who knows what of that made it to the final product. (My influence did result in upgrading to 16 bit wide PSRAM)

MXX · 2025-09-09 21:05

Thanks again to everyone for the feedback!

@rogloh said:
Neat-o! This is a very feature rich platform and looks like there's gonna be a lot of things in there to test as it's a big upgrade from before.

What do you have working so far? I see the front panel parallel LCD is already working in your youtube vid and it's responding quickly, and your test software screen looks useful. Any tricky problems you had to resolve or is it all coming up nicely?

Most of the hardware is tested and working as expected so far. One thing left to try is the fast 4 bit SD card interface, some help needed here.
The LCD panel responds quickly because it was inserted "hot" with the firmware already running...... also, perhaps by mistake, I compiled the demo with FlexProp that's why it's very fast (about 10x compared to propeller tool).
LCD test software is thanks to @Rayman, I only adapted the pasm LCD driver to fit my circuit.
No big issues in running the LCD panel as it's a raw 24 bit RGB parallel interface, (latched as 8 bit R / 8 bit G / 8 bit B to save some pins).
I would say PSRAM block was a bit tricky.

@Wuerfel_21 said:
But that's Massimo, Marco is @macca , you need to get your Italians straight.

Marco is my collegue helping on the software side, it's not @macca which I forgot to mention for his work on USB.
We used Marco yuotube account to post the video.

@Rayman said:
@Wuerfel_21 Are your emulators going to work with this LCD?

I'm going to share the schematics soon, it's something similar to the LCD 6 bit interface already present in NeoVGA but with 8 bits instead of six plus some syncing signals. Would be great to have the emulators running on the LCD but I really need help fo this.

Rayman · 2025-09-09 21:17

Hope you can get the 24-bit latched LCD working with the emulators. Also have some dual latched boards here that can plug into eval/edge headers.
Think @Wuerfel_21 and myself decided that 16-bit with one latch was better at some point, but then just dropped the ball on it.

Think it was when realized could just use an hdmi panel for similar cost...

Wuerfel_21 · 2025-09-09 21:31

@MXX said:
Most of the hardware is tested and working as expected so far. One thing left to try is the fast 4 bit SD card interface, some help needed here.

Oh carp! 🐟
I just realized the NeoYume you pre-loaded isn't using 4bit and when I build with that it doesn't work!

Uuhhh, I think that's a problem. I apologize profusely for forgetting to test it. (I was in a total rut for a few months...)

The LCD panel responds quickly because it was inserted "hot" with the firmware already running...... also, perhaps by mistake, I compiled the demo with FlexProp that's why it's very fast (about 10x compared to propeller tool).
LCD test software is thanks to @Rayman, I only adapted the pasm LCD driver to fit my circuit.
No big issues in running the LCD panel as it's a raw 24 bit RGB parallel interface, (latched as 8 bit R / 8 bit G / 8 bit B to save some pins).
I would say PSRAM block was a bit tricky.

>

I'm going to share the schematics soon, it's something similar to the LCD 6 bit interface already present in NeoVGA but with 8 bits instead of six plus some syncing signals. Would be great to have the emulators running on the LCD but I really need help fo this.

RBG latches cause Problems^TM> I recall, was taling with Ray about a similar thing. The main problem is that when you build up the data bus gradually with latches, you'll very easily violate the hold timing constraints for the parts you latch first/last. But can't recall that now, need to troubleshoot that SD thing rather asap.

@Wuerfel_21 said:
But that's Massimo, Marco is @macca , you need to get your Italians straight.

Marco is my collegue helping on the software side, it's not @macca which I forgot to mention for his work on USB.
We used Marco yuotube account to post the video.

Lots of Italians to keep track of. Good to clear up any and all confusion.

Wuerfel_21 · 2025-09-09 21:42

Okay, so I've narrowed it down a bit:

The problem seems to be with the card power switch.
If I set the following config to disable it, SD4 is working:

#define USE_SD_4BIT
SD4_DAT0 = 16
SD4_CMD  = 20
SD4_CLK  = 21
SD4_PLED = 22
SD4_PPWR = -1

But the expected problem of only being able to mount the card reliably on cold-boot appears. Launching any other program that puts the SD card into SPI mode needs a power or insert cycle afterwards.

Relevant bit of schematic:

Wuerfel_21 · 2025-09-09 22:01

Building with -DSD_DEBUG begets us Error: Stuck high at SD power-down.

I think I see the problem! The actual power switch does work, but you've routed the pull-up resistors to VIO (pre-switch), but they must go to VDDSD (post-switch) instead. The driver tries to make sure the power is actually off by sampling the CLK pin with the P2's voltage comparator. This doesn't work if the pull-up is always high instead of being referenced to the SD power.

This is the correct setup as seen in the reference schematic:

Luckily this is a software issue that can be worked around! ( @evanh will try to kick me, I'm sure )
Go into sdsd.c (included in NeoYume in blkdrvr directory) around line 242 and change

    if( samples ) {
#ifdef SD_DEBUG
        __builtin_printf("  Error: Stuck high at SD power-down\n");
#endif
        releasepins();
        return 0;
    }

to

    if( samples ) {
#ifdef SD_DEBUG
        __builtin_printf("  Warning: Stuck high at SD power-down\n");
#endif
        //releasepins();
        //return 0;
    }

(Then of course use the proper config with SD4_PPWR = 23)

EDIT: I've also pushed this nasty patch to the bundled SDSD driver to NeoYume's GitHub/SourceHut repos
EDIT2: fixed some wording
EDIT3: added ref. schematic

Wuerfel_21 · 2025-09-09 22:27

There's also another problem I noticed earlier, forgot about and just encountered again, I can't seem to flash large binaries properly. @MXX somehow got them on there, so I don't think it's impossible, but my loadp2 doesn't wanna, neither with the explicit flashloader or the new -SPI option. Need to check tomorrow if this is a general issue with all boards, I rarely use flash.
What does help is enabling executable compression (--compress flag to flexspin), which I am astonished I still haven't done by default everywhere.

Rayman · 2025-09-09 22:51

@Wuerfel_21 Think @ersmith said something about needing to switch to proploader for binaries?

Think just creating a fake .spin2 file with the binary in a dat section works usually though...

evanh · 2025-09-09 23:10

@Wuerfel_21 said:
Building with -DSD_DEBUG begets us Error: Stuck high at SD power-down.

I think I see the problem! The actual power switch does work, but you've routed the pull-up resistors to VIO (pre-switch), but they must go to VDDSD (post-switch) instead. The driver tries to make sure the power is actually off by sampling the CLK pin with the P2's voltage comparator. This doesn't work if the pull-up is always high instead of being referenced to the SD power.

Correct. It is intended to comply with the SD spec of requiring a power cycle to be below 0.5 volts on VDDSD for at least 1.0 millisecond.

Luckily this is a software issue that can be worked around! ( @evanh will try to kick me, I'm sure )

A software workaround for a hardware issue, thank you very much!

EDIT: I've also pushed this nasty patch to the bundled SDSD driver to NeoYume's GitHub/SourceHut repos

You're now relying on a 500 ms delay for the capacitors to discharge and just assuming it works without confirmation. The routine could be notably reduced in size ...

//-----------------------------------------------------------------------
// Simple power cycling of the SD Card, optional - if pin defined
//-----------------------------------------------------------------------

static int  sdcard_power( void )
{
    unsigned  PIN_CLK = clkpin;
    unsigned  PIN_CMD = cmdpin;
    unsigned  PIN_DAT = dat0pin | 3<<6;
    unsigned  PIN_PWR = pwrpin;    // pin number of power switch (-1 == not defined)
    uint32_t  samples, threshold;
    int32_t  tmr, timeout;

    releasepins();    // SD spec 6.4.2

    _pinl(PIN_CMD);
    _pinl(PIN_DAT);
    _waitus(1);
    _pinf(PIN_CMD);
    _pinf(PIN_DAT);
    _waitus(1);    // wait for pull-up resistors to act

    if( PIN_PWR == PIN_CLK ) {    // power switch not present
        if( _pinr(PIN_CMD) )
            if( _pinread(PIN_DAT) == 15 )
                return 1;    // pull-up resistors are present
#ifdef SD_DEBUG
        __builtin_printf(" Error: CMD/DAT pull-up resistors are missing\n");
#endif
        return 0;
    }

    if( _pinr(PIN_PWR) ) {    // An inserted card will pull this down against the 22k ohm pull-up
#ifdef SD_DEBUG
        __builtin_printf(" Error: SD Card not detected\n");
#endif
        return 0;
    }
#ifdef SD_DEBUG
    __builtin_printf(" Card detected ... 500 ms power cycle of SD card\n");
#endif

// Overpower the pull-ups so that the SD card can be powered down
    _pinl(PIN_CLK);
    _pinl(PIN_CMD);
    _pinl(PIN_DAT);
// Use blind 500 ms delay for SD supply to fall below the requisite 0.5 Volt
    _pinh(PIN_PWR);    // power off the SD card by overpowering the 1800 ohm Card Detect
    _waitms(500);

    releasepins();    // and power back on
    _waitms(1);

    return 1;
}

EDIT: Added the 1 ms power up delay too.
EDIT2: Added overpowering of the pull-ups

evanh · 2025-09-09 23:26

It is still problematic. The whole power cycling sequence still may not be working because all those pull-ups will be supplying power to the SD card.

You'll need to get a scope on the SDVDD power rail to see what is really happening.

EDIT: I've changed the routine above to hopefully drain the capacitor by overpowering all the pull-up resistors. I guess it's not too different to the original sequence since most of the pull-ups were driven low there too. Just the CLK pin extra now.

evanh · 2025-09-09 23:49

I've updated the releasepins() function too. Placed the power switch release at the end instead of beginning.

//-----------------------------------------------------------------------
// Orderly clean up of pin and smartpin modes
//-----------------------------------------------------------------------

static void  releasepins( void )
{
    unsigned  PIN_CLK = clkpin;
    unsigned  PIN_CMD = cmdpin;
    unsigned  PIN_DAT = dat0pin | 3<<6;
    unsigned  PIN_PWR = pwrpin;
    unsigned  PIN_LED = ledpin >> 8;    // Doubles up as SDSC byte addressing flag in bit0

    _pinf(PIN_CLK);    // stop SD clock

    _pinf(PIN_CMD);
    _pinf(PIN_DAT);
    _wrpin(PIN_CMD, 0);
    _wrpin(PIN_DAT, 0);

    _waitus(1);    // wait for pull-up resistors to act

    _wrpin(PIN_CLK, 0);    // release clock pin

    if( PIN_LED != PIN_CLK ) {    // activity LED is present
        _pinf(PIN_LED);
        _wrpin(PIN_LED, 0);
    }
    if( PIN_PWR != PIN_CLK ) {    // power switch is present
        _pinf(PIN_PWR);
        _wrpin(PIN_PWR, 0);
    }

    _waitus(1);    // wait for pull-up to act
}

The P2 Thing

Comments