Emulate game console's cartridge through PC's lpt...

Status
Not open for further replies.
G

gatas

New Member
Greetings electronics fans...
I want to make an interface of the nintendo NES with my computers' LPT...
So instead of a rom cartridge, i ll serve the data through lpt...Rom dumps will be available on hard disk...So my question is the following:

Nes is 6502-based and is clocked at 1.7 mhz...guess that this means that rom accesses will be much below <1 mhz right?
Will the lpt be able to serve data at these frequencies?
What is lpt's maximum speed?
I guess one cannot count that easily due to lots of interrupts happening here and there...
And lastly, win XP have a selection for the lpt (through the device manager), "Never use an interrupt", as well as "Use interrupt" etc...
How will these affect perfomance? Especially the "never use" one selection....

Thanks to everyone in advance....
 
Well I've never seen an NES, but presumably the cartridge is a ROM?.

This will have a number of data lines (presumably eight?) and a larger number of address lines (16 for a 64K ROM, 17 for 128K etc.), plus chip select lines etc.

This is a lot more lines than are available on a printer port, plus the majority require input lines not output lines. Attempting to do anything like that under Windows (particularly XP, or other NT systems) would also be fraught with problems.

As I see it the solution would be to build a cartridge full of static RAM, as much as you need to store a complete cartridge - preferably battery backed, so it keeps it's memory. Have circuitry to enable downloading from the PC into the memory, by either parallel port, serial port, or USB. The RAM should be read only from the NES side, and read/write from the PC side - it's called an EPROM Emulator, various designs for standard EPROM use have been published over the years.

This always presumes there's no kind of copy protection on the cartridges?, if there is you would need to deal with that as well.
 
Nigel Goodwin said:
This is a lot more lines than are available on a printer port, plus the majority require input lines not output lines.
Click to expand...

Yeah i kow..I forgot to tell u that i am gonna use multiplexers of course..Maybe a second lpt...

By the way anybody knows cheap ttl 8:32 and 8:16 MUXes/DEMUXes?
As far as cartridges copy protection, problem already solved..
My main concern (apart from the MUXes) is the LPT ability to work fine at these speeds...
 
 
Perhaps u r right Nigel..But i ve done lots of studying for this project and really wont give up...
What if I used PCI I/O ?
Probably get lots of I/O lines..maybe dump the MUXes....
Anybody perhaps know its clock, as well as typical access PCI times?
 

You could certainly speed it up by using sufficient I/O lines, rather than just the parallel port - and by not using Windows. But if it's going to be fast enough?, I really don't know.

As I mentioned earlier, the way to do it is with external static RAM, as an EPROM emulator. I seem to remember such cartridges been commercially available in the past for other systems.
 
It might be easier to make the PC write the settings into the
'rom cartridge' then take the 'rom cartridge' over to the
game console and plug it in.

These cartridges dont hold a very large amount of information
as far as i know, i think its usually les than a megabyte, the
PS2 is only a few hundred kilobytes, i think.

Doing it like that, i dont think you would have to worry
about the speed of writing to the cartridge.
 
I hate to brag, but if I understand what you need, I have the site explaining this exact project: **broken link removed**
*Looks at the site again* Except it's only for the Sega Genesis/Mega Drive and the Nintendo SNES. :lol: Sorry. But the guy said it shouldn't be too hard to add more systems. Does this help you?
 
Electric Rain said:
I hate to brag, but if I understand what you need, I have the site explaining this exact project:
Click to expand...

That's just the sort of thing I was suggesting!.
 
The reason i dont want the battery-backed Ram, is that every memory-mapping pattern will have to be achieved via hardware..So my design will probably include support for only one mapping mode...
I want to resolve the address,via software, depending on the mapping method, and then supply that to the NES...
Thats why i want the data to be fed in real time..
Anyway thanks to everybody for his concern...I ll try maybe I/O on ISA bus and keep u posted...
 
gatas said:
Anyway thanks to everybody for his concern...I ll try maybe I/O on ISA bus and keep u posted...
Click to expand...

Good luck, I look forward to hearing how you get on.
 

Ahh... I see. I understand that. Well, if that doesn't help you then I'm afraid I can't do much else to help you. But at least I tried. :lol:
 
Little mistake here... I've posted three times under Electric_Rain... But I'm the same guy you all know... Electric Rain. (Sign-in problems... Just now noticed it.) :lol:
 
I can provide some insight on the parallel port operational speed from a device I have built.
All I read indicated parallel port could provide data thru-put as high as 10MBPS (in EPP mode). When observing the pulses on a scope, the pulse width looked to be close to 200ns, so if you could access the port continuously, you could get 5MBPS data thruput (If my math is correct). Reality, however is that you cannot access the port that fast.
My device is currently able to acheive a max thru-put of ~3.18 MBPS and that is under dos mode. Operating under windows 98SE drops that to 2.48MBPS (OS and background process overhead of around 22% of real time).
A faster machine than mine (PIII @1.4GHZ) may be able to better this thru-put, but I have not tried it yet. Another factor may be that my test program is written in 16 bit code.
Dialtone
 
Status
Not open for further replies.

Similar threads

B
  • Question
Game Laser Sensor
2
Replies
21
Views
2K
Tony Stewart
  • Question
What's the simplest way to emulate the output of a rotary encoder?
Replies
13
Views
13K
jelliott
A
Efficient current through 30 leds
2
Replies
27
Views
4K
crutschow
M
  • Question
Wireless charging receiver that works through metal [Aluminum/Stainless Steel]
Replies
8
Views
13K
mcbrown
M
J
How to check buffer/Driver is BAD or Data is not passing through
Replies
7
Views
2K
Pommie
P
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…