Shop OBEX P1 Docs P2 Docs Learn Events
MicroDOS - a simple loader for PSRAM based system (now with USB keyboard) — Parallax Forums

MicroDOS - a simple loader for PSRAM based system (now with USB keyboard)

pik33pik33 Posts: 2,347
edited 2023-05-08 11:37 in Propeller 2

Latest version - 0.04 with USB keyboard at post #35


We have more and more toys like NeoYume and the standard way of uploading them from PC is less and less convenient. So I made this loader. This is a first, crude, but working, version of it.

The loader searches for binary files in /sd/microDOS, lists them and allows to select and load the program. It uses hacked version of PSRAM driver, where I moved mailboxes to $7F000. After the Enter key pressed, MicroDOS loads the binary to PSRAM, stops all cogs except PSRAM driver and runs a cog which moves the binary from PSRAM to HUB. The cog then stops the PSRAM driver, inits the cog #0 from address #0 and stops itself.

The name of the program comes from the 8-bit Atari world. Atari microdos boots from the floppy disk, then searches and lists executable files on it.

There are no standard way to attach a keyboard, so if you want to play with the program. you have to replace my "retrocog.spin2" which uses the RPi based serial kbd interface with your keyboard driver, and add a "readkey" function to it so the main program can call it and read a pressed key code.

«1

Comments

  • Wuerfel_21Wuerfel_21 Posts: 4,374
    edited 2022-06-13 19:36

    I kinda wanted to write something to this extent at some point, but, like, fancier. Never got around to it.

    @pik33 said:
    There are no standard way to attach a keyboard

    I'd argue native USB is, on account of being the only thing you can just plug straight into the Parallax-provided hardware without building some custom contraption. It's not good standard though, USB driver is huge and sucks bong.

    Speaking of, I guess you don't actually have input working in neoyume? Serial input should be easy. Look at the way the raw pin input "driver" works, it's really simple. Just need a cogless serial driver.

    Also, is it just me or is there no sound during the logo screen on mslug?

    Back on topic, SD load should be possible without PSRAM (that's how hot-reload works on P1, afterall. (Spin Hexagon even hot-reloads with some state kept so the main game executable doesn't need to worry about FAT)), but I guess it is easier this way.

  • pik33pik33 Posts: 2,347

    I'd argue native USB is, on account of being the only thing you can just plug straight into the Parallax-provided hardware without building some custom contraption. It's not good standard though, USB driver is huge and sucks bong.

    I simply don't have enough place for another full sized keyboard, and P2 USB driver doesn't like this RPi small kbd. Maybe the best way is to buy another small format keyboard which is compatible with a P2 USB.

    Speaking of, I guess you don't actually have input working in neoyume? Serial input should be easy. Look at the way the raw pin input "driver" works, it's really simple. Just need a cogless serial driver.

    I don't have an input yet but I think it will not be too difficult to replace the USB driver with this serial thing. I wanted to have a MicroDOS first :)

    Also, is it just me or is there no sound during the logo screen on mslug?

    It is there, the amplifier volume was set too low

    Back on topic, SD load should be possible without PSRAM

    Instead of loading from PSRAM you have to have a cog which will do the SD loading. Too complex, and if it is a file system, a bunch of file system related code has to reside in the HUB RAM. This limits the loaded program size. With PSRAM only mailboxes have to reside in HUB and they can be relocated even up to $7FF00.

  • @pik33 said:
    and P2 USB driver doesn't like this RPi small kbd.

    > USB driver is huge and sucks bong

    Back on topic, SD load should be possible without PSRAM

    Instead of loading from PSRAM you have to have a cog which will do the SD loading. Too complex, and if it is a file system, a bunch of file system related code has to reside in the HUB RAM. This limits the loaded program size. With PSRAM only mailboxes have to reside in HUB and they can be relocated even up to $7FF00.

    The way it works on P1/KyeFAT is that the FS code figures out the 64 sectors to load (64*512 = 32k) and then the SD cog code does the rest.

  • pik33pik33 Posts: 2,347

    The way it works on P1/KyeFAT is that the FS code figures out the 64 sectors to load (64*512 = 32k) and then the SD cog code does the rest.

    We have 512 k here, so things are somewhat harder, as the file may be fragmented. For a P1 we may avoid that, using 32kB cluster size. But it seems to be doable: first a list of sectors has to be done using the file system stuff, then the low level SD cog can do what my PSRAM loading cog does, using that list.

    However, we already need a PSRAM for all these ****yumes, the player and whatever fancy will be written in the future so if it is already needed, why not use it in the loader?

  • Yep, might aswell.

  • roglohrogloh Posts: 5,122
    edited 2022-06-14 08:23

    A while back I had this crazy idea of using the same mailbox interface to the memory driver for accessing SD card's file data as well as the usual suite of other memory devices. This would be somewhat like having a memory mapped method for accessing the file. Hasn't eventuated yet but it's in the back of my mind to eventually look at it again to see if there is any scope/use for it, at least in read-only mode. This sort of thing may be useful for a loader tool like pik33's MicroDOS above for example, although it still needs its own standalone COG and it would not be combined with the PSRAM driver COG for example because each driver type runs as an independent COG. A multi-COG initial loader is not beyond the realms of possibility though; we do have 8 COGs free at boot time for such things.

    For an SD file driver I was planning to extend some of the mailbox parameters to refer to sectors instead of bytes so it could handle file sizes > 4GB. It also needs a high level way to open/close files and initialize cards etc, but if that was available it could be neat to be able to open a file and then access its contents just like other memory with the same set of transfer commands already available, it would give you random access to data and do all seeking automatically. This could simplify accessing files quite a bit, especially if you have a PASM COG that wanted access to the SD files and you can't just use the SPIN2 or C driver APIs. Due to the complexity of SD & filesystem stuff, I'm expecting some of this code would have to run as HUB exec, but that's not an issue for the less speed critical paths like file table lookups and directory traversal.

    By using its mailbox polling scheme it would inherently allow sharing of SD file data by multiple COGs which is always handy and it already has the support for locked transfers if writes were enabled too at some point. But there's a lot more to getting this going and I've not had the time to look into it so far. We sort of need some "best of breed" SD sector access code too to leverage and so many people still seem to be doing their own thing there. Got to be rock solid stable over the P2 frequency range for it to be reliable.

    Relatedly I also still want to have a way to use the onboard SPI flash memory chip (e.g. Winbond part) by including it into my memory drivers, similar to what we have for HyperFlash, for example. I've actually started some of that driver work but it's in limbo right now (among several other things). One day...

  • pik33pik33 Posts: 2,347
    edited 2022-06-14 06:21

    Relatedly I also still want to have a way to use the onboard SPI flash memory chip (e.g. Winbond part) by including it into my memory drivers, similar to what we have for HyperFlash, for example. I've actually started some of that driver work but it's in limbo right now (among several other things). One day...

    I extracted simple read and write flash procedures from "jm_p2_flash.spin2" for the robot so it can keep sounds ("the robot is ready", "please remove an object" etc)and maps for autonomic drive in it. My idea is to keep fonts, cursor definitions, sound waves etc in there. There can be also cog driver code kept there so the main program can use them instead of having objects added at the compilation time. These objects eat the memory: you initialize the cog, but the code is still in RAM and this means the heap and stack space is shorter. Maybe something like "use once" may be added to flexprop so it can place the code in the heap space to initialize and forget.

  • pik33pik33 Posts: 2,347
    edited 2022-06-14 10:20

    0.02.

    It is now not as raw as 0.01

    I replaced the "retrocog.spin2" with a "keyboard.spin2" which is a version doing only a keyboard and not mouse or midi, so it can be replaced easier. Todo is to use USB KBM instead. To do this, I have to add a "readkey" method to it.

    To avoid screen switching between VGA and HDMI the program now outputs on both of them at the same time :) (yes, we can :) ) I added color definitions to make them display at different colors.
    I also added a keycodes constants at the starts of it

    The underscores in file names (compile with LFN enabled or it will not work !) are now replaced with spaces.

    There are more comments, and the code is somewhat cleaned.

  • pik33pik33 Posts: 2,347

    0.03

    Cosmetic changes. I changed a font size for a file list and made the space between lines higher. Now it is more readable and there is a place for more columns if needed.

  • pik33pik33 Posts: 2,347
    edited 2022-06-14 12:02

    Speaking of, I guess you don't actually have input working in neoyume?

    Now I have.

    #ifdef INPUT_USE_RPI
    kbd : "keyboard.spin2"
    #endif
    
    #ifdef INPUT_USE_RPI
    kbd.start()
    cogstop(cogid)
    #endif
    

    The keyboard.spin2 has to be cleaned, but it is based on a MicroDos kbd code and instead of putting reports to the buffer it puts bits to $60.

    ' A keyboard contraption cog 
    ' The purpose: to read keyboard serial data from a RPi contraption keyboard interface
    ' v. 0.01 pik33@o2.pl
    '
    con
    
    rxpin=16
    txpin=17
    baudrate=1920000
    
    var
    
    long kbdfront,kbdtail
    long kbdbuf[32]
    long serialstack[64]
    
    pub dummy()
    
    repeat
    'this is the object and not a program
    
    pub start() :cog
    cog:=cogspin(16,serialcog(),@serialstack)
    return cog
    
    pub readrawkey:key |result
    
    if kbdfront<>kbdtail
      result:=kbdbuf[kbdtail]
      kbdtail++
      kbdtail:= kbdtail // 32
    else
      result:=0  
    return result
    
    pub readkey:key |result
    
    if kbdfront<>kbdtail
      result:=(kbdbuf[kbdtail] & $00007F00)>>8
      kbdtail++
      kbdtail:= kbdtail // 32
    else
      result:=0  
    return result
    
    pub serialcog()| rr, mrr, srr, b, mb, midireport, kbmreport
    
    ' This cog listens to the serial port at rxpin and fills a keyboard event buffer.
    
    serial_start(rxpin, txpin, baudrate)
    
    mb:=(-1)
    b:=(-1)
    
    kbdfront:=0
    kbdtail:=0
    
    repeat
    
      rr:=rxcheck(rxpin)
      if (rr>=$80) && (rr<>$FF) && (b==(-1))
        b:=3
        kbmreport:=rr<<24
    
      elseif (b>0) && (rr>=0)
        b--
        kbmreport+=rr<<(b<<3)  
    
      elseif (rr==$FF)
        b:=0   
    
      if b==0  
    
        if (kbmreport +>= $80000000) && (kbmreport +< $87000000)  'mouse, ignore
        b:=(-1)
    
        if (kbmreport +>= $87000000) && (kbmreport +< $8a000000)  'keyboard
          kbmreport:=kbmreport>>16
          if kbmreport==$8852
            long[$60]:=long[$60] | 1  
          if kbmreport==$8851
            long[$60]:=long[$60] | 2  
          if kbmreport==$8850
            long[$60]:=long[$60] | 4  
          if kbmreport==$884f
            long[$60]:=long[$60] | 8 
          if kbmreport==$881D
            long[$60]:=long[$60] | 16  
          if kbmreport==$881B
            long[$60]:=long[$60] | 32  
          if kbmreport==$8806
            long[$60]:=long[$60] | 64 
          if kbmreport==$8819
            long[$60]:=long[$60] | 128  
          if kbmreport==$8828
            long[$60]:=long[$60] | 256 
          if kbmreport==$882a
            long[$60]:=long[$60] | 512
          if kbmreport==$8752
            long[$60]:=long[$60] & %1111_1111_1111_1111__1111_1111_1111_1110      
          if kbmreport==$8751
            long[$60]:=long[$60] & %1111_1111_1111_1111__1111_1111_1111_1101     
          if kbmreport==$8750
            long[$60]:=long[$60] & %1111_1111_1111_1111__1111_1111_1111_1011    
          if kbmreport==$874f
            long[$60]:=long[$60] & %1111_1111_1111_1111__1111_1111_1111_0111   
          if kbmreport==$871D
            long[$60]:=long[$60] & %1111_1111_1111_1111__1111_1111_1110_1111    
          if kbmreport==$871B
            long[$60]:=long[$60] & %1111_1111_1111_1111__1111_1111_1101_1111      
          if kbmreport==$8706
            long[$60]:=long[$60] & %1111_1111_1111_1111__1111_1111_1011_1111    
          if kbmreport==$8719
            long[$60]:=long[$60] & %1111_1111_1111_1111__1111_1111_0111_1111     
          if kbmreport==$8728
            long[$60]:=long[$60] & %1111_1111_1111_1111__1111_1110_1111_1111    
          if kbmreport==$872a
            long[$60]:=long[$60] & %1111_1111_1111_1111__1111_1101_1111_1111       
        b:=(-1)
    
    ''---------------------- Serial functions from jm_serial.spin2, modified
    
    pub serial_start(rxpin, txpin, baud) | bitmode
    
    bitmode := muldiv64(clkfreq, $1_0000, baud) & $FFFFFC00       ' set bit timing
    bitmode |= 7                                                  ' set bits (8)
    pinstart(rxpin,P_HIGH_15K|P_ASYNC_RX,bitmode,0)
    pinstart(txpin,P_ASYNC_TX|P_OE,bitmode,0)
    pinhigh(rxpin)
    
    pub rxcheck(pin) : rxbyte | check
    
    '' Check for serial input
    '' -- returns -1 if nothing available
    
      rxbyte := -1
      check := pinr(pin)
      if (check)
        rxbyte := rdpin(pin) >> 24
    
    pub tx(pin,b)
    
    '' Emit byte
    
      wypin(pin, b)
      txflush(pin)
    
    pub txflush(pin) | check
    
    '' Wait until last byte has finished
    
      repeat
        check := pinr(pin)
      while (check == 0)
    
  • pik33pik33 Posts: 2,347

    .. I have to add a real joystick to this. I have: a 9-pin joystick, a resistor based contraption to connect it to 2 pins, a code which reads the joy... So, what I need is to connect all things together. The joy can be up, down, left, right, A. The rest have to be entered from the keyboard...

  • hinvhinv Posts: 1,252
    edited 2022-07-09 00:44

    @Wuerfel_21 said:
    I kinda wanted to write something to this extent at some point, but, like, fancier. Never got around to it.

    @pik33 said:
    There are no standard way to attach a keyboard

    Has noone produced a PS/2 keyboard & mouse accessory yet? I'm not really into PS/2 mice as my favorite ones, and the cheap good ones are all USB, but all of my favorite keyboards are PS/2 and nothing but a direct wired joystick beats the latency of a PS/2 keyboard.

    I'd argue native USB is, on account of being the only thing you can just plug straight into the Parallax-provided hardware without building some custom contraption. It's not good standard though, USB driver is huge and sucks bong.

    Also a combined PS/2 keyboard and mouse driver was plenty light on the P1, so in many cases reading either can just be done as an incidental to a not-fully-utilized cog. Call me an old fart, but I also still like VGA like @Cluso99.

  • roglohrogloh Posts: 5,122
    edited 2022-07-09 02:31

    I've not seen a breakout around, but it should be easy to make your own dual PS/2 board if you are handy with a soldering iron, it's just a handful of resistors and 5V. A full COG to do it certainly seems a waste. Would be nice if some interrupt or a polled SPIN2 API using a smartpin could be used inline instead. That seems like it could be useful.

    A breakout accessory for PS/2 would only need 4 pins for keyboard and mouse use. I wonder what the other 4 IO could be used for? What would make sense to do with them? Maybe some optional audio line outs if you choose to use the HDMI breakout instead of the A/V accessory, or a header pinned for a serial FTDI cable (it could probably support both)? A single wide accessory could fit one of those double stacked mini-din6 connectors and a 6 pin header behind it for an FTDI cable (and/or a prop-plug header too).

  • @rogloh said:

    A breakout accessory for PS/2 would only need 4 pins for keyboard and mouse use. I wonder what the other 4 IO could be used for? What would make sense to do with them?

    Provided there's a 5 V power-source available, why not MIDI?

  • Good choice for two pins but the midi connector is rather bulky unless you breakout only to a pin header. May need a slightly bigger board with an optocoupler or socket for one if optional. Something wired up like this might make a handy board that could be used for lots of things...serial, audio, kbm, midi, take your pick.

    Another way to go is to have a separate midi + audio board with 2 x midi pins, 4 x i2s digital dac pins, 2 analog audio pins, and keep the other one for serial + KBM.

  • pik33pik33 Posts: 2,347

    @rogloh said:
    Good choice for two pins but the midi connector is rather bulky unless you breakout only to a pin header. May need a slightly bigger board with an optocoupler or socket for one if optional. Something wired up like this might make a handy board that could be used for lots of things...serial, audio, kbm, midi, take your pick.

    Another way to go is to have a separate midi + audio board with 2 x midi pins, 4 x i2s digital dac pins, 2 analog audio pins, and keep the other one for serial + KBM.

    A good idea. What is FTDI for in this?

  • Well you could breakout a second serial port via an FTDI cable or as a logic level UART to something else like a RasPi etc - It's sometimes handy to have another separate way to have the P2 talk outside of the main USB or prop plug on board. It lets you send out to a separate RS232 transceiver board too if required. I'm just proposing to wire in the 6 pin header.

  • It seems to have P2-related previous works, and also external references, so as to avoid (re-)starting from scratch:

    https://forums.parallax.com/discussion/171997/p2-midi

    https://learn.sparkfun.com/tutorials/midi-tutorial/all

    And sure, the "master" source:

    https://midi.org/

    Full specs and guidance can be found there, for free; just a simple registering proccess, and you're in.

    The most recent specs have a lot to say about using 5 V, or even 3.3 V power to drive the circuits, and also many words of caution on EMC, grounding (loops and the like), and non-conforming hardware that can be source of many (and usual) headaches.

  • hinvhinv Posts: 1,252
    edited 2022-07-09 23:12

    @rogloh said:
    I've not seen a breakout around, but it should be easy to make your own dual PS/2 board if you are handy with a soldering iron, it's just a handful of resistors and 5V.

    Indeed. I've got a Johnny Mac, so I'll breadboard it for my ow

    A full COG to do it certainly seems a waste. Would be nice if some interrupt or a polled SPIN2 API using a smartpin could be used inline instead. That seems like it could be useful.

    Yes, indeed. I don't know how to program a smart pin, but PS/2 keyboard protocol is stupid simple. I would think a smart pin could do it. Ben Eater explains:

    A breakout accessory for PS/2 would only need 4 pins for keyboard and mouse use. I wonder what the other 4 IO could be used for? What would make sense to do with them?

    @Yanomani said:
    Provided there's a 5 V power-source available, why not MIDI?

    I'm sure @pik33 would agree with you on that one. I do also as MIDI doesn't seem to be covered by any other accessory. Does the P2 drive high enough for MIDI, or are level shifters needed? If not, it the board would just be connectors, traces and solder. (oh, and resistors too)

  • hinvhinv Posts: 1,252

    @rogloh said:
    Well you could breakout a second serial port via an FTDI cable or as a logic level UART to something else like a RasPi etc - It's sometimes handy to have another separate way to have the P2 talk outside of the main USB or prop plug on board. It lets you send out to a separate RS232 transceiver board too if required. I'm just proposing to wire in the 6 pin header.

    I would rather it NOT have a PropPlug connector but rather one for the cheaper 4/$10 FTDI boards (https://www.amazon.com/FT232RL-Serial-Converter-Adapter-Arduino/dp/B07XF2SLQ1/ref=sr_1_6?crid=3A16YD93CD5TV&amp;keywords=ftdi+usb+to+serial&amp;qid=1657408052&amp;sprefix=ftdi,aps,177&amp;sr=8-6) unless Parallax is going to make the thing (it might be profitable with enough demand). I proposed it in the p2-MIDI thread. I wonder how much interest there is. The PS/2 ports could be quite handy for Console Emulation also.

  • hinvhinv Posts: 1,252

    @pik33 said:
    .. I have to add a real joystick to this. I have: a 9-pin joystick, a resistor based contraption to connect it to 2 pins, a code which reads the joy... So, what I need is to connect all things together. The joy can be up, down, left, right, A. The rest have to be entered from the keyboard...

    Another idea for an accessory board. 2 PS/2 ports and 2 Joy ports (using resistors for analog input, is there a standard for this?). The 2 DB9's could poke out on the left and right and 2 PS/2 ports on the end.
    This probably would be the best Console Emulation too. That brings up another question, does the https://www.ebay.com/sch/i.html?_from=R40&_trksid=p2047675.m570.l1313&_nkw=New+Retro-Bit+Official+Sega+Genesis+Controller+6-Button&_sacat=0 have standard pinouts? How are the extra 5 buttons handled?

    Thanks,
    Doug

  • @hinv said:
    Another idea for an accessory board. 2 PS/2 ports and 2 Joy ports (using resistors for analog input, is there a standard for this?).

    Not really a single standard. There were so many different joystick interfaces...which would you target?

    • 9 pin Atari (5 or 6 buttons I think)
    • S/NES controllers used a 3 pin serial shift register approach
    • Old PC analog 15 pin DB-15, 4 "analogue" inputs plus digital switch buttons, then a few custom extensions on that
    • Sony PS2 used SPI
    • PS3 used Bluetooth or USB
    • Xbox used USB
    • Wii used I2C
    • arcade machines + Jamma boards just use discrete digital buttons inputs
    • probably others...

    Many joystick controllers nowadays use USB which can make thing more difficult to interface to in your own projects, although the USB driver for P2 has been recently modified to support some gamepads by macca and Wuerfel_21, which is very helpful.

  • YanomaniYanomani Posts: 1,524
    edited 2022-07-10 02:01

    @hinv said:

    I'm sure @pik33 would agree with you on that one. I do also as MIDI doesn't seem to be covered by any other accessory. Does the P2 drive high enough for MIDI, or are level shifters needed? If not, it the board would just be connectors, traces and solder. (oh, and resistors too)

    My stronggest advice is for you to take a look at the freely-available MIDI specs, and the more examples you can find, before trying it.

    The following page shows a suggested interface circuit (MIDI 1.0 Electrical Specification Update [2014]), and the link to it can be accessed without registration:

    https://midi.org/specifications-old/item/midi-din-electrical-specification

    When it comes to 3.3V-powered interfaces, it shows very low values for the involved resistors at the "OUT" and "THRU" circuit.

    Since P2 pin-drivers stronggest settings results in ~18 Ohm of series resistance, any extra current-limiting resistor will be limited to just a few Ohms, which seems "very dangerous", in the sense of protecting the output-pins from "your most beloved processor, ever", just to say a minimum.

    The "IN" circuit will also require some toughtfull decisions, since it'll depend on the chosen opto coupler requirements. Without it (opto) your board can be part of a huge ground loop; in general, not a really good thing to deal with...

    But the board(s) is(are) yours (and so does the money); at least, you have way more than 50 free pins for "experimenting"... :smile:

  • evanhevanh Posts: 15,126
    edited 2022-07-10 02:28

    @rogloh said:

    • 9 pin Atari (5 or 6 buttons I think)
      ...

    • arcade machines + Jamma boards just use discrete digital buttons inputs

    Those two are the same and was the norm throughout the 1980's. Many cheap joysticks were built for the 9-pin plug, but the market vanished when 3D graphics and joypads arrived.

  • pik33pik33 Posts: 2,347

    When it comes to 3.3V-powered interfaces, it shows very low values for the involved resistors at the "OUT" and "THRU" circuit.

    I power my 5V based (Arduino type) breakout from 3V3 and it works OK for MIDI In. However I didn't test MIDI Out in this. We can always use a logic level shifter chip, they are cheap, and a 5V voltage is available on the 12-pin connector

    All this optocoupler stuff is done to not connect grounds of the music stuff. For a desktop setup however I already have much worse ground loops (and it is hearable :( ) The P2 is connected to PC USB, then P2 audio is connected to the mixer along with a PC audio, and what is the most evil is the HDMI switch, so I use another small 15" TV for a P2. Adding a (one) MIDI controller keyboard without an optoisolator while the same controller is connected to a PC via USB will add 4th loop. :(

    So in reality the P2 based synth module should (1) have this MIDI optoisolator on board, (2) have its own display, maybe even a touch controlled one, (3) the output audio transformer can also be useful.

    9 pin Atari (5 or 6 buttons I think)

    I already made an interface for Atari type joystick, which was the 80's standard, Atari8, ST, Amiga and C64 used it. 2 pins used, one for direction, one for buttons, several resistors and ADC pin mode. Maybe I should try this with NeoYume or MegaYume But then, Ataris also uses something called paddle, which is in reality a potentiometer, which can be easily created at home, there are objects in Thingiverse ready. These NeoGeo and MegaDrive consoles use controllers with a lot of buttons, so maybe the solution with a PS2, audio and MIDI on one bank and 2 multicontroller interface on another can be better.

  • Wuerfel_21Wuerfel_21 Posts: 4,374
    edited 2022-07-10 11:24

    I ordered some parts for a SNES interface (really just needs two N mosfets to boost latch and clock to 5V and a bunch of resistors). I have a semi-unfinished arcade stick left over from an old project, which I wired up with shift registers at some point. That'll be pretty neat ig.

  • YanomaniYanomani Posts: 1,524
    edited 2022-07-10 12:58

    @pik33 said:

    I power my 5V based (Arduino type) breakout from 3V3 and it works OK for MIDI In. However I didn't test MIDI Out in this. We can always use a logic level shifter chip, they are cheap, and a 5V voltage is available on the 12-pin connector

    Please note that in case of P2 Edge Mini Breakout Board, and P2 Edge Module Breadboard (AKA, JonnyMac), there are two 12-pin accessory headers in each product where the 5V output isn't even available:

    • at J204 (both boards), pin 11 is unconnected;

    • at J205 (Mini Breakout, 64019) and J208 (JonnyMac, 64020), pin 11 is directly connected to P2_RESN.

    Just to keep it in mind:

    • At both boards J204 is the one (connector) that brougths P2_IO[31:24], VIO_24_31, and GND.

    • As for J205 (Mini Breakout), and J208 (JonnyMac), there are P2_IO[63:56], P2-RESN, VIO_56_63, and GND.

    Some useful references can be found at each board Schematics/User-Manuals, and:

    https://forums.parallax.com/discussion/comment/1538575/#Comment_1538575

    Hope it helps (to just don't "fry") any/many bit(s). :smile:

  • Wuerfel_21Wuerfel_21 Posts: 4,374
    edited 2022-07-10 13:40

    The 5V output boost circuit I use for SNES outputs looks like this. I guess the drive through the 10K resistor is a bit weak, but this works at pretty absurd speeds (for SNES clocking, anyways). This may be the smallest possible circuit that accomplishes this.

    For inputs it's just 3.3k inline resistors, as per Chip's recommendation for P1. Is that good for P2 too?

  • evanhevanh Posts: 15,126

    You can probably go direct out. 3.3 Volts for a logic high should work. You could use the 10 k resistors for incoming. If that's enough then it'll be less stress than 3.3 k resistors.

  • @evanh said:
    You can probably go direct out. 3.3 Volts for a logic high should work.

    No it doesn't. The shift registers are CD4021, which need a 3.5V high level.

Sign In or Register to comment.