GEMS YouTube video

Talk about anything else you want

Moderator: BigEvilCorporation

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Sun Oct 19, 2014 12:21 pm

r57shell wrote:
MintyTheCat wrote:You have missed my points entirely.
I think I don't. Make questions more clear.
:)

Quite clear but for your benefit let us reiterate:

GEMS was used in a number of MD Games and to my understanding it was used a great deal with early MD Games. However, I had heard that GEMS as a driver and system had a few issues but it was used widely as it was released by SEGA themselves and it was fairly easy for musicians to use.

1. Does anyone have any understanding of GEMS and indeed sound drivers that were used on the MD and be able to explain a little further as to what the problems (if any) were when using it to create music for Games?

At this point in time there have been a few attempts at making sound drivers such as Echo. however, there is no definitive sound driver that could be used as yet. My thoughts are that one of the goals for the MD Dev Community would be to have a decent sound driver implementation and indeed a set of tools to facilitate music development on the MD. Reading of CountSymphonic's progress in developing a native MD Tracker is again promising and good news. My only hope is that he makes it Open-Source.

2. What are the shortcomings of GEMS for Musicians and could an improved version of GEMS be developed as a community

Given that these days some of the Assemblers that are kept up to date now have backwards compatibility with older and more established Assemblers it makes one think about applying this approach to sound drivers and indeed music development systems on the MD.

I would be interested in your thoughts.
UMDK Fanboy

User avatar
powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Sun Oct 19, 2014 3:32 pm

MintyTheCat wrote: GEMS was used in a number of MD Games and to my understanding it was used a great deal with early MD Games. However, I had heard that GEMS as a driver and system had a few issues but it was used widely as it was released by SEGA themselves and it was fairly easy for musicians to use.
I know this isn't a question, but the widespread use of GEMS was likely because it was a "turn-key" system. A completely developed, ready to use, officially supported solution that Sega of America stood behind. Its shortcomings, I feel, are overstated in light of its benefits. I think a lot of people don't appreciate it in perspective of the time it came to exist and what MD development was like at the time.
MintyTheCat wrote: 1. Does anyone have any understanding of GEMS and indeed sound drivers that were used on the MD and be able to explain a little further as to what the problems (if any) were when using it to create music for Games?
I don't know much about other MD sound drivers (other than what is generally known by say, the Sonic hacking community) but here is the way I see GEMS, and indeed Sega, relative to the time.

I'll be referring to the MD as the Genesis from here on out to emphasize its position in the USA, and I feel that the GEMS "phenomenon" is definitely American. This is going to be a long meandering post so stick with me.

From about 1989 to 1991, the Genesis had a marketing problem in the form of games that would appeal to the American market. Sega's early brand strategy is well known--celebrity endorsements (Michael Jackson) and major sports figures (Joe Montana etc). Lots of these early games were developed by Sega of Japan, for Sega of America, or were rebranded games that existed prior (Tommy Lasorda Baseball was Super League, Buster Douglas Knockout Boxing was Taito's Final Blow, the first Joe Montana game was rushed and bought by Sega from EA and quickly rebranded, Arnold Palmer Tournament Golf was some other golf game and so on).

Anyway, the point of this is that Sega needed more games, particularly in light of the success of Sonic the Hedgehog and the sales spike that caused. They needed games that would sell to an American market. This leads to 1992.

If you look at all the games for Genesis released in 1992, you'll notice something straight away compared to years prior--there was something of a renaissance of American developers that year. Look more closely and you'll notice something else--basically all of those games use GEMS for music and sound. Why this is, I can only postulate, but I wouldn't doubt that it had something to do with wanting to get those games out as soon as possible, and the less time those developers spent developing tools and the more time they spent on games, that would have been a benefit to Sega of America. It's well known that Sega of America commissioned GEMS from Technopop, so they obviously saw a need and wanted to fill it. From there on out I imagine it was momentum. Many of those initial American developers went on to develop more Genesis games in a 2nd party capacity and by that point their composers and programmers understood GEMS--and GEMS was constantly being improved, too.

Other factors that I believe led to high adoption of GEMS:

- As far as I can tell the software was royalty free beyond the initial purchase--if these developers even had to purchase it, most of them were contracted to Sega--so using it saved both time and money
- FM is "hard." Your average musician/keyboardist of the time, the closest they got to FM was the DX7 and it was infamous for not being the type of keyboard you wanted to make your own patches on. Example: GEMS itself doesn't come with patches beyond the Ship demo, yet many GEMS games use the same patches. I'm sure good sounding patches got swapped around back then.
- MIDI. This was the standard, at least in America, of the type of composer that had familiarity with computer music well enough to get a job as a video game composer. Sure, we had people who used things like trackers, and we had a demoscene, but most musicians familiar with computer music knew and understood MIDI.
- Genesis audio is sort of weird to the uninitiated. Keep in mind video game audio up to this point was square waves and a handful of 8 bit port writes, from one main CPU. The Genesis added layers of complexity to this in the form of FM synthesis, a separate CPU running its own program with its own RAM and its own bus, having to code around that--and this is just the stuff that was intentional by design, not even considering the hardware bugs and quirks that were later discovered.
- Technical reasons. Dynamic channel allocation means musician doesn't have to worry about individual channels, only not exceeding total channel budget, and sound effects are handled automatically. On the software end, it integrated well with C compilers.
- Prior use in games. If a developer used GEMS to develop a game, it makes sense to use it in the sequel, or in another game that reuses the same code base.

As far as problems with GEMS goes? It's not perfect as lots of armchair critics have observed. It doesn't have the best sample quality (but IMO it is comparable to other engines), it has some shaky tempo issues, and there's reports of it not working 100% identically on all MD hardware. I have a Genesis that doesn't like certain GEMS games and has tempo issues, and I have others that don't have any problems. That said I honestly feel its biggest downside is its ease of use. I think that GEMS got a bad reputation for exactly two reasons.

1. Lazy musicians not utilizing features of GEMS that would make their music sound better (pitchbends, modulation), or simply just not writing very good music. Not really the fault of the driver.
2. Bad emulator sound. This has really tarnished the reputation MD sound in general and has made every "gamer" out there who thinks they know a thing or two about retro games utter this statement in some form in their lives: "The GEMS sound engine sounds bad." This isn't really true. I can cite one example: going back to what I said earlier about GEMS games sharing patches, there was one really prevalent patch, a hi-hat type sound, that got shared a lot. It's a patch that sounds fine on hardware, and on modern emulators. Older emulators though, like Gens, emitted a horrible bleeping/ringing sound when it played back. You would not believe how many people think this is how GEMS actually sounds, as if any developer would let a game out of the door sounding like this.
MintyTheCat wrote: At this point in time there have been a few attempts at making sound drivers such as Echo. however, there is no definitive sound driver that could be used as yet. My thoughts are that one of the goals for the MD Dev Community would be to have a decent sound driver implementation and indeed a set of tools to facilitate music development on the MD. Reading of CountSymphonic's progress in developing a native MD Tracker is again promising and good news. My only hope is that he makes it Open-Source.

2. What are the shortcomings of GEMS for Musicians and could an improved version of GEMS be developed as a community
Certainly, I can think of a few features that might help improve it as a driver, but the most desirable development would be a replacement for the 20+ year old GEMS.EXE. A MIDI converter, I think, would be the most feasible, but there would still need to be some sort of opcode-editor. r57shell's GEMS split and merge tools are interesting as well and you should check into them if you haven't. They basically de-compile GEMS data into its constituent patches, modulators and even decompiles sequence data into text form. The merge tool recompiles it. It would be nice to have a modern GUI app that mimics the old GEMS.EXE in functionality, with built in sound emulation cores to remove the need for a Genesis.
MintyTheCat wrote:Given that these days some of the Assemblers that are kept up to date now have backwards compatibility with older and more established Assemblers it makes one think about applying this approach to sound drivers and indeed music development systems on the MD.

I would be interested in your thoughts.
In order to get GEMS.A to assemble with vasm I had to change one opcode (it used a backward notation for indexed addressing that was nonstandard), change the syntax of local and global labels, and do a find-and-replace on some other minor things. It worked perfectly in conjunction with the VBCC C compiler with no other changes. I also made some other minor changes to the code like automatically loading the bank pointers instead of doing so through an external function, but that's hardly a huge change.

I feel that GEMS would make a great community sound engine for many of the same reasons it was popular back in the MD's day. Ease of use, the source is there, we know it's been well-tested. With the knowledge we have now, we might even be able to fix its few remaining issues. The only drawback is we do not really know its copyright status.

If the community was to work together to create a new sound engine--I would strongly push for it to be like GEMS. If that is not a ringing endorsement, I don't know what is. :)

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Sun Oct 19, 2014 7:43 pm

Thanks, PowerOfRecall - that is certainly an in-depth description.

I think that what we could do is to perhaps start a Thread on GEMS research.

If we listed the necessary components that would be required - you mentioned having a modern-day equivalent of the GEMS.exe from back in the early Windows days that was written using something like QT then it should build and run under most modern OSes.

Having a back end that allowed a Musician to be able to make music without having te real MD Hardware but in its place something that emulated the MD's sound hardware is a good idea and what's more there should be examples from Open-Source emulator Projects that have code available to refer to.

If anyone else is interested then I would be happy to start a collaboration thread and to start planning the project.

I feel that the MD Dev Scene would benefit greatly in having a decent development system for music.

Cheers,

Minty.
UMDK Fanboy

Chilly Willy
Very interested
Posts: 2603
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun Oct 19, 2014 8:19 pm

MintyTheCat wrote:Hi all,

I am not at all in any way experienced in GEMS or indeed making Music on the MD but a few points have sprung to mind:

1. Would it be possible to replicate GEMS and to use it on modern systems?
2. What are the shortcomings of GEMS for Musicians and could an improved version of GEMS be developed as a community?

It is very interesting for me to see you two chaps developing insight into how GEMS works and I hope that it will benefit us all in the long run.

Cheers,

Minty.
The answer to both is "how well documented is the GEMS format?" If it is fully documented, said doc can be used to make an export plugin for something like OpenMPT. It could also be used to make a list of anything missing that are available in editors like OpenMPT. Making changes to support those would require source code to the GEMS driver, and the ability to add those changes (someone really good with Z80 assembly and knowledgeable about music players).

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Sun Oct 19, 2014 8:31 pm

Chilly Willy wrote:
MintyTheCat wrote:Hi all,

I am not at all in any way experienced in GEMS or indeed making Music on the MD but a few points have sprung to mind:

1. Would it be possible to replicate GEMS and to use it on modern systems?
2. What are the shortcomings of GEMS for Musicians and could an improved version of GEMS be developed as a community?

It is very interesting for me to see you two chaps developing insight into how GEMS works and I hope that it will benefit us all in the long run.

Cheers,

Minty.
At a push someone either into the Master-System or the Spectrum.

Worst-Case the entire GEMS.exe can be reversed.

The answer to both is "how well documented is the GEMS format?" If it is fully documented, said doc can be used to make an export plugin for something like OpenMPT. It could also be used to make a list of anything missing that are available in editors like OpenMPT. Making changes to support those would require source code to the GEMS driver, and the ability to add those changes (someone really good with Z80 assembly and knowledgeable about music players).
UMDK Fanboy

User avatar
powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Sun Oct 19, 2014 9:21 pm

Chilly Willy wrote: The answer to both is "how well documented is the GEMS format?" If it is fully documented, said doc can be used to make an export plugin for something like OpenMPT. It could also be used to make a list of anything missing that are available in editors like OpenMPT. Making changes to support those would require source code to the GEMS driver, and the ability to add those changes (someone really good with Z80 assembly and knowledgeable about music players).
It is essentially fully documented on the MD end as the full source exists. The part that's not really understood right now is the parallel data transfer from GEMS.EXE (the editor) to GEMS (the MD side software). I don't think reversing GEMS.EXE is really necessary as what it does is more important than "how" it does it. r57shell in this thread already cracked the (very basic) communications, all that's really left is to find out what data controls what.

As far as readable format documentation, aside from the actual GEMS player source, r57shell has open source utilities on github to manipulate GEMS data, and both he and ValleyBell have created GEMS-to-MIDI tools. The source of both of these are available and give good insight into the GEMS opcode set. I also have snippets of info but it is mostly gleaned from the GEMS source and those utilities.

What we don't know/isn't common knowledge about GEMS:
The hardware itself--we know it is a socketed board with ROMs and RAM on it but not a lot else
The Sega Loader Board referred to in the GEMS documentation (I don't know exactly what this is/if it is the board the GEMS ROMs are actually attached to)
Of these two things, neither is particularly relevant unless we want to get the old GEMS.EXE functioning on a modern setup (which is what I am endeavoring to do).

That said, I am hoping to fit together a way to use the GEMS MD software with the DOS editor software. I can already use the editor as I described before, in a DOS VM with MIDI data piped to it. I'm trying to take this one step further by piping out raw parallel data into an emulator, simulating the data going into the EXT port 1 byte at a time. If this works the way I think it will (fingers crossed) I won't need to know anything about the data or GEMS.EXE in order to use it--but I may need to know a bit about the GEMS hardware in order to emulate that.

r57shell
Very interested
Posts: 475
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Mon Oct 20, 2014 9:34 am

powerofrecall summarizing what you may read if you not lazy. That's why I don't want to write all things again, because I'm lazy as...
powerofrecall wrote:As far as readable format documentation, aside from the actual GEMS player source, r57shell has open source utilities on github to manipulate GEMS data, and both he and ValleyBell have created GEMS-to-MIDI tools.
:shock: ValleyBell have created GEMS-to-MIDI tools? If you're thinknig that I was making GEMS-to-MIDI with his help - you're wrong. If VelleyBell creating it too, then give us link please.
powerofrecall wrote:I also have snippets of info but it is mostly gleaned from the GEMS source and those utilities.
I have full format details but in Russian, started by Smoke and added VAST of info and polished by me.
powerofrecall wrote:I'm trying to take this one step further by piping out raw parallel data into an emulator, simulating the data going into the EXT port 1 byte at a time.
You're doing it wrong, reread my posts about MD and DOS side. keyword is "high level".
powerofrecall wrote:If this works the way I think it will (fingers crossed)
Yeah, it must work, if your dos emu output data as it should. My problem is to output parallel data. DOSBox can output data only in file or real parallel port. It outputs in file only part of data in unknown for me format, and then closing file, and after that GEMS.EXE hangs. It's not how it should work. Also, It does not have option to write into pipe or socket, that's why I need to modify it. I still have troubles to compile it. (still adding .cpp files in project, and compiling side libraries. Also there is bugs in source, so I have to google how to fix them, because author didn't fix them. I don't even know how he was able to build it in state how it is available on his site.)


EDIT:
Hurray! Now I'm able to compile DOSBox. After hour of messing up with standard Parallel ports in memory, I realized that I had mistake in this part:
r57shell wrote: DOS side revealed too.

Code: Select all

void write_byte(byte b)
{
    DATA = b;
    int c = CONTROL;
    CONTROL = c|1;
    while (STATUS & 0x40);

    c = CONTROL;
    CONTROL = c & (~1);
    while (!(STATUS & 0x40));
}
First fix: I removed "!" (not operator), because there is jnz instead jz. Second fix more interesting. I was being confused with debugging my parallel handler in DOSBox. I made code that supposed to output "WriteData(%08X)" when write in DATA port of Parallel is performed, but it wasn't called at all. I did same output if status was read: there was spam log. There was question: why no DATA, only STATUS? Then I set breakpoint in status reading right in dosbox. When it was triggered, in call stack was: INT17_HANDLER (something like that). Then I tried to find int 17 in disassemble: no result. Checking few times: same result. Hmm. If you look "int 21h" in hex you'll see "CD 21" bytes. I did search of CD 17 sequence of bytes and found it. It was in dissasembly too, but some how I didn't find it myself with text search. May be I was retarded again. So... then I tried to find external references to this function: it was at same place where was code which is up here. And... I remembered that I thought it is debug output into bios console, because there was check "which code to use" and I just did wrong selection of right branch :D.

So, it is like this: if (0) { code_upwards_in_this_post } else {

Code: Select all

biosprint(0,0,byte|0x80);
biosprint(0,0,byte>>1);
Yes, so simple. biosprint is just: int 17 with args: port, cmd, val.

Right now I'm building connection on sockets.
Image

User avatar
powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Mon Oct 20, 2014 3:15 pm

ValleyBell's converter is in this post
r57shell wrote:You're doing it wrong, reread my posts about MD and DOS side. keyword is "high level".
No, this is "high level:" I don't have to know anything about the data. :) I am using a named pipe (FIFO) on Linux. Dosemu outputs parallel data to pipe, it is picked up by emulator and returned on EXT port read. Unix-style IPC. Probably not the best way as it is blocking to the DOS emulator--it will freeze until FIFO is read out on the MD emulator side--but I think it should work as this is not really different from the behavior it would have if it was running on real DOS.

At least I need to stop being lazy and do it but I have to read and learn about Unix FIFO. It is new to me.

Good luck with DOSBox. I did not use it because I did not have the patience to hack on it and that is how I found Linux Dosemu does what I need.

What you found about int 17 parallel print is good news for me. I was worried that Dosemu might try to format the parallel output for printer but it looks like it is the raw data.

r57shell
Very interested
Posts: 475
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Mon Oct 20, 2014 4:44 pm

MintyTheCat wrote:I think that what we could do is to perhaps start a Thread on GEMS research.
I was started this topic for this research, but it was long ago. Now, I don't mind where info located...
MintyTheCat wrote:If anyone else is interested then I would be happy to start a collaboration thread and to start planning the project.
Instead of planning projects, I'm making research.
Chilly Willy wrote: The answer to both is "how well documented is the GEMS format?" If it is fully documented, said doc can be used to make an export plugin for something like OpenMPT.
I doubt there is no suitable tracker. DefleMask/OpenMPT rows-like style - is not suitable for GEMS. Hm... I mean it's restriction on abilities of GEMS. If you know suitable open source project, it would be nice.
powerofrecall wrote:ValleyBell's converter is in this post
Why I didn't know that when I was making mine? :( It would help me a lot. Is it as powerful as mine? Ah, nvm I'll check later.
powerofrecall wrote:
r57shell wrote:You're doing it wrong, reread my posts about MD and DOS side. keyword is "high level".
No, this is "high level:" I don't have to know anything about the data. :)
Yeah me too. But still, "high level" I mean level send(byte), recieve(byte). Note, that I was replying when it was not updated code. So when you said something like "send to EXT port", actually instead of that, you should interpret what was sended to DATA port, and replace reading routine in GEMS rom with reading this byte.

After code update, there is two ways:
1) Intercept two bytes from parallel port, mix them together (to get byte what was sending by GEMS.EXE), and replace high level function of GEMS ROM with your modification.
2) Intercept byte one by one, and replace low level function of GEMS ROM with read of bytes one by one.

Actually, second way is easier, so it's my choice. I have implemented second way, and from what I have, I see that GEMS ROM writes into range from 0x10000 to 0x20000 approximately. I'm trying to setup SRAM in emulator in this way, but it still not working.

Also, if you want pictures of GEMS hardware, it is in this thread.
Image

User avatar
powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Mon Oct 20, 2014 5:41 pm

http://i.imgur.com/U5JUEpA.jpg

I think the board in the top right must be this "Sega Loader Board" GEMS.DOC mentions. Looks as if it is just an adapter of some sort.

The top part of the ROM/RAM boards looks like normal 28 pin SRAMs. I would assume they're just part of the regular cartridge address space. Now all I'll need to know is where they're mapped. Guess I'll have to look!
Last edited by powerofrecall on Mon Oct 20, 2014 8:14 pm, edited 1 time in total.

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Mon Oct 20, 2014 6:51 pm

Cool. Did you manage to buy that, PowerOfRecall?

I am asking a fellow MD Developer if he can help by adding anything further as I know that he collects old MD dev Hardware and Software.
UMDK Fanboy

User avatar
powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Mon Oct 20, 2014 7:00 pm

Oh no, that belongs to TmEE. I wish I could snag one but I'm sure it'd be pricy if I could even track one down.

r57shell
Very interested
Posts: 475
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Mon Oct 20, 2014 7:25 pm

I don't need to suggest. I can check in code. :D

BTW, we forgot about this is YouTube thread!!!
http://youtu.be/2s5Oa_rqMTM
Thanks to powerofrecall, without you, I didn't even start to look at it closer. :lol:

Now, to summarize:
MD Side:

Code: Select all

byte ext_read() 
{ 
    while (EXT&0x10); // wait for data 
    low = EXT; 
    EXT = 0; // may be for next part, but there is no wait after it. 
    high = EXT; 
    EXT = 0x40; // acknowledge 
    return (low & 0xF) | ((high&0xF)<<4); 
} 

byte read_byte() 
{ 
 do { low = ext_read(); } while (!(low & 0x80)); 
 do { high = ext_read(); } while ((high & 0x80)); 
 return ((high << 1) & 0xF0) | (low & 0xF); 
}
also, I fixed this code too, in second 'while' of read_byte '!' (not operator) removed.

DOS Side

Code: Select all

biosprint(0,0,byte|0x80); 
biosprint(0,0,byte>>1);
here biosprint = int 17 port cmd value

What goes into biosprint on DOS side, must be readed in ext_read() on MD side. ext_read is at offset 0x798 int GEMS ROM. Feeded in biosprint falue in result must be in d0 at 'rts' opcode of ext_read = offset 0x1192.

1) Don't forget to put EGAVGA.BGI into GEMS.EXE folder
2) You must setup SRAM on genesis side at 0x10000, it must reach at least 0x17FFF offset, but I'm not sure is it enough or not.

I was using:
1) DOSBox Daum with turned off many of plugins. Here is my GemsLPT source, in case if someone would like to build it on his own.
2) Gens-rerecording 11a with modified Mem_M68k.asm to allow SRAM based in 0x10000-0x1FFFF range.
3) LuaSocket: for sockets in lua scripts.
4) Lua script here.

With this info, anyone (with enough knowledge) can make device to connect GEMS.EXE with MD, or with any other emulator, for example: genplus-gx.

powerofrecall, please, replace image above with link instead of it.
Image

Chilly Willy
Very interested
Posts: 2603
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Oct 20, 2014 7:37 pm

A lot of us old-timers are more comfortable with the tried and true tracker style editors, but there's more out there. Perhaps you prefer a midi sequencer like MusE or RoseGarden. Maybe you prefer editing a score with standard musical notation, like Denemo. There's plenty of editors to check out, but I think most folks would prefer a converter, like the MIDI<>GEMS converters posted earlier.

User avatar
powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Mon Oct 20, 2014 8:21 pm

r57shell wrote:I don't need to suggest. I can check in code. :D

BTW, we forgot about this is YouTube thread!!!
http://youtu.be/2s5Oa_rqMTM
Thanks to powerofrecall, without you, I didn't even start to look at it closer. :lol:
Excellent work! I will have to try this out on one of my windows machines but for now I'm going to see if I can get my dosemu -> emulator pipe working.

So you're saying I'll need 0x7fff of RAM starting at 0x10000 for the cart RAM?

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests