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.
Very cool informational site about the pre-OSX version of Apple Unix (A/UX). Totally piques my obscure hardware/software interest. 😉
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…
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 Microsystems‘ Solaris, 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 Microsystems‘ Solaris debugging kernel to mark kmemfree() memory
0xCEFAEDFE : Seen in Intel Mach-O binaries on Apple Computer‘s Mac OS X platform (see
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 Graphics‘ IRIX 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 Microsystems‘ Solaris, 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 Microsystems‘ Solaris, 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
Just found out about this today – I was always curious as to how they developed games for the Super Nintendo…
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.
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:
Some pictures here:
More info here (from an owner of the system):