Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

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

Status
Not open for further replies.

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.

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...
 
gatas said:
Nigel Goodwin said:
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...

Parallel ports are fairly slow anyway, they don't run at processor speed, but at the (extremely low) speed of the I/O section of a Intel processor, standard parallel port outputs are often 'claimed' to be 1MB per second, but a lot of books are sceptical about reaching that speed - although EPP and others are supposed to be faster.

Multiplexing would slow it down even further, 8:16 would at least half it.

Think how a ROM works - the processor puts out a 16 bit address on the address lines, and reads back the data off a different 8 lines. For a PC to do this it's going to have to read at least two seperate 8 bit bytes, combine these to make a 16 bit address, look up a data byte at the 16 bit address, then output the data.

Common EPROM's only take 100nS-150nS to do this - that's up to 10 million readings per second - if it's slightly too slow the processor crashes!.

If the NES uses a 6502 as you suggested, these pre-fetch codes from the EPROM ready for the next instruction - which is what makes them far faster for their clock speed than other processors of the same era. A 1MHz 6502 is probably as fast, or faster, than a 4MHz Z80.

My personal view! - you don't have a prayer :cry:
 
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?
 
gatas said:
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* :oops: 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?
 
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:
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...

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.

Latest threads

New Articles From Microcontroller Tips

Back
Top