Warning: set_time_limit(): Cannot set time limit in safe mode in /home/www/dynamic/uv.ro/pubory.uv.ro/public_html/pub/index.php on line 526 sega/00index.txt0000755000000000000000000000121011266514771010702 0ustar copyrfaq.txt Game Copiers for the SNES/Genesis FAQ - version 1.15 emu-mech.txt discussions about software emulators (c.s.a.emulators) gamemed2.txt control signals in '139 and '374 gamemedc.txt gamemedc.zip info gamemedc.zip SNES and Genesis cartridge reader - desc, schema, source ggenie.txt Game Genie for Genesis decoder info hardware.txt Sega Genesis Hardware Internals - 4 July 1993 joystick.txt Genesis joystick pinout rgbcable.txt Genesis RGB cable order info sega-rgb.txt do-it-yourself connect Genesis to RGB monitor sega8pin.txt pin configuration segafaq.doc Sega Programming FAQ - 4 July 1994 switch.txt Sega NTSC/PAL and Language Switch sega/demo0000755000000000000000000000000011277647666007556 5ustar sega/demo/index.html0000755000000000000000000000230611277647666011636 0ustar Index of /demo
BluePink BluePink
XHost 		Gazduire site-uri web nelimitata ca spatiu si trafic lunar la doar 15 eur / an. Inregistrare domenii .ro .com .net .org .info .biz .com.ro .org.ro la preturi preferentiale. Pentru oferta detaliata accesati site-ul BluePink

Index of /demo

Last Updated: Wednesday, September 3rd, 2003

File name Size Last update Description
[..]<DIR>9/3/2003, 19:45Parent directory

There are 0 files and 1 directories
for a total of 0 bytes. sega/docs0000755000000000000000000000000011277647701007550 5ustar sega/docs/copyrfaq.txt0000755000000000000000000003604211266515000012204 0ustar From: vsuhocki@cbnewsm.cb.att.com (v.p.suhocki) Subject: Copier FAQ v1.15 THE FREQUENTLY ASKED QUESTIONS LIST TO GAME COPIERS FOR THE SNES/GENESIS ver 1.15 (Last Revision 11/16/93) Credits: Maintained by: vsuhocki@cbnewsm.cb.att.com <------(send submissions here) Edited by : ratnuts@panix.com skleung@csd.hku.hk Contributors : drknight@garg.campbell.ca.us cw531@slc4.ins.cwru.edu coyote@mentor.cc.purdue.edu joss@asterix.grenoble.hp.com This is being maintained because there are always questions on rec.games.video.* about what a game copier is, where to get one, how much is it, how does it work, etc. I'll try to update this as I get new info or corrections, but no guarantees. Some information might be incorrect, so if you have the correct info, please mail it to me and I'll include it and list your name at the top as one of the contributors. Table Of Contents a) Preface (taken from the rec.games.video FAQ) 1) What is a Game Copier? 2) What are the different kinds? 3) How does it work? 4) Are all machines compatible? 5) Where can I get GoldFinger codes? 6) What are some problems? 7) Is this thing legal? 8) How much does it cost? 9) Where can I get one? 10) Will it become obsolete? 11) News Updates 12) User Tips 13) Mailing List 14) Final Notes a. Preface I think the short part from the r.g.video FAQ is good for starters. (maintained by Ken Arromdee (arromdee@jyusenkyou.cs.jhu.edu)) Yes, it is legal to copy games for your own private use. No, it is not legal to give away or sell the copies. No, it is not legal to give away or sell the original and keep the copy. No, there is no known cheap way to copy CD-ROMs yet. Yes, they have legal uses: to copy your own games for backup, and to directly modify the game code without a Game Genie-type device. New developments such as Real Time Saving and Slow Motion add to the versatility of these copiers. Backup RAM copying is one great feature, it allows multiple save games instead of the 3 you are limited to in a game. It's questionable how many copierowners actually use them mostly for this. 1) What is a Game Copier? A game copier is a machine that hooks into your game system and takes the game that is in the cartridge and copies it to a diskette. 2) What are the different kinds? (Note: there are more than this, this is just a sample list) For SNES: Super Wild Card, Super Magicom, UFO Super Drive, Super Pro Fighter Q, Supercom Pro, Game Doctor SF, Supercom Partner, Dragon Boy. For Genesis: Super Magic Drive, Interceptor, Mega Disk, Magic Drive Plus (SMD can be used for SNES with an optional adaptor called the Super Magicom Drive) For SNES and Genesis: Multi-Game Hunter, Multi-Game Hunter/ASIC. (Note:Check your systems RAM physically. It won't show the extra 8 meg on startup. You should have 6 rows of chips and no empty clusters.) For SFC,SNES,MD,GEN,PCE,TG16,SuperGrafx,GB,NeoGeo: Multi-Game Doctor II 3) How does it work? The game copier takes the game from the ROM in the cartridge and then copies it out to a file on the diskette in the drive. Then it is your backup copy; if you ever lose your original, you have a backup to replace it. To play the game, you put the diskette in the drive and it loads it into memory and the game is able to be played. Games larger than 12 megabits (like SF2) need more than one diskette. The copier breaks the game into 2 parts which are copied to 2 diskettes. Games that have battery saves (like Zelda 3) save the games to diskette in files, so they are still retrievable and usable. The disks are MS-DOS format. 4) Are all machines compatible? No, some machines write in to their own format. But most follow the SMC or SMD format. There are utilities to convert between formats. The most compatible machine is the SWC. It can read all HiRom formats created by backup copiers, and most file formats by other copiers. 5) Where can I get GoldFinger codes? There is a server called Email a message with the text send SNES/game_name or send Genesis/game_name quit For the game name you must use dashes as spaces. Like Final Fantasy 2 is Final_Fantasy_II. 6) What are some problems? Some cartridges require a DSP chip made by the company, or a RISC chip (aka FX chip) in the cartridge. An adaptor can be bought, or the cartridge must be seated at the top for the game to access the chip. Also HiRom games are problems if your copier doesn't support them. There are 2 decoders, one for <=16M and one for >16M, make sure you get both. Now games are using an SRAM check to check the amount of SRAM avaiailable. Most cards have 8k-16k, but a copier usually has 256k. Most copiers need a patch to fix this, but the GDSF3, SWC, and SPF-Q automatically protect this problem. A list of games with DSP/FX/HiRom/SRAM is at the end of this section. Also, if Nintendo comes out with a hardware protection scheme, a new copier might be needed (or just another adaptor) but this is not likely because it adds to the cost of producing the cart, and not many software companies will spend the extra money just for the sake of stopping these backup devices when they will sell at least their expected number of units anyway. Game Size Extra Lord Monarch 4M HiRom Super Mario Kart 4M DSP Pilotwings 4M DSP F1 ROC 2 8M DSP Super Bomberman 4M HiRom StarFox 8M FX/RISC FX Trax 8M FX/RISC SF2 Turbo 20M HiRom Super Air Dual 4M DSP Exaust Heat II 8M DSP 3D Baseball 8M DSP Suzuka 8 Hours 8M DSP Votoms 8M DSP Barcode Battle 4M HiRom Dungeon Master 8M DSP Psycho Dream 8M HiRom SD Battle Soccer 8M HiRom Dragon Knight Group 8M HiRom Romance/3 Kingdoms 2 12M HiRom Ramna 1/2 Part 2 12M HiRom Europe Sensen 12M HiRom F1 GrandPrix 2 12M HiRom Super Baseball 2020 12M HiRom Wolf/Wild Deer 12M HiRom Taikon Rissiden 12M HiRom Elnard 12M HiRom Dragon Slayer 2 12M HiRom Final Fantasy 5 16M HiRom Castle Wolfenstein 8M HiRom World Heroes 16M HiRom Seventh Saga 12M HiRom Secret of Mana 16M HiRom Shooting Macross 8M HiRom Aladdin 10M SRAM R-Type III 16M SRAM Madden 94 8M SRAM Super Mario All-Stars 16M SRAM Art Of Fighting 16M HiRom Another problem with copiers (usually old ones) is FastRom. Fast rom refers to cartridges which require DRAM that run at speeds of at least 70ns. Many of the older backup systems used 80ns DRAM boards. The reason why these older backup systems will not run the crop of FastRom games is because the memory is too slow to handle the FastRom routines in the cartridge, and thus you will get black screens or glitches during a game. These FastRom routines are beings used because the SNES is a slow machine, and so to speed up the the newer games, FastRom is used to eliminate any potential slowdown of the system. The first FastRom game was Super Star Wars, since then there have been many games FastRom games released. All current backup systems can handle them, and you can get an upgrade chip or software patch if you don't have a FastRom decoder. 7) Is this thing legal? Technically, yes. You are within your rights to make an archival copy of your games for safekeeping in the event your original breaks. Piracy is an awful side-effect of these, but if you pirate the games, the companies will lose money, and then games will begin to suck, and then there will be no point of using game systems anymore. 8) How much does one cost? This is the bad part. They usually cost $300 and up, the lowest I've seen so far was $280 for a Super Wild Card 16MB from some guy who said he was going to get them at cost on a trip to Hong Kong. But usually expect to pay a higher price for a system that supports more, like the Super Wild Card 24MB is about $355, but for the MultiGame Hunter 24MB which supports SNES and Genesis is $370. The Multi-Game Doctor II which supports every known system (including Neo-Geo) costs $650. Check your company for what adaptors you get with the MGD2. 9) Where can I get one? The best place I know of is National Console Support. They sell all of the above systems, at decent prices. They also have lifetime support of the system, and a monthly newsletter. They can be reached at: Voice: (718) 523-5774 (9-6 weekdays) Mail: (917) 788-0699 Fax: (718) 523-8414 BBS: PRIVATE (If your are a NCS customer, email ratnuts for the #) You can also email ratnuts@panix.com for an info-pak with color pictures of their most popular systems from NCS about their systems and prices. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ skleung@csd.hku.hk sells systems at cost prices and mails them to you from Hong Kong. His prices are cheaper than NCS. Some prices include the Super Wild Card 24MB for $330, the MGH/ASIC 24MB $330, and the Magic Drive Plus 24MB $345. No power adaptors are shipped with his products, and to pay you must use direct/wild money transfer. If you have more questions, please email him. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Console Connection sells MGH's and parts only. They are available at (214)306-3640. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Beyond Computers sells consoles for most systems. Info: 212-832-0078 Mail: 917-462-5071 Order: 800-851-9176 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Console Repairs repairs ALL console systems at reasonable prices. Call for more information on prices for each individual system repairs. (312)947-0107 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 10) Will it become obsolete? Well, all things do become obsolete, but these new systems will last as long as the Genesis and SNES do. All current systems are upgradeable to 24 meg and 32 meg to support the new games. The MGH is a good example of an upgradeable system. For example, the first batch of MGHs released in the spring of '92 are able to run high rom games with the use of the high rom adaptor. On the Super Magicom, you had to replace the mother board with The Super Magicom+ or Super Wild Card upgrade board in order to backup and run the high rom games. But the system was still upgradeable though the upgrade path was not as simple as the MGH. 11) News Updates ----------------------------------------------------------------------------- The Game Doctor SF3 was released recently. It now occupies about 50% of the copier market in Hong Kong. It has 24MB or 32MB, supports all DSP/HiRom games, and can play StarFox. It is MultiLingual, has advanced OS, and superior backup features. It is the most user-friendly system. ----------------------------------------------------------------------------- The Magic Drive Plus has been released from the creators of the Super Magic Drive. Also known as the Super Magic Drive 2, this has 24 megs and can copy all Genesis games, including SF2:SCE. But it can't play SF2:SCE from a backup. ----------------------------------------------------------------------------- The Super Pro Fighter now has a Turbo cart which when plugged in, along with a 24MB ram upgrade, will let users backup and play SF2:Turbo. Also there have been similar upgrades released for the UFO and MGH. ----------------------------------------------------------------------------- A new dummy cart with 8MB of ram will be released for current MGH systems so they can backup 20-24MB games. ----------------------------------------------------------------------------- FFe (the makers of the SWC) has released the "Turbo Upgrade Kit" for current SWC systems. It consists of a 24MB ram board, DOS 2.6CC, and a U12 18CV8 Peel. Estimated costs are between $135-$150. Check with your dealer for possible trade-in's of current 16MB ram boards for credit. ----------------------------------------------------------------------------- The MGH/ASIC has been released. This is just an update of the current MGH and has an ASIC chip and a new SNES decoder chip. It is fully compatible with the MGH. All current accesories for the MGH work with the MGH/A. 2 bases were released: A grey one, and a black one. The black one includes both hirom decoders and can play all games, while the grey one only includes the one for <=16MB games. ----------------------------------------------------------------------------- 12) User Tips a) skleung@csd.hku.hk (Michael Klauser) writes that the UFO Super Drive reads slowly, and to make it faster you should use the internal format command, but that is not MS-DOS compatible. To attain a maximum of 29 seconds for an 8M file, you should use FDFORMAT and make the following batch file called f144.bat: fdformat b:/u d16 g100 x1 y3 For the MGH: fdformat b: g42 t82 n20 d16 x1 y3 b) ratnuts@panix.com (Peter Mui) writes on how to make the cable to transfer files between a PC and a SWC. Get a RS232 DB M/M 25 pin cable. Remove pins 12, 14, 15, and 16. This removes the volts sent by the computer when it is turned off. For an Amiga to SWC cable, get an assembled RS232 DB 25 M/M and switch the wires from pin 1 to 13 on one end. You will have to connect the modified end to the Amiga and the unmodified end to the SWC. For more information on proper assembly, contact Peter. 13) Mailing List A new mailing list has started for the Copier FAQ. If you want to get each new version as it comes out, please send email to me with the subject: Copier Mailing List (your.email@address.here) Then you will be added and get each new revision as it comes out. 14) Final Notes Thanks for reading this. If you have any suggestions, corrections, tips, additional questions, etc, please e-mail them to the address at the top of the FAQ. DISCLAIMER: I DO NOT IN ANY WAY, SHAPE, OR FORM ADVOCATE OR SUPPORT PIRACY. GAME COPIERS ARE FOR ARCHIVAL PURPOSES ONLY. NO ONE WILL BE HELD LIABLE FOR WHAT OWNERS DO IN THE PRIVACY OF THEIR OWN HOMES. SOFTWARE PIRACY IS A CRIME. I WILL NOT AID OR ABET ANYONE WITH THE INTENT TO PIRATE SOFTWARE. THIS FILE IS FOR INFORMATIONAL PURPOSES ONLY. Thank you, and have a nice day. -- /vsuhocki@cbnewsm.cb.att.com|Disclaimer: My opinions are my own, and \ |attbl!cbnewsm!vsuhocki |not affiliated, or related to my employer's| \PGP key available by finger|-------------------------------------v1.4--/ sega/docs/emu-mech.txt0000755000000000000000000030770311266515002012067 0ustar Due to the discussion on the software emulation of other systems on the MEGADEV mailing list, I am uploading this comp.sys.amiga.emulations discussion which occured in 1991. It does contain quite a bit of useful information and ideas for anyone interested in producing their own emulators. It specifically concentrates on the 6502 and Z-80, although the concepts are generally applicable for other systems as well. Ian. >From: jnmoyne@lbl.gov (Jean-Noel MOYNE) >Newsgroups: comp.sys.amiga.emulations >Subject: Re: Emulator Mechanics (sorry long post) >Message-ID: <10652@dog.ee.lbl.gov> >Date: 6 Mar 91 03:03:52 GMT >Organization: Lawrence Berkeley Laboratory >References:<4992@mindlink.UUCP> <1991Mar6.010141.5905@mintaka.lcs.mit.edu> > > > Yes, insteresting indeed. I've _heard_ (i.e. don't quote me on >that) that once a company did such a "application-translator", on unix. >Where you could take an Ms/Dos exe file, and the program would generate a >unix C source code, maping all the Ms/Dos int traps into legal unix os >calls. I've heard this program was able to translate well-known commercial >programs, and that these programs were able to run after that under normal >unix multi-user configuration, the end of the story is that the people >that made this soft could never even try to sell it (guess why). > > Anyway, doing such a thing wouldn't be impossible technically (but >it'd be hard for sure ! (-:), especially for ms/dos programs. All these >big softs are made to run on all the different flavors of IBM clones, that >means they use no dirty tricks, they stick to BIOS calls so it'll run even >on an Amstrad (or under the transformer or IBeM for instance). That means >you could quite easily put all the BIOS ints in an Amiga shared lib, and >taking the 8088 binary, generate C code from it. Programs a'-la >"re-sourcer" allready exist, they take the .exe file, and generate a 8088 >source code file from it, at this point it's possible to generate a C >source code that would do the same thing. You could optimise it to >recognise patterns in the ASM instructions (don't forget most of these big >programs, the one you're interested in to run on the Amiga, are usually >written in C or some other high-level language, and so the binary is >generated by a compiler, thus creating patterns ...), and eventually build >a C source code not to far from the original (the guys who wrote Microsoft >C could eventually write a reverse compiler that would generate a code >very close to the original, and such a program wouldn't be machine >dependent at all). > > An other problem who be to catch the busy wait loops in these >mono-tasking programs (I think most of these loops are in the BIOS, like >waiting for a key, easy to take care of). So these programs would be >multitasking friendly, and so that you could eventually run more than one >at the same time without loosing performance. > > Anyways, all this is my mind wandering sideways (I've thought >about that before), and most of what I wrote is closer to dreams than to >reality (and in bad English, sorry about that, still learning (-:). Mostly >because, if it's not impossible to write such a program, it for sure very >hard ! And so, it'll take a lot of time and effort, more than what a >standalone guy doing that on the side of his regular job could invest. A >team in a company could do it, but no company's gonna take such a risk, >there's too much potential danger on that, even if the potential sales are >very big ! Sure one could say that if you buy the original program, you >should be able to run it ... even on another machine, but I'm sure the >army of lawyers from let's say Microsoft or Aston-Tate would have >something to say about that ! And they could sue you for years without >sweat, preventing you from selling the program before the end of the >trial... etc ... etc ... > > Eventually, if the program was freeware, written by a bunch of >programers not earning money for it, this would be a different figure, >much different. But I'm really no lawyer, I'm still thinking sideways .... >(-: > > > JNM > >-- >These are my own ideas (not LBL's) > > >From: Chris_Johnsen@mindlink.UUCP (Chris Johnsen) >Newsgroups: comp.sys.amiga.emulations >Subject: Emulator Mechanics (sorry long post) >Message-ID: <4992@mindlink.UUCP> >Date: 4 Mar 91 15:20:48 GMT >Organization: MIND LINK! - British Columbia, Canada > > > The following messages were shared in an email environment between Charlie >Gibbs and myself over the last couple of days. We decided that it would be a >good idea to share these thoughts with the readership of >comp.sys.amiga.emulations. The messages speak for themselves for the most >part. > > ------------ Included text of messages ------------ > >Sun Mar 3 6:40:53 1991 From: Chris Johnsen [547] Subject : Emulators > >Hello Charlie! Long time no talk to you eh? I haven't seen you for quite some >time. I was particularly fond of those after-PaNorAmA meetings at Wendy's a >few years ago. I trust you recall me from back then. > >I have been following the comp.sys.amiga.emulations newsgroup on Usenet for >quite awhile now and was quite interested in the IBeM program that is being >posted about recently. In one of the near Alpha/Theta states that, being a >programmer, such as yourself, one recognizes as some kind of "source"; I had >an idea. Since there are not many "new" ideas spawned I wanted to get some >feedback from a person with the expertise you possess. The reasons I thought >of you for this private consultation are: 1) you've written an emulator - >SimCPM 2) you've written an assembler - A68K 3) you have a broad knowledge of >the computing field beyond lowly PC's and 4) you're such a nice guy! > >I was musing about how an emulator would work. I must confess I have no >concrete knowledge of this. It has been said that "Not knowing how to do a job >'right' frees you to discover new and better ways of accomplishing the desired >result". Freeman Patterson (a Canadian photographer), in his book Photography >and the Art of Seeing, called this "thinking sideways". I believe I've >thought of a way of writing an emulator that would run at least as fast on the >Amiga as it would on the source machine. > >My questions for you are: > >Would you be interested in being a mentor to me in developing further this idea >or in fact ascertaining whether my concept has any validity? > >I'm reticent to spill this on the net until I'm somewhat confident that it is >indeed practicable. I have thought about the possible legal considerations of >producing an emulator. There are potential commercial possibilities that one >could consider also. > >Would you please give me just a quick, superficial rundown of the basic >algorithms used in developing an emulator? > >I have assumed that you would read in the object module of say an IBM >executable, read it by opcode or routine, decipher the intent and then call a >library of glue routines to do the job that the program would have on an IBM >or clone. I have no idea how the interrupt structure would be handled but know >that you have done it with SimCPM. > >I don't want to waste your time, but I would appreciate this information. I >would like to get your feedback on these questions to see if you are interested >in further discussion with me on this matter. If you are not interested or >don't have the time I'll certainly understand. I realize I'm asking you for >more information than I'm sharing but an idea is a tiny property and I'd like >to at least savor this for a while before I decide what to do with it. That is >the sole reason I have not gone public with it yet. > >If you are indeed interested, after you tell me on the highest level how an >emulator functions, I'll be able to describe this idea on some kind of >comprehensible basis. I'm looking forward to your response! Thanks Charlie. > >csj > >Sun Mar 3 23:12:32 1991 From: Charlie Gibbs [218] Subject : Emulators > > Indeed I am somewhat short of time these days, but I wouldn't mind kicking >the odd idea around without getting too wrapped up in it. I do understand your >idea of "thinking sideways" and enjoy being able to do it myself from time to >time. A similar way I've heard it described is that even though it's been >proven that bumblebees can't fly, they don't realize this and so do it anyway. >Or to put it another way, I like to write programs that are too stupid to know >what they're doing, so they can do anything. > > Your ideas on emulation are basically in line with what's considered the >standard way of doing things. A machine instruction is analyzed as to just >what it's supposed to do, and appropriate code then carries out the operation. >The guts of SimCPM appeared in Dr. Dobb's journal as an emulator that was meant >to run under CP/M-68K. This made the job a bit easier for the original author, >since the CP/M-68K system calls were quite similar to the CP/M calls that he >was emulating. I had to replace this portion of code with appropriate AmigaDOS >routines. In addition, I extended the code to handle the full Z-80 instruction >set, since the original code could only handle the 8080 subset. > > Since emulating another processor in software is quite a CPU-intensive >process (several machine instructions have to be executed to emulate a single >machine instruction on the target machine) I tried to optimize SimCPM for speed >at the expense of memory and redundant code. The overhead of a single >subroutine call, plus any extraction and interpretation of arguments, would >require several times as much time as a hand-picked set of instructions >dedicated to a single opcode. > > For system calls there's easy out - as soon as I recognize what the >emulated program is trying to do (e.g. read a block from a disk file), I call >the corresponding AmigaDOS routine, so I/O can proceed pretty well at native >speeds. Therefore, even though CPU-bound programs might run 10% as fast as >they would on the target machine, I/O bound programs might get up to 50% of >speed. > > Interrupts were easy - since most CP/M systems don't use hardware >interrupts, except possibly for a very few hardware-dependent programs, I >simply didn't worry about them. Software interrupts (the RST instruction) were >a snap on the other hand, since they're basically a special-purpose subroutine >call. > > The Intel 8080 is fairly easy to emulate because the opcode is uniquely >determined by the first byte of the instruction. Some instructions might have >register numbers encoded in a few bits of that first byte, but I just treat >them as special cases. To decode the byte, I just multiply its value by 4 >(shift left 2 bits) and use the result as an index into a table of 256 pointers >to the actual emulation routines. Since there are 64 possible MOV instructions >(well, 63 because one of the bit combinations is actually HLT) I actually have >63 MOV emulations, one for each combination of registers. This means that I >don't have to do any register decoding, since each routine consists of a >dedicated 68000 MOVE instruction, followed by a jump back to the main emulation >loop. Lots of almost-redundant code, but it's about as fast as it can get. > > This is getting kind of long-winded. I'd be interested in hearing any >ideas you may have; although I wouldn't have time to get into the programming >of such stuff, I'm willing to act as a sounding board. Talk to you soon... CJG > >Sun Mar 3 23:18:48 1991 From: Charlie Gibbs [218] Subject : Emulators > > Another approach I've heard of is to "compile" the code to be emulated >into native machine code. This would involve a front-end program which would >read the target machine's program and analyze the instructions. For instance, >if the "compiler" detects an instruction that does a move between two of the >emulated machine's registers, it would simply generate a move instruction in >the emulating machine's code. It could generate either a translated assembly >language source file or a machine-language file ready to load into the >emulating machine. This would require the "compilation" process to be run once >on the program to be emulated, and you'd then run the output of this >"compiler." There are special tricks to consider here, such as resolving >addresses - you couldn't just copy the memory addresses across because the >emulated routines would likely be a different size. It might be easier to >generate a label (e.g. Axxxx where xxxx is the hex address in question) in an >assembly source file and let the emulating machine's assembler sort it all out. > > I've never actually seen this process in action, but it's another >possibility. --CJG > >Mon Mar 4 12:38:31 1991 From: Chris Johnsen [547] Subject : Emulators > >Thanks a lot for your effort in explaining SimCPM to me man. As you describe >it, it would seem that I had intuitively understood the basic concepts. I >would think that interrupts would be the hardest part to get down to reliable >operation. What I had in mind, while thinking about this, in general terms, >was an emulator that was non-specific as to the machine, therefore I was >attempting to contemplate it handling say IBM, Mac, (hey it may even be >possible to deal with Amiga emulation!) and Atari ST on the Amiga and >imagining what the various architectures would require. All this on a very >abstract level. > >Your second message hit the nail on the head! I got bogged down at about the >level you describe in your first message. Lots of details to be sought and >worked out. Gee, I'm really not even available to code another program just >yet anyway. I was giving the whole concept a rest when, what I thought of, >kind of sideways (lazy minds tend to look for an easier way around an >obstacle, sometimes unconsciously, even though this can lead to harder, though >more elegant solutions to problems), was to read the opcodes from the "source >executable" of the emulated machine, producing an assembly listing of the >program. This I imagine would be a two pass process, sort of like a C >compiler, followed by an assembler's two passes, and finished off with a >linker. > >I thought that, if the compiler was "intelligent" enough, the output, though >likely larger, would be much faster than the common "interpreter type >emulator". I had never heard of such an idea and since there are none out >there, wanted to discuss this with you. I have developed the idea no further >than this in essence. > >I did think of a few other considerations however. If one could, indeed, >compile an executable image of say Lotus 123 from the IBM into a program which, >on a base Amiga, could run at half speed, or on a A2500 or A3000 at twice the >speed, it would be a viable alternative, besides being a neat toy. However, >the standalone program generated would likely infringe on the copyright of >Lotus because the Amiga executable would actually be Lotus 123. Take >WordPerfect for instance. The latest version available is 4.1 or just a >micro-point higher, no problem, get hold of the IBM version 5.1, I believe it >is, and compile it and you have something some other people are wailing for. Of >course the rebuttal (I can hear you thinking?) is that, if a person owns >WordPerfect he has an inalienable right to run it. Run it on an IBM. Run it on >a clone. Run it through an Amiga compiler. You know, if it's for personal >use, etc. > >As to the increase in size of the "compiled emulation" program, I have a couple >of ideas. First, the executable, though larger, would be standalone, except >for any support libraries. This doesn't mean that this "form" of emulator, >more like a "translator of executables", would be any less efficient than the >"interpreter type". Perhaps more memory efficient in a couple of possible >ways. Since the interpretation section of the program is in the compiler, and >the source executable is not required at runtime, memory usage may well be less >with a "compiled emulation". The second concept is to use link libraries which >would bind only the emulation routines required to the final program. Possibly >a combination of bound-at-link-time modules of less frequently used routines >and a shared library of essential routines all programs would need. A solely >link library approach would leave this concept open to claims that pirates >could produce "warez" that need no extra code or setup to work. Of course, >pirates appear to be capable of ripping anything off anyway! > >This "compiled emulation" would, given sufficient memory and CPU >speed/efficiency, allow the running of multiple programs. Both emulated >programs and standard Amiga programs. Through the use of a shared library more >than one emulating program could be run without the overhead of multiple >"emulation interpreters" resident in memory. > >The compiler could generate C statements so that you could take advantage of >the advancements in technology in the compiler, assembler and linker, without >having to deal, directly, with those parts of the system. I know this would >make the compiler operation more unwieldy. More operations, therefore it >would take longer, but theoretically the source is bugless, so you would >expect the output of this "emulation compiler" to either succeed or fail. >You'd run the emulator on the program only once. The beauty of producing >assembler (C would be better here), is that if it didn't work first time, a >programmer type could patch it up in source and get it running. I'm really >intrigued by this idea. Where did you hear about it, do you remember? > >My knee-jerk reaction initially was to file the idea, but then I got to >wondering why no one had done it. There were many emulators out there for >various source machines. Why were none of them compilers? Another idea I had >was to contact the dude in Oz (or is he a Kiwi?) that wrote IBeM. He already >has the emulation working except for the parallel and serial ports. It would >appear that he reads the IBM object code, deciphers it and runs a routine, or >simply does a MOVE using an opcode lookup table, as you suggest; an >interpreter. If he instead simply wrote out an instruction in ASCII to do the >call or move instead, using a shared library of his emulation routines, he'd >basically have it. The end user would also have to have an assembler or C >compiler, however. This type of approach has got to produce faster emulation, >if it is possible. I believe it to be. > >Anyway, that's what I had in mind Charlie. I really do appreciate your >feedback on this. Care to comment on any directions you think could be >followed? Do you know anyone with enough venture capital to fund the further >development of this concept? ;-) Do you think I should approach the author of >IBeM (cute name) directly? Or, should this private discussion we've been >having be moved to Usenet? Thanks again Charlie! I appreciate you man. > >csj > >Mon Mar 4 15:36:53 1991 From: Charlie Gibbs [218] Subject : Emulators > > I can't remember where I first heard of the idea. The converted code >won't necessarily be smaller than the original, depending on the relative sizes >of corresponding machine instructions on both machines. However, if you could >make the compiler really smart it might be able to recognize certain sequences >of instructions and replace them by sequences designed to accomplish the same >thing more efficiently. For instance, since the 8080 doesn't have a multiply >instruction it needs to fake it with a bunch of adds and shifts. A smart >compiler, if it could recognize such a routine, could replace it with a single >68000 multiply instruction and see huge savings. > > I'd stay away from calling subroutines; the overhead could kill you. > > The copyright issue could be a sticky one, although I can't see any >problems if you run the converter on your own copy of the emulated software and >don't try to sell the result. It would no doubt be classified as a "derivative >work". > > Perhaps it might be interesting to throw this discussion out to Usenet. It >won't be a trivial job, which is probably why we haven't seen it done >elsewhere. Remember that a straight machine-code emulation duplicates all the >register fiddling that is required by the target machine's architecture (and >the 80x86 family needs a LOT of register fiddling). This code is replaced by >the 680x0's own internal fiddling if you're re-compiling source code. One way >of looking at it is to decompile the original machine code, then recompile it >for the new machine. > > Interesting stuff... CJG > > ------------ End of included text of messages. ----------- > >Both Charlie Gibbs and myself frequent this newsgroup and look forward to any >additions to this discussion with which others may respond. Sorry that the >posting is so long but I felt there was little enough chaff contained in the >messages to warrant including all of them. > >csj > >The hard way is usually the disguised easy way, you take your choice. Usenet: >a542@mindlink.UUCP Phone: (604)853-5426 FAX: (604)854-8104 > > >From: rjc@pogo.ai.mit.edu (Ray Cromwell) >Newsgroups: comp.sys.amiga.emulations >Subject: Re: Emulator Mechanics (sorry long post) >Message-ID: <1991Mar6.010141.5905@mintaka.lcs.mit.edu> >Date: 6 Mar 91 01:01:41 GMT >References: <4992@mindlink.UUCP> >Organization: None > > > Very interesting article. I myself have been tempted several times >to try and write an emulator. Since I programmed 6502 assembly on the >C64 for 4 years, and I know 68000 on the Amiga, I was tempted to >try to beat the speed of the other emulators. Then I realized >the sheer magnitude of the project. Emulating the instruction set is >easy. In fact, I am quite confident I can make a 6502 emulator run >faster on the Amiga then the C64. The hard part is the hardware. >Most C64 programs discard the oS entirely and bang on the hardware. >Further more, most of them use polling loops, like polling the >raster beam register and using precisely cycle timed delays. Moreover, >the VIC chip contains several glitches that allow programmers to >use tricks to remove the borders, vertically scroll the screen to >ANY raster location, horizontally shift the screen, vertically and >horizonally interlace the screen, stretch pixels (double, triple, >quaduple) length vertically. This is virtually IMPOSSIBLE to >detect, unless the emulator is artifically inteligent. And, any >program that has a fastloader won't work. This is because fastloaders >usually transfer data over the serial clock line, and data line. This >doubles bandwidth, unforunately it requires PERFECT timing, so perfect >in fact that it won't work on PAL computers, and vice versa. >Sprites are another problem, since Amiga sprites are only 16 pixels wide, and >C64 sprites can have their width and heigth doubled, and they rely >on a chunky pixel format. Text is another problem since the >C64 has a builtin Text mode. > > The Mac is the easiest computer to emulate because it's not a computer >at all. The Macintosh computer does not exist, it's nothing more >than a ROM chip. > >A few days ago, I was impressed. I downloaded a demo from ab20 called >C64Music.zap. This demo emulates 6502 at 100% (in fact, it emulates it >at perfect timing because the music is exactly the same speed.) This >demo emulates the SID chip PERFECTLY, and I mean perfect. These guys >should join together with the maker of A64. > > > I can't speak for other 6502 emulators, but if I wrote one, the fastest >method looks like table lookup, with careful optimization to make >sure things are long word aligned. For instance, I might do something like > >pc6502 equr a5 >accum equr d5 >xindex equr d6 >yindex equr d7 >stack equr a4 ; 6502 stack, which is base address + $0100 on the C64 >stat equr d4 ;status register > > > > [allocmem the 6502's address space, load in an > executable and set the pc to it's start] > > lea jumptbl(pc),a2 > sub.l d0,d0 >loop move.b (pc6502)+,d0 > lsl.l #2,d0 > move.l (a2,d0),a3 > jmp (a3) > > >then every instruction would be emulated (even undoc's) and put into >the jumptbl. The code for 'LDA address' might look like: > >lda sub.l d0,d0 > move.b (pc6502)+,d0 > lsl.l #8,d0 > or.b (pc6502)+,d0 > add.l addresspace,d0 ;this code inverts the 6502 little-endian > ; and then add's the base address of the > ; memory that was alloc's for it > move.l d0,a3 > move.b (a3),accum > jsr GetCC() ? ;It might be better to use move SR, providing you > ; check the machine you were running on and did > ; and did a move ccr otherwise > ; status reg is now in d0 > and #mask,d0 ; mask off everything but the Z bit > bne whatever >whatever bclr #1,stat > jmp loop > bset #1,stat > jmp loop > >(note: this code can be optimized, its off the tip of my tongue, and >probably bugged since I haven't coded in asm in awhile) > >>From my quick calculations, the jump table dispatcher incurs about a 3-4 >microsecond delay in the fetch of each instruction. This is equivelent >to about 4 cycles on a 6502 @1.02mhz. If you had infinite amounts of ram, >the object code loader could 'inline' the code for each instruction >and get rid of this delay, I beleive this is probably how the C64Music >demo does it, since music players on the C64 were only about 1k of code. > >The Lda routine itself looks like about 2.2 times slower than a true 6502 >delay which 4 cycles. However a 25mhz 68030 would run more than >twice as fast. > > >Theoretically speaking, an IBM emulator running on an Amiga3000 >should be running at atleast 5mhz 80286 speed. Consider SoftPC on >the NeXT which runs at 12mhz UNDER UNIX. 68040's are about 2-3 times >faster then 68030's, so SoftPC on the Amy should run at about 5mhz. > > > Maybe we all should trying something like 'NetIBM'. What I mean, is >like Nethack, we should all participate in coding an IBM emulator. >Each person might post a small code segment (in assembler), the rest >of us can compete optimize it. I remember having a contest with >some trying to optimize the 'size' of a binary to decimal print >routine, the final result was the code was reduced 300% in size. >(we kept passing the optimized source back and forth, each shedding >a few bytes.) > > >Regardless of what happens. Let's keep the discussion up, it's interesting >and educational. > > > > > >From: ifarqhar@sunb.mqcc.mq.oz.au (Ian Farquhar) >Newsgroups: comp.sys.amiga.emulations >Subject: Re: Emulator Mechanics (sorry long post) >Message-ID: <1303@macuni.mqcc.mq.oz> >Date: 6 Mar 91 12:57:34 GMT >References: <4992@mindlink.UUCP> <1991Mar6.010141.5905@mintaka.lcs.mit.edu> >Organization: Macquarie University, Sydney, Australia. > >In article <1991Mar6.010141.5905@mintaka.lcs.mit.edu> rjc@pogo.ai.mit.edu (Ray Cromwell) writes: >> The Mac is the easiest computer to emulate because it's not a computer >>at all. The Macintosh computer does not exist, it's nothing more >>than a ROM chip. > >The best description of a Mac I've ever read! :-) > >> I can't speak for other 6502 emulators, but if I wrote one, the fastest >>method looks like table lookup, with careful optimization to make >>sure things are long word aligned. For instance, I might do something like > >How about this? > >Write code for every one of the 256 possible opcodes, and make sure that >it follows these important considerations: > >1) The code is responsible for updating all registers, the 6502PC, > and also for checking special functions if a hardware location > is called. >2) It should be 256 bytes per opcode or less. >3) It should jump back to STLP (see below) when done. >4) It should intelligently introduce timing delays (very hard) >5) Something else I've forgotten. > >Take each piece of code, and distribute it in a 64K memory area, so that >the code for opcode N starts at base + (n << 8). There may be a lot of >wasted space, but on any reasonable Amiga, this space can be sacrificed >for speed IMO. > > ; Base reg of instruction code in A0. 6502PC in A1. > >STLP MOVE.B (A1), lcna ; lcn is the upper byte of the > ; dsp displacement below > JMP dsp (A0) > > >Excuse my poor 68K code. I think this will work, but it has been three >years since I even looked at assembler on the 68000. Before anyone >screams about this code failing on a 68030, remember that the >modification made above is only needed until the JMP. After that, we do >not need to see it again. If I read the info on the 68030 cache >properly, this should be okay. At worst, the instruction cache can be >disabled. > >This should be considerably faster than any table driven system. On any >system with multi-byte opcodes (eg. the 8088), this system can be easily >extended, and minor modifications can be made to emulate most modern CPU >with reasonable speed. > >Now a suggestion for dealing with hardware locations (harder on memory >mapped systems than on things like Intel and Zilog chips which have I/O >instructions.) This is another memory-expensive solution, BTW. > >For every location, have two flags, one for read and one for write. If >the opcode handlers write to the location, they can check the write flag >and if it is set, call a handler which determines which location is >being modified, and pass control to a routine to do it. > >Now for the VERY memory expensive solution. > >Have one 16 bit displacements per memory location (ie. for 1M of >simulated RAM you must have 3M of real RAM.) This location contains the >displacement from a base register to a routine which handles that memory >location. If this word is non-zero, an instruction that reads or write >to it calls this routine. You could even have two displacements, one >for read and one for write, but this would only be practical for systems >that have small amounts of simulated memory (eg. C64). > >At a rough estimate, for a C64 emulator (IMO the hardest of all >emulators.) > > Simulated Memory 64K > Read Displacements 128K > Write Displacements 128K > Opcode handlers 64K > Memory Location Handlrs 28K (?) > Rest 100K (??) > ---- > 512K > >So, for an average 1M Amiga, this is quite possible. > >As for the project, why not start with something much simpler? An Atari >2600 emulator. The hardware is quite simple to simulate, though the >timing will have to be *very* precise. This would be a good starting >point. Opinions, anyone? > >-- >Ian Farquhar Phone : + 61 2 805-9400 >Office of Computing Services Fax : + 61 2 805-7433 >Macquarie University NSW 2109 Also : + 61 2 805-7420 >Australia EMail : ifarqhar@suna.mqcc.mq.oz.au > > >From: ifarqhar@sunb.mqcc.mq.oz.au (Ian Farquhar) >Newsgroups: comp.sys.amiga.emulations >Subject: Re: Emulator Mechanics (sorry long post) >Message-ID: <1304@macuni.mqcc.mq.oz> >Date: 6 Mar 91 13:52:25 GMT >References: <4992@mindlink.UUCP> <1991Mar6.010141.5905@mintaka.lcs.mit.edu> <1303@macuni.mqcc.mq.oz> >Organization: Macquarie University, Sydney, Australia. > >An idea about code compilation, rather than interpretation. > >If you assume that a program does not employ self-modifying code, this >may not be nearly as had as it first appears (I am not saying that it is >trivial, just not too bad.) This assumption can be made if the program >runs out of ROM, and also in 99% of non-ROM cases. > >The problems of compiling code for one CPU into that for another are >fairly easy, but a major problem occurs when table-driven code is >employed (common.) > >What I am suggesting is this. It is reasonably elegant, and quite >simple to perform: > >Store the loaded memory image of the original program as well as the >compiled code. For every instruction in this image, a pointer to the >compiled code is generated indicating where the corresponding code >actually is. As the program executes, the working store is this memory >image, and if a piece of data is read, it can be dealt with normally. >However, if a program attempt to jump, branch or call a location using >data loaded (as would happen with a table), then the corresponding >location can be determined and the correct code called. > >This has a high memory overhead (3-5 times original image size *plus* >compiled code). > >I am sure that there is a more memory-effective way of doing this by >identifying such tables during the compile, but it seems a difficult >problem. Has anyone got any better solutions? > >BTW, an idea for semi-compiled code. Have two branches for every location, >and simulate the machine that way. Reading an opcode calls the >appropriate opcode handler, writing it calls a reevaluation routine that >changes the pointers for the two locations. System and special >locations are handled similarly. This may actually be a quite >reasonable solution, as inelegant as it first sounds. > >-- >Ian Farquhar Phone : + 61 2 805-9400 >Office of Computing Services Fax : + 61 2 805-7433 >Macquarie University NSW 2109 Also : + 61 2 805-7420 >Australia EMail : ifarqhar@suna.mqcc.mq.oz.au > > >From: rjc@geech.ai.mit.edu (Ray Cromwell) >Newsgroups: comp.sys.amiga.emulations >Subject: Emulator Mechanics >Message-ID: <1991Mar7.093149.18707@mintaka.lcs.mit.edu> >Date: 7 Mar 91 09:31:49 GMT >Organization: None > > > I got an idea. How about combining both methods? (compile and interpret) > > First compile the executable with flow analysis into 68k code. Any >instruction that tries to touch a hardware register will become >a trap instruction(or use an MMU to trap it) to emulate the hardware. > > Where does the interpreter come in? Any code that tries to self modify >or do a change of state (table lookup, indirect jumps, etc) with be >interpreted. > > Sounds hard? You bet. The easier solution of all is to throw faster >CPUs at the problem. > > >Now for another question: > > Why doesn't AMAX multitask? It should be EASY to run multiple copies >of the Mac ROM as a task (since its a rom, its mostly pure code, except >each task would need to alter where the ROM things the system memory is.) > > For things like the Atari emulator, or another 68000 emulator, the compile >technique should work great! Just recompile the parts of the code >that bang on the hardware, or use an MMU to trap them. > > >The whole compilation process is made easier when the machine >your trying to emulate has an object code format that contains >seperate data and code chunks, and perhaps some relocation data. >Further more, if the machine has rules against self modifying code, >and a device independent OS it becomes trivial. > >Could someone run SI or dhrystone on IBeM and tell me how it performs? >Itis said that SoftPC on a Mac @25mhz 68030 runs at 6mhz AT speed. > >Does anyone know if IBM code uses self modifying code, or >jump tables? What kind of code does their compilers produce? >And, does the IBM has a special object code format that seperates >code and data? > > >The compilation technique could work well, but the compiler would have >to be VERY smart in its flow analysis of detecting code/data, jump >tables, self modifying code, PC counter and stack manipulation, etc. > >I'll clairfy my thoughts tommorow, it's going on 4:30am here, and I >need to get some well deserved sleep. :-) > > >From: stevek@amiglynx.UUCP (Steve K) >Newsgroups: comp.sys.amiga.emulations >Subject: Re: Emulator Mechanics (sorry long post) >Message-ID: >Date: 6 Mar 91 23:12:59 GMT >References: <4992@mindlink.UUCP> >Organization: Amiga-Lynx Bbs Multi-Node 201-368-0463 NJ,USA > >The idea of a "translator compiler" is very interesting. I could have sworn I >saw some talk about a IBM->Atari ST translator that exists on FidoNET. But >why is everyone talking about IBM? Why not Macintosh programs? Though I am >not anyting close to a professional programmer, I'd imagine programs that run >off different computers with the same processor would share some op-codes, >right? Even if that is not true, they do both have similar GUIs, windows, >gadgets, and menu bars, ect. which shold make the translation easier and more >like the original. I sincerly hope someone will pick up and persue these >ideas, it would be very benificial for me and others - I'd love to run a nice >pascal compiler like Turbo Pascal, and an excellent ANSI editor like TheDraw! > >- Steve Krulewitz - Fair Lawn, NJ - > > >From: dclemans@mentorg.com (Dave Clemans @ APD x1292) >Newsgroups: comp.sys.amiga.emulations >Subject: Re: Emulator Mechanics (sorry long post) >Message-ID: <1991Mar6.212548.9641@mentorg.com> >Date: 6 Mar 91 21:25:48 GMT >References: <4992@mindlink.UUCP> >Organization: Mentor Graphics Corporation > >On the "compiled" approach to emulation: > >There definitely has been previous work in this area. The >system I've heard of was an internal tool that was used experimentally >to port some games from the Intel world to the 68K world. > >To use it, you basically had to develop enough information to >get a clean disassembly of the Intel code; i.e., so that you "knew" >where all the code and data was in the source object file. >That then was used to drive the tool that produced the "compiled" >68K file. After that was done you had to go over the output >for correctness, system dependencies, etc.; it was not intended >as a turn key system. > >... > >As a side issue, to bring over some of the bigger DOS packages >you'll have to worry about more than just converting a single >file. You have to find and convert all of their code overlay files.... > >dgc > > >From: ifarqhar@sunb.mqcc.mq.oz.au (Ian Farquhar) >Newsgroups: comp.sys.amiga.emulations >Subject: Re: Emulator Mechanics (sorry long post) >Message-ID: <1312@macuni.mqcc.mq.oz> >Date: 8 Mar 91 03:51:21 GMT >References: <4992@mindlink.UUCP> <1991Mar6.212548.9641@mentorg.com> >Organization: Macquarie University, Sydney, Australia. > >In article <1991Mar6.212548.9641@mentorg.com> dclemans@mentorg.com (Dave Clemans @ APD x1292) writes: >>To use it, you basically had to develop enough information to >>get a clean disassembly of the Intel code; i.e., so that you "knew" >>where all the code and data was in the source object file. >>That then was used to drive the tool that produced the "compiled" >>68K file. After that was done you had to go over the output >>for correctness, system dependencies, etc.; it was not intended >>as a turn key system. > >Well, on a 6502, it is practically impossible to truly decide what is >code and what is data. Let's imagine that you are (as I have done), >writing a 6502 disassembler. For every byte you store a status thst >says DATA, OPCODE, ARGUMENT, and also non-exclusive flags (eg. >BRANCHENTERSHERE, BRANCHISNOTHERE.) Initially, all bytes are set to DATA, >and BRANCHISNOTHERE. > >Write a recursive procedure that starts at the program entry point, and >goes through the code. For every byte read as an opcode, tag it as an >OPCODE, and the bytes following as ARGUMENT. If you get to a branch >instruction, recursively call the new branch point, and continue >processing that until you hit a byte that has already been processed >(ie. not tagged DATA.) You should continue until the whole procedure >exits, then run the same thing on the RESET, INT and NMI vectors. Calls >are treated the same way as branches, except that the routine exits to a >higher level invocation when it hits a RET or RTI. > >Now, you should have all the data tagged as either program (OPCODE and >ARGUMENT), or DATA. Right? Wrong. Why? Because the 6502 has no >branch always instruction, and your program may continue past what >appears to be a conditional branch, into data, and screw everything up >completely. > >I experimented with using a two pass approach to this problem. First, >the program was scanned sequentially, treating every byte as an opcode, >and tagging every point referenced by some branch, call, jump or vector. >Then, when a branch was found during the second recursive pass, the >program would backtrack and examine every last opcode till it hit a >branch in point (after which no assumptions could be made), to see if >the flags were left in a deterministic state. At this point I lost >interest in the whole idea. > >Anyway, on the 6502 and anything without a BRA or equivalent, the >problem of automatically determining what is data and what is code is >extremely difficult. > >However, on the 68K, this approach is probably quite profitable. Why? >Because there is enough correspondence between the 6502 and 68K >instructions sets (both having the same ancestor, the 6800) to mean that >the compilation process is reasonably simple. > >Simulating the hardware is still a problem, and I'll have to give that >one some thought... I still tend to favor the idea that I presented in >a previous article, carrying around a compiled image (of code only), and >uncompiled data with labels to the compiled code and handlers for the >I/O locations. > >-- >Ian Farquhar Phone : + 61 2 805-9400 >Office of Computing Services Fax : + 61 2 805-7433 >Macquarie University NSW 2109 Also : + 61 2 805-7420 >Australia EMail : ifarqhar@suna.mqcc.mq.oz.au > > >From: drysdale@cbmvax.commodore.com (Scott Drysdale) >Newsgroups: comp.sys.amiga.emulations >Subject: Re: Emulator Mechanics (sorry long post) >Message-ID: <19614@cbmvax.commodore.com> >Date: 7 Mar 91 20:15:07 GMT >References: <4992@mindlink.UUCP> >Reply-To: drysdale@cbmvax.commodore.com (Scott Drysdale) >Organization: Commodore, West Chester, PA > >In article stevek@amiglynx.UUCP (Steve K) writes: >>The idea of a "translator compiler" is very interesting. I could have sworn I >>saw some talk about a IBM->Atari ST translator that exists on FidoNET. But >>why is everyone talking about IBM? Why not Macintosh programs? Though I am > >IBM to Atari ST ports should be relatively simple. the ST essentially runs >CP/M 68K with several extensions, much like ms-dos. so low level calls >will pretty much translate directly, and you only have to worry about access >to hardware. > >>- Steve Krulewitz - Fair Lawn, NJ - > > --Scotty >-- >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Scott Drysdale Software Engineer >Commodore Amiga Inc. UUCP {allegra|burdvax|rutgers|ihnp4}!cbmvax!drysdale > PHONE - yes. >"Have you hugged your hog today?" >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > >From: cg@ami-cg.UUCP (Chris Gray) >Newsgroups: comp.sys.amiga.emulations >Subject: Re: Emulator Mechanics (sorry long post) >Message-ID: >Date: 9 Mar 91 08:11:28 GMT >References: <4992@mindlink.UUCP> <1991Mar6.212548.9641@mentorg.com> <1312@macuni.mqcc.mq.oz> >Organization: Not an Organization > >In article <1312@macuni.mqcc.mq.oz> ifarqhar@sunb.mqcc.mq.oz.au (Ian Farquhar) >writes: > >[Discussion of using a recursive approach to run through all branches and >calls to tag bytes as being code/data.] > >>However, on the 68K, this approach is probably quite profitable. Why? >>Because there is enough correspondence between the 6502 and 68K >>instructions sets (both having the same ancestor, the 6800) to mean that >>the compilation process is reasonably simple. > >My Amiga disassembler, Dis (which is available somewhere or other; I believe >I sent it out last year some time) does this. The thing it has troubles >with are things like function variables. In writing disk-resident libraries, >a lot of that is done, so it doesn't work too well on such things. It has >special code to handle case/switch statements generated by several compilers, >but an assembler program doing a branch table will usually mess it up. I >don't think there is much hope of an automated translater. Perhaps some >kind of interactive one, so that the user can aid in identifying what is >code and what is data. > >-- >Chris Gray alberta!ami-cg!cg or cg%ami-cg@scapa.cs.UAlberta.CA > > >From: finkel@TAURUS.BITNET >Newsgroups: comp.sys.amiga.emulations >Subject: Re: Emulator Mechanics (sorry long post) >Message-ID: <2406@taurus.BITNET> >Date: 9 Mar 91 21:26:03 GMT >References: <4992@mindlink.UUCP> <1991Mar6.004247.8964@cpsc.ucalgary.ca> >Reply-To: finkel%math.tau.ac.il@CUNYVM.CUNY.EDU (Udi Finkelstein) >Organization: Tel-Aviv Univesity Math and CS school, Israel > >as someone who wrote a 8085 emulator/disassembler/monitor for the C64 >I would like to contribute my on thoughts on the subject. > >I have toyed the idea of writing an IBM PC program translator that >would take an IBM program and 'translate' it to run on the amiga, but >after careful examination of the idea I decided to drop it for a few >reasons: > >1. There is no way to find out at compile time which memory references >are accessing special RAM areas such as the text/graphics video screen. > >2. self modifying code breaks such schemes easily > >3. code/data seperation can be tough. for example, it's very hard to detect >if memory block contains code ( translate it) , data ( don't touch it) >or worse - near or far pointers. > >(2) is rare, but (1) and (3) are common, so I guess many programs will >break. > > >even commercial systems claiming the ability to 'compile' PC binaries >into UNIX programs such as XDOS (anyone heard of them lately??) aren't >automatic. > >Instead, I decided to try concentating on the 'usual' type of emulators >such as IBeM and Transofrmer. > >What caught my attention is that a large portion of the time an emulator >is spending while emulating an instruction is to check whether a memory >read/write accesses video memory. every address being written to memory must >be checked whether it lies in the $BXXXXX range, and if it does, it should >be written to the screen. > >What I really wanted to do if I had an MMU based machine is to write an >emulator that will use the MMU to track such memory accesses. The emulator's >memory will be referenced without translation, but every address in the range >where the video memory is located will be caught by the MMU and special code >will be run to handle it. This would speed things up. > >Udi > > >From: ifarqhar@sunb.mqcc.mq.oz.au (Ian Farquhar) >Newsgroups: comp.sys.amiga.emulations >Subject: Re: Emulator Mechanics (sorry long post) >Message-ID: <1323@macuni.mqcc.mq.oz> >Date: 10 Mar 91 03:33:49 GMT >References: <4992@mindlink.UUCP> <1991Mar6.004247.8964@cpsc.ucalgary.ca> <2406@taurus.BITNET> >Organization: Macquarie University, Sydney, Australia. > >In article <2406@taurus.BITNET> finkel%math.tau.ac.il@CUNYVM.CUNY.EDU (Udi Finkelstein) writes: >>as someone who wrote a 8085 emulator/disassembler/monitor for the C64 >>I would like to contribute my on thoughts on the subject. > >A 8085 toolkit on a C64? The mind boggles. Why?! :-) > >>2. self modifying code breaks such schemes easily > >I have yet to see a piece of self-modifying code on an IBM PC, and it >will cause problems on the many 386DX and 486 systems that have instruction >caches without write-through. > >>What I really wanted to do if I had an MMU based machine is to write an >>emulator that will use the MMU to track such memory accesses. The emulator's >>memory will be referenced without translation, but every address in the range >>where the video memory is located will be caught by the MMU and special code >>will be run to handle it. This would speed things up. > >Check my article on using lots of memory to very quickly tag this >occurence on non-PMMU systems, by vectoring every location to a >handler. > >-- >Ian Farquhar Phone : + 61 2 805-9400 >Office of Computing Services Fax : + 61 2 805-7433 >Macquarie University NSW 2109 Also : + 61 2 805-7420 >Australia EMail : ifarqhar@suna.mqcc.mq.oz.au > > >From: ecarroll@maths.tcd.ie (Eddy Carroll) >Newsgroups: comp.sys.amiga.emulations >Subject: Re: Emulator Mechanics (sorry long post) >Message-ID: <1991Mar9.225807.26560@maths.tcd.ie> >Date: 9 Mar 91 22:58:07 GMT >References: <4992@mindlink.UUCP> >Organization: Dept. of Maths, Trinity College, Dublin, Ireland. > >In article <4992@mindlink.UUCP> Chris_Johnsen@mindlink.UUCP (Chris Johnsen) >writes: >> >> [ Interesting discussion about a new sort of PC emulator ] > >My final year project for college last year tackled exactly this problem, i.e. >given a PC executable file, produce an Amiga executable file which will >perform the same function. The end result worked, in a limited sort of way; >it was fairly easy for it to be misled by any program of reasonable size. > >There are a few tricky problems that must be handled if you want to achieve >a good degree of success: > > o Given the instruction MOV reg,VAL do you treat VAL as a constant value > or as an offset to an address in one of the PC's segments? The 8086 > uses the same opcode for both cases, and it is far from easy to work out > which meaning to use. It's important to get it right because in the > translated program, all the constant values should remain the same > but address offsets will be different. > > o How do you handle jump tables? Most compilers implement switch/case > statements with jump tables, but it is not always clear what the bounds > of such tables are. > > o On the PC, byte values can be pushed onto the stack as byte values. On > the 68000, you can only push word values. You can see why this might be > a problem if you consider a function accessing a parameter at an offset > of 8 from the stack pointer. If the preceding parameters were four words, > then this is okay. If they were two words and four bytes however, then > the offset on the 68000 needs to be 12 to access the same data. > > o Given that most major PC programs access the PC's video RAM directly > for speed reasons, such accesses must be mapped to act equivalently > on the Amiga. The problem is that the usual method for doing this is to > set a segment register to point to the video RAM and then to access the > RAM through this. The same register is likely used for for all sorts of > other data access elsewhere in the program. > >Of course, there are other problems too. The main thing I discovered during >the course of the project was that it's a lot harder to do translation than >it might first seem. > >My program performs the translation in two passes. The first pass traces out >all possible paths through the PC code, building up a symbol table and >separating code from data as it goes. The second pass then walks sequentially >through the code, producing 68K assembly source code for each line. Certain >instructions generate macros instead of opcodes, which are later expanded >to calls to library functions. The resulting source is fed into Charlie's A68K >and then linked with a library that sets up a PC-like environment (custom >screen, ibm.font etc.) and handles the INT calls. The result is a standalone >executable file. > >If anyone else has a shot at it, I'd be interested in seeing how it turns out. >Perhaps a more practical route to take is to produce a translator that can >take reasonably well written PC source code (say, C or assembly) and >automatically convert it to Amiga source code. If such a tool existed and >worked well, it might encourage more companies to port their products to the >Amiga. > >In the meantime, back to IBem. >-- >Eddy Carroll ----* Genuine MUD Wizard | "You haven't lived until >ADSPnet: cbmuk!cbmuka!quartz!ecarroll | you've died in MUD!" >Internet: ecarroll@maths.tcd.ie | -- Richard Bartle > > >From: srwmpnm@windy.dsir.govt.nz >Newsgroups: comp.sys.amiga.emulations >Subject: 8 methods to emulate a Z80 >Summary: 8 methods to emulate a Z80 on a 68000 >Keywords: Z80 68000 Amiga >Message-ID: <18847.27d80900@windy.dsir.govt.nz> >Date: 8 Mar 91 21:58:24 GMT >Organization: DSIR, Wellington, New Zealand > >Ok folks, here are 8 methods for doing z80 emulation on a 68000, in software. >(Well, 8 methods to get to decode a z80 instruction and get to the right >emulation routine, anyway.) > >Trade-offs are speed, space and cleanliness. They all fall short of >"compiling and optimising", but most of these methods will speed up most >existing emulators. As you might expect, the largest and dirtiest code is >usually the fastest (and least portable). The same methods should work with >emulation of 6502, PDP-11 and any other 16-bit processors. > >In all methods, I assume there is a 64kb block of memory representing the z80's >address space, allocated by AllocMem (say), and pointed to by "z80ram". > >------------------------------------------------------------------------------- >Method 1: The "standard" method: > >I call this method "standard" because it's used in both of the CP/M z80 >emulators I know about. The general idea is to decode the current instruction >and jump to the appropriate emulation routine via a vector table. That is, >like a CASE statement with 256 selections. The code is clean and re-entrant. > >; Setup > move.l z80ram,a2 ; load pseudopc > lea.l optabl(pc),a1 ; a1 always points to optabl > lea.l mloop(pc),a3 ; a3 always points to mloop > >; Main loop (decode) starts here >mloop: moveq #0,d0 ; 4 Execute appropriate subroutine. > move.b (a2)+,d0 ; 8 Grab the next opcode and inc pc. > asl #2,d0 ;10 D0 high word is still zero! > move.l 0(a1,d0.w),a0 ;18 Get address of routine from table > jmp (a0) ; 8 Do the subroutine. > ;48 total cycles to decode > even >optabl: dc.l nop00,lxib,staxb,inxb,inrb,dcrb,mvib,rlc > dc.l ... > >Each z80 instruction emulation routine ends with: > > jmp (a3) > >------------------------------------------------------------------------------- >Method 2: The "position-independent" method: > >This is slightly quicker, the executable is more than 1500 bytes smaller, and >you get another register to play with in the emulator (a1 in this case). I >currently use this method (or close to it) in my Spectrum emulator. The code >is clean and re-entrant. > > move.l z80ram,a2 ; load pseudopc > lea.l mloop(pc),a3 ; a3 always points to mloop >mloop: moveq #0,d0 ; 4 clear opcode word > move.b (a2)+,d0 ; 8 get opcode byte > add.w d0,d0 ; 4 2 bytes per entry > move.w optabl(pc,d0.w),d0 ;14 get offset of routine > jmp optabl(pc,d0.w) ;14 do instruction > ;44 total to decode > even >optabl: dc.w nop00-optabl,lxib-optabl,staxb-optabl,inxb-optabl > dc.w inrb-optabl,dcrb-optabl,mvib-optabl,rlc-optabl > dc.w ... > >Each instruction emulation routine ends with: > > jmp (a3) > >------------------------------------------------------------------------------- >Method 3: The "decode-at-end-of-instruction" method: > >(There are really 2 methods described here.) Take either method 1 or method 2. >Instead of ending each emulation routine with "jmp (a3)", end each one with a >complete copy of the code from mloop to the indirect jmp. There is no longer >a main loop, because each instruction jumps directly to the next one. > >This method is slightly faster, takes maybe twice as much code, is clean, and >is re-entrant. It also saves yet another reserved register, in this case a3. >(Personally, I find that a z80 emulator needs as many free registers as you >can get your fingers on.) > >------------------------------------------------------------------------------- >Method 4: The "threaded jsr's" method: > >Warning: This method uses self-modifying, non-re-entrant code, and therefore >is not recommended. This code is hazardous to your cache! (No flames please >--- read on). > >Introduce a 390kb contiguous block of code (called thread) which looks like >this: > >thread: jsr patch ; 0 > jsr patch ; 1 > ... > jsr patch ; 65535 > jmp thread > >That is, there is a jsr instruction for each byte in the z80's address space. >This is in addition to z80ram. > >To start the emulator, you transfer control to "thread". What the "patch" >routine does is to replace the current "jsr patch" with "jsr this_routine", >where this_routine is the emulation routine for the corresponding opcode in >z80ram. Then patch jmps to the this_routine to execute the instruction and to >return to the next jsr in the thread. After a while, patch will no longer be >called (except by z80 self modifying code), and every jsr made will be to >emulate a z80 opcode directly. > >Whenever a z80 instruction writes to RAM, it patches the corresponding >"jsr this_routine" with "jsr patch". As a variation, it could patch >"jsr this_routine" with "jsr new_routine", but that would probably be slower >in general. > >Advantage: > >It would be faster than methods 1 to 3, --- I think, --- especially in the >Spectrum emulator, which has to do a lot of work with every write to RAM to >check for ROM and video RAM anyway. The main reason for the extra speed is >that it no longer has to decode the opcode on every instruction. There are >the extra overheads of call and return though, and extra work to do on every >RAM write. > >Disadvantages: > >1: The code breaks C='s self-modifying code law. To run on Amiga's with >caches, it would have to either disable the caches or update them manually >after every patch. The code is extremely dirty, not re-entrant, and >definitely not recommended; > >2: You need 390k contiguous memory (plus another 64k somewhere else, plus >whatever else you need for video). > >Other characteristics: > >Code would run slowly the first time round the loop, then speed up. > >-------------------------------------------------------------------------- >Method 5: The "replicated code" method. > >Warning: This also uses self-modifying, non-re-entrant code and is therefore >not recommended. > >Thread consists of 65536 blocks of code, each long enough to emulate the >trickiest z80 instruction. Initially it contains 65536 copies of patch. (You >will need A LOT of contiguous memory.) What patch does is to actually copy >the code for the opcode over itself, then transfer control to the beginning of >itself. (Tricky, but it can be done.) Every emulation routine finishes with >a "bra.s next_instr" so they are all really the same length. That saves the >call and return overhead. > >If an emulation routine is too long, then just use a jmp to somewhere. In >practice, you would probably start with: > > jsr patch > bra.s next_instr > >in every slot, rather than a complete copy of patch. Z80 RAM writes would >copy the above code to the corresponding slot, if necessary, rather than >copying the whole patch routine. > >Short of "compiling and optimising", this is the fastest method I can think of, >but it is incredibly space-wasting, self-modifying, extremely dirty, and >definitely not recommended. > >-------------------------------------------------------------------------- >Method 6: The "threaded vector table" method: > >Ok, now to fix the self-modifying code problem. Take method 4 (threaded jsr's), >but use a 262kb vector table in a private data segment, instead of a thread in >the code segment. > >vectors: dc.l patch ; 0 > dc.l patch ; 1 > ... > dc.l patch ; 65535 > dc.l jmp_thread > >The main instruction loop looks like: > > lea.l vectors,a0 > lea.l mloop(pc),a2 >mloop: move.l (a0)+,a1 ;12 cycles > jmp (a1) ; 8 cycles > >and every instruction finishes with "jmp (a2)". A0 is acting as a "pseudo-pc" >into the vector table. Of course patch performs the same functions as before >(except it is no longer self modifying, it just patches a vector). The vector >table still needs to be updated by every write to Z80 RAM. The code is >re-entrant provided each task has a separate copy of the vector table. > >-------------------------------------------------------------------------- >Method 7: The "position-independent threaded vector table" method: > >Same as method 6, except that now the private data segment is: > >thread: dc.w patch-base ; 0 > dc.w patch-base ; 1 > ... > dc.w patch-base ; 65535 > dc.w jmp_thread-base > >and the main loop is: > > lea.l thread,a0 > lea.l mloop(pc),a1 >mloop: move.w (a0)+,d0 ; 8 cycles > jmp base(pc,d0.w) ;14 cycles >base: >patch: ... >op00: ... >op01: ... >jmp_thread: ... > >Now it is position-independent, only 128kb contiguous memory, the executable >is 1500 bytes smaller, and it is slightly slower (only by 2 cycles per z80 >instruction though). The code is re-entrant provided each task has a separate >copy of the vector table. > >-------------------------------------------------------------------------- >Method 8: The "decode-at-end-of-instruction threaded vector table" method: > >Same as method 6 except that every opcode emulation routine finishes with: > > move.l (a0)+,a1 > jmp (a1) > >instead of "jmp (a2)". Now isn't that faster? And it saves a2 for more >important things. > >Unfortunately you can't do exactly the same thing to method 7 unless you can >write a complete z80 emulator in 256 bytes 8-) . But you could take method 7 >and end each emulation routine with: > >mloop: move.w (a0)+,d0 > lea.l base(pc),a1 > jmp 0(a1,d0.w) > >instead. The code is re-entrant provided each task has a separate copy of >the vector table. > >-------------------------------------------------------------------------- >Personally I'm considering using one of the methods 6, 7 or 8 in the next >version of the Spectrum emulator (probably method 8) (That is, if I ever get >enough spare time without more interesting things to do.) I'll probably make >the source public domain. That will use more Amiga RAM, but should go faster >(I hope). Any guesses as to which method will be the fastest, and still fit >comfortably in a 512k machine? > >Unfortunately I don't think any of the methods (except the first 3) are >suitable for an 8088 emulator because of the huge memory requirements. > >I'm interested in any ideas anyone might have along these lines. The >discussion of "compiling and optimising" is very interesting, but I don't see >how the details would work. In particular, how do you cope with self-modifying >code, code loaders, overlays etc? > > >Peter McGavin. (srwmpnm@wnv.dsir.govt.nz) > >Disclaimer: I haven't tested any of the above ideas (except 1 and 2). If you >see any bugs, point them out. > > >From: daveh@cbmvax.commodore.com (Dave Haynie) >Newsgroups: comp.sys.amiga.emulations >Subject: Re: Emulator Mechanics >Message-ID: <19749@cbmvax.commodore.com> >Date: 11 Mar 91 20:25:55 GMT >References: <1991Mar7.093149.18707@mintaka.lcs.mit.edu> >Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) >Organization: Commodore, West Chester, PA > >In article <1991Mar7.093149.18707@mintaka.lcs.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: > >> Why doesn't AMAX multitask? It should be EASY to run multiple copies >>of the Mac ROM as a task (since its a rom, its mostly pure code, except >>each task would need to alter where the ROM things the system memory is.) > >Without massive patching of the Mac ROM, I don't think so. The same reason >you don't have more sophisticated multitasking on the Mac itself. You can't >run multiple copies of the same Mac ROM code, since the code is not reentrant >like Amiga code. Without some clever MMU tricks, I don't think you could >easily relocate things such that several different copies of the ROM code >could coexist. At least, you would expect Apple to have considered any of >the more mundane tricks available on any 680x0 system. Apple does seem to have] >decent technical folks, I doubt they missed any easy tricks... > >Via MMU, you could certainly get further. Multifinder didn't do that, since >it would have required an MMU based system for any multitasking. I'm surprised >Apple didn't work out anything like that for their MacOS-under-UNIX, though. > >>Does anyone know if IBM code uses self modifying code, or >>jump tables? > >Self modifying code and other uglies are very prevalent in MS-DOS code. That's >the main reason Intel went for a unified code/data cache for the 80486. >Separate I and D caches with internal Harvard architecture (like the '030 and >'040) can yield a much faster system, all else being equal. But that extra >performance would not have been worth tossing out what was apparently a large >portion of the MS-DOS programs out there. > >MS-DOS programs, more and more often, think they're the operating system. >Every program is responsible for managing differences between CPUs, managing >memory (beyond the 8088 model), graphics, etc. > >-- >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > "What works for me might work for you" -Jimmy Buffett > > >From: srwmpnm@windy.dsir.govt.nz >Newsgroups: comp.sys.amiga.emulations >Subject: Re: 8 methods to emulate a Z80 >Summary: 4 more methods to emulate a Z80 >Keywords: Z80 68000 Amiga Emulator >Message-ID: <18850.27dbf20e@windy.dsir.govt.nz> >Date: 11 Mar 91 21:09:34 GMT >References: <18847.27d80900@windy.dsir.govt.nz> >Organization: DSIR, Wellington, New Zealand > >Here are 4 more methods for doing z80 instruction decoding on a 68000. These >methods are all based on fixed-size instruction emulation routines. > >There are some general comments, on handling multiple-byte opcodes, writing to >hardware registers, and flag handling, at the end of this post. > >These 4 methods are faster than methods 1..3 (see previous post), they do not >have the RAM-write overheads of methods 4..8, and they do not require tables of >opcode routine address offsets. Some of these methods might be superior to all >previous methods. > >In all these methods, each z80 instruction emulation routine is fixed at 256 >bytes in length. (See earlier post by Ian Farquhar.) They are coded in the >sequence op_80, op_81, ... op_ff, op_00, op_01, ... op_7f. So there is exactly >64k of code. If a routine is shorter than 256 bytes, the extra space is >wasted. If a routine is longer than 256 bytes then it will need a jsr to >somewhere. > >------------------------------------------------------------------------------- >Method 9: The "self-modifying fixed-size routine" method: > >Warning: Self modifying code follows. > >This method is almost the same as in Ian Farquhar's earlier c.s.a.e post. > >setup: lea.l op_00(pc),a1 ; a1 always points to op_00 > move.l z80ram,a2 ; load pseudopc > >mloop: move.b (a2)+,1$-op_00+4(a1) ;16 patch $ff in jmp instruction, inc pc >1$: jmp $ff00(a1) ;10 Jump to routine. > ;26 total cycles > >Every instruction emulation routine ends with a copy of mloop, rather than a >jump back to mloop. > >The move.b patches the high byte of the offset in the second instruction, so >the jump goes to the right routine. (1$-op_00+4 might be 1$-op_00+2 --- I >haven't checked.) > >The code is extremely fast (maybe the fastest yet), but it does not work on >Amigas with memory caches. > >I thought of making it even faster by permanently setting a4 to the address of >the byte to patch, and then using: > >mloop: move.b (a2)+,(a4) ;12 Patch $ff in jmp instruction, inc pc > jmp $ff00(a1) ;10 Jump to routine. > ;22 total cycles > >but you run out of reserved registers if there are lots of copies of mloop. >(I.e, you can't use the decode-at-end-of-instruction technique.) Using >"jmp (a3)" at the end of every routine makes it slower. > >------------------------------------------------------------------------------- >Method 10: The "standard fixed-size routine" method: > >Now we eliminate self-modifying code. > >The main loop is coded into the wasted space at the end of op_ff (so that it is >within 128 bytes of op_00 --- Remember that op_00 is in the middle of the 64k >code block). > >setup: subq.l #2,sp ; make room for scratch area on stack > clr.w (sp) ; low byte of scratch area is always 0 > lea.l mloop(pc),a3 ; a3 always points to mloop > move.l z80ram,a2 ; load pseudopc > >mloop: move.b (a2)+,(sp) ;12 Opcode to scratch high byte, inc pc > move.w (sp),d0 ; 8 high byte is opcode, low byte is 0 > jmp op_00(pc,d0.w) ;14 Jump to routine. > >Each z80 instruction emulation routine ends with: > > jmp (a3) ;10 > ;44 total cycles > >Unfortunately it's quite a bit slower. We can do better... > >------------------------------------------------------------------------------- >Method 11: The "decode-at-end-of-instruction fixed-size routine" method: > >Register a3 always points to op_00 instead of to mloop, and we have: > >setup: subq.l #2,sp ; make room for scratch area on stack > clr.w (sp) ; low byte of scratch area is always 0 > lea.l op_00(pc),a3 ; a3 always points to op_00 > move.l z80ram,a2 ; load pseudopc > >mloop: move.b (a2)+,(sp) ;12 Opcode to scratch high byte, inc pc > move.w (sp),d0 ; 8 high byte is opcode, low byte is 0 > jmp 0(a3,d0.w) ;14 Jump to routine. > ;34 total cycles > >Each z80 instruction emulation routine ends with a copy of the decode routine. >This is faster than method 10, and mloop can be coded anywhere. > >Can we avoid using scratch memory and still be as fast? Think about how you >might do this before you read on. An 8-bit shift of register d0 avoids using >scratch memory, but is slower (on a plain 68000). The next method shows how to >make the decode faster and avoid using scratch memory, but it (possibly) >introduces overhead elsewhere. > >------------------------------------------------------------------------------- >Method 12: The "stretched-address-space fixed-size-routine" method: > >This method assumes that the z80 address space (z80ram) is stretched to 128k, >so that each byte in the z80's address space takes up a word in the Amiga. >The low order byte of every word must always be 0. > >setup: move.l z80ram,a2 ; load pseudopc > lea.l op_00(pc),a3 ; a3 always points to op_00 > >mloop: move.w (a2)+,d0 ; 8 Opcode to d0 high byte, inc pc > jmp 0(a3,d0.w) ;14 Jump to routine. > ;22 total cycles > >For best results, every routine ends with the mloop code (decode at end of >instruction). The instruction decode is faster than method 11, but now many >instructions will have extra work to do to convert byte z80 addresses to word >amiga addresses. Still, this code looks good enough to try. > >Miscellaneous hint #9: To convert a byte offset to a word offset, use >"add.w d0,d0", not "lsl.w #1,d0". > >Another miscellaneous hint: Maybe there's a use for movep here. > >You could maintain 2 copies of the z80 address space --- one in 64k and the >other in 128k. Then it's just a simple matter of writing a byte to both places >whenever the z80 does a write. That gets rid of the overhead of converting >between offset types on memory reads. > >But now our method is starting to look like threaded code (method 8) again. >The threaded code method uses the 128k block to store the offset to the >handling routine, rather than storing the opcode itself. The overhead in doing >a memory write is the same in both methods, and threaded code has other >advantages (like not having to pad code to 256 bytes, multiple-byte opcodes >handled better). So we're back to threaded code again. > >------------------------------------------------------------------------------- >A note on multiple-byte opcode instructions: > >The z80 uses these. They are prefixed with $cb, $dd, $ed and $fd. There are >also $ddcb and $fdcb prefixed instructions. > >For fixed-size methods, (methods 9..12), the fastest way to cope with long >instructions is to use more tables. But that means multiplying the number of >tables by 5 or 7. 64k of code has just jumped to 320k or 448k. That's no good >on a small machine. Also, if you reserve a register to point to op_00 in each >table, that's 5 or 7 registers gone. Oops. > >------------------------------------------------------------------------------- >Some notes on threaded code: > >I spent last evening trying threaded code (method 8) in the Spectrum emulator. >(See previous post.) I got a 20..40% speed improvement over the position- >independent standard method (256-way CASE statement). It's still several times >slower than a real Spectrum, unfortunately. There is some slow code in places >where there wasn't before, so there is scope for more improvement. >Unfortunately I introduced some bugs during the systematic changes, and they >are proving hard to track down. Everything in the Spectrum ROM seems to work >ok. Some machine-code programs that worked before have stopped working. > >Threaded code is extremely fast for multiple-opcode instructions. Control is >vectored directly to the right routine first time, without having to decode >multiple tables. A problem with this is that if a Spectrum program overwrites >the second opcode of a multiple-byte instruction ($cb, $dd, $ed, $fd) without >writing to the first byte, then the emulator doesn't cope. > >------------------------------------------------------------------------------- >Note on hardware registers: > >Handling writes to hardware registers in the Spectrum isn't really very hard. >The z80 has a separate IO address space with a separate set of instructions for >handling it. (The same is true of the 8088.) The only thing to watch for is >writing to video RAM. It is fixed size and at a fixed place, so it takes 2 >tests. (There doesn't seem to be a faster way of doing a single bit test --- >the video RAM doesn't end on a power-of-2 boundary.) I have a separate task >(sort of) which uses the blitter to keep the screen up-to-date with the video >RAM. So when there is a write to video RAM, the emulator task doesn't have to >do much. It just flags the blitter task "Hey, there's something to update in >character row n, when you wake up". The blitter task doesn't slow the emulator >down much, because it's mostly running on another processor, and it sleeps when >there's nothing to update. > >------------------------------------------------------------------------------- >Some notes on flag handling: > >Both of the CP/M emulators I know about spend a lot of time handling z80 flags >(condition codes). After just about every instruction they do a "move sr,d0" >or "move ccr,d0" or call GetCC() to get the 68000 flags, then they do a table >lookup to translate them to z80 format. After every logical instruction (not, >or, xor etc), a second table lookup is done to set the z80 parity flag. (The >68000 does not have a parity flag.) These table lookups are slow. In fact, >they often take several times as long as the guts of the instruction itself. > >Both these table lookups are totally unnecessary! It's faster to save the >flags in 68000 format (in a register). Routines that test flags simply test >the corresponding 68000 flag. For logical instructions, simply save the parity >byte away somewhere, and set another bit in the register to say to use the >parity byte and not v flag. The parity testing instructions (e.g, "jp po,nn") >look at that bit, and then test either the v flag or the saved parity byte. >The only times you need to translate flags between z80 and 68000 formats are in >"push af" and "pop af" instructions. > >I got a 10..20% speedup in my Spectrum emulator this way. > >------------------------------------------------------------------------------- >I said in my previous post that threaded code for 8088 emulation would use too >much memory to be practical. In fact it would be perfectly practical on an >Amiga equipped with 3 Mbytes or more. > >Peter McGavin. (srwmpnm@wnv.dsir.govt.nz) > > >From: Chris_Johnsen@mindlink.UUCP (Chris Johnsen) >Newsgroups: comp.sys.amiga.emulations >Subject: Emulator Mechanics [Transpiler] >Message-ID: <5097@mindlink.UUCP> >Date: 10 Mar 91 17:54:43 GMT >Organization: MIND LINK! - British Columbia, Canada > > > Thank you all for the valued input into this discussion to date, both >pro and con. I must say I find it very stimulating. > > When discussing this form platform porting translator/compiler with >anyone, I find the need for a short word to use. In a humble attempt to coin >a descriptive phrase, may I suggest transpiler? >Charlie Gibbs (Charlie_Gibbs@mindlink.UUCP) Jean-Noel Moyne (jnmoyne@lbl.gov) >Dave Clemans (dclemans@mentorg.com) Dwight Hubbard (uunet.uu.net!easy!lron) >Pete Ashdown (pashdown@javelin.es.com) Jyrki Kuoppala (jkp@cs.HUT.FI) confirm >that, indeed some research and even program development has been done in this >direction. > >Eddy Carroll (ecarroll@maths.tcd.ie) has written such a transpiler, as a last >year project, with some success, some reservations. > >Chris Gray (cg@ami-cg.UUCP) suggests that the most practicable route to >desinging a viable transpiler would be to make it interactive. BTW Chris, I >very much enjoyed your compiler articles in the Amiga Transactor. > >Ray Cromwell (rjc@pogo.ai.mit.edu) suggested an interesting thought, a sort of >Usenetware combined effort for development, he also thinks reasonable execution >speed can be achieved. > > Those are what I percieve to be the ideas supporting the transpiler >concept. The statements of contrary considerations are more voluminous. These >appear to fall into a number of categories. > o Self-modifying code > o Separating code from data > o Determining video access > o Stack handling > o Jump table problems > o Handling overlay segments >Ian Farquhar (ifarqhar@sunb.mqcc.mq.oz.au) suggested that a compiled module be >run concurrent with an emulator type section so that in some parallel way, any >references within the source executable, which would also be loaded during >runtime of the emulation, could be validated. It could be argued that this >should be placed on the pro side of the ledger, but the incurred overhead >during execution would be large. This function, I had imagined initially, >would be carried out during the transpiler phase and not attached to, or >burdening, the runtime execution. > >Brad Pepers (pepers@enme1.ucalgary.ca) Jyrki Kuoppala (jkp@cs.HUT.FI) Jonathan >David Abbey (jonabbey@cs.utexas.edu) were somewhat concerned with >self-modifying code. There were a significant number of voices that dismissed >this concern. Personally, I wouldn't worry about it. If a particular program >used this technique, for whatever reason, I would accept the fact that not all >programs can be transpiled. > >Ian Farquhar (ifarqhar@sunb.mqcc.mq.oz.au) Dave Clemans (dclemans@mentorg.com) >Sullivan (Radagast@cup.portal.com) Jean-Noel Moyne (jnmoyne@lbl.gov) Chris >Gray (cg@ami-cg.UUCP) raised concerns about determining code from bytes of the >data persuation. This is what I had thought would be the biggest stumbling >block. I hadn't thought there would be so many others. :-) It's great to hear >how how long the road is before you begin the journey. > >Udi Finkel (finkel@TAURUS.BITNET) Eddy Carroll (ecarroll@maths.tcd.ie) are >concerned about determining when the access to memory is video ram. This, I >believe, can be solved, if it is dealt with in the same manner as the code/data >resolution. Please read on. > >Eddy Carroll (ecarroll@maths.tcd.ie) points out problems with processor stack >handling. How did you resolve this with the transpiler you developed? It >occurs to me that every emulator whether it be a transpiler, or interpretive >type must handle the stack properly. To me, it would be more difficult to >approach this problem if I were writting an emulator, as opposed to a >transpiler, as less executable size constraints would inhibit producing an >intelligent stack handler. On the 68000 the stack would be handled as >word/longword only. Any bytewise stack functions within the source executable >would be transpiled into wordwise handling. A problem, but surmountable. > >Chris Gray (cg@ami-cg.UUCP) Eddy Carroll (ecarroll@maths.tcd.ie) raised the >problem of coping with jump or branch tables properly. Weighty point. This I >would describe as a grey area between code and data where it may be actual jump >instructions, or a table of label locations, the code to be emulated >calculating an offset into it. This must be handled in a similar fashion to >the code/data recognition problem. > >Dave Clemans (dclemans@mentorg.com) Kurt Tappe (JKT100@psuvm.psu.edu) Jonathan >David Abbey (jonabbey@cs.utexas.edu) were concerned with the handling of >overlay segments. This bothers me too. With the Amiga, it would be possible >to either use overlays, in the case of very large programs, or convert to >all-in-one programs by consolidating the overlay hunks. The main problem is >determining that overlays are employed, loading them and transpiling. This is >closely related to the code/data determination problem. > >Dwight Hubbard (uunet.uu.net!easy!lron) suggest that this would work, kind of >like DSM. I have DSM and must say it was a model for me when contemplating >this idea. Chris Gray (cg@ami-cg.UUCP) believes that an interactive compiler >holds some promise. In one of my initial messages to Charlie Gibbs I >entertained the reality of having to fall back on human intervention, at the >transpiler output source code level. This would be determined at runtime, >when the emulated program failed to operate correctly or at all. A programmer >would be required to fix the problem. > > What I interpert the huge human parallel processor the net represents, >to be saying, is that human intervention must be employed. My only reservation >in this regard is that there are interperative emulators that run a wide >variety of software on-the-fly. To me, this feat is more difficult than a >transpiler, which can ruminate over the executable for as long as say a >raytracer. > > To incorporate the above concepts, and arrive at a workable resolution, >what is required is an expert system, probably requiring a resident expert (not >software, though brain matter is soft), to resolve the code/data, video access, >jump/branch table and overlay problems. I don't suppose that the average >emulator user is prepared to deal with or even understand the problems we have >been discussing. I don't think it would be worthwhile writing a transpiler >unless it could be made to work in some standalone fashion. Feed it the >source executable and out pops the Amiga version. > > Mind shifting stage left... > > I have a suggestion, since it is not considered practicable to write a >transpiler that will work unassisted, that may resolve the percieved problems >using some of the concepts from this message thread. > > First, an off-the-wall analogy. Here he goes again. :-) > > Consider a desirable program, running on another platform, useful to >an Amiga user, but with a very large dongle attached. This useful program must >be run on the dongle in fact. This is inconvient. What do I do if I loose my >dongle? I propose you think of this as a form of copy protection for a >moment, obstructiing the Amiga owner, who also owns a program that runs on >another platform. Follow me so far? The legitimate program for the other >platform cannot be used on the favoured, Amiga machine, so it needs to be >decopy-protected. What do you use if you wish to backup and/or deprotect >software? A copier program. Most copiers can be employed by users who have >little knowledge of copy protection, yet they succeed in making the copy. The >more difficult protection schemes require "brain files" which are written by >experts to achieve this end. End of transpiler/copy-protection analogy. > > Take a basic transpiler, such as the one Eddy Carroll wrote, and add a >toolkit. The transpiler would do its best to translate and compile the source >executable. If this failed, an expert, not just the average user, would either >run the transpiler in expert mode, or a debug tool from the toolkit, which >would work through any problem areas. The result of this would be an expert >transpiler file. The beauty of this approach is that any user could run the >transpiler, given access to the expert file. These expert files could be >included with the release package and any new ones could be included in any >updates or shared by conventional electronic means as PD. > >What do you think? > >csj > > No really officer, I wasn't speeding, just keeping a safe distance in front of >the car behind me! > >Usenet: a542@mindlink.UUCP Phone: (604)853-5426 FAX: (604)854-8104 > > >From: Chris_Johnsen@mindlink.UUCP (Chris Johnsen) >Newsgroups: comp.sys.amiga.emulations >Subject: Emulator Mechanics [Transpiler] >Message-ID: <5097@mindlink.UUCP> >Date: 10 Mar 91 17:54:43 GMT >Organization: MIND LINK! - British Columbia, Canada > > > Thank you all for the valued input into this discussion to date, both >pro and con. I must say I find it very stimulating. > > When discussing this form platform porting translator/compiler with >anyone, I find the need for a short word to use. In a humble attempt to coin >a descriptive phrase, may I suggest transpiler? >Charlie Gibbs (Charlie_Gibbs@mindlink.UUCP) Jean-Noel Moyne (jnmoyne@lbl.gov) >Dave Clemans (dclemans@mentorg.com) Dwight Hubbard (uunet.uu.net!easy!lron) >Pete Ashdown (pashdown@javelin.es.com) Jyrki Kuoppala (jkp@cs.HUT.FI) confirm >that, indeed some research and even program development has been done in this >direction. > >Eddy Carroll (ecarroll@maths.tcd.ie) has written such a transpiler, as a last >year project, with some success, some reservations. > >Chris Gray (cg@ami-cg.UUCP) suggests that the most practicable route to >desinging a viable transpiler would be to make it interactive. BTW Chris, I >very much enjoyed your compiler articles in the Amiga Transactor. > >Ray Cromwell (rjc@pogo.ai.mit.edu) suggested an interesting thought, a sort of >Usenetware combined effort for development, he also thinks reasonable execution >speed can be achieved. > > Those are what I percieve to be the ideas supporting the transpiler >concept. The statements of contrary considerations are more voluminous. These >appear to fall into a number of categories. > o Self-modifying code > o Separating code from data > o Determining video access > o Stack handling > o Jump table problems > o Handling overlay segments >Ian Farquhar (ifarqhar@sunb.mqcc.mq.oz.au) suggested that a compiled module be >run concurrent with an emulator type section so that in some parallel way, any >references within the source executable, which would also be loaded during >runtime of the emulation, could be validated. It could be argued that this >should be placed on the pro side of the ledger, but the incurred overhead >during execution would be large. This function, I had imagined initially, >would be carried out during the transpiler phase and not attached to, or >burdening, the runtime execution. > >Brad Pepers (pepers@enme1.ucalgary.ca) Jyrki Kuoppala (jkp@cs.HUT.FI) Jonathan >David Abbey (jonabbey@cs.utexas.edu) were somewhat concerned with >self-modifying code. There were a significant number of voices that dismissed >this concern. Personally, I wouldn't worry about it. If a particular program >used this technique, for whatever reason, I would accept the fact that not all >programs can be transpiled. > >Ian Farquhar (ifarqhar@sunb.mqcc.mq.oz.au) Dave Clemans (dclemans@mentorg.com) >Sullivan (Radagast@cup.portal.com) Jean-Noel Moyne (jnmoyne@lbl.gov) Chris >Gray (cg@ami-cg.UUCP) raised concerns about determining code from bytes of the >data persuation. This is what I had thought would be the biggest stumbling >block. I hadn't thought there would be so many others. :-) It's great to hear >how how long the road is before you begin the journey. > >Udi Finkel (finkel@TAURUS.BITNET) Eddy Carroll (ecarroll@maths.tcd.ie) are >concerned about determining when the access to memory is video ram. This, I >believe, can be solved, if it is dealt with in the same manner as the code/data >resolution. Please read on. > >Eddy Carroll (ecarroll@maths.tcd.ie) points out problems with processor stack >handling. How did you resolve this with the transpiler you developed? It >occurs to me that every emulator whether it be a transpiler, or interpretive >type must handle the stack properly. To me, it would be more difficult to >approach this problem if I were writting an emulator, as opposed to a >transpiler, as less executable size constraints would inhibit producing an >intelligent stack handler. On the 68000 the stack would be handled as >word/longword only. Any bytewise stack functions within the source executable >would be transpiled into wordwise handling. A problem, but surmountable. > >Chris Gray (cg@ami-cg.UUCP) Eddy Carroll (ecarroll@maths.tcd.ie) raised the >problem of coping with jump or branch tables properly. Weighty point. This I >would describe as a grey area between code and data where it may be actual jump >instructions, or a table of label locations, the code to be emulated >calculating an offset into it. This must be handled in a similar fashion to >the code/data recognition problem. > >Dave Clemans (dclemans@mentorg.com) Kurt Tappe (JKT100@psuvm.psu.edu) Jonathan >David Abbey (jonabbey@cs.utexas.edu) were concerned with the handling of >overlay segments. This bothers me too. With the Amiga, it would be possible >to either use overlays, in the case of very large programs, or convert to >all-in-one programs by consolidating the overlay hunks. The main problem is >determining that overlays are employed, loading them and transpiling. This is >closely related to the code/data determination problem. > >Dwight Hubbard (uunet.uu.net!easy!lron) suggest that this would work, kind of >like DSM. I have DSM and must say it was a model for me when contemplating >this idea. Chris Gray (cg@ami-cg.UUCP) believes that an interactive compiler >holds some promise. In one of my initial messages to Charlie Gibbs I >entertained the reality of having to fall back on human intervention, at the >transpiler output source code level. This would be determined at runtime, >when the emulated program failed to operate correctly or at all. A programmer >would be required to fix the problem. > > What I interpert the huge human parallel processor the net represents, >to be saying, is that human intervention must be employed. My only reservation >in this regard is that there are interperative emulators that run a wide >variety of software on-the-fly. To me, this feat is more difficult than a >transpiler, which can ruminate over the executable for as long as say a >raytracer. > > To incorporate the above concepts, and arrive at a workable resolution, >what is required is an expert system, probably requiring a resident expert (not >software, though brain matter is soft), to resolve the code/data, video access, >jump/branch table and overlay problems. I don't suppose that the average >emulator user is prepared to deal with or even understand the problems we have >been discussing. I don't think it would be worthwhile writing a transpiler >unless it could be made to work in some standalone fashion. Feed it the >source executable and out pops the Amiga version. > > Mind shifting stage left... > > I have a suggestion, since it is not considered practicable to write a >transpiler that will work unassisted, that may resolve the percieved problems >using some of the concepts from this message thread. > > First, an off-the-wall analogy. Here he goes again. :-) > > Consider a desirable program, running on another platform, useful to >an Amiga user, but with a very large dongle attached. This useful program must >be run on the dongle in fact. This is inconvient. What do I do if I loose my >dongle? I propose you think of this as a form of copy protection for a >moment, obstructiing the Amiga owner, who also owns a program that runs on >another platform. Follow me so far? The legitimate program for the other >platform cannot be used on the favoured, Amiga machine, so it needs to be >decopy-protected. What do you use if you wish to backup and/or deprotect >software? A copier program. Most copiers can be employed by users who have >little knowledge of copy protection, yet they succeed in making the copy. The >more difficult protection schemes require "brain files" which are written by >experts to achieve this end. End of transpiler/copy-protection analogy. > > Take a basic transpiler, such as the one Eddy Carroll wrote, and add a >toolkit. The transpiler would do its best to translate and compile the source >executable. If this failed, an expert, not just the average user, would either >run the transpiler in expert mode, or a debug tool from the toolkit, which >would work through any problem areas. The result of this would be an expert >transpiler file. The beauty of this approach is that any user could run the >transpiler, given access to the expert file. These expert files could be >included with the release package and any new ones could be included in any >updates or shared by conventional electronic means as PD. > >What do you think? > >csj > > No really officer, I wasn't speeding, just keeping a safe distance in front of >the car behind me! > >Usenet: a542@mindlink.UUCP Phone: (604)853-5426 FAX: (604)854-8104 > > >From: daveh@cbmvax.commodore.com (Dave Haynie) >Newsgroups: comp.sys.amiga.emulations >Subject: Re: Emulator Mechanics >Message-ID: <19792@cbmvax.commodore.com> >Date: 12 Mar 91 22:39:53 GMT >References: <1991Mar7.093149.18707@mintaka.lcs.mit.edu> <19749@cbmvax.commodore.com> <1991Mar12.011418.24768@mintaka.lcs.mit.edu> >Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) >Organization: Commodore, West Chester, PA > >In article <1991Mar12.011418.24768@mintaka.lcs.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: >>In article <19749@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>>In article <1991Mar7.093149.18707@mintaka.lcs.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: > >>>> Why doesn't AMAX multitask? > >>>Without massive patching of the Mac ROM, I don't think so. > >> Well it's not a heavy loss if you can't make the Mac ROM resident, but >>why does AMAX have to take over the Amiga's operating system? The only >>thing that would make it really diffcult to run MacOS under >>AmigaDOS is if Mac code fiddles with absolute memory locations or the >>OS implements function calls as traps/interupts. > >Well, the Mac OS fiddles with absolute memory locations, and the OS implements >function calls as line-A exceptions. Apparently, all the absolute locations >are in low memory and get swapped as part of the process context when you run >Multifinder. > >>I also wonder why readysoft used a special disformat for Mac disks >>instead of reading Amiga disks. > >No doubt this was to make Mac software work on Amiga disks. The Mac isn't >as nice about filesystem independence as the Amiga is, so you can't really >provide a loadable Mac filesystem kind of thing that maps Mac filespace >into Amiga filespace adequately. So ReadySoft essentially just built a new >device driver, which uses Amiga-readable formats, but Mac filesystem >organization. > >This is apparently why Mac's don't generally talk to MS-DOS disks via an >alternate filesystem like CrossDOS or MSH, but instead use a user program for >the conversion, along the lines of the old PC Utilities. >-- >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > "What works for me might work for you" -Jimmy Buffett > > >From: ifarqhar@sunb.mqcc.mq.oz.au (Ian Farquhar) >Newsgroups: comp.sys.amiga.emulations >Subject: Re: Emulator Mechanics [Transpiler] >Message-ID: <1338@macuni.mqcc.mq.oz> >Date: 13 Mar 91 03:24:04 GMT >References: <5097@mindlink.UUCP> >Organization: Macquarie University, Sydney, Australia. > >In article <5097@mindlink.UUCP> Chris_Johnsen@mindlink.UUCP (Chris Johnsen) writes: >>Ian Farquhar (ifarqhar@sunb.mqcc.mq.oz.au) suggested that a compiled module be >>run concurrent with an emulator type section so that in some parallel way, any >>references within the source executable, which would also be loaded during >>runtime of the emulation, could be validated. It could be argued that this >>should be placed on the pro side of the ledger, but the incurred overhead >>during execution would be large. This function, I had imagined initially, >>would be carried out during the transpiler phase and not attached to, or >>burdening, the runtime execution. > >No, I suggested that an image of the original code, without translation, >be carried around with the compiled code, with indexes into the compiled >code's equivalent sections that would allow jump tables and so forth to >function correctly. This would be a memory intensive but low-time-overhead >time way of resolving problems. It should also be noted that such a >system would allow trapping of addresses that need to be handled by >special code (hardware locations etc.), and that the image is also used >for data storage, meaning that once loaded and allocated, the program >would be unlikely to need any further allocation of heap. > >This system solves two problems: the data/code differentiation (if you >accidentally compile some data, it is no great problem) though a much >more minor problem remains if a couple of opcodes are missed because of >data being accidentally compiled and the compiler assuming an opcode is >the data for a false opcode, and also the problem of jump tables >and jumping to locations stored in registers. > >-- >Ian Farquhar Phone : + 61 2 805-9400 >Office of Computing Services Fax : + 61 2 805-7433 >Macquarie University NSW 2109 Also : + 61 2 805-7420 >Australia EMail : ifarqhar@suna.mqcc.mq.oz.au > > >From: srwmpnm@windy.dsir.govt.nz >Newsgroups: comp.sys.amiga.emulations >Subject: Re: CPU-emulators >Message-ID: <18878.2801a4ad@windy.dsir.govt.nz> >Date: 9 Apr 91 11:25:31 GMT >Organization: DSIR, Wellington, New Zealand > >Ilja Heitlager (iheitla@cs.vu.nl) wrote: >>I'm planning to write a 6502 (and maybe when I like it some others) emulator. > >Good on you! I've played around with the Z80 emulators for the Amiga, by Ulf >Nordquist and Charlie Gibbs, making them faster. I have never touched 6502 but >the same techniques should apply. > >>At this moment I think there are two ways of doing it: >> 1- Compare every Opcode and jump to a routine which executes the >> instruction >> 2- Do it more or less the way the microcode does it. >> Ok in software you can't do more operations at the same moment. > >I found at several more fundamentally different ways of doing it, and many >variations on those. So far the fastest practical method seems to be threaded >code. You can avoid decoding an opcode for every 6502 instruction altogether! >The emulation routine for each 6502 opcode ends with: > > move.l (a3)+,a0 > jmp (a0) > >So each emulation routine jumps directly to the next emulation routine without >any decoding at all. Register a3 is acts like a "pseudo pc" into a 256 kbyte >table in which there is a longword pointer to the emulation routine for each >corresponding opcode in the 64 kbyte 6502 address space. > >Now, every time the 6502 writes to RAM, you need to update an entry in the >256 kbyte table. At first it looks as if you have to do an instruction decode >to compute the new table value every time the 6502 writes to RAM. But in fact >that is not necessary either! > >What you do, when the 6502 writes to RAM, is to write a constant address into >the table. That constant address points to a special routine called "patch". >When patch is called, you finally get to do an instruction decode. Patch >computes the address of the routine for the current instruction, stuffs it >in the 256 kbyte table, then jumps to the routine for the current instruction. >Next time this instruction is executed, control bypasses patch and goes >directly to the right routine. > >A variation of this method which saves memory but is slightly slower, is to use >word offsets in a 128 kbyte table, instead of longword addresses in a 256 kbyte >table. Each routine ends with: > > move.w (a3)+,d0 > jmp 0(a2,d0.w) > >where a2 holds the base from which all the routine offsets are computed. > >This method has more advantages: > >1: To handle known ROM entry points, just point the vector for the entry point >at an optimised 68000 routine to do what the ROM routine does. There is no >overhead at all in checking for ROM entry points. > >2: To handle multiple-byte opcodes (e.g, prefix instructions), patch can be made >smart enough to point the vector for the prefix byte to the routine for the >entire instruction. There is no need to decode opcodes after the prefix every >time the instruction is executed. > >3: Patch can be made smart enough to recognise common sequences of 6502 >instructions, and to point the vector at an optimised 68000 routine for the >whole sequence. > >Note that 2 and 3 above (if implemented) won't correctly emulate certain types >of self-modifying code. > >There was a good article on "Portable Fast Direct Threaded Code" by Eliot >Miranda in comp.compilers recently. He uses GCC to write "machine independent" >threaded code that is just about as efficient as my 68000-specific code. > >Hope this helps. Regards, Peter McGavin. (srwmpnm@wnv.dsir.govt.nz) > > sega/docs/ggenie.txt0000755000000000000000000001123011266515003011611 0ustar From rec.games.video Fri Jan 8 10:05:34 1993 Newsgroups: rec.games.video Path: netnews.louisville.edu!ukma!darwin.sura.net!spool.mu.edu!uunet!digibd!merlyn From: merlyn@digibd.com (Merlyn LeRoy) Subject: Game Genie for Genesis decoder Organization: DigiBoard Incorporated, Eden Prairie, MN Date: Thu, 07 Jan 1993 16:31:27 GMT Message-ID: <1993Jan07.163127.8219@digibd.com> Lines: 353 I've figured out the Genesis Game Genie 8-letter codes; all the codes are for a 24-bit address and 16-bit data for the 68000. The Game Genie lies to the CPU about those addresses, substituting the 16-bit instruction at that address. For example, the codes for Sonic 1 to make each ring worth 2 rings, SCRA-BJX0, decodes to 009c76: 5478, which is an addq #2,... instruction (instead of adding 1 to the total, add 2). Since the 68000 has a regular instruction set for addq 1..8, you can make rings worth 1 to 8 each. The instruction 5478 disassembles into addq.w #2, , so if we instead change the instruction to bra.s +2 (branch over the word address), rings are worth nothing. bra.s +2 is 6002, so putting 009c76: 6002 into the decoder gives us ALRA-AA50. Using this code makes all loose rings worthless; only monitors give you rings, and picking up rings after getting hit does nothing. Unfortunately, the Game Genie seems to erase all of RAM when it resets; if it didn't, it would be possible to use the GG to write a small program in RAM and execute it to dump a game cartridge ROM. Another possibility is using the battery-backup RAM of a game to hold the program (assuming such games use normal-looking RAM, and has enough to hold a program). I'll play around with this possibility, but it doesn't look promising. In any case, it's still possible to dump the ROM of a game veeeeery slowly. What you do is find a section of code that you can clobber with 4 or 5 words of code, and insert code that does a btst #n, addr followed by a beq.s -2 (if the bit tested is zero, branch to itself, otherwise, continue). This will hang if you find a 0 and continue if you find a 1. The btst instruction can have a 1 or 2 word address. btst.b #3, 1111 would be 0838 0003 1111 and btst.b #4, 12345 would be 0839 0004 0001 2345; beq.s -2 is 67fe. Addresses greater than 7fff need the 2-word form. In Sonic 1, you can test this with the following: 00039a: 0838 0000 0007 67fe Which becomes: HABT-ATE4 AABT-AAE6 A6BT-AAE8 92BT-AR7A This tests the LSB of byte 7, the LS byte of the initial PC value on reset. This has to be zero (even addresses only), so the game will hang after the SEGA banner (39a is just after the banner call). If you change the bit to test to 1 by changing AABT-AAE6 to AEBT-AAE6, the program will NOT hang (but it will crash later) and you know bit 1 of byte 7 is 1. And so on... You can also find out things faster if you can have the game help you. For example, Sonic 1 has the exception vectors display data, so you can load a word in memory into a register, optionally add 1 to it, then jump to it. If the value is odd, you will get an address exception with the data you loaded displayed (if it isn't odd, change your add 1 instruction and try again). Here's that code: move addr, a1 2279 0000 0004 addq.l #1, a1 5289 ; if you don't get addr error at 3a4, change this jmp (a1) 4ed1 ; to addq.l #1, a0 (5288) Remember to unsubtract the 1 if you are adding 1 to it to make it odd. Here it is to read the longword at 4, the initial PC value, which we know must be even (so we'll add 1 to make it odd, and remember to subtract 1). 39a: 2279 0000 0004 5289 4ed1 Here's the full format of what the decoder prints: SEBT-AEN4 = 00039a: 2279 AABT-AAE6 [ 0] = 00039c: 0000 ATBT-AAE8 [ 4] = 00039e: 0004 VEBT-BEZA +1 = 0003a0: 5289 4EBT-A6ZC = 0003a2: 4ed1 The number in brackets are the decimal values of the bottom 8 bits; this is shown if the 68000 instruction is a move immediate, or if all the high bits are zero. This is for GG codes like "starting number of lives"; you can type the genie code with your own number in brackets to make it whatever value you want. Similarly, the "+1" indicates an addq instruction; you can add a +1..+8 or -1..-8 to change it. To not add 1 to a1, change VEBT-BEZA to VABT-BEZA, which adds one to a0. Anyway, if you plug in these codes, you'll get an address exception after the Sega banner. You should see, in a very unreadable italic font: ADDRESS ERROR $000003A4$00000207 Which means the value at 4: is 00000206 Too bad Sonic 2 doesn't have the exception code anymore. Anyway, if anyone out there knows either 1) RAM that the GG doesn't touch, or 2) battery-backed-up RAM addresses for a Genesis game, please send email. sega/docs/hardware.txt0000755000000000000000000003746611266515004012174 0ustar Sega Genesis Hardware Internals - Revised: 04/07/1993 An up-to-date version of this file can be gotten by anonymous ftp from ftp.spd.louisville.edu, in the file "pub/sega/hardware.txt". Please send corrections or comments to: Rick McTeague sysrick@starbase.spd.louisville.edu Disclaimers: The following information was extracted without the use of official information from Sega Enterprises, Ltd. I therefore offer no warranty on the correctness of this information. Use it at your own risk. This information was gathered as a personal project, and is not the responsibility of my employer. Different versions of the Genesis exist, so I won't suggest that any of this information is right for anybody's Genesis but my own. Sega, Genesis, Sonic the Hedgehog, and Ecco the Dolphin are trademarks of Sega Enterprises, Ltd. Other trademarks are the property of their respective companies. The Cartridge ROM ----------------- As others on the net have observed, a standard Genesis cartridge is nothing more than a small printed circuit board with a ROM on it. There are some cartridges which have battery-backed RAM for saving high scores, configurations, etc., but I haven't seen these, so I don't know about them. If you know of a particular cartridge that has RAM, let me know so I can go rent one and take it apart (shhhh!) to see what's in it. A cartridge contains a word-wide (16 bit) ROM with up to 2 Meg words (4 Mbytes). This is based on the signal !C_CE (see below), which is used as the cartridge ROM's chip enable on the cartridges I've looked at, and which is active at addresses $000000-$3fffff. It may be possible to have more than 4 Mbyte cartridges; if so, either they ignore the !C_CE line and do their own address decoding, or there's a register somewhere in the Genesis which changes the default address decoding scheme for !_CE. Note that cartridges are advertised as being "8 Meg"; as far as I know, is 8 Meg _bits_, not bytes. 1 Mbyte is still pretty impressive for a game machine. SONIC uses a 40-pin 256Kx16 (512Kx8) ROM in word mode. Ecco the Dolphin uses a 42-pin 512Kx16 (1024Kx8) ROM in word mode. This one confused me because I'd never seen a 42-pin DIP before, so I thought it was 40 pins. No wonder the signals didn't look right... Putting together a little bit of information from a Sharp data sheet for a 512 Kword ROM with a bit of conjecture based on the Sonic and Ecco cartridges, this is what I can come up with for pinouts: Sonic Ecco (256 Kword) (512 Kword) ------u------ ------u------ A18 1=| |=42 VCC? A17 1=| |=40 A 8 A17 2=| |=41 A 8 A 7 2=| |=39 A 9 A 7 3=| |=40 A 9 A 6 3=| |=38 A10 A 6 4=| |=39 A10 A 5 4=| |=37 A11 A 5 5=| |=38 A11 A 4 5=| |=36 A12 A 4 6=| |=37 A12 A 3 6=| |=35 A13 A 3 7=| |=36 A13 A 2 7=| |=34 A14 A 2 8=| |=35 A14 A 1 8=| |=33 A15 A 1 9=| |=34 A15 A 0 9=| |=32 A16 A 0 10=| |=33 A16 !CE 10=| |=31 !BYTE !CE 11=| |=32 !BYTE GND 11=| |=30 GND GND 12=| |=31 GND !OE 12=| |=29 D15 !OE 13=| |=30 D15 D 0 13=| |=28 D 7 D 0 14=| |=29 D 7 D 8 14=| |=27 D14 D 8 15=| |=28 D14 D 1 15=| |=26 D 6 D 1 16=| |=27 D 6 D 9 16=| |=25 D13 D 9 17=| |=26 D13 D 2 17=| |=24 D 5 D 2 18=| |=25 D 5 D10 18=| |=23 D12 D10 19=| |=24 D12 D 3 19=| |=22 D 4 D 3 20=| |=23 D 4 D11 20=| |=21 VCC D11 21=| |=22 VCC ------------- ------------- Note that the address line numbering is different than that of the 68000; line A0 of the ROM is really connected to the 68000's A1. This is because of the way the 68000 handles even/odd byte addressing using !UDS and !LDS. The !BYTE line is held high. This puts the ROM chip into "word" mode, where data is accessed 16 bits at a time. The convenient correspondence between ROM and 68000 data and address lines (ROM D0 = 68K D0, ROM D1 = 68K D1, etc..., and ROM A0 = 68K A1, ROM A1 = 68K A2, etc...) may not exist in all cartridge designs. This is sometimes difficult to visualize, but keep in mind that the ROM doesn't care whether its D0 is really D0, or if its A3 is really A3, etc. As long as each data line is used as the same D## line for both programming and reading, and each address line is used as the same A## for both programming and reading, the ROM will function properly and the 68000 will see the right instructions. Think about it... Why bring this up? If you remove the ROM from the cartridge PCB and try to read it with a EPROM programmer, there may be situations where you won't see valid 68000 instructions, or things won't be in the right place... Assuming your programmer isn't messed up, this would be because the address and data lines on the ROM aren't assigned the way you'd expect. Why would someone make a cartridge like this? To make your life difficult, if you're wanting to hack their ROMs, or to make their life easy, by making the cartridge PCB easier to design. Does anyone make cartridges like this? I don't know. But the possibility exists, and I thought you should know. The easiest way to avoid this potential problem is to build an adapter from your programmer's EPROM socket to an edge card connector into which you plug the cartridge. This is a bit safer, too, so you don't have to remove the ROM from the cartridge (or even open it up). The Cartridge Port ------------------ The cartridge port presents the 68000's 23 address lines, 16 data lines, as well as some control signals, described below. With the exception of the standard 68000 signals, signal names are my own and may bear no resemblance to their real (i.e., internal to Sega) names. Active low signals are prefixed with a "!". !C_OE drives the cartridge ROM's output enable. It's taken low on any 68000 read from locations $000000 to $0dfffff, but doesn't really matter unless !C_CE is low. !C_CE is the cartridge ROM's chip enable, and is taken low when the processor accesses memory locations $000000 to $3fffff. !LO_MEM looks similar to !C_CE, but is taken low on accesses to locations $000000 to $7fffff. I haven't tried tying anything to this yet. Not used by the ROM. CLK is the 68000's 7.67 MHz clock, being fed to the cartridge in case something might want to use it. Not used by the ROM. There's a !DTACK at the cartridge port, but I don't know how useful it is. It looks like the Genesis has its own logic for giving !DTACK to the processor, so it's not necessary (or advisable) for the cartridge to generate it. Perhaps there's some good reason why a cartridge might want to see the !DTACK being generated on its behalf. Directly connected to the 68000 (open collector line?). Not used by the ROM. !AS isn't used by the cartridge ROM, but is present in case something else wants it. Direct from the 68000. Byte reads from ROM don't need !UDS or !LDS, as the processor just ignores the unneeded bytes on the data bus. Byte writes shouldn't enable both upper and lower bytes, so the cartridge port provides a lower- byte write (!LDSW) and upper-byte-write (!UDSW) signals. These would be useful for cartridges with RAM. !RESET is provided for cartridges with logic which needs to be reset. Direct from the 68000. Not used by the ROM. !S_RESET is an input to the Genesis which causes a "soft" reset (see below). Not used by the ROM. !H_RESET is an input to the Genesis which causes a "hard" reset (see below). Not used by the ROM. !CART_IN is an input to the Genesis which lets it know that the cartridge is in place. This is used to enable the internal OS ROM and !C_CE signals. See the discussion on hard and soft resets, below. HS_CLK is a 13.188 MHz output from the Genesis. You tell _me_ what it's for! Not used by the ROM. VIDEO is an output which appears to be some sort of (non-NTSC?) video signal. I guess this goes with VSYNC and HSYNC, but I haven't tried to look at it. VSYNC is a 60 Hz output - possibly the vertical sync signal for VIDEO. HSYNC is a 16.240 KHz output - possibly the horizontal sync signal for VIDEO. This isn't NTSC... What is it? EGA? There are four signals I haven't got a clue on: B1: Goes through capacitor and resistor to IC12 pin 2. B3: Goes through capacitor and resistor to IC12 pin 8. B21: This is a strange one. When the processor is halted, this signal pulses at 60 KHz. When the processor is running, its rate varies. Hmmm.... B31: This is an output, but it's always high and I've not seen it go low. I know it's not an input because it sources too much current; it's not a 5V supply because it doesn't source enough. There is no R/!W line, as it's built into !UDSW and !LDSW signals. There are no !BR, !BG, or !BGACK signals at the cartridge port. The cartridge port pins are numbered A1-A32 and B1-B32, left-to-right, with the A row toward the back of the Genesis and the B row toward the front. The "i" and "o" labels describe whether a signal is an input and/or an output to/from the Genesis. Signals with an "o" are output from the Genesis to the cartridge. Signals with an "i" are input to the Genesis from the cartridge. Pin Signal Pin Signal -------------------------------------- A1 - gnd B1 - ? A2 - +5v B2 i !H_RESET A3 o a8 B3 - ? A4 o a11 B4 o a9 A5 o a7 B5 o a10 A6 o a12 B6 o a18 A7 o a6 B7 o a19 A8 o a13 B8 o a20 A9 o a5 B9 o a21 A10 o a14 B10 o a22 A11 o a4 B11 o a23 A12 o a15 B12 o VIDEO A13 o a3 B13 o VSYNC A14 o a16 B14 o HSYNC A15 o a2 B15 o HS_CLK A16 o a17 B16 o !C_OE A17 o a1 B17 o !C_CE A18 - gnd B18 o !AS A19 io d7 B19 o CLK A20 io d0 B20 i !DTACK A21 io d8 B21 o ? A22 io d6 B22 io d15 A23 io d1 B23 io d14 A24 io d9 B24 io d13 A25 io d5 B25 io d12 A26 io d2 B26 o !LO_MEM A27 io d10 B27 o !RESET A28 io d4 B28 o !LDSW A29 io d3 B29 o !UDSW A30 io d11 B30 i !S_RESET A31 - +5 B31 o ? A32 - gnd B32 i !CART_IN Resets and the OS ROM --------------------- A hard reset, which happens at power-up or when the cartridge port's !H_RESET line is pulled low, enables the Genesis' internal "OS" ROM. This is responsible for checking for a "valid" (i.e., does it say "SEGA" at location $000100?) cartridge, presenting the "Produced by or licensed from Sega Enterprises, ltd." message, enabling the cartridge ROM, and jumping to the cartridge's entry point. This only happens if the !CART_IN signal is pulled low; if not, the internal ROM (and cartridge ROM) is disabled, the 68000 sees invalid instructions, and eventually puts its heels up and dies. A system with a CD may behave differently, but I don't have one, so I don't know. A soft reset, which happens when you press the reset button or pull the cartridge port's !S_RESET line low, causes a 68000 reset: the processor fetches an initial stack pointer from locations $000000-$000003, and jumps to the initial PC specified by locations $000004-$000007. This will be the entry point of the cartridge ROM, if it's enabled, or the entry point of the OS ROM if the processor is reset before the OS ROM is finished doing its business. The Memory Map -------------- $000000 $3fffff Cartridge ROM, when enabled by cartridge control register and !CART_IN. $000000 $0007ff Internal OS ROM, when enabled by cartridge control register and !CART_IN. $ff0000 $ffffff 64Kbytes scratchpad RAM Partially decoded; RAM actually appears repeated between $e00000 through $ffffff. $a14101 cartridge control register bit 0 = 0: cartridge disabled, OS ROM enabled bit 0 = 1: cartridge enabled, OS ROM disabled $a00000 $a????? Unknown. Audio? Controller I/O? $c00000 $c????? Video display controller registers The OS puts the top of its stack at $ffff00, and defines a "user stack pointer" at $000000 (building down through the top of RAM memory). The Z80 processor (used for sound? controller i/o?) uses 8Kbytes of RAM. I don't know anything about how the Z80 does its work, as I haven't looked. Major parts ----------- I don't know what some of these are, as I'm working off a 1988 IC Master and a couple of data books. If anyone has better information, I'd love to have it. IC1 Hitachi HD68HC000P8 - Motorola 68000-compatible CMOS microprocessor, clock: 7.67 MHz IC2, IC3 Motorola MCM51L832 - 32K x 8-bit pseudo-static RAM for 68000 IC4 Sega 315-5433 - glue chip ? - 160 pins On older systems, this is a Sega 315-5364. IC5 No such beast on newer systems. On older systems, this is an 80 pin chip, labelled Sega 315-5309. IC6 NEC D780C-1 - Zilog Z80-compatible microprocessor IC7 Samsung KM6264BLS - 8K x 8 static RAM (used by the Z80) IC8 Sega 315-5313A-01 - glue chip? - 128 pins IC9, IC10 Hitachi HM53461ZP - 64K x 4 bit dual-port video RAM IC11 Yamaha YM2612 - Sound chip? IC12 Sony CXA1034P - Timer? Op-amp? IC13 Sony CXA1145P - RGB to Composite Video encoder. IC14 LM358 - Dual op-amp. Used for sound? OSC1 53.6931 MHz crystal oscillator. Divided by 7 to get the 68000 clock frequency, and used elsewhere for video, sound, Z80 clock, etc. Printed Circuit Board My Genesis circuit board is labelled "IC BD M5 USA". An older (and presumably PAL) system which has an IC5 and a different IC4 is labelled "IC BD M5 PAL". There is no explicit OS ROM chip, nor is there a ROM chip for the Z80. My guess is that these "ROMs" are part of one or both of the glue chips, IC4 and IC8 (and IC5 on older systems). System Revisions ---------------- I'm aware of at least two revisions of the Genesis. Earlier models may not have had an OS ROM, so some of the above discussion is probably not valid. Specifically: o There is probably no Cartridge Control Register. o Hard and soft resets might be one-and-the-same. I don't know about the cartridge pins used for these signals. o Any cartridge - not just those with "SEGA" in the right place - will work (maybe). o The parts in the box are different. IC5 is present, and IC4 is different. How can you tell new and old ones apart without opening it up? I think that older ones don't give a "Produced..." message on power-up with a Sega-produced/licensed cartridge. I'd like to get more complete info on this. If you happen to open your Genesis, I'd appreciate it if you'd compare it the information above and let me know if there are any differences. One poster on netnews mentioned a "Type III" Genesis. Does anyone know anything about this? The Joystick Ports ------------------ Info on the joystick ports can be found in the file "pub/sega/joystick.txt" on ftp.spd.louisville.edu. See acknowledgements below. The Game Genie -------------- The Game Genie sits between the cartridge port and the cartridge. It watches the address bus during read accesses to the cartridge ROM, and substitutes its own data/instructions according to the Game Genie codes you've entered. Game Genie codes are nothing more than encoded address and data. More information on the encoding scheme, and a C program which decodes Game Genie codes can be found in "pub/sega/game_genie.txt" and "pub/sega/decoder.c". See acknowledgements below. Acknowledgements ---------------- Thanks to: d91jn@efd.lth.se (Tore Nestenius) for info on older Genesis systems. lewism@rpi.edu (Michael Lewis) for info on the Sony CXA1145 and Samsung KM6264 chips. crs@crs-sys.uucp (Chris Gregors) for posting a version of the Genesis cartridge port pinouts. nhowland@matt.ksu.ksu.edu (Neal Howland) for information on the Joystick port. merlyn@digibd.com (Brian Westley) for Game Genie information and decoder program. sega/docs/index.html0000755000000000000000000000454211277647701011634 0ustar Index of /docs

Index of /docs

Last Updated: Wednesday, September 3rd, 2003

File name Size Last update Description
[..]<DIR>9/3/2003, 19:45Parent directory
copyrfaq.txt15,39410/12/1995, 0:0
emu-mech.txt10233910/12/1995, 0:0
ggenie.txt4,76010/12/1995, 0:0
hardware.txt16,18210/12/1995, 0:0
joystick.txt5,15910/12/1995, 0:0
rgbcable.txt68010/12/1995, 0:0
sega-rgb.txt2,15110/12/1995, 0:0
sega8pin.txt36010/12/1995, 0:0
segafaq.doc48,87510/12/1995, 0:0
switch.txt3,14010/12/1995, 0:0

There are 10 files and 1 directories
for a total of 199040 bytes. sega/docs/joystick.txt0000755000000000000000000001204711266515006012224 0ustar Date: Tue, 2 Mar 93 08:10:28 CST From: nhowland@centurion.ksu.ksu.edu (Neal Patrick Howland) To: sysrick@starbase.spd.louisville.edu Subject: Genesis joystick pinouts Yes folks! It is the much requested Gensis joystick pinout information!!! First some background info: The chip inside the controller is a 74HC157. This is a high-speed cmos quad 2-line to 1-line multiplexer. Basically how this works is there are two inputs ( A and B ) for every output ( Y ). There are four groups like this. There is one select signal for the whole chip. When the select signal is low, the output ( Y ) is the same as input A. When the select signal is high, the output Y is the same as input B. The pinout for the chip is as follows: Pin 1 - Select Pin 16 - Vcc (+5V) Pin 2 - 1A Pin 15 - G (? must be low) Pin 3 - 1B Pin 14 - 4A Pin 4 - 1Y Pin 13 - 4B Pin 5 - 2A Pin 12 - 4Y Pin 6 - 2B Pin 11 - 3A Pin 7 - 2Y Pin 10 - 3B Pin 8 - Gnd Pin 9 - 3Y All the controls are done with switches. Up is a switch, Down is a switch, etc. Now, I will be refering to the output of these switches later on. What I mean is that the output is usually high, that is when the switch isn't pressed. When the button is pushed, the output goes low. This is accomplished by connecting the output to +5V through a 10k resistor. The button is then attached between the output and ground. It looks like this: +5V -----/\/\/------+--------- Output 10k | | / | Ground -----/ -------+ button (normally open) For all of those who could actually decipher the above schematic, congratulations! I will now run down what lines from the plug are connected to what. The line numbers are determined as follows, looking straight at the plug on the front of the Genesis the numbers are: 1 2 3 4 5 6 7 8 9 (For those of you who buy a joystick cable from radio shack the pin #'s to wire colors are as follows: 1-black 2-brown 3-red 4-orange 5-get cup from bag sorry about that, lets start again 1-white 2-blue 3-green 4-brown 5-yellow 6-orange 7-red 8-black 9-gray, ) anyway, line connections: Line 1 - Up output Line 2 - Down output These are the only two direct connections Line 3 - Pin 4 of the chip output 1Y Line 4 - Pin 7 of the chip ouput 2Y Line 5 - This line carries in +5V. It is connected to the +5V bus line. Line 6 - Pin 9 of the chip output 3Y line 7 - Pin 1 of the chip this carries in a select signal from the Genesis. This is a signal which varies rapidly and controls which input goes through the ouput Line 8 - Ground This is connected to the Ground bus line. Line 9 - Pin 12 of the chip output 4Y Now for the chips pin connections: Pin 1 - Line 7 (select) Pin 2 - Ground (1A) don't ask me why they do this. Maybe future expansion Pin 3 - Left (1B) Pin 4 - Line 3 (1Y) Pin 5 - Ground (2A) again, possibly future expansion Pin 6 - Right (2B) Pin 7 - Line 4 (2Y) Pin 8 - Ground (GND) Pin 9 - Line 6 (3Y) Pin 10 - Button B (3B) Pin 11 - Button A (3A) Pin 12 - Line 9 (4Y) Pin 13 - Button C (4B) Pin 14 - Start (4A) Pin 15 - Ground (G) This must be connected to ground Pin 16 - +5V (Vcc) Power source for the chip Anyway thats all the info needed to build your own joystick. Now as an added bonus, additional indormation! A simple source for a joystick cable is the Radio Shack joystick extension cable. It is around $5 and is 10 ft. long. Just snip off the connector that won't plug into the Genesis, strip the wires back, and use the color pinout list I gave above. I went to my local arcade game repair company today and purchased the supplies I needed. They were much cheaper than I expected. Things you would need to buy from them would be: an 8-way joystick this ran me $15 3 buttons $2.50 apeice I only bought three buttons because I am going to use a Radio Shack push button switch for my sart button. You can purchase 4 arcade game buttons if you wish. Interesting ideas for extras on the joystick: 1. Autofire can be acheived with a simple 555 timer circuit. For anyone wanting a challenge it should be possible to build a digital autofire using a divide-by-n counter with the select signal as clock input. 2. Slow down mode is just autofire for the start button. For anyone looking for an easy way out, buy a cheap joystick or pad with the features you want, tear into the pad and steal the circuit board and the cable. The complicated part will be attaching wires between the new joystick and buttons and the correct spot on the circuit board. This method may even be cheaper than buying electronics parts and building from scratch depending on how expensive the control pad that you buy is. Anyway, that should be enough to at least get you guys started. Let the net know how these homebuilt joysticks are performing. I hope to have mine working within a couple weeks. Neal Howland nhowland@matt.ksu.ksu.edu sega/docs/rgbcable.txt0000755000000000000000000000125011266515007012121 0ustar Newsgroups: rec.games.video.sega Subject: Re: RGB Cable for Genesis? Followup-To: rec.games.video.sega,rec.games.video.misc In article <1993Nov15.202619.6735@mmm.mmm.com>, smcarey@hesdmail.mmm.com. (Sean Carey) wrote: > I noticed in the r.g.v FAQ that a genesis can be hooked up to an RGB > monitor. Before I build a cable for this, I was wondering if anyone > has done this before/has any advice, or knows where one can be > purchased? Can the +5v/ground signals be ignored? Anything I should > watch out for? > > Thanks alot! > Genesis RGB cables can be purchased from Redmond Cable, (206)882-2009. As of a year ago, their prices were $30-60, depending upon monitor. sega/docs/sega-rgb.txt0000755000000000000000000000414711266515010012051 0ustar From: dgb@owlnet.rice.edu (Dennis Gale Brown) Newsgroups: rec.games.video.sega This is an article I wrote last year to post here. I'm posting it again. This is probably not the best way to hook up the Genesis to a monitor but it works. I have no clue what the "new" Genesis is like, so this may or may not work with it. ------------------------------------------------------------------------------- Here's how I hooked up my Genesis to my NEC Multisync II: First, I went to Radio Shack and bought the following parts: 274-026 8-pin DIN plug (Genesis end) 276-1427 9 Position D-shell MALE connector 276-1513 Hood for above 278-775 9-conductor wire (sold by the foot; I got 3') Then I checked out the Genesis Monitor pinout from the FAQ: (looking at port itself) 1 . 8 . 7 2 . . . 6 3 . . 5 4 ' (these numbers probably aren't correct but they match my list below!): 1 - Negative Combined Sync 2 - Composite Video 3 - Green 4 - Ground 5 - +5 Volts 6 - Audio 7 - Red 8 - Green Then I checked out the pinout for the Multisync: 1 2 3 4 5 . . . . . . . . . 6 7 8 9 2 - Sync 3 - Blue (analog) 4 - Green (analog) 5 - Red (analog) 6 - Ground (again, numbers are probably wrong, and this isn't the full pin-out, but it's enough) After this, it's just a matter of putting things together. Using the 8-pin DIN connector requires some soldering, but the 9-pin connector I chose can simply have the pins clamped onto the wires. One note: You may have to bend the pins in the 8-pin connector slightly to make it fit in the Genesis. I had to bend the middle pin down a bit and the two top pins outward. After that, no problem. Final word: Do this at your own risk. This probably isn't the best way to go about this, but it does work. If your equipment blows up, don't blame me! Have fun... BTW, If you have a different monitor, I can't help you. All I can say is that if it works with an Amiga 500/1000/2000, it probably works with the Genesis (similar if not identical scan rates), provided you have the correct pinouts and connectors... sega/docs/sega8pin.txt0000755000000000000000000000055011266515010012072 0ustar From: QUINNGRANFOR@delphi.com Newsgroups: rec.games.video.sega The pin configuration is as follows.... Match pin----------O Red-------------O O----Negative sync O---Blue Audio(mono)-O O---Composite Video Vcc +5 volts---O O---Green Ground--O The O's are the pins...hope this helps. Quinn Granfor sega/docs/segafaq.doc0000755000000000000000000013735311266515012011727 0ustar Sega Programming FAQ July 4, 1994, Fifth Edition ---- Happy Birthday America ============================================================= This FAQ (Frequently Asked Questions) is about how to program the Sega Genesis and Mega Drive Video Games Systems. This file IS Public Domain, and can be used by all. You may copy and post this file elsewhere. Share and enjoy. If you want to add anything, especially game code or information on the hardware please E-mail me. My E-mail and real address are below and at the end of this FAQ. Disclaimer : In no way I am indorsing any products, systems, etc. What I am doing is providing the information that I have found throughout internet and other network systems and reporting them here, with out reverse engineering. All information is reported as is- I will not accept any responsibility if you fry your system trying something out. All copyrights are owned by their respective owners, no infringements intended. Henry Rieke US Mail: Henry Rieke Attn: Sega FAQ 161 Poplar Dr Morgantown, Wv 26505-2340 ============================================================= 0.1 Changes, Updates and Coming Soon 1) Coding for the four player tap from Electonic Arts has been added. Does anyone have the code for the multi-tap from Sega, and how it works? 2) I have sent out the letters soon a few months ago to all the companies on the list (US only) (See Chapter 3.0, Companies) asking for more information concerning their products, and details. Only Sierra Products bothered to return the call. Nice people, and I do have their information pack, which time willing, I will add. Sierra was at the time considering to support the 32-X (Mars) and the Saturn systems from Sega. Sega put me on a mailing list for information junk mail. Go figure. 3) I am now beginning to work on a topic header on languages that you can program in for the Sega and Sega CD ROM. If you have any direct information (compiler, how to compile, etc) let me know so I can include it. 4) More code has been added, but it is only a sample. Because of the size (5+ pages and growing) I have deciede to create a second file called code.txt which can be found where I have posted this file. 5) Listing of all the addresses that Sega has on the Internet. These are one-way only, so we can not look in, but they can look out (read: Firewall). ============================================================= 1.0 Questions Q) What are the differences between Mega Drive and Genesis? What are the differences between Mega CD and Sega CD? A) Physically, on the outside, the only difference is the plastic case, the cartridge shape is slightly different on the American version, smaller in size. On the inside there are four jumpers labeled J1 though J4. J1 and J2 is the language switch, between English and Japanese, J3 and J4 select the output between PAL and NTSC. You can build a switch that can allow you to select between these options. The diagram is included in this document (Chapter 5.0, called "Language Switch"). The reason for the language switch is to keep people from getting the game before it is officially released elsewhere in the world. The newer Sega Machines do not have the jumpers, and hence you can not build a switch (as of yet). The difference between Mega CD and Sega CD are internal. In side the machine there is a ROM BIOS chip which is changed for different markets. Sega has a version of the BIOS which will play any system's games, but this is for Game developing and testing. There is a device called Pro-CDX which will allow you to by-pass the lockout and play any country's games. Q) Where to find files on the Sega Genesis/Mega Drive hardware? A) You can find the files on the Sega hardware from one of the following FTP sites. A brief section describing memory and cartridge ROMs are included in this FAQ. The author Rick McTeague, is from Louisville and the most current copy can be found there first. FTP ftp.spd.louisville.edu pub\sega\hardware.txt FTP busop.cit.wayne.edu pub\megadev\incoming\hardware.txt There are also many other files here as well as a few 68000 ASM. Q) What does it take to program the Genesis? A) Development kits can be bought from many companies, a list is included in the section called "Companies". These kits require an IBM or Amiga computer to compile the code, which is usually assembly, but can be in C as long as it can be compiled into 68000 binary. SEGA's own kit is extremely expensive and they are rumored to have slow response time to answer questions. The price of the kits cost from $1000 to $4000. Q) Is IBM or Amiga the only two platforms for game development? A) No. The Apple Macintosh does have a system, which does allow you to compile games, but it is a do-it yourself job (See below for the whole scope). There also is a system for the Apple IIgs, called Sluggo from Parsons Engineering. As for the Mac, if you know, please pass it on. It is rumored that Electronic Arts uses a priority system on the Macintosh for porting the games. -- This information comes from Landon Dyer , -- You can generate 68K code for the Sega "trivially" with the C compiler and assembler in the Macintosh programmer's workshop (MPW). You'll need to hack up some transfer utilities, but this is not really hard. You can wire-wrap a ROMulator, or buy one; there are a bunch on the market that should work just fine. I had a ROMulator and a debugger up and running in about a week, working evenings. (Ed note: ROMular information can be found at the FTP sites) Q) How do I program the SEGA CD Rom? A) I am beginning to understand how to program this device, but more information is needed, so if you have any, please pass it along to me so I can include it in the next update. Look under Hardware 2.1, Sega CD for more information about the unit. Q) What is Saturn, and how do I program that? A) Saturn is Sega's next generation game machine, which is based on Sega's S-1 /S-2 arcade Machine's motherboard. Rumor has it that it will allow programming in C as well as Assembly, and porting of arcade games that are based on the S-1 and S-2 boards will take only a week. There is good news and bad news as well. Good news, Microsoft will be writing the OS. Bad new, Microsoft will be writing the OS. Q) What else is there on Internet? A) Well there is the Sega Programming forum, which you can join by subscribing to it with this command: Send a message to Listserv@Busop.Cit.Wayne.Edu with the first line reading SUBSCRIBE MEGADEV To unsubscribe, do the same above, except the first line should read UNSUBSCRIBE MEGADEV There is also Rec.Games.Video.Programmer and Rec.Games.Video.Sega where you can ask your questions. There are also files on how to use the old SEGA 3D glasses with your IBM compatible computer which can be found all over the place (including the above FTP sites). ============================================================= 2.0 Hardware : This is the inner workings of the Sega system ROM and Memory. For a better understanding Sega Hardware I suggest reading Hardware.txt. An up-to-date version of this file can be gotten by anonymous ftp from Ftp.spd.louisville.edu, in the file "Pub/sega/Hardware.txt". Genesis - this information comes from Rick McTeague. Sega Genesis Hardware Internals - Revised: 04/07/1993 Please send corrections or comments to: Rick McTeague Sysrick@starbase.spd.louisville.edu Disclaimers: The following information was extracted without the use of official information from Sega Enterprises, Ltd. I therefore offer no warranty on the correctness of this information. Use it at your own risk. This information was gathered as a personal project, and is not the responsibility of my employer. Different versions of the Genesis exist, so I won't suggest that any of this information is right for anybody's Genesis but my own. Sega, Genesis, Sonic the Hedgehog, and Ecco the Dolphin are trademarks of Sega Enterprises, Ltd. Other trademarks are the property of their respective companies. The Cartridge ROM ----------------- As others on the net have observed, a standard Genesis cartridge is nothing more than a small printed circuit board with a ROM on it. There are some cartridges which have battery-backed RAM for saving high scores, configurations, etc., but I haven't seen these, so I don't know about them. If you know of a particular cartridge that has RAM, let me know so I can go rent one and take it apart (shhhh!) to see what's in it. A cartridge contains a word-wide (16 bit) ROM with up to 2 Meg words (4 Mbytes). This is based on the signal !C_CE, which is used as the cartridge ROM's chip enable on the cartridges I've looked at, and which is active at addresses $000000-$3fffff. It may be possible to have more than 4 Mbyte cartridges; if so, either they ignore the !C_CE line and do their own address decoding, or there's a register somewhere in the Genesis which changes the default address decoding scheme for !_CE. Note that cartridges are advertised as being "8 Meg"; as far as I know, is 8 Meg _bits_, not bytes. 1 Mbyte is still pretty impressive for a game machine. SONIC uses a 40-pin 256Kx16 (512Kx8) ROM in word mode. Ecco the Dolphin uses a 42-pin 512Kx16 (1024Kx8) ROM in word mode. This one confused me because I'd never seen a 42-pin DIP before, so I thought it was 40 pins. No wonder the signals didn't look right... Putting together a little bit of information from a Sharp data sheet for a 512 Kword ROM with a bit of conjecture based on the Sonic and Ecco cartridges, this is what I can come up with for pinouts: Sonic Ecco (256 Kword) (512 Kword) ----u---- ----u---- A18 1=| |=42 VCC? A17 1=| |=40 A 8 A17 2=| |=41 A 8 A 7 2=| |=39 A 9 A 7 3=| |=40 A 9 A 6 3=| |=38 A10 A 6 4=| |=39 A10 A 5 4=| |=37 A11 A 5 5=| |=38 A11 A 4 5=| |=36 A12 A 4 6=| |=37 A12 A 3 6=| |=35 A13 A 3 7=| |=36 A13 A 2 7=| |=34 A14 A 2 8=| |=35 A14 A 1 8=| |=33 A15 A 1 9=| |=34 A15 A 0 9=| |=32 A16 A 0 10=| |=33 A16 !CE 10=| |=31 !BYTE !CE 11=| |=32 !BYTE GND 11=| |=30 GND GND 12=| |=31 GND !OE 12=| |=29 D15 !OE 13=| |=30 D15 D 0 13=| |=28 D 7 D 0 14=| |=29 D 7 D 8 14=| |=27 D14 D 8 15=| |=28 D14 D 1 15=| |=26 D 6 D 1 16=| |=27 D 6 D 9 16=| |=25 D13 D 9 17=| |=26 D13 D 2 17=| |=24 D 5 D 2 18=| |=25 D 5 D10 18=| |=23 D12 D10 19=| |=24 D12 D 3 19=| |=22 D 4 D 3 20=| |=23 D 4 D11 20=| |=21 VCC D11 21=| |=22 VCC --------- --------- Note that the address line numbering is different than that of the 68000; line A0 of the ROM is really connected to the 68000's A1. This is because of the way the 68000 handles even/odd byte addressing using !UDS and !LDS. The !BYTE line is held high. This puts the ROM chip into "word" mode, where data is accessed 16 bits at a time. The convenient correspondence between ROM and 68000 data and address lines (ROM D0 = 68K D0, ROM D1 = 68K D1, etc..., and ROM A0 = 68K A1, ROM A1 = 68K A2, etc...) may not exist in all cartridge designs. This is sometimes difficult to visualize, but keep in mind that the ROM doesn't care whether its D0 is really D0, or if its A3 is really A3, etc. As long as each data line is used as the same D## line for both programming and reading, and each address line is used as the same A## for both programming and reading, the ROM will function properly and the 68000 will see the right instructions. Think about it... Why bring this up? If you remove the ROM from the cartridge PCB and try to read it with a EPROM programmer, there may be situations where you won't see valid 68000 instructions, or things won't be in the right place... Assuming your programmer isn't messed up, this would be because the address and data lines on the ROM aren't assigned the way you'd expect. Why would someone make a cartridge like this? To make your life difficult, if you're wanting to hack their ROMs, or to make their life easy, by making the cartridge PCB easier to design. The easiest way to avoid this potential problem is to build an adapter from your programmer's EPROM socket to an edge card connector into which you plug the cartridge. This is a bit safer, too, so you don't have to remove the ROM from the cartridge (or even open it up). The Memory Map -------------- $000000 $3fffff Cartridge ROM, when enabled by cartridge control register and !CART_IN. $000000 $0007ff Internal OS ROM, when enabled by cartridge control register and !CART_IN. $ff0000 $ffffff 64Kbytes scratchpad RAM Partially decoded; RAM actually appears repeated between $e00000 through $ffffff. $a14101 cartridge control register bit 0 = 0: cartridge disabled, OS ROM enabled bit 0 = 1: cartridge enabled, OS ROM disabled $a00000 $a????? Unknown. Audio? Controller I/O? $c00000 $c????? Video display controller registers The OS puts the top of its stack at $ffff00, and defines a "user stack pointer" at $000000 (building down through the top of RAM memory). The Z80 processor is used for sound and has 8Kbytes of RAM. I don't know anything about how the Z80 does its work, as I haven't looked. Acknowledgements ---------------- Thanks to: dt93tn@pt.hk-r.se (Tore Nestenius) for info on older Genesis systems. lewism@rpi.edu (Michael Lewis) for info on the Sony CXA1145 and Samsung KM6264 chips. crs@crs-sys.uucp (Chris Gregors) for posting a version of the Genesis cartridge port pinouts. merlyn@digibd.com (Brian Westley) for Game Genie information and decoder program. ------------------------------------------------------------ Brief technical description of the Genesis: --- The genesis graphics hardware consists of 2 scrollable planes. Each plane is made up of tiles. Each tile is an 8x8 pixel square with 4 bits per pixel. Each pixel can thus have 16 colors. Each tile can use 1 of 4 color tables, so on screen you can get 64 colors at once, but only 16 in any specific tile. Tiles require 32 bytes. There is 64K of graphics memory. This would allow for 2048 unique tiles if memory were used for nothing else. Each plane can be scrolled independently in various ways. Planes consist of tables of words, where each word describes a tile. The word contains 11 bits for describing which tile, 2 bits for flip x and flip y, 2 bits for the selection of the color table, and 1 bit for a depth selector. Sprites are composed of tiles also. A sprite can be up to 4 tiles wide by four tiles high. Since each tile is 8x8, this means sprites can be anywhere from 8x8 pixels to 32x32 pixels. There can be 80 sprites on screen at one time. On a scan line you can have 10 32 pixel wide sprites or 20 16 pixel wide sprites. Each sprite can only have 16 colors but they are out of the 4 different color tables. Color 0=transparent. Colors are 3 bits for each gun, so 512 colors are possible. There is a memory copier that is in hardware. This does fast copies from the 68000 ram into the graphics ram. The 68000 runs at about 8 mhz. It has 64K of memory devoted to it. The ROM cartridge appears at 0. The Z80 has 8K of ram. The 68000 can download programs to the z80 and let them go. The z80 can access the graphics chips or the sound synth chips but usually those things are controlled by the 68000. The sound chips consist of a Yamaha synthesis chip and a TI programmable sound generator. The PSG has 3 square wave tones and 1 white noise tone. Each tone/noise channel can have its own frequency and volume. The Yamaha chips are based on FM synthesis. There are 6 voices with 4 operators each. The chips are similiar to those used in the Yamaha DX27 and DX100 synthesizers. By setting up registers a rich variety of sounds can be created. ------------------------------------------------------------ 2.1 Sega CD Rom. The following information came from Leyland@island.COM (Robert Leyland), who was a programmer for the most excellent Sega CD Rom game - Flying Aces. (Plug!Plug! Plug!Plug!Plug!Plug!) -- The Sega CD is ISO 9660 format, with proprietary start-up code that must be licensed from SEGA in order to work. For programming you use two PC's, one connected to a debugging system and the other emulated an CD-ROM drive. The trickiest part of programming the Sega CD/Genesis combo is keeping the two CPU's synchronized. For some reason the single hardest thing to do with any computer is get it to talk reliably with another computer. -- ------------------------------------------------------------ 2.2 Joystick - 3 button version - Could some please post a 6 button version? By: nhowland@matt.ksu.ksu.edu (Neal Howland) for information on the Joystick port. First some background info: The chip inside the controller is a 74HC157. This is a high-speed cmos quad 2-line to 1-line multiplexer. Basically how this works is there are two inputs ( A and B ) for every output ( Y ). There are four groups like this. There is one select signal for the whole chip. When the select signal is low, the output ( Y ) is the same as input A. When the select signal is high, the output Y is the same as input B. The pinout for the chip is as follows: Pin 1 - SelectPin 16 - Vcc (+5V) Pin 2 - 1APin 15 - G (? must be low) Pin 3 - 1BPin 14 - 4A Pin 4 - 1YPin 13 - 4B Pin 5 - 2APin 12 - 4Y Pin 6 - 2BPin 11 - 3A Pin 7 - 2YPin 10 - 3B Pin 8 - GndPin 9 - 3Y All the controls are done with switches. Up is a switch, Down is a switch, etc. Now, I will be referring to the output of these switches later on. What I mean is that the output is usually high, that is when the switch isn't pressed. When the button is pushed, the output goes low. This is accomplished by connecting the output to +5V through a 10k resistor. The button is then attached between the output and ground. It looks like this: +5V -----/\/\/------+--------- Output 10k | | / | Ground -----/ -------+ button (normally open) For all of those who could actually decipher the above schematic, congratulations! I will now run down what lines from the plug are connected to what. The line numbers are determined as follows, looking straight at the plug on the front of the Genesis the numbers are: 1 2 3 4 5 6 7 8 9 (For those of you who buy a joystick cable from radio shack the pin #'s to wire colors are as follows: 1-white 2-blue 3-green 4-brown 5-yellow 6-orange 7-red 8-black 9-gray ) anyway, line connections: Line 1 - Up output These are the only two direct Line 2 - Down output connections Line 3 - Pin 4 of the chip output 1Y Line 4 - Pin 7 of the chip output 2Y Line 5 - This line carries in +5V. It is connected to the +5V bus line. Line 6 - Pin 9 of the chip output 3Y line 7 - Pin 1 of the chip this carries in a select signal from the Genesis. This is a signal which varies rapidly and controls which input goes through the output. Line 8 - Ground This is connected to the Ground bus line. Line 9 - Pin 12 of the chip output 4Y Now for the chips pin connections: Pin 1 - Line 7 (select) Pin 2 - Ground (1A) Don't ask me why they do this. Maybe Pin 3 - Left (1B) future expansion Pin 4 - Line 3 (1Y) Pin 5 - Ground (2A) Again, possibly future expansion Pin 6 - Right (2B) Pin 7 - Line 4 (2Y) Pin 8 - Ground (GND) Pin 9 - Line 6 (3Y) Pin 10 - Button B (3B) Pin 11 - Button A (3A) Pin 12 - Line 9 (4Y) Pin 13 - Button C (4B) Pin 14 - Start (4A) Pin 15 - Ground (G) This must be connected to ground Pin 16 - +5V (Vcc) Power source for the chip Anyway that's all the info needed to build your own joystick. Now as an added bonus, additional information! A simple source for a joystick cable is the Radio Shack joystick extension cable. It is around $5 and is 10 ft. long. Just snip off the connector that won't plug into the Genesis, strip the wires back, and use the color pinout list I gave above. I went to my local arcade game repair company today and purchased the supplies I needed. They were much cheaper than I expected. Things you would need to buy from them would be: an 8-way joystick this ran me $15 3 buttons $2.50 apiece I only bought three buttons because I am going to use a Radio Shack push button switch for my start button. You can purchase 4 arcade game buttons if you wish. Interesting ideas for extras on the joystick: 1. Autofire can be achieved with a simple 555 timer circuit. For anyone wanting a challenge it should be possible to build a digital autofire using a divide-by-n counter with the select signal as clock input. 2. Slow down mode is just autofire for the start button. ============================================================= 3.0 Companies - these companies produce the hardware that is required to write games for the Genesis. The original document came from: Scott Golby Hi Everyone, Here is the current list of info I have about the Sega. I have had about 10 replies so far asking to pass my info on. If people want I will pass their EMail address on to everyone else so we can work as a group. Drop me a line if you want to be added to the 'group' list. ***** <----- Five astrict like this means info from different people Sega Genesis Developer Resources Dan Chang April 18, 1993 Sega of America Inc Consumer Products Division 125 Shoreway Road San Carlos, California, 94070 Tel : (415) 802-4400 Fax : (415) 802-4458 Stuart Kosoy is the person to contact at Sega of America at (415)802-4407. Products : Detailed SEGA Genesis technical information. GEMS SEGA music development package. Solution : Music and Sound effects package for the Sega. SOA can provide detailed information on programming the Genesis; however they will want to know more about your company first. Western Technologies, Inc. 12057 Jefferson Blvd Culver City, California, 90230 Tel : (310) 821-7880 Fax : (310) 306-1739 Products : SegaDev Card. PC-Hosted Genesis development hardware, which includes SEGADEV.EXE, a Windows-hosted source-level debugger, and SEGALOAD.EXE, a PC_hosted 68000 object code downloader. Solutions : SEGA Genesis Hardware, WT recommends Sierra Systems 68000 Assembler. Sierra Systems 6728 Evergreen Ave Oakland California 94611 Tel : (510) 339-8200 or (800) 776 4888 Fax : (510) 339 3844 Products : PC-hosted Sierra C cross-compiler, which included 68000 C compiler, assembler, linker. Contact person at Sierra Systems is Larry Rosenthal E-Mail Sierra@netcom.com Motorola, Literature Dist This entry basically has a list of 68000 reference and programming books. Echidna 1101 W Stevens Ave, Suite 232 Santa Ana California 92707 Tel : (714) 545-2662 Fax : (714) 545-3705 Products : tUME - the Universal Map Editor. PC-Hosted tool to edit tile-maps. Solutions : Saves time in designing game maps and placing level information. Downloads maps to Western Techs SegaDev card. A tUME demo can be found by FTP busop.cit.wanye.edu under /pub/megadev/incoming/tumedemo.zip Well worth a look. Cross Products Limited 23 The Calls Leeds LS2 7EH, England Tel 0532 429814 Fax 0532 426163 (dial 011 44 532 426163 from USA) Product : SNASM68K : PC-Hosted SEGA Genesis development system, which includes a 68000 assembler, linker, debugger. Parsons Engineering Imhurst Ave Covina California 91724 Tel (818) 966 5538 Products : PC/Apple IIgs hosted Sluggo Genesis development hardware. Advantech 1333 E.9400 South, Suite 160 Sandy Utah, 84092 Tel : (801) 572-5410 Fax : (810) 572-5674 Products : blank SEGA Genesis cartridge PC boards, blank EPROMS. ***** Genesis Development System Frequently Asked Questions Q:What is the Genesis Development System? A:The GDS is a cross development system that lets you develop games and other software to run on the Sega Genesis. The system consists of a 4 inch by 8 inch printed circuit board that plugs in the cartridge slot of the Genesis, and has a cable going to the parallel port of the host computer. A complete software set is included consisting of an integrated editor/assembler, a stand alone assembler, a symbolic debugger, a music and sound effect editor, a utility to break standard 16 color IFF images into tiles to be downloaded to the Sega, a utility to capture screen graphics on the Genesis, a utility to send an LBM image to the Genesis for preview, a linker for joining multiple object modules, and several example files. Q:Does it come with any source files? A:You get source to the music editor, source to a Z80 program to run on the genesis to interpret the music files, source to a demo program that plays music and has sprites bouncing around behind the Sega logo, source to the download utilities. Complete source is provided on communicating between the host machine and the Genesis. Q:How much memory does it have on the board? A:It comes with 2.25 or 4.25 megabytes of memory. Older versions had 1.25 megabytes. 256K is reserved for use by the debugger for variable storage and symbols. Q:Can you program CD games with it? A:It is not specifically designed for a CD. You could program as if you're creating a cartridge then modify the code later to make it work on the CD. I provide no information on the Genesis CDROM drive. I don't own one myself. The Genesis CDROM market is perhaps 10% of the cartridge market. Q:Does it include technical specifications for the Genesis? A:Yes, it comes with descriptions of the memory map, graphics registers, the Z80's functions, reading the joysticks, sprites, scrolling, tiles, the DMA copier, the audio chips-in short everything required to program the genesis. Also provided are several working demos with source. Q:Is this proprietary information stolen from Sega? A:No, the information on the Genesis came from reverse engineering it, completely independent of Sega. There are no copyright violations in the purchase or sale of this development system, nor is there anything illegal about any use of it. Q:How does it work? A:The board has ROMs on it which contain the monitor and debugger that runs on the Genesis. When the Genesis is reset, the ROMs take over and wait for commands to come from the host machine-commands like download bytes, send bytes back, set up registers, define a symbol, or enter the interactive debugger. When in the interactive debugger the host machine acts as a terminal, and characters are sent over the cable. Full 68000 debugging is possible, including disassembly, single step, register view and modify, breakpoints, expression evaluation, memory view, modify, search and copy, symbol definition, memory compare. There is also a z80 disassembler built in. Q:What about the assembler? A:The assembler is a full macro 68000 assembler, and includes the full 8080 and parts of the Z80 instruction set. It generates symbol table information that can be downloaded to the Genesis to allow for symbolic debugging. On a 66 Mhz DX2 the assembler is about 550,000 lines/minute. There is also a linker which combines multiple object files. Q:Can I program in C? A:There is no C compiler included in the package. In the future there may be. Q:How do I make artwork? Is there a sprite editor? A:Originally I planned on including a simple graphic editor, but I found that no one used it-instead they used Dpaint. The best way is to use dpaint to create graphics in lo-res 16 color mode, then to use the utility I provide to convert them to raw data to be sent to the Sega. Animation can be done within Dpaint. Unfortunately there is no editor for manipulating giant figures made out of sprites, but in principle it would be possible to do. So probably you will use dpaint or some other painting program to create the artwork. A:Can you backup existing cartridges like the game backup systems? Q:The system is intended for game development. However if you were able to obtain ROM images, they can be downloaded just like original code. When running a ROM under the system, you can tinker with memory, modify gameplay, add lives, etc. You can do all the normal debugging functions, like single step, breakpoints, etc, to see how the program is working. In the future (Mid March, 1994) a reader will be available for $100 which will let you read out the contents of your cartridges. Q:How fast are downloads? A:The current board has transfer rates of up to 105K bytes per second. Older versions of the board had a 49K bytes per second transfer rate. Q:What host machines is this available on? A:Currently the complete system is available on the IBM PC. There is also an Amiga version but it has fewer features than the PC version. Q:Why should I buy your system and not go through Sega? A:My system is better and cheaper than those provided by Sega. I sell to anyone. Sega sells only to large companies. I require no non-disclosure statements to be signed. Sega requires you to sign extensive non-disclosure statements, and you essentially have to be subservient to them forever. If you buy my system you immediately have the ability to create software for the Genesis. If you create a game, you can then sell it outrifht or attempt to publish it yourself. You wouldn't have to pay Sega any of their rediculous royalties on each unit, regardless of how well your program sells. Q:How long has this system been available? A:It first became available in April 1991. The 2 and 4 megabyte versions first became available in February, 1994. Q:How many have already been sold? A:I've sold around 30 units so far. Q:How much does it cost? A:For the 4 megabyte version the cost is $1600. For the 2 megabyte version the cost is $1500. For the duration of March, 1994 there is a special introductory price of $1000 for the 2 megabyte version and $1100 for the 4 megabyte version. After March, 1994 the price will be raised by $500. Q:Will it be ported to other platforms? A:There are no plans to port the software to any other platforms. Q:What about technical support? How about software upgrades? A:You can send me email and I will answer questions and help solve your problems. If I'm home you can call me. Concerning software support: I want you to be happy with this. If you want some program written, and it seems like a good idea, chances are I'll do it for free and include it with the system. Currently if the software seems sparse it's because no one has complained so I guess I include enough. There's no point in writing software if it isn't going to be used. In any case software upgrades are free unless it's some major upgrade like including a C compiler-I don't believe in selling something for hundreds of dollars then nickel and diming you on upgrades. EPROM upgrades are free if you send back your originals. Q:Do we need to pay you any royalty on games developed with the system? A:No. Once you bought the system you can do anything you want with it-except copy it and sell it yourself... Q:How can I contact you? A:Send me mail, email or call. 818-584-0357 INTERNET: dash@netcom.com David Ashley 395 Sierra Madre Villa Pasadena, CA 91107 USA ***** ============================================================= 4.0 Code samples. The following code was graciously given to me by David Ashley, inventor of the GDS. We all owe him a big Thanks! Here's sample code for reading the joystick: ------------ ;jsinit must be called to set up the joystick, otherwise reading back will ;have errors. This need only be called once. jsinit: moveq #$40,d0 move.b d0,$a10009 move.b d0,$a1000b move.b d0,$a1000d rts ;The following two routines can be used for reading from the joystick ;ports. ;porta and portb return a byte in d0. 0 bits mean button is not down, ;1 mean button is down. ;The order is: ;76543210 ;SACBRLDU ;meaning Start, A, C, B, Right, Left, Down, Up porta: move.b #$40,$a10003 nop nop move.b $a10003,d1 andi.b #$3f,d1 move.b #$00,$a10003 nop nop move.b $a10003,d0 andi.b #$30,d0 lsl.b #2,d0 or.b d1,d0 not.b d0 rts portb: move.b #$40,$a10005 nop nop move.b $a10005,d1 andi.b #$3f,d1 move.b #$00,$a10005 nop nop move.b $a10005,d0 andi.b #$30,d0 lsl.b #2,d0 or.b d1,d0 not.b d0 rts ----------------------- Graphics code is another matter. Since I sell a development system, and one of the features is I provide technical info on the Genesis hardware, it would sort of be a conflict of interest for me to give things away :^). ----------------------- The whole sample is not inlcuded because of it's size. However you can find the rest of the code, about 5 pages worth, at the same locations as this file. Look for a file called code.txt. These files will always be posted together. dc.l $FFFE00,$D7E,$200,$200,$200 dcb.l $17,$200 dc.l $E9E,$200,$EAE,$200,$20E dcb.l $F,$20E dcb.l $F,$200 dc.b "SEGA MEGA DRIVE (C)SEGA " dc.b "1989.AUG _____",$87,"V " dc.b " " dc.b " ",$87,"V " dc.b " " dc.b " GM 00054010-01",$93,"G" dc.b "JD ",$0,$0,$0,$0,$0,$3,"",$FF dc.b $0,"",$0,$0,$0,"",$FF," " dc.b " " dc.b " " dc.b "JUE " move #$100,$A11100 ============================================================= 4.11 Four Way Player Tap from Electonic Arts. While no code is prodived, here is a hack of sorts. I am honoring the request of anonymity from the sender. The $__ are ports calls by the software to control the hardware (of couse). With the EA 4 way play adapter, all the controllers are read through controller 1's port after sending the selection data out of controller 2's port. The selection data is $0C for controller 1, $1c for controller 2, $2c for controller 3, and $3c for controller 4. The adaptor is detected by setting the registers in the following way. (This is from G______ C____ code, so don't ask me why they did some of this stupid stuff.) $40->CTRL1 $40->CTRL2 $43->CTRL2 (This doesn't make sense... why set it twice?) $7C->DATA2 (This is probably masked off by the $43 above...) $7F->CTRL2 $7C->DATA2 If you read DATA1 and either of the low 2 bits is set, there isn't a 4 tap. You must enable writing to port two after that so that you can select the port. Well this is the view from inside the machine... hope this helps you somewhat. ============================================================= 4.2 Graphics, Color Palette and sprit control ============================================================= 5.0 Language Switch, from Rec.Games.Video FAQ How to make a language switch (Genesis/MD). On a Genesis/MD, there are jumpers labelled JP1, JP2, JP4, and JP3. The Genesis has a capacitor on JP1 and a trace on JP2; the Mega Drive has a capacitor on JP2 and a trace on JP1. The bottom ends of JP1 and JP2 are connected together. So if you cut the trace and the top end of the capacitor, and install a DPDT switch between them which reconnects them either unchanged or swapped left to right, you have a language switch. You'll need some wire, a soldering iron, solder, and a DPDT switch. Some machines have an open circuit instead of the capacitor. Also, I've been told that even if there is a capacitor, you can throw it out and leave an open circuit. Either way, the switch is a lot simpler, requiring a SPDT switch and less wire and solder. Several people have told me that you could just cut both JP1 and JP2 and put a SPST switch on JP1. This is even simpler, but I'm not sure it really works, as opposed to putting your machine in an intermediate state that only sort-of works. The redesigned Genesis 2 machines don't appear to have either the capacitor or circuit. Nobody yet knows how to make the language switch for one, though there are language switch cartridges you can buy to act as one. IF YOUR MACHINE HAS NO CAPACITOR (or if you want to cross your fingers and throw away your capacitor) and is not a Genesis 2: Cut JP2. The trace might be covered with paint and hard to see. (If you started with a Mega Drive, JP2 is open and you have to cut JP1 instead.) If you aren't sure which end I mean by "bottom", just check the back of the board to see which end is connected together. Original state of machine: After cutting: JP2 top JP1 top JP2 top JP1 top | | | | | | | | | | | | | | | | \ / \ / \_______/ \_______/ bottom of both bottom of both Add a SPDT switch which can be in one of two positions: ._ _ _ _ _ _ _ _ _ _ _ _ . . . . _ _ _ _ _ _ _ _ _ _ . . . . JP2 top JP1 top . . | | . . | | _________ | o o | | \ | | \ | \___o___/ | | . \ / . \_______/ - - - - - - - - - - - - bottom of both ._ _ _ _ _ _ _ _ _ _ _ _ . . . . _ _ _ _ _ _ _ _ _ _ . . . . JP2 top JP1 top . . | | . . | | _________ | o o | | / | | / | \___o___/ | | . \ / . \_______/ - - - - - - - - - - - - bottom of both ------------------------------------------------------------- IF YOUR MACHINE DOES HAVE THE CAPACITOR: Cut both sides. (Note: if you started with a Japanese Mega Drive the capacitor will be on the side labelled X instead) Original state of machine: After cutting: JP2 top JP1 top JP2 top JP1 top | | | | | | | | | | | | | | | X | ### X | ### | ### | ### | ### | ### \ / \ / \_______/ \_______/ bottom of both add switch which can be in one of two positions: JP2 top JP1 top (Connect 2 to 2 | | and 1 to 1) | | 2 1 2 1 1 2 ______________ _ _ _ _ _ _ _ _ _ _ | o o o o | | ` | \ \ | X | ###` ` | \ \ | | ### ` ` \____o__o____/ | ### ` ` ' ' \ / ` `- - - - -' ' \_______/ ` _ _ _ _ _ _ _ _ ' bottom of both JP2 top JP1 top (Connect 2 to 2 | | and 1 to 1) | | 2 1 2 1 1 2 ______________ _ _ _ _ _ _ _ _ _ _ | o o o o | | ` | / / | X | ###` ` | / / | | ### ` ` \____o__o____/ | ### ` ` ' ' \ / ` `- - - - -' ' \_______/ ` _ _ _ _ _ _ _ _ ' bottom of both 50/60 hertz switch. You can build a 50/60 hertz switch on a Genesis/Mega Drive like a language switch, but using jumpers JP3 and JP4. The standard setting is 50 in PAL areas such as Europe, and 60 in NTSC areas like the US and Japan. In the 60 hertz mode, the game is faster and the screen taller; however, not all TVs and monitors in Europe can display this mode. Some American/Japanese games are protected to keep Europeans from playing them; this protection checks the 50/60 hertz setting. You can usually get around it by installing the switch and switching when starting the game, then switching back afterwards. Many European games are simple ports of American or Japanese games and are not redesigned for 50 hertz, so work faster and with "better" screen proportions if played at 60 hertz. Genesis/Mega Drive dual version (language switch) list: *Battle Maina 2: The game plays in both positions. However with both controlers removed, a system info screen appears which informs about system version, langauge mode. Bonanza Brothers: Game plays in Japanese. (Maybe. There seems to be more than one version floating around.) Columns: Game plays in Japanese. *Cyberball: Japanese version has a modem option. Dragon's Fury: Works only with language set to English. The original, Devil's Crush MD, works either way. Dynamite Duke: Harder on the Mega Drive. Elemental Master: Harder on the Mega Drive. Fatal Labyrinth: Game plays in Japanese. Fire Shark: Different title screen with Kanji. Flicky: Characters have Japanese names and instructions are in Japanese. Forgotten Worlds: Game plays in Japanese. Gaiares: only mentions the Japanese licensee on the title screen, and has Japanese text; you can also select Japanese text from the option screen. Ghostbusters: Game plays in Japanese. Ghouls and Ghosts: Different title screen with Kanji. To see it on a Genesis, select the last music and sound (26 and 56) from the options screen, then press lower left; A, B, or C; and Start all at the same time. (I never tried this, but Gamepro magazine claimed it works.) The game shows some other Japanese text, and when you die during a boss you start out earlier. Insector X: Title screen refers to company as Hot-B, not Sage's Creation. The MD version shoots more slowly. The ending text is still English. *Marvel Land: The Japanese version says "for Mega Drive" or "for Genesis" but the language stays Japanese. (What does an English version do?) Monaco GP: Game plays in Japanese (also an option on the option screen). Mystic Defender: This game is actually the anime-based Kujaku-Ou (Peacock King) 2 game. In Japanese mode, the opening text is replaced by a graphics screen (never seen in the US version) with Japanese. The levels have names, the main character wears a white robe, the lightning magic effect is different, and the character is named Kujaku in the ending (which is still English). Outrun: The attract mode lacks sound, the startup screen says "push" (not "press") start button, and "(C) Sega 1986, 1991" is printed in reverse order. The default options are KM/H and a different button selection (but can still be changed on the option screen). Quackshot: Game plays in Japanese. Raiden Trad: The "licensed to Sega" line is absent on both title screens, and the second title screen includes only the Japanese part instead of the non-Japanese part of the first one. Revenge of Shinobi: Title changes to Super Shinobi; credits show at the end. Rolling Thunder II: The Japanese version only works on a Japanese setting. The US version works either way (and isn't bilingual). Sonic the Hedgehog II: Tails is renamed to "Miles". Streets of Rage: Title screen changes to Bare Knuckle, and all text is in Japanese, including the introduction. The clock resets when you encounter the bosses. Streets of Rage II: Turns to Bare Knuckle II, and renames Skate to Sammy --_if_ you change the setting sometime after turning the machine on (to skip the lockout). Thunder Force II: Title screen has "MD" on it, and company name is "Tecnosoft". Thunder Force III: company's name is spelled "Tecnosoft". *Thunder Storm FX (CD): Turns to Cobra Command in US mode. Truxton: Japanese title is Tatsujin. Twin Hawk: Different title screen with Kanji. *Wrestle War: The wrestler is blond on a Genesis and black-haired on a MD. * Information from testing a Japanese game ============================================================= 6.0 Sega Internet Information - This information came from Bernd P. Ziller. Mailing to any of these site (or FTP, gopher, etc.) will not work due to a firewall. They are looking out, but we can't look in. I stongly suggest that you don't try anything stupid. segaoa.com 198.176.13.13 130slmail 198.176.14.65 loghost 198.176.13.13 localhost 127.0.0.1 400mail 198.176.14.57 pd275 198.176.14.68 trixie 198.176.9.40 torcable 198.176.14.53 pd130 198.176.14.61 storm 198.176.11.47 segaintera 198.176.14.52 segaoa 198.176.13.13 sonic 198.176.13.13 blackhole 198.176.14.69 multimedia 198.176.14.63 pd1 198.176.14.62 segard 198.176.14.51 segaeurope 198.176.14.50 tormail 198.176.14.54 si32 198.176.14.55 sb1mail 198.176.14.60 macpo 198.176.14.67 pluto 198.176.9.52 fremontml 198.176.14.56 racerx 198.176.9.41 hummer 198.176.11.55 303tdmail 198.176.14.64 sb2mail 198.176.14.58 ftp 198.176.13.13 gambit 198.176.11.46 Emerald_Dragon 198.176.8.22 ============================================================= I am still hoping to expand this document. I am looking for information on the Sega Multitap, CD, 32-X (Mars), HMD, hardware in general, Saturn, and the controllers. Please E-Mail me for a copy or to add information to this list. Again My E-Mail address is: U6c16@Wvnvm.Wvnet.Edu Snail Mail: Henry Rieke Attn: Sega FAQ 161 Poplar Dr Morgantown, Wv 26505-2340 A Very Special Thanks to: David Ashley Rober Leyland Special Thanks to : Scott Golby Rick McTeague Landon Dyer Neal Howland Bernd P. Ziller  sega/docs/switch.txt0000755000000000000000000000610411266515013011661 0ustar From: v922354@fabricius.si.hhs.nl To: "Mega Drive/Genesis Development Group" Subject: ? Date: Tue, 30 Nov 93 11:47:49 +0100 Reply-to: megadev@busop.cit.wayne.edu Sender: Listserv@busop.cit.wayne.edu X-Mailer: Mercury MTA v1.0. SEGA NTSC/PAL & LANGUAGE SWITCH ------------------------------- This modification will convert your PAL megadrive into a NTSC megadrive. Experience FULL SCREEN GAME PLAY!! Realy cool!! On most of the games the vertical retrace is programmed very badly or due to loads of graphix on screen the line becomes visible... In NTSC mode this will be a gonner... (most of the times :) ) _______________________________________________ ________________________ \ | MC68000 | | |______________________| | | ======================= | ======================= | | _________ : : : : | | 3 4 2 1 --------- before: ------- O O O O | | (Don't remove the CAPACITOR on JP1!!) O O O O jp3 jp4 jp2 jp1 after: ------ C D E F O O O O \ \ 2 SEPARATE SWITCHES!! | | O---O O---O jp3 jp4 jp2 jp1 A B JP 3/4 and JP 2/1 connected to each other. SWITCH 1: PAL/NTSC: / \ / \ [=====] [=====] [=====] [=====] | | | | | | C A D C A D PAL NTSC Most of the games you can play faster on NTSC then PAL!! Anoying VR-bar is gone in most of the cases... Check Desperado's not even possible to play in PAL!! No probs in NTSC!! Now you can see that EA programs their games quite correctly,... no change of sound speed etc... SWITCH 2: JAPANESE/ENGLISH: / \ / \ [=====] [=====] [=====] [=====] | | | | | | E B F E B F ENG JAP ENG = Streets Of Rage | All in the same ROM-PACK!! JAP = Bare Knuckles | Same game : different graphix (some...) This only worx if the ROM-PACK suports both languages,... HAVE FUN!! Questions ?!? : _________________ :/\______:_______ 68030 40MHz +======\____ /___ \/\/ / _\____ \======+ GVP286/16MHz 68882 50MHz : .:: ::/ \/ \/ / / | :|/ \:: :. USR 14K4 HST A530-TURBO . . ::/ | / / / /\____ ./ | /: :. . A3070 TS 2MEG CHIP[16].:::::.\_______/___/ /\ / / / .\_______/:::.::..QUANTUM 240 8MEG FAST[32] +================/___/==\/=/________|==============+ MAXTOR 120 Tom Oorthuis, V922354@si.hhs.nl The Netherlands Haagse Hogeschool, sector informatica voice:+31-2550-20405 sega/index.html0000755000000000000000000000342611277647761010712 0ustar Index of /

Index of /

Last Updated: Wednesday, September 3rd, 2003

File name Size Last update Description
[..]<DIR>8/5/2003, 16:33Parent directory
[demo]<DIR>9/3/2003, 19:45
[docs]<DIR>9/3/2003, 19:45
[src]<DIR>9/3/2003, 19:45
[util]<DIR>9/3/2003, 19:45
00index.txt64810/12/1995, 0:0

There are 1 files and 4 directories
for a total of 203462 bytes. sega/src0000755000000000000000000000000011277647734007415 5ustar sega/src/index.html0000755000000000000000000000232211277647734011473 0ustar Index of /src

Index of /src

Last Updated: Wednesday, September 3rd, 2003

File name Size Last update Description
[..]<DIR>9/3/2003, 19:45Parent directory

There are 0 files and 1 directories
for a total of 0 bytes. sega/util0000755000000000000000000000000011277647747007607 5ustar sega/util/index.html0000755000000000000000000000251211277647747011666 0ustar Index of /util

Index of /util

Last Updated: Wednesday, September 3rd, 2003

File name Size Last update Description
[..]<DIR>9/3/2003, 19:45Parent directory
mr-send.zip3,77410/12/1995, 0:0

There are 1 files and 1 directories
for a total of 3774 bytes. sega/util/mr-send.zip0000755000000000000000000000730005654520562011745 0ustar PKy]SgSEND.CWkO9d2)ɄФtU^-De4<ObebGc)} m;}﹯3ڿ:L1BƄm\])$W9b渶rH 8_Vf)Cq{88:9= |3,P~;^,1’D@Gp8l7Z]1+ 10Q7[M)C b$%+Ua@u߿H{}9Œ E>)\X /y4^;4aNQdD ']}.T 'hJhŘ[]oL\)W$HExlz2OQbt3RAq̩PtmfK]{+sFDH`5Q 8)#cMJZ݌eK9PIo4O[w;.vաx:3ce$pu[_ULj`aXh̵$ /h-'Ô 4Y?hoE-[*ΈITuXD5Q. 'N:mvxv`=UҩX]6C(MDi{%n!̯gBfs)!ů`F訖W){JDڐ{.X9uL˦/j!et02JTLHlP.je/S<0>2IC%SBu@R8(te[E>WV(߃V ,-lt^|ixޭՍ'7{΁\!LUŵ  ^g4p(i9r8'[oVխ?vI =\X/B/%U@RuLS`Lx{4U %gn$aT aGM>C:&Ge*vJ=P1wt/=,\E2A9E07UµB4C؅sU_Tt.؅j9TD5q*4/"юZz<~j b?{@W8v-%^9h2%2 ֛;T_g<{ E6%.;{v!Mfv賊򽡪^AE$#R F._~oyp:P9St8? Y3y]{WcI/{)cps:B܅˹6 %[6̃tYtrN[#Bx͟PK]veq ROM.CVO90>4@ w*)PD %=C*gZٵ$WߌuUyxG{0I%,8 ,+_2 5~NpF/ *0QNeb/-0kڬ G4&v=h(mã0- Qf5AچVZ%Z72(ŪɭĠ)sx S8~[L0K岀n;À^S>V5>0~<Py~>Nx|&p0 hJ!+ .bf ݳsM*Qn4yeR /wGMp3_cjA0Q}k3 z6+NԘ{ÑJ?|3Ja&쩯ʂ}iu7zVu)&F^^;f)^!N,PKy]Sg SEND.CPK]veq  ROM.CPKt].@ V  ROM.HPK]c-y SEND.TXTPK