I do not use any "social networks". Please e-mail me if you require further contact information.
These are some things I made in my spare time. If you'd like more information, e-mail me.
STUMP is a demonstration of running a multicore 64-bit OS alongside DOS on a PC. It is launched from DOS like a DOS application. A loader/driver program runs under DOS, allocates resources from it, and sets up the keyboard, mouse, and video hardware. A small piece of processor startup code is dropped into page-aligned conventional memory. The loader then abuses "unreal mode" to poke at the APIC and send interprocessor interrupts to start the other processor cores at this code. Those processor cores are then put into 64-bit Long Mode and begin entering the kernel. If the kernel panics, the loader can stop the other cores, clean up its DOS resources, and return to the COMMAND.COM.
The root filesystem is stored in a RAMdisk built into the kernel. All of the hardware drivers come from the DOS side of the system. The PC BIOS, DOS, and TSRs are still accessible and are used to handle input and output. Ring buffers are allocated in conventional memory to pass data between the 64-bit multicore kernel and the 16-bit real-mode DOS loader. In this way, STUMP should work on most machines that can run DOS, have at least 2 CPU cores, and support Long Mode (AMD64).
The example image here can run under QEMU. Use a command like this:
qemu-system-x86_64 -cpu max -cdrom stumpdos.iso -smp 2 -m 256Code:
The JVS-Bridge is both a standalone I/O board and a USB device for relaying game input data. In its standalone mode, it only draws power from its USB port. Switches are connected to headers J5 and J6 to provide input data. In USB mode, the JVS-Bridge acts as a USB device. The USB host sends packets of input data to the JVS-Bridge. Then, the input from those packets are given to the game board at its next request.
Photos:The IO-Buddy is an adapter for using a USB gamepad on a JVS arcade game board (such as a Sega NAOMI). Xbox 360 and PlayStation 4 controllers are supported. Up to 4 controllers may be used simultaneously via a USB hub.
The IO-Buddy device is built around a PIC32MX220. The PIC32 has an integrated USB host controller; the IO-Buddy enumerates USB devices and searches for those it recognizes. These devices are then polled for their input data every USB frame. All of the supported controllers use "interrupt mode" USB endpoints, so those with no data are simply ignored until the next 1ms frame. The USB host stack is written from scratch, and just supports enough functionality to enumerate and poll gamepads.
The JVS side of the adapter is built using a MAX485 differential transceiver, attached to a PIC32 UART. The transmit/receive pin on the transceiver is attached to a GPIO, and normally receives. The code for communicating on the JVS bus is entirely interrupt-driven. The PIC32 buffers the bytes received on the JVS bus, until it sees a complete frame. If the frame is valid, it will construct and transmit a reply. This happens in the interrupt service routine, so USB activity is frozen while the JVS reply is made. The USB hardware will, however, continue sending SOF packets, keeping the devices stable until polling resumes. In this manner, the latency from the actual gamepad microswitch to the JVS reply data is minimized.
The IO-Buddy supports re-mapping controller buttons to JVS switch inputs. Different JVS games typically require different control layouts; a controller hotkey is used to re-define the order in which buttons are reported to the JVS host. There is an EEPROM on board to save these mappings; the last 10 USB devices connected will have their settings retained. The EEPROM is connected to the PIC32 via I2C; internal pull-ups on the PIC32 are used.
Photos:The Little80 board is a minimal JAMMA-compatible arcade game PCB. It runs a game called "Falling Block Game" which definitely resembles a famous Russian puzzle game. No DIP switches are provided; the system configuration is entirely done in a test menu, and saved to a serial EEPROM on board. One or two players are supported. High scores are saved to the nonvolatile memory as well.
The main CPU is a Zilog Z80 (more particularly, a Z84C00) running at 6MHz. Its memory space consists of 32KBytes ROM (lower half) and 32KBytes RAM (upper half). The first 4KBytes of RAM is shadowed on write by a set of dual-port 7132 static RAMs, which contain a tilemap for the video display. The video display itself is controlled by an Atmel AT89C2051 microcontroller, which is a cycle-accurate 8051 clone running at a 6MHz input clock. The image on the screen is generated by a series of memory lookups. A counter feeds the tilemap RAM, which feeds a set of 4 pattern ROMs, which feeds a pair of color ROMs. The results of the final lookup feed a simple DAC made from a DIP resistor array. Sound is generated by a second 8051-compatible MCU. It receives commands from an IO port on the CPU, and outputs samples to a 7524 DAC.
As in my prior projects, I developed an emulator to assist with development. Aside from the onboard EEPROM, the emulator mirrors the functionality of the actual board, down to the individual address/data transpositions on the ROM chips. This greatly accelerates testing and debugging.
Photos:The background image shown in these screenshots was created by "Ironthunder" at OpenGameArt.
The Emu-Laser attaches in place of the KSM-440ACM optical block; the Jade Gecko microcontroller is used to emulate its behavior. Outputs from the PlayStation servo driver are fed through voltage dividers into a polling ADC in the Jade Gecko. The Jade Gecko, in turn, outputs an EFM RF signal using a synchronous serial port. The EFM RF signal is fed through a voltage divider into the PlayStation RF amplifier, creating a fake CD readout.
To create a proper EFM RF signal, a simulation of the CD mastering process must take place. Most of this is implemented on a PC with a normal CD-ROM drive. A PlayStation disc is read on the PC; the table-of-contents and all user sectors (with subchannel words) are stored. These are fed into a Cross-Interleaving Reed-Solomon encoder. The output frames from the CIRC encoder are fed into a software Eight-to-Fourteen modulator. The result represents the pattern of pits and lands on the surface of a CD. The fourteen-bit codeword selections - and intervening merging bit selections - are stored in an "Optical Channel Frame" file. The Jade Gecko then only reads the file from the SD card and looks up, once more, the EFM codewords and merging selections.
Photos:Hardware features include:
Graphics are rendered line-by-line in internal memory, similar to classic sprite-engine hardware designs. SDL-based shims can be substituted for hardware drivers, so higher-level functionality can be tested and debugged on a PC. Video output from the Blackfin is "240p"; approximately NTSC line and field timing.
Screenshots:The photos are from a TV which overscans a bit; arcade monitors are underscanned. The actual hardware uses a 6.144MHz dot clock, with 390 clocks per line, and 262 lines per frame. Unfortunately, my video capture card doesn't tolerate this, nor any other timings I can make. Whoops.
Available for download. Building the image will require the excellent WLA-Z80 assembler. GCC can be used to build the graphics-conversion tools. Please excuse the messy code.
Download:These are some of the more interesting projects I worked on in school. The reports assume knowledge of the assigned problems. Unfortunately, I cannot redistribute the problems here.
Web pages look strange without a footer full of fine print. Isn't this print fine?
Lorem ipsum et cetera, Bryan Topp, 2019: Useless link
