What's new
By:

Looking for Linux Expert

One thing that might be useful for probing the boot process and execution of the Lindberh might be to try and get a game to boot in a virtual machine. That way you are running the actual kernel/libraries, and you have full access to the VM's IO to see what the boot process and baseboard module are doing (or trying to do).

With a VM, you'd also be able to write software to emulate some of the custom hardware, like the dip switch bank mentioned previously. On the right motherboard that has proper IOMMU (that works with Linux's KVM) and PCI slots, it would even be possible to throw an original JVS card in and map directly to the VM. I don't think you will find a motherboard with AGP and working IOMMU for virtualization, though, so probably no graphics.

https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware

This is probably some pie in the sky thinking, but I wonder how hard it would be to take PCI devices that mame has emulated and attach those to the vm.

Another potentially useful endeavor might be to disassemble and decompile the baseboard module , and write our own baseboard emulation module to control the appropriate device nodes. This would be another place to go for reverse engineering game/hardware interaction. There are probably some other good targets for disassembly and decompilation on there too, like the sega library mentioned earlier.

Reversing the driver and running a vanilla 2.6 kernel with some custom drivers might be a legitimately good way to run these games on a regular PC once more is known about the custom bits. If there is nothing special about the nvidia drivers, it might even be possible to give the VM its own pcie graphics card with the IOMMU virtualization thing I mentioned before.

The kernel config is definitely not anywhere to be found, right? Not at /proc/config.gz on a booted system or in /boot anywhere? I doubt such a closed kernel would leave those enabled, but you never know.

Full disclosure, I've never done any kernel development, and have had only mild success with reversing some binaries. Granted they were 68k and my assembly isnt the best, but if i were looking at some even shittily decompiled C I could probably figure out what it was doing, especially given the constraints of a kernel module.

I do know quite a bit about the Linux early boot process that might help, like everything starting from the bios all the way until init is called, and some stuff after init as well. This is mostly from a fun problem at my previous job that had me setting up a crash handler for some hung IO so I could get a dump of the entire system memory to some people better than me at GDB.

I'm also competent at linux internals from a systems perspective. I'm interested to see what is on these filesystems and the exact mechanisms through which these parts are mounted and unlocked. I didn't know IDE security/locking was a thing until I started looking at Naomi CF card stuff, and this seems even more complex. I'm going to see if I can acquire a dvd or hdd dump, cf dump, and bios image to see if I can make any headway.

Is there currently a way to get a shell on an running lindbergh system? Being able to get strace on there and run it against segaboot would probably help us understand what it takes for a game to start besides just having the right libraries.

Anyways, I'm happy to help. If there is anything specific anyone thinks I should look into, any questions I might be able to shed some light on, let me know. Otherwise I'm gonna just poke around images I can find and see what I can learn about how this is all put together.
 
Booting the system wouldn't be very difficult however the kernel module won't load because I don't have Lindbergh hardware for the baseboard hook up. The actual driver isn't of much importance it's replacing it and filling in the calls to speak with the games. Either way though my approach is of no use with that because the system files I have are extremely outdated compared to what the games were expecting.
 
sammargh said:
Booting the system wouldn't be very difficult however the kernel module won't load because I don't have Lindbergh hardware for the baseboard hook up. The actual driver isn't of much importance it's replacing it and filling in the calls to speak with the games. Either way though my approach is of no use with that because the system files I have are extremely outdated compared to what the games were expecting.
Click to expand...
There is clear evidence that the CF image contains a very simple Linux system and each game has the possibility of mounting up extra discs which may contain enhanced drivers kernel modules etc.

A VM would be good but if they have compiled in the PCI drivers and suchlikes into the kernel it will fail early when the hardware does not match.
 
rtw said:
sammargh said:
Booting the system wouldn't be very difficult however the kernel module won't load because I don't have Lindbergh hardware for the baseboard hook up. The actual driver isn't of much importance it's replacing it and filling in the calls to speak with the games. Either way though my approach is of no use with that because the system files I have are extremely outdated compared to what the games were expecting.
Click to expand...
There is clear evidence that the CF image contains a very simple Linux system and each game has the possibility of mounting up extra discs which may contain enhanced drivers kernel modules etc.
A VM would be good but if they have compiled in the PCI drivers and suchlikes into the kernel it will fail early when the hardware does not match.
Click to expand...
The base CF image from Mame and the existing dumps paints a pretty clear picture of what is happening with the games. Each game contains its own set of NVidia drivers as well as the baseboard.ko kernel module. From my understanding the Lindbergh baseboard is JVS so it would just be a standard serial port (could be wrong here) and provides a list of function calls that programs can use. Aside from the nvidia drivers and baseboard.ko there is a single extra library in /usr/lib made my Sega. X11 configs are also per-game and loaded based off what baseboard provides while initializing.
 
sammargh said:
From my understanding the Lindbergh baseboard is JVS so it would just be a standard serial port (could be wrong here) and provides a list of function calls that programs can use.
Click to expand...
Unlike Type X, Lindbergh's JVS port is mounted on a PCI card:
837-14472R01_large.jpg
 
sammargh said:
rtw said:
sammargh said:
Booting the system wouldn't be very difficult however the kernel module won't load because I don't have Lindbergh hardware for the baseboard hook up. The actual driver isn't of much importance it's replacing it and filling in the calls to speak with the games. Either way though my approach is of no use with that because the system files I have are extremely outdated compared to what the games were expecting.
Click to expand...
There is clear evidence that the CF image contains a very simple Linux system and each game has the possibility of mounting up extra discs which may contain enhanced drivers kernel modules etc.A VM would be good but if they have compiled in the PCI drivers and suchlikes into the kernel it will fail early when the hardware does not match.
Click to expand...
The base CF image from Mame and the existing dumps paints a pretty clear picture of what is happening with the games. Each game contains its own set of NVidia drivers as well as the baseboard.ko kernel module. From my understanding the Lindbergh baseboard is JVS so it would just be a standard serial port (could be wrong here) and provides a list of function calls that programs can use. Aside from the nvidia drivers and baseboard.ko there is a single extra library in /usr/lib made my Sega. X11 configs are also per-game and loaded based off what baseboard provides while initializing.
Click to expand...
Interesting....
 
twistedsymphony said:
sammargh said:
From my understanding the Lindbergh baseboard is JVS so it would just be a standard serial port (could be wrong here) and provides a list of function calls that programs can use.
Click to expand...
Unlike Type X, Lindbergh's JVS port is mounted on a PCI card:
837-14472R01_large.jpg
Click to expand...
Does the baseboard plug into that? From what I gathered it looked like the kernel module was for this thing

ABohe1b.jpg


Ah-ha, so that pci card is called the baseboard. What a goofy system. Either way though you can write around that kernel driver if you are skilled in drivers/function hijacking. There's no obfuscation on the kernel module and all of the functions are named. Someone with the system and GDB should be able to handle it.
 
sammargh said:
the baseboard
Click to expand...
define what you mean by "baseboard"

....

THIS is the "lower filterboard" or the "security/dip filter board"
837-14520R.jpg


that is where the security key plugs in, it's got dip switches, 2 LEDs, 2 buttons (test and service), and a pin header
it plugs directly into the "motherboard" via what I believe is either a parallel port or something completely custom to the Lindbergh motherboard.

HTB1GrZcKXXXXXXHXXXXq6xXFXXXI.jpg



the lower filterboard it is physically unattached to the JVS card, which plugs into the motherboard like an normal PCI card plugs into a normal PC.
 
Last edited:
Interesting, I've never heard of the JVS card being called the "Baseboard".
 
The lower filterboard i.e. the 171-8322c must connect to something GPIO based.
This is where the PIC is inserted, however there are no active components on the
filterboard whilch will allow it to be detected. This means that before the system probes
the PIC it cannot know if the "filterboard" is present before it probes the PIC.

Does anyone know if an insmod on the baseboard.ko populates /proc in any way ?

Or if an insmod baseboar.ko gets something interesting out of: dmesg ?
 
IIRC the pic goes directly into the parallel port of the motherboard and is read using regular parallel port commands. As it used to be done long ago with parallel port dongles :)
 
somebody loan me one of those filter boards, and i'll create a schematic.
i may even trace it on the motherboard-side.

i only have the motherboard. :(
 
I am curious as to what is on the other side of the 171-8322C PCB, because if they are using a parallel port you don't have a lot of pins. The DIP block would use 8 of them. And with a parallel port you do not get more than 8 inputs ... so I am curious to what is on the other side of that PCB :)


Code: 
  ATARI Joystick                              PC Parallel port
                   +------------------------- pin 5   (Data bit 3)
                   |  +---------------------- pin 4   (Data bit 2)
                   |  |  +------------------- pin 3   (Data bit 1)
                   |  |  |  +---------------- pin 2   (Data bit 0)
                   |  |  |  |  +------------- pin 6   (Data bit 4)
                   |  |  |  |  |  +---------- pin 7   (Data bit 5)
                   |  |  |  |  |  |  +------- pin 8   (Data bit 6)
                   |  |  |  |  |  |  |  +---- pin 9   (Data bit 7)
                   |  |  |  |  |  |  |  |
                   @  @  @  @  @  @  @  @     (resistors)
                   @  @  @  @  @  @  @  @
                   |  |  |  |  |  |  |  |
  pin 1 (UP)     --|--|--|--|--|--|--|--+---- pin 10  (-ACK)
  pin 6 (FIRE_1) --|--|--|--|--|--|--+------- pin 11  (BUSY)
  pin 2 (DOWN)   --|--|--|--|--|--+---------- pin 12  (PE)
  pin 3 (LEFT)   --|--|--|--|--+------------- pin 13  (SLCT)
        (FIRE_2) --|--|--|--+---------------- pin 14  (-AUTO FEED)
  pin 4 (RIGHT)  --|--|--+------------------- pin 15  (-ERROR)
        (FIRE_3) --|--+---------------------- pin 16  (-INIT)
        (FIRE_4) --+------------------------- pin 17  (-SLCT IN)
  pin 8 (GND)    ---------------------------- pin 18  (GND)
 
It looks like a 30 pin connector, so I doubt it's LPT It's probably something custom sega created.

LPT headers on a mobo are 26 pin if I remember well, and they don't stick out on the back.
 
lpt has atleast 14pins inc handshaking and you can multiplex the inputs.
 
You must log in or register to reply here.
Back
Top