For what I'm working on I've got some questions, and might possibly have others as I come to'em, so I figure I'll just use this one topic as they come along instead of making a bunch for different things.
Firstly, can anyone see any issue with putting a pulldown resistor of say 10k on the VRAM /CE, so that without a cartridge in the system, the onboard memory will automatically be activated? I know that it's apparently safe to keep it pulled straight to ground, because my earliest breadboard NROM board didn't have any CHR rom or ram, and I was using the internal 2k full-time, but no cartridge could ever be put in with that setup. So theoretically, the signal on the cartridge itself should override the pulldown, but when it comes to how them wacky electronics work, there might be some consequence I'm not thinking of.
Second, is it okay to leave the /OE signal activated on an sram when you also have /WE active? Will the chip ignore the output enable and go into write mode? I already planned out how to do it the "safe" way, but if /WE always overrides, this'll save me from a little more logic wiring. I just don't want the chip trying to possibly output anything when I'm trying to write to it.
I think that's all for now!
On the SRAM datasheets I've seen, /WE will override /OE. I don't know if that's standard, might depend on the chip. I could see it causing bus conflicts if /OE goes low first and the SRAM is really fast. I dunno how likely that is to happen though.
I'd just get the PRG /RD signal, all you need is an inverter. But since I do my tests as PCBs I tend to go the safest way. Plus on Squeedo I already had a NAND gate that needed to be used.
I should mention that this particular project will be seperate from a cartridge; it'll still allow normal carts to be played. Of course, I've never designed such a hardware project before, so one can only hope my designing will be correct! I could probably go look at how folks have done certain similar elements, but that takes away from some of the satisfaction of doing it myself.
In this case the idea behind my first question is to sever the PRG R/W going into the cartridge so that I can override the signal when wanting to write to a PRG eeprom or PRG sram, to prevent the mapper from detecting writes. I'd have the pure PRG R/W signal coming through one of the EXP pins, which would deal with only the eeprom or sram's read and write control. Using the inverter was what I had in mind for the safe method, using a second EXP line to avoid putting an inverter in the cartridge. Otherwise I was just gonna tie /OE to ground. But if I end up having the extra inverter to spare, I see no reason not to do it safe.
Also, if there's no conclusive knowledge of whether a pulldown will work properly on the VRAM /CE, I had the idea that I can just tape over the CHR pins on my dev cart, connect the pulldown, and then write a simple test rom to verify that the internal ram is working. Then I can pull the tape off and put the cart in again, and see if it uses the onboard. And actually, since I already know what Galaga looks like when trying to run in the onboard 2K, I might could just use that, too.
UPDATE: I pulled out my breadboard jungle instead and used it for experimenting, simulating the cartridge being removed by changing some of the wiring. From what I can tell, the pulldown works fine. VRAM was always on with the CHR side disabled, and when re-enabled, VRAM seemed to behave normally. I tried both a test rom which only used the internal 2k, as well as Galaga.
Hmm, I had a thought, which possibly messes up my idea. While doing the resistor on VRAM /CE might keep it pulled low on no cartridge, and leave it alone when a cart is in it, I realized that I might have a problem if there's a cartridge inserted, but that particular one doesn't use the NES internal vram at all. In such a case, I'd assume VRAM /CE gets pulled permanently high inside the cartridge. But, I have no idea whether a particular cart might pull it high via tying it directly to 5v, or by using a resistor. If they used a resistor, suddenly there'd be a conflict between their pull-up and my pull-down. If the resistors were of the same amount, I assume my pull-down would win (right?), which would keep the internal vram on, even when the cart is wanting to use its own.
I mean, to save on costs, one would think they'd prolly tie it straight to 5v, but unless it were possible for somebody to check every cartridge that used its own vram to confirm such a thing, I guess I'm going to have to change my method some. Mind you if I'm wrong about anything mentioned above, I'm open to correction.
I should explain a little first as to why I want to force internal VRAM on in the first place. The overall plan is to have a "Disable CHR ROM" register bit (via an output from octal flip-flop). 0 = normal operation, 1 = CHR ROM disabled (aka holding A13 going to the rom high). Aside from that main function, when 0, internal VRAM will also behave based on what the cartridge wants of it, and when 1, internal VRAM will be forced on, allowing me to use that 2K to hold 64 tiles and 1 background (now that the CHR ROM is disabled), which is fine for what I have in mind.
Using a tri-state signal is the likely solution here in terms of forcing the internal vram on when I want it, and then going into tri-state mode when I want to let the cartridge take over. But since that'd require sticking a whole buffer IC or something tri-statable into the project just for this one thing, it seems like overkill. I'm not 100% certain what happens when an IC puts an output into tri-state mode, but I think it could be emulated using just a transistor.
Shouldn't I be able to connect the output of my register bit to the base of an NPN transistor, connect the collector to VRAM /CE, and collect the emitter to ground? When my register bit is high (CHR ROM off + VRAM forced enable), it should let current flow through the transistor, allowing VRAM /CE to flow to ground and hold it low. When the register bit is off, nothing should flow through the transitor, but does this make it the equivalent of tri-state? My knowledge of dealing with analog electronics is limited, so this might not work at all for all I know, but I figured I'd pass it along to those of you who know your stuff, and would appreciate any input! If nothing else, I can stick that extra tri-statable chip on if I have to, but this seems so much simpler if I can figure it out properly.
When an IC puts I/O in tri-state mode (Hi-Z) it's as if they are open circuit.
I'm a little bit confused as to what you're trying to do (that was a lot to digest!) but the transistor idea will definately beat a pullup. Back to your pulldown against a pullup, I think that'll cause a voltage divider and put the level in an indeterminate low state. Maybe you could use a 1M pulldown which will always loose.
If you're planning to tri-state your octal DFF output, you could use a 74374 which already has /OE. If you're talking about tri-stating the data bus, you'll need two '244 since it's bidirectional and R/W select logic which could also disable the CROM/CRAM instead of holding /A13 high. (What if a game uses active high A13 to decode? :)
Yeah it'd prolly be easier if I could just show what all I've scribbled on paper, but I don't have access to a scanner as of the moment. And it's probably about like programming, anyway; even with something to look at, it can be hard to tell what somebody elses stuff is doing sometimes, if it's very complicated. I pretty much just want to be able to disable any cartridge CHR rom/ram (including any extra nametable ram it might have available), and be able to use the NES's internal 2k VRAM for both tiles and a single nametable.
Something you said made me realize you could have a point, about some cartridges possibly using A13 in both high and low, which I wasn't taking into account. Sure enough, it would seem that MMC5 for example connects to VRAM /CE, but CHR /A13 doesn't connect to the mapper. Obviously it's inverting A13 on its own to control VRAM /CE. This completely throws out what I was blabbering about, because intercepting/overriding CHR /A13 myself would be pointless on such a cartridge.
But something else you said possibly put me on the right path, about tri-stating the data lines themselves. I wouldn't even have to bother working out a bunch of logic to disable the CHR rom as well as any onboard vram it has; I can just sever any communication it attempts to have from reaching the NES. But I think to do so, a '245 transceiver might work best, which I happen to have already. It'd just take the one chip, using the CHR R/W line to toggle its direction. I could tri-state the thing and activate the NES internal vram, and shouldn't have to worry about any chip enable types of conflicts that might arise from doing it the other convoluted way, since even when CHR chips and/or ram get activated, their data won't make it back to the NES.
The only downside here is that I have to actually separate all 8 data lines to sit as the go-between, as opposed to my last plan which only required separating 2-3. X_X
I may have lost everyone again, but I'll put some thinking on all of this and see if it'll work out like I'm figuring it would.
I've got all that worked out now, I believe.
I'm curious though; the only way for a cartridge to determine whether an attempt to access WRAM has taken place is by using O2 and PRG /CE, right? I won't go into another drawn-out explanation of what I want to do and the other ways I'm working around it, but I was thinking that as long as the clock was low going into the cart, the mapper (or any other hardware a cart used) would never be able to determine when the NES was trying to access the lower 32K of address space.
FyberOptic wrote:
I'm curious though; the only way for a cartridge to determine whether an attempt to access WRAM has taken place is by using O2 and PRG /CE, right?
It needs to use A13 and A14 too. All 4 of those signals would be high during a WRAM access.
Well true, though I mostly just meant that the only way for it to determine the upper and lower 32K was by using O2 and PRG /CE, since it doesn't have a pure A15 available for the true way of determining. As far as I understand it, you can't base just an inverted PRG /CE on whether it's the lower 32K by itself, since once O2 goes low, all address decoding goes high due to how O2 is connected to the initial address decoder. I just figured that holding O2 low seems like it would prevent the cart from ever enabling WRAM. Holding PRG /CE high at the same time should theoretically prevent the cart from sending back anything else, as well.
This isn't so much a question, but I thought I'd put it here since it's all related, and someone might find it interesting.
For my project here, I knew I was going to need a way to transfer code to the NES often for debugging purposes, since it'll be nearly impossible to test things in an emulator due to custom hardware. And where better to transfer data than the NES controller port, right?. Though I had only heard of people using it for replaying keystrokes, and not for any actual "useful" purpose (as far as I've seen, anyway), leaving me with no real idea if it'd be practical. The keystroke player also required some extra hardware, since the parallel port isn't fast enough to keep up with the data clock pulses, it would seem, from my own experiments.
Well, after a lot of wasted time debugging my code, only to find I had an "AND" in place of an "ORA", I successfully managed to transfer a byte of data to the NES via the PC parallel port, without using any hardware in between. I don't have any spare controller cables (or even a second controller for that matter), but I used the plug off of a spare controller socket I had, and strung some speaker wire between it and a DB-25 connector. It's not really anything spectacular to see so I won't bother taking pictures this time. But basically it's a 2-bit data connection, using the third data line along with the latch line to maintain a flow control. I'm also using controller port 2, so that the system's actually still usable.
The first test was displaying the transferred byte on the screen in hex, to verify it's even getting the right byte. I then updated my PC-side code to increment it after each byte transfer, which made it count upwards on the NES just fine, showing that it seems to be a reliable connection. I updated the PC-side code again to track my transfer rate, but since I was waiting for a refresh to display each data byte on the screen, the cps was only about 55 bytes/second. That's pretty awful.
So I decided to remove the screen updatery and just do a pure transfer.
The results were much more pleasant. I admit I was impressed to get 4kB/s, which is a fine speed considering the method involved, and is more than fast enough for my needs.
Anyhoo, I don't know if anyone else has ever experimented with transferring data like that, which is why I thought I'd post about it. My next test will involve altering one of my NROM-to-UNROM patches to transfer the whole 8kB of CHR data from the PC instead of getting it from the eeprom. I can't think of any real reason why it wouldn't work properly, but it'll just be a fun experiment nonetheless.
I tried coding a receive routine below to see what the maximum data rate might be. I assumed that the wait loop would run two iterations each time, so the NES has a little slack. I get 225 cycles to transfer one byte, resulting in about 8KB/sec maximum. I expected things to be a little more streamlined with a 2-bit interface, since this isn't much higher than the 5.8KB/sec I get over a software-based RS-232 version I use. I'm realizing that having to acknowledge each bit pair adds a fair amount of overhead, where the serial can just delay by a fixed time. Have you considered using RS-232, which has the advantage of not needing any special PC drivers? I bet you could do it without a MAX-232 level convertor chip if you just want a one-way connection from the PC to the NES. Here's the (definitely not optimized) code I came up with, with instruction cycle counts listed in the comments:
Code:
page_loop:
lda #$00 ; 2
sta temp ; 3
ldx #4 ; 2
loop:
lda #$XX ; 2
wait:
bit $4017 ; 4 wait for latch
beq wait ; 3
; -1
lda #$XX ; 2 clear latch
sta $4016 ; 4
lda #$XX ; 2
sta $4016 ; 4
lda $4017 ; 4 read two bits of data
and #$18 ; 2
ora temp ; 3 insert into buffer
asl ; 2
adc #0 ; 2
asl ; 2
adc #0 ; 2
sta temp ; 3
dex ; 2
bne loop ; 3
; -1
sta (addr),y ; 6
iny ; 2
bne page_loop ; 3
I once did a serial connection with a PIC by using manual timing, but it wasn't the most reliable. I don't think I know enough about the timings of the instructions per clock and such of the 6502 to try and do it, though.
If my math is right, 1.7897725mhz of the cpu should mean about 558ns per clock, I think. If I look at
an opcode reference, which says an immediate mode ADC takes 2 of "time", would this be direct clock cycles? As in, that ADC would take about 1.116us?
If I tweak my parallel port code I might could squeeze some more speed out, since it's not very optimized, and I think I might actually be doing an unneccessary extra bit of waiting at one point. But I like the idea of actually triggering each bit transfer so that none get missed, despite a little bit of overhead. Though if I could write an absolutely reliable serial protocol without using hardware, and just use a normal terminal app, that'd be pretty handy.
Right, ADC #immediate adds two ~1.79 MHz clocks to the total execution time. Just now I coded up 115.2kbps serial and it's working well on a 6KB random test data set. I found that using 2 stop bits gives a little more breathing room in the receive code. The 57.6kbps routines I've been using have been reliable for a couple of years now, and the loader that uses them does a checksum verification after every complete transfer. I'd like to help if you're going to make a serial-based devcart. I'm really happy with mine.
Can one be made with a USB to serial adapter chip? Such chips are likely to run at 5V (just like USB itself) and thus not need a level shifter. With the 9-pin RS232 being eliminated from newer mainboards (and already gone from Macs for a decade), this might be important in the future.
tepples wrote:
Can one be made with a USB to serial adapter chip? Such chips are likely to run at 5V (just like USB itself) and thus not need a level shifter.
They probably still have a small
charge-pump convertor to generate +/- 12V, as the standard MAX-232 does. For just receiving, a resistor or zener diode might suffice to convert the signal to something usable by the NES.
The main problem with software-based serial is the lack of flow control. If the NES needs the PC to wait at all, it'd need to be implemented using custom code on the PC side. The main advantage of serial is that no low-level PC programming is needed, just standard serial writes and reads. I've got a self-contained USB-to-serial adaptor that I still haven't tested with my NES, though I'm fairly sure it'll work.
I remember from my PIC projects that my PC's serial port wouldn't work with standard TTL voltages, though my laptop would. So seeing as how most of my work is on my desktop machine (since it's the better of the two), I'd probably want a MAX-232 in the mix if I were going to use serial. It's certainly an option for the more permanent connection I'll implement later; either that, or an actual full 8-bit parallel connection. But for my initial debugging to get the hardware going, I'll probably have to stick to my controller port.
Speaking of the hardware though, time for another question. It turns out I'm needing more logic than I had hoped. The board is going to have some onboard SRAM for PRG and CHR, as well as an EEPROM to get things started up. But it's also going to use about 15 standard 'LS logic chips of various sorts, primarily ORs and ANDs, then a couple inverters, a buffer, latch, address decoders, etc. I suddenly had the realization that I might in fact have a power issue here. I'll be drawing most of my connections from the cartridge connector, for the record. But the thing is, a cartridge will still be insertable too, which will drain even more power.
So the biggest question is, would the power consumption be too much? At the very least, it seems I might need some capacitors on the board I'm making to avoid fluctuations in power. I'm not sure really what sizes to use, so I'll probably try whatever I have on hand unless somebody has any suggestions. Hopefully I didn't bite off more than I (or the NES) can chew when I started designing all of this!
EDIT: I figured I'd add the prototype layout picture I took (so I wouldn't forget how I wanted things). The actual chips in there are just placeholders, as is the socket in place of where the top SRAM will go. I'll socket everything though I reckon, to avoid any damage to the chips. Not all those sockets on the board might get used, mind you, they're just there in case I want to add something in.
Well it's always recommended you should have 100nF bypass capacitors on each IC operating at high speeds to smooth transients, it also would be smart to have a 47uF or 100uF cap in parallel with those to reduce ripple.
If you're going to allow another cartridge to be inserted, you may be pushing the limits of the voltage regulator/your power adapter. I believe the cart is normally allowed 200-300mA, your board will be fine but I'm not so sure about the cartridge which plugs in if it's a MMC5. Make sure you use LS logic, LP SRAM and ROMs which are LP when inactive which should be all EEPROM.
I was under the beliving that LS logic would consume more current than HC logic ?
Anyway you could use your own power supply to preven overloading the one inside the NES.
Using my own supply was a consideration if absolutely necessary, but obviously I'd rather try to avoid it.
I can't find the datasheet for the old SRAMs I'm using; they're cache ones from some 486 motherboard. UM61M256K-15. The closest I found was
someone in a newsgroup linking to a different model but probably similar chip. If that one is anything like the ones I'm using though, it means I'll be sucking up over 100ma when the chip is active (assuming my SRAM is similar to the one in that datasheet). My EEPROM, on the other hand, will apparently only need 25ma when active. Cache SRAM is obviously not designed for low power consumption. But do they even make the narrow DIP sizes in low power versions? I'd hate to go to two normal wide DIPs.
As far as power consumption goes, the EEPROM and onboard PRG SRAM won't be chip-enabled unless they're trying to be used, so at least those won't be trying to draw power at the same time. The cartridge PRG *should* be completely disabled at those times as well because of how I'll force O2 low and PRG /CE high. And whenever the cart PRG is activated again, the EEPROM and onboard SRAM of course won't be.
My onboard CHR SRAM however will be chip-enabled as long as the option to use it is toggled on. I'm not sure how much power it consumes in this mode though as opposed to when actually reading or writing data. I suppose it probably draws about the same, as long as its enabled.
I don't really know any way around keeping the CHR SRAM active full-time like that. It'll fill the "standard" 10kB address range (supporting mirroring instead of using a full 12kB), meaning I'll be holding the CIRAM /CE high to prevent it from activating while the CHR SRAM is enabled. I'll also hold the /RD and /WR lines going into the cartridge high to prevent them from sending back anything. But this probably means the cartridge CHR ROM/RAM will be enabled, since A13 is usually tied straight into their /CE. I suppose I could force CHR A13 going into the cart high as well, but if the cart happened to have its own 4k of nametable ram, that'd get enabled instead. So as I said, I'm not sure a fullproof way around keeping the CHR side of things from all being powered up.
Either way, when those two SRAMs go active at the same time, I'm going to be drawing a couple hundred milliamps. I haven't figured up how much the logic chips themselves will use, and have no idea how much mappers use, but I think I'm going to be pushing it.
Bregalad wrote:
I was under the beliving that LS logic would consume more current than HC logic ?
Anyway you could use your own power supply to preven overloading the one inside the NES.
CMOS' consumption is proportional to it's speed; for very slow speeds CMOS is more efficient, but at >1MHz, it starts to consume more than TTL.
I've only seen LP SRAM in full size, the easiest to find are PDIP from scrap game carts.
Just out of pure curiosity, if a person added in a second 7805 regulator, tying it into the 9v coming from the adapter (wiring it right off the legs of the 7805 in the NES already, since they're easy to get to), would that allow for another few hundred more milliamps for other use? I mean the NES wants an 850ma ac adapter, but as far as I know, an '05 is only rated for 500ma. I'm no genius with this sort of thing so there might be some other consideration, but I thought I'd throw that out there as a possibility, especially since the adapter I'm using for my NES is 1000ma.
EDIT: I don't mean to up the overall milliamps going into the NES, btw, I mean use a seperate '05 to power my own components. I thought I should clarify that since apparently using two to up the current of a circuit has been done before, though it's not the best way of doing it.
7805 are rated for either 1A or 1.5A. The system itself uses between 500 and 600mA. If you have a 1A 9V adapter, sure you can put on another 7805 for a little more current, I don't know if it's worth it though. Maybe you should replace the default BJT regulator in the NES with a better 3A switching one which will let you make the most of a power adapter.
I think the main problem with 7705 regultaor isn't the load current, but how much they overheight. Without any heat sink, they cannot drive more than one hundred of miliamps without overheating.
The one inside the NES is solidify fixed to the metal shield, who seem to be quite accurate for heat power dissipation.
You said puting a second 7705 in parallel or just putting another power supply in you other post ? One other is parallel should work fine, but it would just share the power dissipation between both chips I think. That'd be pretty innacurate, if you need to do something just make your external power supply.
Just to clarify you can't safely put the 7805 outputs in parallel but you can put the inputs/gnd in parallel.
I decided that for the initial model, I'd just not use the SRAMs on my board at all, since the original concept didn't involve those anyway. That aspect evolved out of my "just one more little thing" tendency, which added unnecessary complexity considering I've never made such a thing before. I'm down to just the EEPROM and 11 misc chips, which should hopefully be fine for running on the NES's internal power. But I still have the design for the more elaborate version; maybe it'll be the Mark II. hehe.
The thing I want to know, though, is does anyone know of a decent way to remove the inner sets of pins from the cartridge connector? Getting the outer ones out is pretty easy, since you can slip'em out from the back, and have some leverage to work with. But them inner ones only want to bend no matter what I do. And I can't release the little notches holding'em in place, even using a needle from the inside. I mean I can solder to and cut the ones I need from where they are, I guess, but it'd sure be a lot easier if I could do it outside the plastic connector.
