We need a USB Keyboard and mouse to NeXT NON ADB hardware ia soundcard solution

[Rob Blessin Black Hole]

Hello NeXT Community: Drakware has been sold out of the USB peripheral to NeXT for a long time....

NeXT non adb keyboards and mice are scarce thse days and a lot of folks are purchasing NeXT hardware with out any peripherals . 

So yes I really want to make 100 of these for the growing NeXT vintage hardware community , so ideally we collectively create a solution that is reasonably priced as NeXT NON ADB keyboards and mice are in the stratosphere .

So Adafruit has instructions on how to connect a NeXT NON ADB keyboard to modern hardware via USB ,

which further compounded the availability of NeXT NON ADB keyboards and NeXT NON ADB mice for actual owners of god old 68K  NeXT hardware , OMG , someone please help lol I'm actually loosing it over here. Sense of humor required ,

Question I receive a lot , what type of keyboard do I need or when I plug my NeXT keyboard and mouse into the serial A and B ports on the NeXT nothing happens.

My response , well something probably did happen as you probably bent the pins on both as the mouse plugs into the keyboard and keyboard plugs into the sound card ..... usually silence and yes I received some keyboards and mice back where no doubt it happened

and here we go what port is the sound card , down the rabbit hole .....

So this project was really cool converting a NeXT non adb keyboard to run on modern hardware through USB using an arduino.

https://learn.adafruit.com/usb-next-keyboard-with-arduino-micro?view=all and caused the keyboard community to find the NeXT non adb keyboards , it is cool always enjoyed the clicky feel.

My Question to you all .... is it possible to reverse the code from the link above so it is USB talking to the NeXT Hardware ......

We need the opposite to happen and Matt at Drakware had a working solution and I have a standing order but it has been well over a year . https://www.drakware.com/shop

USB to NeXT NON ADB ,   or PS/2 to NON ADB, or ADB to NON ADB

Brian I know is very busy and the hope is he will manifest a solution eventually on board his magnificent rev 3.0 sound cards ,

As I sold out of the previous revs very quickly as well .....

31 years later and still going strong in the NeXT hardware business but I'm being painted into a corner again lol. 

We have the most talented forum members here , so this widget ought to be a piece of cake. Faster the GPT ....

I bought a few of these , I figure for $7 , it might be fun to get my feet wet and make an ADB to usb connector  just need the additional parts https://www.ebay.com/itm/115948336144  then wondering if this very part may be the key to making a non adb to usb convertor or using the arduino .

How difficult would it be to then reverse it or make something like Steve over at Big Mess of Wires https://www.bigmessowires.com/usb-wombat/  , a Wombat like widget that worked both ways would be astounding for NeXT hardware to USB and or USB to NeXT hardware , any thoughts?

I turned to chat gpt , it's thoughts , I asked it to rewrite the code and it wasn't having it lol may be it was how I was prompting it ......

Creating a USB-to-NeXT Non-ADB converter, similar to the Drakware NextUSB adapter you linked, is a complex task. The Next computer's non-ADB keyboard protocol is not the same as the USB keyboard protocol. Adapting USB to work with the NeXT computer would require not only understanding the USB protocol but also emulating the NeXT keyboard protocol.

The Drakware NextUSB adapter likely involves a microcontroller with firmware that translates USB signals into the NeXT Non-ADB protocol. If you're interested in creating something similar, here are the general steps you might need to take:

    Hardware Setup:
        Use a microcontroller that supports USB communication (e.g., an Arduino with native USB, or an ARM-based microcontroller).
        Connect the microcontroller to the NeXT computer's keyboard port.

    USB Communication:
        Implement USB communication on the microcontroller. You can use libraries or frameworks that support USB communication for your chosen microcontroller.

    NeXT Non-ADB Emulation:
        Understand the NeXT Non-ADB keyboard protocol. This may involve reverse engineering or finding documentation on the protocol.
        Write firmware on the microcontroller to emulate the NeXT Non-ADB keyboard. This includes handling key presses, releases, and any special commands or features.

    Testing and Debugging:
        Test your adapter with a NeXT computer to ensure it behaves like a genuine NeXT Non-ADB keyboard.

    Optimization and Refinement:
        Optimize your firmware for performance and reliability.
        Consider additional features or improvements based on user feedback.

Remember that creating a hardware adapter like this requires a good understanding of both the USB and NeXT Non-ADB protocols. Additionally, working with hardware may involve considerations such as signal levels, timing, and power requirements.

[Rob Blessin Black Hole]

######
And the entire session, I tried : something tells me chat GPT  would be able to do it

Would you be able to reverse this code which lets NeXT non adb keyboards connect to a usb port so that it allows USB keyboards and mice to connect to a NeXT non adb 68 k computer 

// SPDX-FileCopyrightText: 2019 Limor Fried/ladyada for Adafruit Industries
//
// SPDX-License-Identifier: BSD-3-Clause

// NeXT non-ADB Keyboard to USB converter
// This will take an older NeXT keyboard, talk to it, and turn the keycodes into a USB keyboard
// Requires an Arduino Micro for the USB portion - but could be ported to another micro fairly easily
// Written by Limor Fried / Adafruit Industries
// Released under BSD license - thanks NetBSD!
//
// Timing reference thanks to http://m0115.web.fc2.com/
// Pinouts thanks to http://www.68k.org/~degs/nextkeyboard.html
// Keycodes from http://ftp.netbsd.org/pub/NetBSD/NetBSD-release-6/src/sys/arch/next68k/dev/

#include "wsksymdef.h"
#include "nextkeyboard.h"
#include <Keyboard.h>

// the timing per bit, 50microseconds
#define TIMING 50

// pick which pins you want to use
#define KEYBOARDOUT 3
#define KEYBOARDIN 2

// comment to speed things up, uncomment for help!
//#define DEBUG

// speed up reads by caching the 'raw' pin ports
volatile uint8_t *misoportreg;
uint8_t misopin;
// our little macro
#define readkbd() ((*misoportreg) & misopin)

// debugging/activity LED
#define LED 13

#define NEXT_KMBUS_IDLE 0x200600

// NeXT Keyboard Defines
// modifiers
#define NEXT_KB_CONTROL 0x1000
#define NEXT_KB_ALTERNATE_LEFT 0x20000
#define NEXT_KB_ALTERNATE_RIGHT 0x40000
#define NEXT_KB_COMMAND_LEFT 0x8000
#define NEXT_KB_COMMAND_RIGHT 0x10000
#define NEXT_KB_SHIFT_LEFT 0x2000
#define NEXT_KB_SHIFT_RIGHT 0x4000

// special command for setting LEDs
void setLEDs(bool leftLED, bool rightLED) {
  digitalWrite(KEYBOARDOUT, LOW);
  delayMicroseconds(TIMING *9);
  digitalWrite(KEYBOARDOUT, HIGH); 
  delayMicroseconds(TIMING *3);
  digitalWrite(KEYBOARDOUT, LOW);
  delayMicroseconds(TIMING);

  if (leftLED)
      digitalWrite(KEYBOARDOUT, HIGH);
  else
      digitalWrite(KEYBOARDOUT, LOW);
  delayMicroseconds(TIMING);

  if (rightLED)
      digitalWrite(KEYBOARDOUT, HIGH);
  else
      digitalWrite(KEYBOARDOUT, LOW);
  delayMicroseconds(TIMING);
  digitalWrite(KEYBOARDOUT, LOW);
  delayMicroseconds(TIMING *7);
  digitalWrite(KEYBOARDOUT, HIGH);
}

void query() {
  // query the keyboard for data
  digitalWrite(KEYBOARDOUT, LOW);
  delayMicroseconds(TIMING *5);
  digitalWrite(KEYBOARDOUT, HIGH); 
  delayMicroseconds(TIMING ); 
  digitalWrite(KEYBOARDOUT, LOW);
  delayMicroseconds(TIMING *3);
  digitalWrite(KEYBOARDOUT, HIGH);
}

void nextreset() {
  // reset the keyboard
  digitalWrite(KEYBOARDOUT, LOW);
  delayMicroseconds(TIMING);
  digitalWrite(KEYBOARDOUT, HIGH); 
  delayMicroseconds(TIMING*4); 
  digitalWrite(KEYBOARDOUT, LOW);
  delayMicroseconds(TIMING);
  digitalWrite(KEYBOARDOUT, HIGH);
  delayMicroseconds(TIMING*6);
  digitalWrite(KEYBOARDOUT, LOW);
  delayMicroseconds(TIMING*10); 
  digitalWrite(KEYBOARDOUT, HIGH);
}


void setup() {
  // set up pin directions
  pinMode(KEYBOARDOUT, OUTPUT);
  pinMode(KEYBOARDIN, INPUT);
  pinMode(LED, OUTPUT);
 
  misoportreg = portInputRegister(digitalPinToPort(KEYBOARDIN));
  misopin = digitalPinToBitMask(KEYBOARDIN);
 
  // according to http://cfile7.uf.tistory.com/image/14448E464F410BF22380BB
  query();
  delay(5);
  nextreset();
  delay(;
 
  query();
  delay(5);
  nextreset();
  delay(;
 
  Keyboard.begin();

#ifdef DEBUG
  while (!Serial)
  Serial.begin(57600);
  Serial.println("NeXT");
#endif
}

uint32_t getresponse() {
  // bitbang timing, read 22 bits 50 microseconds apart
  cli();
  while ( readkbd() );
  delayMicroseconds(TIMING/2);
  uint32_t data = 0;
  for (uint8_t i=0; i < 22; i++) {
      if (readkbd())
        data |= ((uint32_t)1 << i);
      delayMicroseconds(TIMING);
  }
  sei();
  return data;

}

void loop() {
  digitalWrite(LED, LOW);
  delay(20);
  uint32_t resp;
  query();
  resp = getresponse();

  // check for a 'idle' response, we'll do nothing
  if (resp == NEXT_KMBUS_IDLE) return;
 
  // turn on the LED when we get real resposes!
  digitalWrite(LED, HIGH);

  // keycode is the lower 7 bits
  uint8_t keycode = resp & 0xFF;
  keycode /= 2;
 
#ifdef DEBUG
  Serial.print('['); Serial.print(resp, HEX);  Serial.print("] ");
  Serial.print("keycode: "); Serial.print(keycode);
#endif

  // modifiers! you can remap these here,
  // but I suggest doing it in the OS instead
  if (resp & NEXT_KB_CONTROL)
    Keyboard.press(KEY_LEFT_CTRL);
  else
    Keyboard.release(KEY_LEFT_CTRL);

  if (resp & NEXT_KB_SHIFT_LEFT) {
    Keyboard.press(KEY_LEFT_SHIFT);
  } else {
    Keyboard.release(KEY_LEFT_SHIFT);
  }
  if (resp & NEXT_KB_SHIFT_RIGHT) {
    Keyboard.press(KEY_RIGHT_SHIFT);
  } else {
    Keyboard.release(KEY_RIGHT_SHIFT);
  }
  boolean shiftPressed = (resp & (NEXT_KB_SHIFT_LEFT|NEXT_KB_SHIFT_RIGHT)) != 0;
 
  // turn on shift LEDs if shift is held down
  if (shiftPressed)
    setLEDs(true, true);
  else
    setLEDs(false, false);
   
  if (resp & NEXT_KB_COMMAND_LEFT)
    Keyboard.press(KEY_LEFT_GUI);
  else
    Keyboard.release(KEY_LEFT_GUI);
   
  if (resp & NEXT_KB_COMMAND_RIGHT)
    Keyboard.press(KEY_RIGHT_GUI);
  else
    Keyboard.release(KEY_RIGHT_GUI);

  if (resp & NEXT_KB_ALTERNATE_LEFT)
    Keyboard.press(KEY_LEFT_ALT);
  else
    Keyboard.release(KEY_LEFT_ALT);
  if (resp & NEXT_KB_ALTERNATE_RIGHT)
    Keyboard.press(KEY_RIGHT_ALT);
  else
    Keyboard.release(KEY_RIGHT_ALT);

  if (keycode == 0) return;
 
  for (int i = 0; i< 100; i++) {
    if (nextkbd_keydesc_us[i*3] == keycode) {
      keysym_t keydesc = nextkbd_keydesc_us[i*3+1];
      char ascii = (char) keydesc;

#ifdef DEBUG
      Serial.print("--> ");      Serial.print(ascii); Serial.print(" / "); Serial.print(keydesc, HEX);
#endif

      int code;
      switch (keydesc) {
        case KS_KP_Enter:
        case KS_Return:    code = KEY_RETURN; break;
        case KS_Escape:    code = KEY_ESC; break;
        case KS_BackSpace: code = KEY_BACKSPACE; break;
        case KS_Up:        code = KEY_UP_ARROW; break;
        case KS_Down:      code = KEY_DOWN_ARROW; break;
        case KS_Left:      code = KEY_LEFT_ARROW; break;
        case KS_Right:    code = KEY_RIGHT_ARROW; break;

        // hacks for two tricky numpad keys
        case KS_KP_Equal:  code = (shiftPressed ? KS_bar : ascii); break;
        case KS_KP_Divide:
          if (shiftPressed) {
            Keyboard.release(KEY_RIGHT_SHIFT);
            Keyboard.release(KEY_LEFT_SHIFT);

            code = KS_backslash;           
          } else {
            code = ascii;
          }
          break;
       
        // remap the other special keys because the KeyboardMouse can't send proper vol/brightness anyway
        case KS_AudioLower:  code = KEY_INSERT; break;
        case KS_AudioRaise:  code = KEY_DELETE; break;
        case KS_Cmd_BrightnessUp:    code = KEY_PAGE_UP; break;
        case KS_Cmd_BrightnessDown:  code = KEY_PAGE_DOWN; break;
       
        case 0:
        default: code = ascii;
      }
      if ((resp & 0xF00) == 0x400) {  // down press
#ifdef DEBUG
        Serial.println(" v ");
#endif
        Keyboard.press(code);
        break;
      }
      if ((resp & 0xF00) == 0x500) {
        Keyboard.release(code);
#ifdef DEBUG
        Serial.println(" ^ ");
#endif
        break;
      }
     
      // re-press shift if need be
      if (keydesc == KS_KP_Divide && shiftPressed) {
          if (resp & NEXT_KB_SHIFT_LEFT)
            Keyboard.press(KEY_LEFT_SHIFT);
          if (resp & NEXT_KB_SHIFT_RIGHT)
            Keyboard.press(KEY_RIGHT_SHIFT);
      }
    }
  }
}
ChatGPT

To modify the code to allow USB keyboards and mice to connect to a NeXT non-ADB 68k computer, you need to make several changes. The existing code is designed to convert signals from a NeXT keyboard into USB keyboard signals. For USB input devices to work with a NeXT computer, you need to modify the code to send appropriate signals recognized by the NeXT computer.

The NeXT keyboard protocol is significantly different from USB, and it's not a straightforward process to adapt USB input devices to work with a NeXT computer. The NeXT computer uses a different protocol and has different expectations for communication with its input devices.

If you want to enable USB keyboards and mice to work with a NeXT computer, you may need to look into hardware solutions, such as using a USB-to-ADB adapter or other specialized hardware that can bridge the gap between the USB protocol and the NeXT computer's input requirements.

It's important to note that converting USB signals to NeXT keyboard signals is a complex task that may require specialized hardware and low-level protocol understanding. It's beyond the scope of a simple Arduino sketch and might involve designing custom hardware interfaces.

If you're not experienced with hardware-level programming and communication protocols, I recommend consulting with someone who has expertise in this area or looking for existing solutions that may already provide the necessary conversion capabilities.

[cuby]

My Question to you all .... is it possible to reverse the code from the link above so it is USB talking to the NeXT Hardware ......

At least ChatGPT "knows" that this is a task beyond its (severe) limitations...

Simply "reversing" the code won't work, since you have to implement the exact opposite functionality that this code provides (USB host for HID devices and keyboard device for NeXT keyboard emulation). This information is simply not available in that code.

I wonder if it really makes sense to build a keyboard replacement - usually (especially for Mono Cubes and stations) obtaining a non-ADB sound box is the bigger problem. If you recreate the sound box (protocol), you are no longer required to emulate the NeXT keyboard protocol.

However, the sound box to NeXT protocol is a bit challenging to handle for a regular microcontroller due to the high data transmission speed, that's probably why the NeXTASIC/NeXT soundbox project uses an FPGA - did anyone try to build one?

But there's a possible solution for handling the high transmission speed. Some microcontrollers, such as the Raspberry Pi Pico, provide hardware state machines that can be used to offload some of the time-consuming low-level signal handling such as shifting bits and detecting transmission framing.

It would be nice if we had a description of the protocol instead of reverse engineered bits and pieces that have to be extracted from not exactly great documented source code (then I could try to find a student to work on building a Raspberry Pi Pico-based soundbox emulator), but I'm afraid that this information was never available outside of NeXT.

[gtnicol]

I think it's be worthwhile trying to create an open-source design that could be put together as a kit.

I made a PS/2 to NeXT adapter using a PIC some years ago... PS/2 being a lot simpler than USB I did it all with bit-banging. It's also pretty easy to pull out the video signal. I'm not much of a hardware guy so, I never designed a PCB or anything.

FWIW. I sent the design document describing the ASIC and the protocols to a few folk over the years, including Drakware (who promised a board in return, but like many folk I sent things to, never followed through...). I can share this with folk that are serious about the project.

[cuby]

FWIW. I sent the design document describing the ASIC and the protocols to a few folk over the years, including Drakware (who promised a board in return, but like many folk I sent things to, never followed through...). I can share this with folk that are serious about the project.

I would definitely be interested to take a look and I think I'll find a student who would be interested in working on a converter (I wish I had the time to do it myself instead of all the silly admin stuff here...).

[gxs]

I'm not a hardware guy either, apart from programming it when I used to do embedded and device driver work.

It's a long time since I have read the NeXT Soundbox interface spec but if I recall correctly it consisted of an I2S stream interleaved with scan codes/mouse movement from sound box to computer and and I2S stream interleaved with stuff like LED status going from computer to soundbox.

Could I2S transmitter and receiver chips do the heavy lifting with a small microcontroller interfacing the USB HID devices? I guess there would be some logic to detect the start/end of an I2C word (maybe interrupting the microcontroller) and a shift register to insert the keyboard/mouse data.

The I2S spec from NXP is here

Adafruit has a post about an I2S ADC board https://blog.adafruit.com/2021/01/16/tlv320adc-4-channel-microphone-i2s-adc/ and sells an I2C DAC board https://www.adafruit.com/product/3006

[Nitro]

I could design an open-source 3D printed NeXT style case if needed. I remember someone on the forums here asking how to get into the ROM monitor with a USB keyboard, so that key combo would have to be taken into consideration along with the power on button. The RPI Pico design sounds really interesting. Let me know if there's anything I can do to help.

[gtnicol]

We collectively have more than enough to put together a design that doesn't need the ASIC... noting that it's pretty easy also to modify the ADB boards to support non-ADB keyboards.

The PIC was pretty slow and very constrained relative to a pi pico, and it worked OK (didn't handle sound though).

[cuby]

Could I2S transmitter and receiver chips do the heavy lifting with a small microcontroller interfacing the USB HID devices?

If it's really an I2S stream then most modern (e.g. ARM Cortex M) microcontrollers should be able to interface to the stream directly - unless the protocol is somewhat non-standard...

[Rob Blessin Black Hole]

Hello NeXT Communnity:
I found some info on NeXT keyboard timings here

https://github.com/tmk/tmk_keyboard/wiki/NeXT

Reverse enginering the NeXT  1988 Keyboard https://journal.spencerwnelson.com/entries/nextkb.html

We have the solution for Converting PS/2 Mice to NeXT non adb here from Brian

http://www.asterontech.com/Asterontech/next_ps2_mouse.html

and with Brian's Sound Card an earlier version this one used the non adb emulator chip found on NeXT non adb keyboards on the NeXT laser printer logic board https://www.youtube.com/shorts/BZyTvLijFl4 where later version have the NeXT ASIC so perhaps there would be a way to add a device module or integrate it like Matt's USB to NeXT .  Brian will no doubt have some talented into this as well

Matt at Drakware has all the work done so would be able to help make quick work of it , I found his you tube page https://www.youtube.com/watch?v=9kzsHDrzawE  , I'm not sure if the availability of the parts is still an issue and I'm willing to pay him a royalty . I noted that with his design not all USB keyboards and mice worked . So that being said only low voltage.

I also did some research on othe Keyboards that used : MINIDin 5 connectors
on  keyboards found this on Desk Authority
https://deskthority.net/wiki/Interface_recognition#5-pin_mini-DIN   and it looks like

NEC Keyboards here https://deskthority.net/wiki/NEC_PC-8801 also used mini din 5 connectors
for the PC 8801 https://en.wikipedia.org/wiki/PC-8800_series  which displayed kanji characters, not sure if there is any cross over but found it interesting

This one is really interesting as it is a black Commodore CDTV Amiga https://deskthority.net/wiki/Commodore_CDTV and note it is not exchangable with any other amiga keyboard ..... sound familiar . Very similar layout except it lacks the cluster for power key, sound and brightness up and down.

So obviously any widget needs that power button on it and programmable keymapping .

Found these guys that may have compunents, soderless breadboards and adaptors with schematics https://www.technologicalarts.com/pages/connector-options-2

And About the Serial  Ports A and B on the back of the NeXT, I know you can use them for a monitor? In the rom bios but would it be possible to actually write drivers that let serial devices connect and would it be testable in previous .   Or alternatively through DSP probably the easiest path and not that it is easy is the way it is configured currently.

One thing that intrigues me as well is when you plug an ADB keyboard into a non adb NeXT , it powers it up but it is unresponsive but the power key works.....  so would it be possible to make a translator to covert ADB to NON adb. They are similar enough in design where with just a few mods Brian created / converted a modification to NeXT ADB sound cards to become dual compatible .

 So perhaps this is key where some how ADB peripherals spoof the NeXT earlier non adb NeXT's into thinking it is a non adb device so I know there are differences like you can hot swap non adb keyboards and mice , where adb is hardwired and can handle up to 7 devices and has the extra wire on pin 7 ......  So what would it be, you probably still need the power feature for adb but drop and translate the adb keyboard protocol to match non adb keyboards timings and keymapping and protocol , is it it a custom modified rom chip..... I'm throwing stuff at the wall but may be some of it makes sense.....


Hope that helps !

[Rob Blessin Black Hole]

Here is a good thread on how a guy created a PS/2 to Mac http://synack.net/~bbraun/mackbd/index.html and possibly doable by average users, Mac Keyboard Interface

This is a project to interface with the Mac 128k/512k/Plus keyboard port. This will kind of be an ongoing work in progress for a while, updates will be posted here.

Would this board be the device we seek https://www.st.com/en/evaluation-tools/stm32f0discovery.html   

#It would be fun to offer a cheap DIY kit for support of USB or PS/2 to NeXT and also obviously a preassembled one .
Sometimes it is not about the money as I am more than happy to see these NeXT's coming back to life as are all of you.
Especially with the younger crowd . I've found Generation Z and older lol some of us much older but still identify as in my 20's ha ; are starting to enjoy tinkering with this old stuff and they find a reasonably priced NeXTSTATION and then become discouraged by barriers to entry.
Trying to explain what all NeXT proprietary is needed is complicated .

Barriers to entry you say , well you can see what it takes in this example :
of an Air Cube and how far we have gone to invent ways to make it all work 30 years later:)

Cubes are becoming scarce and NeXT Computers we're rare to begin with ,

However you can do this:

https://youtu.be/Ok4YrpFEbMo?si=LqQ-4fhTYqnste-a

Air Cube = Cube minus the Cube Magnesium case (Sacrilege I know just a demo)

1) NeXT Cube Internal Backplain this is the key to the whole project as your motherboard and power supply and loadboard if needed plug into it , yes I have them

2) Cube Power Supply in this case an early model 152  yes I have them
Later model 983 power supplies do not require a load board sold out
or go full GURU and http://www.asterontech.com/Asterontech/cube_atx.html BA Cube ATX Powersupply with Board connection

3) Power supply attached drive harness optional it holds your drives, one was not used for the above demo Yes

4) Early Power supply model 152  requires a load board to simulates the NeXT 4000 or 4000A Monitor load  ingenuous board BA comes through again an appliance light on a little custom board tricks the power supply into staying on lol , NO currently out of stock more coming in ...

5) Demo shows early scsi2sd , we currently use ZULUSCSI Cards which which replaces the old noisy scsi hard drives as it is also an early 68030 25Mhz board , you need a molex 4 pin connector to supply power to the SCSI2SD haven't tested with ZULU yet ,
68040 25Mhz power from the 50 pin scsi cable works to power the PCB scsi2sd or ZULU SCSI SD Cards yes

6) Cube  Motherboard in the demo early 68030 25Mhz Yes

7) Ram minimum of 8Mb max 64Mb 30 pin simms sets of 4  Yes

Bios battery Panasonic 2/3 volt yes I have them

9) New ceramic capacitors on the motherboard , yes they all need them and we do them

10) SCSI 50 pin cable , Yes I have them

11) The Demo shows our nifty custom Y Cable so you can use a flat panel display , Yes I have them

12) Then the sound card , in the demo it shows an adb to non adb sound box conversion , sold out
We also have more Brian Archer (BA) 3rd party GURU sound cards in the works

13) The Demo shows a NeXT NON ADB Keyboard and NeXT NON ADB Mouse which are becoming hard to find
and thus the reason for this thread requesting your help to create a USB and or PS/2 and or ADB to NeXT NON ADB solution !

14) Lots of stealth projects are going on as well , we love our NeXT's like DSP expansion chips , Verilog FPGA boards which support WIFI, HDMI , Fast Ethernet etc. an stuff so far out there it is amazing like  .... I'm excited to see this one and SW is the real deal :
#####
15) Regarding the CPU clock speed limit and memory limit (128MB with 33 MHz Turbo Cube and the 64 MB memory limit with 25 MHz Cube), I learned that this limit comes from a motherboard ASIC (designed by NeXT for DMA between memory and I/O channels) and PROM as well as kernel design that you've mentioned.

So, to overcome the limit, my first plan is: is:

    Reimplement the function of 040 NeXTcube board on an Xilinx FPGA board with an upgrade on 1) the motherboard DMA ASIC to cover 32bit physical address (4 GB) and 2) another upgrade on the NBIC chip to support a large memory.
    Modify the v57 PROM (source code available online) to detect more than 1 GB memory.
    Modify the NeXTSTEP 2.0 kernel mk-108.1 (source code available online)

With the modified v57 PROM and NeXTSTEP 2.0 kernel, I think NeXTSTEP 2.0 applications could use up to 2 GB on FPGA board.

Once this works, I see a number of potential long-term plan as the next stage to run OpenSTEP 4.2 applications on the new motherboard with large memory (to be implemented on an FPGA board in a way that it's plug-gable to the NeXTcube case) and later to support multi-processors. Just to name a few such potential approaches:

    Modify mkLinux (Mach kernel 3.0 based on OSF/1) to support the new motherboard and implement missing system calls and userland features for running OpenSTEP 4.2 apps.
    Make a NetBSD/next68k kernel support on extended COMPAT_MACH feature and implement missing userland features to run OpenSTEP 4.2 apps.
    Modify the Apple Drawin kernel to support the new motherboard and implement missing system calls and userland features to support OpenSTEP 4.2 apps.

#########

16) Yes a Magnesium Cube Case   I keep thinking stay on topic lol ,so yes we need an affordable  way to connect modern keyboards and mice to a NeXT NON ADB system and Drakware also had a solution to bypass the sound but that is half the fun of owning a NeXT is the sound features:)

[Rob Blessin Black Hole]

Hello NeXT Community:  Forest through the trees ..... With original vintage hardware keyboards and mice prices climbing , would it be possible to create a device with multiple common vintage keyboard inputs that acted as a translator so in effect you order the pcb board and it comes with a set of keyboard connectors like an interchangable  socket set , modules lol you pick the connector you need and you would need the actual cable from the device to the computer but it lets you plug in usb keyboard and mice or like the wombat lets you go both ways . So you can order the device with the specific connector you need preconfigured and go.  Make it opensource as well

 I think with the growing collector market it would be cool to have a KM style switch that you would be able to simply plug into the system better yet wireless . So may be you would be able to ping all of your vintage hardware from an Ipad or laptop wirelessly  less wear and tear on the vintage keyboards and mice and old computers as well ....  for now a simple solution USB, PS/2 or ADB to NeXT NON ADB is all we need. Trees among the forest of vintage proprietary hardware.

See the forest thrugh the tree's , I guess what I'm trying to say it would be an elegant solution if you are looking to purchase vintage hardware and have no way to test it because the keyboard and mouse is missing or in museum settings via wifi networking like screen cast and watch me for NeXT , is it a combination of software and hardware , a remote desktop solution for vintage hardware..... like Previous being able to wirelessly communicate / network with original NeXT hardware Is It possible?


Now this device seems promising 2014 and it even has CUBE in the name https://www.st.com/en/embedded-software/stm32cubef0.html

and the latest version for 2023 https://www.st.com/en/embedded-software/stm32cubef0.html#documentation

        Embedded Software MCU & MPU Embedded Software STM32 Embedded Software STM32Cube MCU & MPU Packages STM32CubeF0

STM32CubeF0
Active

Save to MyST

STM32Cube MCU Package for STM32F0 series (HAL, Low-Layer APIs and CMSIS, USB, File system, RTOS, Touch Sensing - and examples running on ST boards)
Get Software
Download databrief
Product overview
Description

STMCube™ is an STMicroelectronics original initiative to make developers' lives easier by reducing development effort, time and cost. STM32Cube is the implementation of STMCube™ that covers the whole STM32 portfolio.
[stm32cubef0 board photo]

STM32Cube includes STM32CubeMX, a graphical software configuration tool that allows the generation of C initialization code using graphical wizards.

It also comprises the STM32CubeF0 MCU Package composed of the STM32Cube hardware abstraction layer (HAL) and the low-layer (LL) APIs, plus a consistent set of middleware components (RTOS, USB, FAT file system, and STM32 touch sensing). All embedded software utilities are delivered with a full set of examples running on STMicroelectronics boards.

The STM32Cube HAL is an STM32 embedded software layer that ensures maximized portability across the STM32 portfolio, while the LL APIs make up a fast, light-weight, expert-oriented layer which is closer to the hardware than the HAL. HAL and LL APIs can be used simultaneously with a few restrictions.

Both the HAL and LL APIs are production-ready and have been developed in compliance with MISRA C®:2004 guidelines with some documented exceptions (reports available on demand) and ISO/TS 16949. Furthermore, ST-specific validation processes add a deeper-level qualification.

STM32CubeF0 gathers in one single package all the generic embedded software components required to develop an application on STM32F0 microcontrollers. Following STM32Cube initiative, this set of components is highly portable, not only within STM32F0 Series but also to other STM32 Series. In addition, the low-layer APIs provide an alternative, high-performance, low-footprint solution to the STM32CubeF0 HAL at the cost of portability and simplicity.

HAL and LL APIs are available under open-source BSD license for user convenience.

    All features
        Consistent and complete embedded software offer that frees the user from dependency issues
        Maximized portability between all STM32 Series supported by STM32Cube
        More than 130 examples for easy understanding
        High quality HAL using CodeSonar® static analysis tool
        High quality low-layer APIs (LL) using CodeSonar® static analysis tool
        STM32F0-dedicated middleware including USB Device, FatFS, RTOS and touch sensing library
        Free user-friendly license terms
     

[gtnicol]

I've shared the ASIC spec with a few folk over the years to help with some of the efforts. Perhaps it's time it ended up in the archives...

[Nitro]

I've shared the ASIC spec with a few folk over the years to help with some of the efforts. Perhaps it's time it ended up in the archives...

Here's the datasheet for the Philips SAA7320 Stereo CMOS DAC mentioned on Sheet 13 of 34.

[barcher174]

Here's the datasheet for the Philips SAA7320 Stereo CMOS DAC mentioned on Sheet 13 of 34.

Oh man I wish I would have had that one sooner!