The diskette that blew Trixter’s mind

This is pretty obscure, and super old sk00l, but I am completely fascinated. This guy found a disk that was readable by both C64 and IBM PC – quite a rare find indeed…

This diskette has officially blown my mind.

This is the very first time I have ever seen something like this.  The data for the IBM program takes up more than 160KB as evidenced by a DIR.  The C64 1541 drive is a single-sided drive; IBM’s is double-sided. Based on all this, we can deduce how this diskette is structured and why:

– The IBM version of the game required more than 160KB (ie. needed more than one side of a disk), probably because it has a set of files for CGA/Herc (4/2 colors) and another for EGA/Tandy (16 colors) and either set will fit in 160K but both won’t
– The C64 version required around 80K, based on the fact that every other track is unreadable by an IBM drive
– The publisher had the requirement of using only a single disk to save on packaging and media costs
– Not wanting to limit the game to either CGA or EGA, someone at Artech (the developer) built the format of this diskette BY HAND so that DOS would not step on the C64 tracks, and somehow the C64 would also read/boot the disk

I don’t know how the C64 portion boots since track 0 sector 0 looks like a DOS boot sector, but quick research shows that C64 disks keep their index on track 18.  If anyone knows how C64 disks are read and boot, I’d love to know.

The diskette that blew Trixter’s mind « Oldskooler Ramblings.

A/UX Penelope

Very cool informational site about the pre-OSX version of Apple Unix (A/UX). Totally piques my obscure hardware/software interest. 😉

AUX-2x2

From the author’s site:

Between the years 1987 and 1995, Apple Computers, Inc. developed a distribution of System V Unix for the Motorola 680×0-based Macintosh. Much of the initial porting work was performed by UniSoft Corporation, with the project being gradually handed over to Apple Engineers. (UniSoft ported several versions of Unix to Motorola 680×0-based platforms, including the early Sun workstations.)

Apple’s Unix (A/UX) was based on AT&T System V Release 2.2, as the industry had not yet “standardized” on SVR4. However, later versions of the operating system included features from SVR3, and SVR4, as well as BSD Unix 4.2 and 4.3 – TCP/IP networking, streams, Fast File System, job control, lpr, NFS, NIS (Yellow Pages), SCCS, and sendmail. It was a full-featured Unix OS. All of these features, along with a development package (fortran and C) and the X11R4 environment, were included in the base package. Note that these were costly add-ons in many contemporary Unix distributions such as Xenix and SCO Unix.

On top of this solid Unix foundation sat a Macintosh Finder – A full System 7 graphical environment that allowed the system to run both Unix and Macintosh programs, while providing a user-friendly interface. (Sound’s vaguely familiar, doesn’t it?) I’ve included some screenshots to satisfy the curiosity of casual visitors, and to whet the appetite of those who might install the operating system…

(http://www.aux-penelope.com/)

Magic number (programming) – Wikipedia, the free encyclopedia

Interesting list of “Magic Debug Values” from Wikipedia:

  • 0x..FACADE : Used by a number of RTOSes
  • 0xA5A5A5A5 : Used in embedded development because the alternating bit pattern (10100101) creates an easily recognized pattern on oscilloscopes and logic analyzers.
  • 0xABABABAB : Used by Microsoft‘s HeapAlloc() to mark “no man’s land” guard bytes after allocated heap memory
  • 0xABADBABE : Used by Apple as the “Boot Zero Block” magic number
  • 0xABADCAFE : A startup to this value to initialize all free memory to catch errant pointers
  • 0xBAADF00D : Used by Microsoft‘s LocalAlloc(LMEM_FIXED) to mark uninitialised allocated heap memory
  • 0xBADBADBADBAD : Burroughs large systems “uninitialized” memory (48-bit words)
  • 0xBADCAB1E : Error Code returned to the Microsoft eVC debugger when connection is severed to the debugger
  • 0xBADC0FFEE0DDF00D : Used on IBM RS/6000 64-bit systems to indicate uninitialized CPU registers
  • 0xBADDCAFE : On Sun MicrosystemsSolaris, marks uninitialised kernel memory (KMEM_UNINITIALIZED_PATTERN)
  • 0xBEEFCACE : Used by Microsoft .NET as a magic number in resource files
  • 0xC0DEDBAD : A memory leak tracking tool which it will change the MMU tables so that all references to address zero
  • 0xCAFEBABE : Used by both Mach-O (“Fat binary” in both 68k and PowerPC) to identify object files and the Java programming language to identify .class files
  • 0xCAFEFEED : Used by Sun MicrosystemsSolaris debugging kernel to mark kmemfree() memory
  • 0xCEFAEDFE : Seen in Intel Mach-O binaries on Apple Computer‘s Mac OS X platform (see 0xFEEDFACE below)
  • 0xCCCCCCCC : Used by Microsoft‘s C++ debugging runtime library to mark uninitialised stack memory
  • 0xCDCDCDCD : Used by Microsoft‘s C++ debugging runtime library to mark uninitialised heap memory
  • 0xDDDDDDDD : Used by MicroQuill’s SmartHeap and Microsoft’s C++ debugging heap to mark freed heap memory
  • 0xDEADBABE : Used at the start of Silicon GraphicsIRIX arena files
  • 0xDEADBEEF : Famously used on IBM systems such as the RS/6000, also used in the original Mac OS operating systems, OPENSTEP Enterprise, and the Commodore Amiga. On Sun MicrosystemsSolaris, marks freed kernel memory (KMEM_FREE_PATTERN)
  • 0xDEADDEAD : A Microsoft Windows STOP Error code used when the user manually initiates the crash.
  • 0xDEADF00D : All the newly allocated memory which is not explicitly cleared when it is munged
  • 0xEBEBEBEB : From MicroQuill’s SmartHeap
  • 0xFADEDEAD : Comes at the end to identify every OSA script
  • 0xFDFDFDFD : Used by Microsoft‘s C++ debugging heap to mark “no man’s land” guard bytes before and after allocated heap memory
  • 0xFEEDFACE : Seen in PowerPC Mach-O binaries on Apple Computer‘s Mac OS X platform. On Sun MicrosystemsSolaris, marks the red zone (KMEM_REDZONE_PATTERN)
  • 0xFEEEFEEE : Used by Microsoft‘s HeapFree() to mark freed heap memory
  • 0xFEE1DEAD : Used by Linux reboot() syscall

via Magic number (programming) – Wikipedia, the free encyclopedia

Super Nintendo Emulator SE

Just found out about this today – I was always curious as to how they developed games for the Super Nintendo…

emuse2

Super Nintendo Emulator SE

From Wikipedia, the free encyclopedia

The Super Nintendo Emulator SE was a Nintendo-sponsored game development system for the Super Nintendo Entertainment System. It was designed by Intelligent Systems, and sold only to licensed Nintendo development houses.

Physical views

The device is in the form of a large, rectangular metal box, approximately 18 inches high, and 12 inches wide, and 13 inches deep. The box is painted grey, and bears the marking “Emulator SE” on the front in grey.

The device has two controller ports at the bottom that are standard Super Nintendo Controller ports. The rear of the device featured two 50-pin SCSI interface designed to connect to a PC running MS-DOS. One of these ports came with a terminator. The rear of the device also has a port labeled “Multi-Out”, which is identical to the Multi-out port on a normal Super Nintendo.

Below that, it has an 8 position DIP switch. Because there is no known copy of the documentation of this machine, the function of the switches is unknown. Although it is possible the switch is used to set the SCSI ID of the device.

The units bear five-digit serial numbers.

The device is rated to consume 40 watts of power at 120v, and bears a 1991 copyright date. It uses a standard PC Power Cable.

Wikipedia article here:
http://en.wikipedia.org/wiki/Super_Nintendo_Emulator_SE

Some pictures here:
http://shiggsy.gbadev.org/unit.php?unit=22

More info here (from an owner of the system):
http://dforce3000.de/snes.html